Jonathan Underwood [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-27 📝 Original message:I see what you mean. What ...
📅 Original date posted:2019-06-27
📝 Original message: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 <dp at simplexum.com>:
> 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 <junderwood at bitcoinbank.co.jp> 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 <dp at simplexum.com>:
> >
> > > 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
> > > <bitcoin-dev at lists.linuxfoundation.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/30b46b5a/attachment-0001.html>;
📝 Original message: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 <dp at simplexum.com>:
> 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 <junderwood at bitcoinbank.co.jp> 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 <dp at simplexum.com>:
> >
> > > 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
> > > <bitcoin-dev at lists.linuxfoundation.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/30b46b5a/attachment-0001.html>;