Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)
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
[bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Taproot proposal
I have a comment about the 'input_index' of the transaction digest for taproot signatures. It is currently listed as 2 bytes. I think it would be better to expand that to 4 bytes. The two byte limit is derived from the block size / weight limit, which limits the maximum size of a transaction, which in turn, due to a minimum size of an inputs, places a limit on the maximum number of inputs. However, I think it is a mistake to mix limits from the block layer into the transaction layer of the consensus rules. For example, I believe that, as it stands currently, if we wanted to hardfork an increase in the block weight limit, doing so wouldn't have any impact on the transaction layer and we could transparently manage larger transactions with the current transaction format [2]. However if we start incorporating the block limits into the transaction layer, then we run the risk of such a hard fork needing to also make consensus changes in the transaction format/interpretation if we wanted to handle larger transaction sizes, which, while doable, wouldn't be so great. The current transaction format limits the number of inputs (and the number of outputs) to 2^32-1 or less [1]. So using 4 bytes for the 'input_index' will suffice. Given that adding 2 bytes to the signed transaction digest isn't a big deal, it's probably better just to keep block limits and transaction limits separate. [1]The var-integer field for the number of inputs (and the number of outputs) in a transaction looks like it should allow upto 2^64-1 inputs; however this is an illusion. The P2P rules dictate that these values are immediately taken modulo 2^32 after decoding. For example, if the number of inputs is a var-integer encoding of 0x010001, it is actually just a non-canonical way of encoding that there is 1 input. Try this at home! [2]If we were to hardfork an increase in the block weight limit, we would probably want to still keep the limit on the size of transactions that consume legacy UTXOs in order to avoid the quadratic computation problems that plagues the legacy transaction digest. On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello everyone, > > Here are two BIP drafts that specify a proposal for a Taproot > softfork. A number of ideas are included: > > * Taproot to make all outputs and cooperative spends indistinguishable > from eachother. > * Merkle branches to hide the unexecuted branches in scripts. > * Schnorr signatures enable wallet software to use key > aggregation/thresholds within one input. > * Improvements to the signature hashing algorithm (including signing > all input amounts). > * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support > batch validation. > * Tagged hashing for domain separation (avoiding issues like > CVE-2012-2459 in Merkle trees). > * Extensibility through leaf versions, OP_SUCCESS opcodes, and > upgradable pubkey types. > > The BIP drafts can be found here: > * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki > specifies the transaction input spending rules. > * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki > specifies the changes to Script inside such spends. > * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki > is the Schnorr signature proposal that was discussed earlier on this > list (See > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html > ) > > An initial reference implementation of the consensus changes, plus > preliminary construction/signing tests in the Python framework can be > found on https://github.com/sipa/bitcoin/commits/taproot. All > together, excluding the Schnorr signature module in libsecp256k1, the > consensus changes are around 520 LoC. > > While many other ideas exist, not everything is incorporated. This > includes several ideas that can be implemented separately without loss > of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT, > which we're working on as an independent proposal. > > The document explains basic wallet operations, such as constructing > outputs and signing. However, a wide variety of more complex > constructions exist. Standardizing these is useful, but out of scope > for now. It is likely also desirable to define extensions to PSBT > (BIP174) for interacting with Taproot. That too is not included here. > > Cheers, > > -- > Pieter > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
