There is no need, as you can look at the number of xpubs and use that as n. Your wallet will not allow {m=2}{xpub1}{xpub2} signed message to vouch for 2 of 4 because you signed 2 of 2 where the n is shown by the number of xpubs signed. There is no need to add the extra byte, except maybe to help people who are implementing a wallet checking some features to remember to check for the number of total keys. ---- The expire / revoke problem is a larger problem than this feature can handle. In general, if one of the cold keys is stolen, there is rarely a situation where you are completely sure the other cold keys haven't been compromised... so the best practice would be all signers generate new keys and all funds are moved to a completely new multisig wallet (no common xpubs). - Jonathan 2019年6月27日(木) 18:20 Dmitry Petukhov : > You're right re order of the keys, I forgot that redeem/witness > scripts are included in outputs. > > But regarding the number of the keys, you need to always include all of > xpubs, because otherwise, if you only put `m` in PSBT, and you use > 2of3, for example, attacker may put 2 as `m`, two of your xpubs, but > then use redeem/witness scripts for 2of4, where two other keys are > under attacker's control. > > If you only encode `n`, and allow any 'm of n' scheme, then in 2of3 > case, if the attackers have control of only one of the keys, they can > use redeem/witness scripts for 1of3, where two other keys are under > their control. > > It seems to me that you need to sign the whole configuration: > `n`, `m`, and the xpubs. > > And then there's a question of how to conveniently `expire` the keys > that were compromized. If the attackers have a signature of > `n+n+xpubs` package for some configuration that include the keys that > was compromized, they can use that old signed package to fool the > signer. > > Signer would need to somehow distinguish between old and new > configurations, or you would need to change the keys in all the signers > even if one is compromized, so the already-signed packages would become > invalid. > > You could do without changing all the keys when only one is compromized > by including a serial number in the xpub package (but that means signer > will need to have a state where it would store the latest serial > number), or you need some message to be included in the package that a > human can check when manually signing, to ensure that 'obsolete' xpub > package was not used. > > В Thu, 27 Jun 2019 17:56:06 +0900 > Jonathan Underwood wrote: > > > The output will have redeemscript and witnessscript so order is not > > necessary. I can just look at the multisig script and find the pubkey > > inside it. > > > > -Jonathan > > > > 2019年6月27日(木) 17:45 Dmitry Petukhov : > > > > > > m value for a multisig (set 0 for non-multisig), followed by 1 or > > > > more 78 byte serialized extended public keys sorted in canonical > > > > order > > > > > > Sorting xpubs would work if the addresses also sort their pubkeys > > > (like in BIP67) > > > > > > But if the pubkey order in address creation is fixed, you better > > > have the fixed order for xpubs, otherwise you would need to try all > > > combinations of derived pubkeys when checking if the addresss match > > > the presented xpubs. That would be factorial of the number of keys, > > > not feasible beyond very small number of keys. > > > > > > Bitcoin Core, for example, currently does not support BIP67 and > > > supports only fixed pubkey positions in their script descriptors > > > specification. > > > > > > You also need to include all xpubs to match the address, for m of n > > > standard multisig, you need to include n and check that number of > > > keys is exactly n. > > > > > > Otherwise your would not be able to construct the address to > > > compare to the destination address that you need to check, as you > > > need all pubkesy to construct P2SH or P2WSH address. > > > > > > With Shnorr-musig, you probably can interpolate the combined pubkey > > > out of m paticpant pubkeys (but don't cite me on this, I might be > > > wrong) > > > > > > В Thu, 27 Jun 2019 17:16:14 +0900 > > > Jonathan Underwood wrote: > > > > > > > I see what you mean. > > > > > > > > What about this? > > > > > > > > https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=82656c8#diff-82656c833e31e6751a412ce5e5c70920 > > > > > > > > > Plus side: for single sig case, the key only increases by one byte > > > > (0x00 for the {m} value) > > > > > > > > This way if it was 2 of 3 like before, you sign the whole > > > > "packet" so each key only signs the packet once. Way better than > > > > n! > > > > > > > > Anywho. Please send your feedback. Thanks. > > > > Jonathan > > > > > > > > 2019年6月27日(木) 16:27 Dmitry Petukhov : > > > > > > > > > How would signer know that there _should_ be at least 3 > > > > > signatures signed by the key owned by this signer ? > > > > > > > > > > If it does not know that it should enforce 2of3 multisig, for > > > > > example, the attacker that control only one key A can fool > > > > > signer B by sending to 1of1 single-sig that is derived from A's > > > > > xpub, and providing only sBxA in PSBT. > > > > > > > > > > If the signer does not have a hardcoded configuration that > > > > > will mandate a particular multisig scheme, it will allow > > > > > sending to any scheme. > > > > > > > > > > If the signer has a rich enough state to store updatable > > > > > configuration, it can just store the trusted xpubs directly. > > > > > > > > > > Alternatively, signer can sign not individual xpubs, but whole > > > > > xpub packages that correspond to particular multisig > > > > > configuration, and enforce that destination addresses > > > > > correspond to this configuration. > > > > > > > > > > But this would not be possible with your PSBT scheme that uses > > > > > individual key-xpub pairs. > > > > > > > > > > В Thu, 27 Jun 2019 14:07:47 +0900 > > > > > Jonathan Underwood wrote: > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > The way we would do it is: > > > > > > > > > > > > Let's say we have 3 cold keys for multisig: A B and C > > > > > > > > > > > > Whose xpubs are: xA xB and xC > > > > > > > > > > > > We all sign each other's xpubs, whose signatures are: > > > > > > sAxB > > > > > > sAxC > > > > > > sBxA > > > > > > sBxC > > > > > > sCxA > > > > > > sCxB > > > > > > > > > > > > We can then create a wallet that says "when verifying change > > > > > > with 0x01 global type proposed by Andrew Chow, if the change > > > > > > is multisig, we MUST require the other pubkeys to have > > > > > > signatures via my 0x02 proposal" > > > > > > > > > > > > This way, all my PSBTs for my cold will have: > > > > > > 1. an 0x01 entry to tell me how to get my change. > > > > > > 2. All 6 of the signatures above. > > > > > > > > > > > > And the signer will then look at the change, check my pubkey > > > > > > by deriving the xpub and checking equality to the > > > > > > BIP_DERIVATION of the output... it will then check the OTHER > > > > > > pubkeys via BIP32_DERIVATION to master fingerprint, then link > > > > > > that fingerprint to a 0x02 sig from MY key, verifying all > > > > > > pubkeys. > > > > > > > > > > > > So this proposal of mine would not only fix the "send to > > > > > > address verification" problem for HD, but also the multisig > > > > > > change problem with 0x01. > > > > > > > > > > > > Cool. > > > > > > > > > > > > Only thing that is kind of sad is having to include n! (of > > > > > > m-of-n) signatures in every PSBT... but tbh, the PSBT size is > > > > > > not of much concern. > > > > > > > > > > > > Thanks for the reply. > > > > > > - Jonathan > > > > > > > > > > > > > > > > > > 2019年6月27日(木) 13:49 Dmitry Petukhov : > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > I wonder how your scheme handles multisig ? > > > > > > > > > > > > > > As I understand, you sign individual xpubs with cold keys, > > > > > > > so that cold keys can check destination addresses are > > > > > > > trusted. > > > > > > > > > > > > > > I seems to me that if you sign individual xpubs of a > > > > > > > multisig warm wallet, and one key from that multisig is > > > > > > > compromized, attackers can then create a single-sig > > > > > > > destination address that they control, and move the coins > > > > > > > in a chain of two transactions, first to this single-sig > > > > > > > address, and then to an address that they independently > > > > > > > control. > > > > > > > > > > > > > > My idea to prevent this [1] is to sign the whole 'xpub > > > > > > > package' of the multisig wallet, but there is also an issue > > > > > > > of 'partial compromize', where some of the keys in a > > > > > > > multisig warm wallet is compromized, and you do not want to > > > > > > > regard a particular 'xpub package' as trusted. My idea was > > > > > > > [2] to use an auxiliary message that would be signed along > > > > > > > with the 'xpub package', and that message can include > > > > > > > specific 'epoch' word that hardware wallet can show > > > > > > > prominently before signing, or have 'serial number' for > > > > > > > xpub packages (but that will require to store last known > > > > > > > serial inside hw wallet, making it stateful). > > > > > > > > > > > > > > I like the idea to extend PSBT to accomodate these schemes, > > > > > > > but given that the huge number of possible schemes that > > > > > > > each may probably require its own PSBT field type, I think > > > > > > > that this is better dealt with outside of PSBT, as 'PSBT > > > > > > > metainformation', or using some form of 'vendor-specific', > > > > > > > or 'metainformation-specific' PSBT field. This way each > > > > > > > usecase can be independently described in its own > > > > > > > documentation, that would include the particulars of the > > > > > > > format for the metainformation. This would also make it > > > > > > > easier to implement PSBT for simple cases, because the > > > > > > > 'core specification' would not grow that big. > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html > > > > > > > > > > > > > > > > > [2] > > > > > > > > > > > > > > > > > > > > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html > > > > > > > > > > > > > > > > > > > > > > > > В Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via > > > > > > > bitcoin-dev wrote: > > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > > > Just wanted to pick your brains about an idea for PSBT > > > > > > > > extension. > > > > > > > > > > > > > > > > One problem we try to solve with cold -> warm and warm -> > > > > > > > > hot sends for our exchange wallet is "How do I know that > > > > > > > > the address I am sending to is not a hacker's address > > > > > > > > that was swapped in between unsigned tx creation and > > > > > > > > first signature?" > > > > > > > > > > > > > > > > We have a proprietary JSON based encoding system which we > > > > > > > > are looking to move towards PSBT, but PSBT is missing > > > > > > > > this key functionality. > > > > > > > > > > > > > > > > BIP32_DERIVATION does allow us to verify the address is > > > > > > > > from a certain XPUB, but, for example, it can not allow > > > > > > > > us to verify a signature of that xpub. > > > > > > > > > > > > > > > > I have made a rough draft of the proposed key value > > > > > > > > specification. > > > > > > > > > > > > > > > > https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification > > > > > > > > > > > > > > > > > > > > > > The signing key path used in the spec is just randomly > > > > > > > > chosen 31 x 4 bits shown as numbers with hardened paths. > > > > > > > > > > > > > > > > Since this issue seems similar to the change address > > > > > > > > issue, I started from that as a base. With the HW wallet > > > > > > > > case, I can verify the xpub by just deriving it locally > > > > > > > > and comparing equality, however, in our case, we need to > > > > > > > > verify an xpub that we do not have access to via > > > > > > > > derivation from our cold key(s) (since we don't want to > > > > > > > > import our warm private key into our cold signer) > > > > > > > > > > > > > > > > So the flow would be: > > > > > > > > 1. Securely verify the xpub of the warm / hot wallet. > > > > > > > > 2. Using the airgap signing tool, sign the xpub with all > > > > > > > > cold keys. 3. Upload the signature/xpub pairs to the > > > > > > > > online unsigned transaction generator. > > > > > > > > 4. Include one keyval pair per coldkey/xpub pairing. > > > > > > > > 5. When offline signing, if the wallet detects there is a > > > > > > > > global keyval XPUB_SIGNATURE with its pubkey in the key, > > > > > > > > it must verify that all outputs have BIP32_DERIVATION and > > > > > > > > that it can verify the outputs through the derivation, to > > > > > > > > the xpub, and to the signature. > > > > > > > > > > > > > > > > In my attempt to fitting this into PSBT, I am slightly > > > > > > > > altering our current system, so don't take this as an > > > > > > > > indication 100% of how we work in the backend. > > > > > > > > > > > > > > > > However, I would like to hear any feedback on this > > > > > > > > proposal. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Jonathan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- ----------------- Jonathan Underwood ビットバンク社 チーフビットコインオフィサー ----------------- 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3