Adding Type code for Descriptor

[pythcoiner]

As descriptor need to be share between wallets/coordinators and airgapped signers in miniscript setups, it should be useful to have a Type for standalone descriptor, at least used at the initial descriptor registration step.

[nvk]

// Bringing from twitter here.

NVK: Not sure if worth putting that there, might be more suitable for native QR or U type. But could definitely use some thinking.

@pythcoiner: Having a strong typing there can avoid every wallet/signer team to wrap it by its own way in a json. Btw GH is a better place to discuss about that, i'd open an issue about this point, see you there.

[doc-hex]

I'm not against this. Could you @pythcoiner write up a few sentences that could be added to the spec? Just drop them here, no need for a PR.

[pythcoiner]

I'm not against this. Could you @pythcoiner write up a few sentences that could be added to the spec? Just drop them here, no need for a PR.

will take time to do this

[pythcoiner]

cc @seedhammer

[seedhammer]

Thank you for the ping, @pythcoiner.

An output descriptor type code is a good idea for standardization, but allow me to make the case for postponing its specification: we believe something like our proposal, a "PSBT for descriptors" format, is better suited than the plain BIP380 textual descriptor implied by this issue.

Details and from-scratch implementation are at the link, but here's the highlight:

• Same simple binary format as PSBT.
• Compact xpubs using the PSBT_GLOBAL_XPUB format instead of the inefficient base58.
• Like wallet-policies, keys are (always) separate from the descriptor itself, allowing a key to appear multiple times in the descriptor (with different derivation paths).
• Supports metadata for the descriptor and for the keys. Our proposal includes the descriptor label and birth block.
• Compatible with the BIP380-386 + BIP389 textual formats.
• Miniscript compatible, with the restriction that key references must be by index.

Here's a sample of a 2-of-3 threshold descriptor with 3 key references:

wsh(sortedmulti(2,@0/<0;1>/*,@1/<0;1>/*,@2/<0;1>/*))

Playground: https://go.dev/play/p/nouZlbbcEWt

The proposal is pending consensus from wallet developers and Blockchain Commons. Once ready, we plan to push for BIP standardization and broad consensus among wallet implementation. Outstanding issues include: PSBT vs CBOR, should the format be a PSBT extension or have a separate header.

[nvk]

An output descriptor type code is a good idea for standardization, but allow me to make the case for postponing its specification: we believe something like BlockchainCommons/Research#135, a "PSBT for descriptors" format, is better suited than the plain BIP380 textual descriptor implied by this issue.

Was this sent to the bitcoin-dev mailing list? I think I missed it. A "PSBT" for Miniscript sounds like a great idea, very curious on Andrew Chow's comments (original PSBT author) and now general Core maintainer.

[seedhammer]

An output descriptor type code is a good idea for standardization, but allow me to make the case for postponing its specification: we believe something like BlockchainCommons/Research#135, a "PSBT for descriptors" format, is better suited than the plain BIP380 textual descriptor implied by this issue.

Was this sent to the bitcoin-dev mailing list? I think I missed it. A "PSBT" for Miniscript sounds like a great idea, very curious on Andrew Chow's comments (original PSBT author) and now general Core maintainer.

I hadn't posted the proposal to bitcoin-dev, but prompted by your question I just did. [EDIT] Pending moderation.

[nvk]

I don't know much about BC, but often the best place for Bitcoin standards is the IRC and the mailing list, that's where most of the existing large install base software maintainers keep track of new cool things.

[seedhammer]

Was this sent to the bitcoin-dev mailing list? I think I missed it. A "PSBT" for Miniscript sounds like a great idea, very curious on Andrew Chow's comments (original PSBT author) and now general Core maintainer.

I hadn't posted the proposal to bitcoin-dev, but prompted by your question I just did.

In my post I asked whether extending PSBT itself would be better than a new format. A response supports that idea:

I think the goal of such a format should be that it is already a valid
PSBT, or can be trivially converted into one. Ideally, a coordinating
device can load the standardized descriptor file, add inputs (PSBTv2) or
unsigned TX (PSBTv1), and send it to compatible signing devices without
further modification.

For this issue, I believe such a PSBT extension would alleviate the need for a separate type code for descriptors.

[nvk]

Was this sent to the bitcoin-dev mailing list? I think I missed it. A "PSBT" for Miniscript sounds like a great idea, very curious on Andrew Chow's comments (original PSBT author) and now general Core maintainer.

I hadn't posted the proposal to bitcoin-dev, but prompted by your question I just did.

In my post I asked whether extending PSBT itself would be better than a new format. A response supports that idea:

I think the goal of such a format should be that it is already a valid
PSBT, or can be trivially converted into one. Ideally, a coordinating
device can load the standardized descriptor file, add inputs (PSBTv2) or
unsigned TX (PSBTv1), and send it to compatible signing devices without
further modification.

For this issue, I believe such a PSBT extension would alleviate the need for a separate type code for descriptors.

I saw the reply, this would save yet another type :)

[seedhammer]

As per BlockchainCommons/Research#135 (comment) we're going to propose a PSBT extension BIP for output descriptors.

[seedhammer]

For those following along, here's the first draft: https://github.com/seedhammer/bips/blob/master/bip-psbt-descriptors.mediawiki.

[seedhammer]

The author of the PSBT file format wasn't impressed: bitcoin/bips#1548 (comment), which leaves all options open for this issue. I'll eventually circle around to a non-PSTB encoding if no-one else beats me to it, but otherwise any reasonable efficient format that encodes, say, BIP388 would be great. In particular, I hope to avoid base58 encoded extended keys. The format could even be bitcoin/bips#1548 with a different header (and BBQr type code); it has efficient extended keys and metadata such as wallet name and birthblock.

[pythcoiner]

getting back on this lately, i plan start working on QR codes implem for Coldcard Q on Liana, i'm wondering if there is already a way to import a descriptor by QRCode on the Q?
if not, do you guys thinking more about passing a 'raw' descriptor or using BIP388 format?
@nvk @scgbckbone @doc-hex

[scgbckbone]

if there is already a way to import a descriptor by QRCode on the Q?

yes, you can import "bare" multisig BIP-380 descriptors (works also for miniscript in EDGE firmware)

[pythcoiner]

do you think a descriptor type in BBQR should be BIP380 or BIP388 descriptor? or boths?

[scgbckbone]

wrt BBQr you can encode whatever you pleased - no prob doing both. COLDCARD only works with BIP380 output descriptors.