Handle compatibility w/ airgapped QRCode communicant wallet #539
Comments
|
my first draft implementation of miniscript workflow on seedsigner is available here, the flow can be summarized as: graph TB
classDef user fill:#3c3d3e, color:#fff;
classDef test fill:#46d367, color:#000;
classDef signer fill:#7fd310, color:#000;
classDef wallet fill:#ffaa7f, color:#000;
L1(user action)
L1:::user
L2(wallet action)
L2:::wallet
L3(signer action)
L3:::signer
L4{signer\nlogic}
L4:::test
L5[signer display]
graph TB
classDef user fill:#3c3d3e, color:#fff;
classDef test fill:#46d367, color:#000;
classDef signer fill:#7fd310, color:#000;
classDef wallet fill:#ffaa7f, color:#000;
W0(Display descriptor QR)
W0:::wallet -->
S0(Scan descriptor)
S0:::signer -->
S1{has PoR?}
S1:::test
S1 -- yes --> S10[Check policy alias] -- ACK --> S11
S1 -- no --> S20[Check policy] -->
U21(User control policy)
U21:::user -- ACK -->
S22[Save?] -- save --> S210[Display descriptor + PoR QRCode]
S210 --> W00(Scan descriptor + PoR)
W00:::wallet --> W000(store PoR)
W000:::wallet
S22 -- continue --> S11[Scan PSBT]
S210 -- continue --> S11 -->
W12(Display PSBT QR)
W12:::wallet -->
S13(Scan PSBT)
S13:::signer -->
S14[Show PSBT details] -->
U15(check psbt)
U15:::user -- ACK -->
S15(sign PSBT)
S15:::signer -->
S16[Show signed PSBT QR] -->
W17(Scan signed PSBT)
W17:::wallet -- broadcast --> W18(Broadcast)
W18:::wallet
|
|
few remarks:
|
|
after a quick check i found this crate implementing Blockchain Commons UR Types |
|
Thank you very much for the investigative work ! The If i understand correctly
|
|
About the label field, I just left it there because it is used by seedsigner QRCode decoding function to determine that the data are representing a descriptor. I just check to export some wallet descriptors from To To To To To To |
As the descriptor shows in my last post, I think it's cleaner to keep only the |
Yes, that's why I suggest supplying key aliases as a separate table. |
I actually display first the
Right, it's the way I actually follow, the key is needed to check that we have 'control' on at least one xpub prior to building the PoR. |
Actually, if a valid PoR is supplied in QRCode, I just notice the descriptor alias to the user for a check, then label my own spent inputs as 'from me' and outputs as 'to myself'. |
|
Ledger's PoR looks like this: Note that the serialization (and therefore the There might be some other relevant info about the approach in the BIP proposal: https://github.com/bitcoin/bips/blob/bb98f8017a883262e03127ab718514abf4a5e5f9/bip-wallet-policies.mediawiki − although it doesn't quite focus on the registration part. |
En passant: careful with concatenate-and-hash approaches: if you concatenate fields with variable length, it is in general vulnerable to collision attacks. That's solved by length-prefixing anything that is variable length, e.g. for the above: |
Thanks for your quick answer, I already commit to the name (alias) of policy and also thinking about committing to the alias of each key. |
I need to look more into HMAC (I'm not a math nor crypto guy 😅)
Will read it one (many) more time!
Will care about that, thanks to be in our world Salvatore! |
|
I start working on a rust implementation of an encoder/decoder for QRCode data here (only specter format for now, the next step will be to handle UR format), maybe I should turn it into a WIP PR? @darosior @edouardparis |
|
Here are some notes about UR encoding: which might be combined to turn into a PSBT: |
|
Thanks for the information, very interesting! I will try to have a look before the end of the week |
|
We are very interested in standardizing the format and serialization of wallet setups. Because we're engraving descriptors on steel plates, we're particularly interested in compact encodings. Some notes:
To our mind, a (new) standard should:
Ideally, also
Given a serialization, the question of QR encoding is a separate concern. Choosing the Commons UR format is a straightforward choice, because it's already in widespread use.
Indeed, the UR format is quite complex. However, you can avoid a CBOR encoder by encoding the payload as a CBOR binary blob which is just a byte, a length and the payload itself. The fountain encoding part of UR is another complexity; fortunately it's optional and can be ignored (BlueWallet does this). |
|
Hi @pythcoiner. Even if you're not comfortable with CBOR, the UR structures should be quite usable, because they should hide those CBOR details behind the tagged, interoperable UR format. We have a comprehensive set of documents on UR here, and admittedly it leans hard on how the UR converts to CBOR, so maybe we need something that talks about just the UR format? https://developer.blockchaincommons.com/ur/ (Let me know if there's something you think is missing from the docs that would make them more approachable.) We do have a new set of Rust libraries that are in Community Review, which means we're currently taking feedback on not just how they work, but also whether their API is what you expect, and whether they're doing the job you need. The UR library is here: The rest of the stack, and a place for any feedback, is here: |
|
Hi all! I just want to chime in here with some thoughts. IMO, the BC envelope format is pretty simple in its construction and enables a lot of powerful use cases (that go well beyond descriptors too). This video gives a great overview of some of the possibilities: https://www.youtube.com/watch?v=OcnpYqHn8NQ Although the BC envelope standard is not yet widespread, the same would be true of any other new standard we might define. Working with a group like Blockchain Commons to document and manage whatever standard we arrive at is pretty valuable, IMO. The "complexity" of CBOR is mostly hidden behind existing CBOR libraries, but having implemented a subset of CBOR myself previously, the code is pretty straightforward. Implementations are available for all popular languages, though, so nobody needs to write this code, just the code that builds the messages on top of CBOR: The other question raised above is whether descriptors should be encoded as strings or as CBOR or in some other binary format. I'm unsure what the motivation was to deprecate the BC CBOR encoding above, but having a deconstructed binary format does seem valuable vs. a string that has to be parsed. |
|
We've posted a sketch BIP: BlockchainCommons/Research#135. |
|
For everyone interested in joining the discussion, we'll be at the next Gordian Developer community meeting Nov. 1. to present the BIP sketch. |
|
Our BIP proposal is here: https://github.com/seedhammer/bips/blob/master/bip-psbt-descriptors.mediawiki. I'm looking into proof of registration and whether it can be added to the proposal or in another. |
For standardization of proof of registrations, I'm not convinced a symmetric HMAC is the best choice. Some advantages of actual, asymmetric signatures:
|
i think the PoR do not have to be standardized, but the PoR should be an optional field that the software wallet/coordinator can use.
to me the only purpose of the PoR field in our context is to allow the signer to 'outsource' the storage of the PoR in the way to stay stateless. nothing else than the signer have to check the PoR is genuine I guess. If the PoR is valid the signer should only not ask user to review the descriptor.
i don't see any reason to doing that as each PoR is the proof the descriptor have been reviewed for a specific private key context, but maybe I missing something? |
|
btw i'm interested to have @bigspider thought about this BIP proposal |
HMACs (and therefore SLIP-21) are quite easy to implement, much easier than signatures and BIP32 derivations. The running time for BIP32 derivation + signature verification on embedded hardware can be noticeable (tenths of a second), while HMACs ans SLIP-21 are instant even on the weakest hardware. Also, HMAC-256 is only 32 bytes.
Both are true for HMACs, too. More generally, when the signer is also the verifier, there is no difference in cryptographic properties between HMACs and signatures.
Even ignoring the implementation complexity, that would force some non-trivial cooperation (and two rounds of communication) among all cosigners for an action that seems inherently an individual action to me (that is: registering a new wallet on a signing device). |
Some people (e.g. at Unchained Capital, who integrated with them in the context of multisig) did show interest in standardizing the PoR, in order to enable portability across vendors. I think it would be nice in theory, but agreeing on a standard has quite high coordination cost and I'm not sure the benefits in this situation are substantial. Also, I'm not sure everyone would agree with the approach I chose (fully stateless PoR derived from the seed, unrevocable) versus other approaches, for example:
I don't think revocation is very useful in this context, but surely some people will disagree. Note that PoR has no use in software wallets - rather, they just have to store it for the hardware signer precisely to protect them from the software wallet.
+1
There is definitely some shared grounds between this proposal and the work I've been doing and the approach from wallet policies:
However, I'm wary of adding to the PSBT other purposes other than whatever is needed in signing flows. The design space of all the possible signing flows is already very large and mostly not yet standardized. A standard to add descriptors/wallet policies to PSBTs should imho:
Unfortunately, any way of adding descriptors to the PSBT inevitably adds redundancy with the existing PSBT fields, as information is going to be duplicated (e.g. it's present among the PSBT fields, but it could also be deduced from the descriptors); that clashes with the desire of minimizing the PSBTs, which seems crucial for QR-based signing flows. I don't think this redundancy can be avoided without a new PSBT version. |
I mean I don't think the PoR should be standardized in the BIP proposal from @seedhammer IMHO, to be standardized somewhere else I don't have a strong opinion. |
How can a watch-only or coordinator without seeds derive the symmetric SLIP21 keys?
I'm not sure whether it's true in practice, but the idea is that the complexity in implementation and communication rounds is paid during the initial setup of the descriptor among signers anyway.
AFAIK, a MuSig(2) (or FROST) descriptor can be made constant size regardless of number of co-signers. It would be nice that the PoR be constant size as well.
That would be unfortunate, in that we'll lose interoperability among different signer brands. If that's the intent, why not use the PSBT_GLOBAL_PROPRIETARY field? |
my mean your BIP proposal target the as mentioned ealier, in my mind, the PoR is just a way to keep signer btw i'm also interested to have though from @benma, @scgbckbone about PoR, do you have such thing in your miniscript signing workflow? @stepansnigirev, i think the specter DIY is not stateless about the PoR thing, but i'm also interested about you though. @FoundationKen i think miniscript signing is on your roadmap, so interested also by your though. |
The PoR is both created and verified by the signing devices, as both actions require access to the private keys. The software wallets / coordinators only store the PoR. |
The BIP should care about format because of interoperability. If I switch hardware signing device models I shouldn't have to redo the PoR.
Being able to tell the user from the wallet/coordinator UI that a particular descriptor is signed seems like a useful feature to me. |
I think we should have to redo PoR if using key on different HW as some vendor can (maybe) commit to the signer unique id in their PoR calculation process (remember PoR is just prrof that user have rewieved the descriptor) |
I'm interested by the usecase you had in mind? |
Good point, but whatever extra data to commit to can be added to the PSBT key data, no?
I would like to verify the integrity of the descriptor when generating receive addresses. |
what you mean by 'added to the PSBT key'?
in my mind we using Hardware Signers because we assume that our software wallet/ coordinator can be corrupted, if so the corrupted software can display the descriptor as genuine even if not, whatever proof you have.... so user should only trust an adress verified on the Hardware Signer, its less convenient but the only safe way i guess. |
A PSBT map entry contains two values, the key data and the value data. The extra commitment data could be stored in the key data, and the signature itself in the value data.
Using a signer for verifying addresses is a secure way to generate addresses, but has two important downsides: (1) less convenience and (2) temptation to leave the signer in a more exposed location thus increasing the risk of theft. Consider the cold storage wallet that receives much more often than it spends. I argue its safer to generate addresses by having your signed descriptor on, say, a laptop and a phone and always pairwise compare the generated addresses before using them. The descriptor signature ensures that an attacker cannot tamper with the descriptor in transit. |
|
With respect to the complexity of an asymmetric signature, I suppose we can re-use https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki ? |
I open this issue for brainstorm about the optimal workflow for signing with
airgappedwallet using communication overQRCodescanning (Seedsigner/Jade/SpecterDIY/???)I think for now only specter DIY handle
miniscript( but seedsigner also useembitpython library who handle miniscript)An issue also have been open on seedsigner project about that.
I'm interested about your thought about which way to go and which way to not go.
i'm doing some experimentation on a seedsigner, will try to show more about that in few days.
The text was updated successfully, but these errors were encountered: