search

coinkite / BBQr

BBQr: Encodes larger files into a series of QR codes so they can cross air gaps
https://bbqr.org
Other
35 stars 7 forks source link

Adding Type code for Descriptor #1

Open pythcoiner opened 9 months ago

pythcoiner commented 9 months ago

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 commented 9 months ago

// 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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

cc @seedhammer

seedhammer commented 9 months ago

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:

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 commented 9 months ago

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 https://github.com/BlockchainCommons/Research/issues/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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

As per https://github.com/BlockchainCommons/Research/issues/135#issuecomment-1843782094 we're going to propose a PSBT extension BIP for output descriptors.

seedhammer commented 9 months ago

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

seedhammer commented 6 months ago

The author of the PSBT file format wasn't impressed: https://github.com/bitcoin/bips/pull/1548#issuecomment-1919720453, 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 https://github.com/bitcoin/bips/pull/1548 with a different header (and BBQr type code); it has efficient extended keys and metadata such as wallet name and birthblock.

pythcoiner commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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

scgbckbone commented 3 weeks ago

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