[bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3000 bytes --]

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 6005 bytes --]

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@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@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

[-- Attachment #2: Type: text/html, Size: 7639 bytes --]

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 8203 bytes --]

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@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@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@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@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

[-- Attachment #2: Type: text/html, Size: 10986 bytes --]

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 11767 bytes --]

When I say order is not necessary I mean, I won't have to brute force order.

Either way, if we don't sort the xpubs in the key, it would be possible to
create multiple key value pairs for essentially the same group of pubkeys.
"I only want to sign if the multisig is in this order" is pointless.

And like I said, output PSBT includes redeemscript and witnessscript, so my
app can just say "if no redeemscript or witnessscript or BIP32_DERIVATION
for the output, fail"

- Jonathan

2019年6月27日(木) 17:56 Jonathan Underwood <junderwood@bitcoinbank.co.jp>:

> 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 <dp@simplexum.com>:
>
>> > 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 <junderwood@bitcoinbank.co.jp> 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 <dp@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@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@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@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
>


-- 
-----------------
Jonathan Underwood
ビットバンク社 チーフビットコインオフィサー
-----------------

暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3

[-- Attachment #2: Type: text/html, Size: 16307 bytes --]

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 14437 bytes --]

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 <dp@simplexum.com>:

> 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 <junderwood@bitcoinbank.co.jp> 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 <dp@simplexum.com>:
> >
> > > > 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 <junderwood@bitcoinbank.co.jp> 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 <dp@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@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@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@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

[-- Attachment #2: Type: text/html, Size: 20636 bytes --]

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 10256 bytes --]

> By the way, why is this particular path ?

The signing key path used in the spec is just randomly chosen 31 x 4 bits
shown as numbers with hardened paths. Just wanted to make sure it wasn't a
key that people are likely to use for something else.

> It is not clear to me what public key this refers to

I just used the same sentence from the other proposal for 0x01 global tag.
It is kind of confusing, but "can be derived" implies that it is referring
to an xpub, since normal public keys can not "derive children"...

But I could change it if it would be clearer.

2019年6月27日(木) 18:47 Dmitry Petukhov <dp@simplexum.com>:

> " It should be the public key at the highest hardened derivation index
> so that the unhardened child keys used in the transaction can be
> derived."
>
> It is not clear to me what public key this refers to - does this
> refer to 'signing pubkey' ? - then the exact derivation indexes for that
> are given in the value section:
>
>    m/2042083607'/959190427'/1400854130'/990526201'
>
> By the way, why is this particular path ?
>
> В Thu, 27 Jun 2019 17:16:14 +0900
> Jonathan Underwood <junderwood@bitcoinbank.co.jp> 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 <dp@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@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@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@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

[-- Attachment #2: Type: text/html, Size: 14527 bytes --]

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Peter D. Gray]

I haven't studied the new proposal in depth, but my first impression is:

Wouldn't it just be easier and better to just sign the entire "outputs" section of the PSBT?

The signature would cover every byte, and therefore would cover any
future BIP additions to the outputs area, and also help non-multisig
cases today.

---
Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31BAD 5A2A5B10

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Dmitry Petukhov]

Oh, I saw that you covered it in another mail:

> 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).

The setup might not be 'all cold keys', but the keys with different
levels of exposure to possible theft. In this config, compromise of one
of the 'warm' keys might not necessary require changing the 'cold' key.

I'm not sure whether this usecase warrants adding extra 'serial'
field, but on the other hand it is rather simple change, and those who
does not care can always set 0. 

В Thu, 27 Jun 2019 18:14:29 +0500
Dmitry Petukhov <dp@simplexum.com> wrote:

> What do you think about adding serial number to the xpub package ?
> 
> The key would be 
> 
> {0x02}|{signing_pubkey}|{serial}|{m}|{xpub}|...|{xpub}
> 
> and if the signer have the ability to store a counter, it can reject
> 'outdated' xpub packages, and only accept those that was signed using
> the serial number that it deems recent. This would allow a limited
> mechanism to 'revoke' previously signed packages that have compromized
> keys in them.
> 
> В Thu, 27 Jun 2019 17:16:14 +0900
> Jonathan Underwood <junderwood@bitcoinbank.co.jp> 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 <dp@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@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@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@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
> > > > > >    
> > > > >
> > > > >    
> > > >    
> > >
> > >    
> >   
> 

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 2795 bytes --]

Hi Peter,

tl;dr The problem this solves is "How can a signer verify an address with
HD changing the address every time?"

As an aside: (This is sort of explaining the current PR for the 0x01 global
field (separate from mine))
The problem is more easily understood with change addresses: If someone can
alter my PSBT before signing, they could replace my change address with
their address, and my signer would not know unless the signer just guesses
all the path sets it knows, then derives thousands of change addresses and
searches (most likely a signer is offline, so gap limit doesn't work since
we can't tell which change addresses have tx history. So the 0x01 global
tag will tell the signer "here's how you get from your master private key
to the xpub used in the change output's output BIP32_DERIVATION tag... you
can then derive the same key and check it is yours before signing."

Back to my proposal, this problem extends across wallets, since,
for example, if I want to send from my cold wallet to my warm wallet, I
don't want to give my cold signer my warm master key just so it can derive
and check the key. That's what signatures are for. So this proposal says "A
signer can be built to only sign if it sees a signature that itself has
signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
outputs, and if the output doesn't match it will reject and not sign"

This creates a sort of "chain of trust" for the wallet.

Currently the best way to prevent this (hacker swapping the send to
address) without using signatures is to reuse the same address every time
you want to send to the warm wallet, since after a few times, the signers
(people) will be able to remember the address.

This is a huge HD drawback for high security requirement environments.
Having this data in the PSBT standard will allow Trezor etc. to create an
enforceable whitelist feature.

Let me know if you have feedback on the details.

Thanks,
Jon

2019年6月28日(金) 0:07 Peter D. Gray <peter@coinkite.com>:

> I haven't studied the new proposal in depth, but my first impression is:
>
> Wouldn't it just be easier and better to just sign the entire "outputs"
> section of the PSBT?
>
> The signature would cover every byte, and therefore would cover any
> future BIP additions to the outputs area, and also help non-multisig
> cases today.
>
> ---
> Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG:
> A3A31BAD 5A2A5B10
>
>

-- 
-----------------
Jonathan Underwood
ビットバンク社 チーフビットコインオフィサー
-----------------

暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3

[-- Attachment #2: Type: text/html, Size: 3570 bytes --]

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Peter D. Gray]

Thanks I get the idea better now: You want the PSBT creator to be
able to indicate to the signers that it (the PSBT creator) controls
specific outputs that don't otherwise look like change.

Some problems:

> extended private key of the current signer derived from the
> signer's root to m/2042083607'/959190427'/1400854130'/990526201'

1) The PSBT creator would need to know that private key, and the Coldcard, as a matter
   of policy, will never export a private subkey.

2) The 'm' in that path depends on who is reading the PSBT file, in the multisig
   case. Each cosigner would need a different version of the PSBT file.

3) XPUB's are big and hard to parse, and this addition is using lots of them.

4) Coinjoins, and more complex script types, will want to authorize
   outputs that the PSBT signer may not fully understand. Your proposal
   would only help P2PKH and M-of-N multisig users.

To fix, may I propose:

- the signer and PSBT creator must share a pubkey/private key out of band (setup time)
- the origin of that key is out of scope of this standard (but it could be derived via BIP32)
- the PSBT creator can, optionally, sign any or all output sections by number using that key

I would prefer the signatures are in the global section, and the
signature is over all the bytes in the indicated output section,
as originally serialized when it came into the signer's possession.

We should be able to support multiple signers for individual outputs,
and also multiple signatures for the same output section. That would
support different derived keys per co-signer, and also quorum
approval or other policies like that.

Afterthought: Might be good to allow signature over the unsigned transaction, or
maybe it should be part of the signature always.

---
Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31BAD 5A2A5B10

On Fri, Jun 28, 2019 at 11:44:15AM +0900, Jonathan Underwood wrote:
> Hi Peter,
> 
> tl;dr The problem this solves is "How can a signer verify an address with
> HD changing the address every time?"
> 
> As an aside: (This is sort of explaining the current PR for the 0x01 global
> field (separate from mine))
> The problem is more easily understood with change addresses: If someone can
> alter my PSBT before signing, they could replace my change address with
> their address, and my signer would not know unless the signer just guesses
> all the path sets it knows, then derives thousands of change addresses and
> searches (most likely a signer is offline, so gap limit doesn't work since
> we can't tell which change addresses have tx history. So the 0x01 global
> tag will tell the signer "here's how you get from your master private key
> to the xpub used in the change output's output BIP32_DERIVATION tag... you
> can then derive the same key and check it is yours before signing."
> 
> Back to my proposal, this problem extends across wallets, since,
> for example, if I want to send from my cold wallet to my warm wallet, I
> don't want to give my cold signer my warm master key just so it can derive
> and check the key. That's what signatures are for. So this proposal says "A
> signer can be built to only sign if it sees a signature that itself has
> signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
> outputs, and if the output doesn't match it will reject and not sign"
> 
> This creates a sort of "chain of trust" for the wallet.
> 
> Currently the best way to prevent this (hacker swapping the send to
> address) without using signatures is to reuse the same address every time
> you want to send to the warm wallet, since after a few times, the signers
> (people) will be able to remember the address.
> 
> This is a huge HD drawback for high security requirement environments.
> Having this data in the PSBT standard will allow Trezor etc. to create an
> enforceable whitelist feature.
> 
> Let me know if you have feedback on the details.
> 
> Thanks,
> Jon
> 
> 2019年6月28日(金) 0:07 Peter D. Gray <peter@coinkite.com>:
> 
> > I haven't studied the new proposal in depth, but my first impression is:
> >
> > Wouldn't it just be easier and better to just sign the entire "outputs"
> > section of the PSBT?
> >
> > The signature would cover every byte, and therefore would cover any
> > future BIP additions to the outputs area, and also help non-multisig
> > cases today.
> >
> > ---
> > Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG:
> > A3A31BAD 5A2A5B10
> >
> >
> 
> -- 
> -----------------
> Jonathan Underwood
> ビットバンク社 チーフビットコインオフィサー
> -----------------
> 
> 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
> 
> 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 8071 bytes --]

Thanks for the reply Peter. Comments inline:

2019年6月28日(金) 23:37 Peter D. Gray <peter@coinkite.com>:

> Thanks I get the idea better now: You want the PSBT creator to be
> able to indicate to the signers that it (the PSBT creator) controls
> specific outputs that don't otherwise look like change.
>
> Some problems:
>
> > extended private key of the current signer derived from the
> > signer's root to m/2042083607'/959190427'/1400854130'/990526201'
>
> 1) The PSBT creator would need to know that private key, and the Coldcard,
> as a matter
>    of policy, will never export a private subkey.
>

I think you have misunderstood. The signature inserted into this 0x02 field
is generated BY the signer (Coldkey) airgapped ahead of time. Then the
signature (and all the xpubs that were signed, since basically the "key"
value contains the "pubkey" and "message" while the "value" part has the
"signature". so all data items for verification are present.) will be
stored on the unsigned transaction preparing app. (MyTrezor dot com etc.
have an encrypted storage through Dropbox + encrypting with Trezor, so
they, for instance, could store the "whitelist signatures" on that dropbox
feature.


> 2) The 'm' in that path depends on who is reading the PSBT file, in the
> multisig
>    case. Each cosigner would need a different version of the PSBT file


Again, this is the m of the signer's root. The signer should have an xprv,
or some sort of seed (a la BIP39 or aezeed or Electrum phrase etc.) that
gets turned into a xprv. That xprv is m in this case... in the case that
some offline signer is storing the xprv of some path like "xprv/25'/42'" or
something, then the signer's "identity" is whatever xprv that signer holds
and not any of the xprvs derived from that first xprv.

The reason we want only one HD key to sign it is because we want the signer
to be able to generate that path from the root xprv they hold, check that
the pubkey matched the pubkey for verification, then verify. Now the signer
knows "oh, I have signed this xpub / multisig setup before, therefore I
trust it"


> 3) XPUB's are big and hard to parse, and this addition is using lots of
> them.
>

Any app requiring this level of security would gladly add a few millisecond
for parsing some xpubs.
Any HD wallet that can sign using HD derived keys already has the necessary
tools to parse an xpub.


> 4) Coinjoins, and more complex script types, will want to authorize
>    outputs that the PSBT signer may not fully understand. Your proposal
>    would only help P2PKH and M-of-N multisig users.
>

Yes. This proposal is not a requirement. It is just a reservation for a
slot in the key-value scheme for a use case that many exchanges and
hardware wallets should implement. We have implemented something similar to
this using JSON format internally, but since HW wallet makers seem to be
moving toward PSBT adoption, I would love for this info to be possible to
be sent into an HW wallet so that Trezor etc. can implement this
"whitelist" type situation in a way that the Trezor can trust. (remember, a
"whitelist" that just lives in my trezor dot com website cache etc. is
prone to modification, whereas with my proposal the worst case is a hacker
deletes a signature, so Trezor doesn't trust something it should have, and
fails signing. It can not add itself to the "whitelist" without the HW
wallet private key.)

To fix, may I propose:
>
>
The following suggestions seems to be predicated on a misunderstanding of
my proposal, so I will hold off for now.


> - the signer and PSBT creator must share a pubkey/private key out of band
> (setup time)
> - the origin of that key is out of scope of this standard (but it could be
> derived via BIP32)
> - the PSBT creator can, optionally, sign any or all output sections by
> number using that key
>
> I would prefer the signatures are in the global section, and the
> signature is over all the bytes in the indicated output section,
> as originally serialized when it came into the signer's possession.
>
> We should be able to support multiple signers for individual outputs,
> and also multiple signatures for the same output section. That would
> support different derived keys per co-signer, and also quorum
> approval or other policies like that.
>
> Afterthought: Might be good to allow signature over the unsigned
> transaction, or
> maybe it should be part of the signature always.
>
> ---
> Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG:
> A3A31BAD 5A2A5B10
>
> On Fri, Jun 28, 2019 at 11:44:15AM +0900, Jonathan Underwood wrote:
> > Hi Peter,
> >
> > tl;dr The problem this solves is "How can a signer verify an address with
> > HD changing the address every time?"
> >
> > As an aside: (This is sort of explaining the current PR for the 0x01
> global
> > field (separate from mine))
> > The problem is more easily understood with change addresses: If someone
> can
> > alter my PSBT before signing, they could replace my change address with
> > their address, and my signer would not know unless the signer just
> guesses
> > all the path sets it knows, then derives thousands of change addresses
> and
> > searches (most likely a signer is offline, so gap limit doesn't work
> since
> > we can't tell which change addresses have tx history. So the 0x01 global
> > tag will tell the signer "here's how you get from your master private key
> > to the xpub used in the change output's output BIP32_DERIVATION tag...
> you
> > can then derive the same key and check it is yours before signing."
> >
> > Back to my proposal, this problem extends across wallets, since,
> > for example, if I want to send from my cold wallet to my warm wallet, I
> > don't want to give my cold signer my warm master key just so it can
> derive
> > and check the key. That's what signatures are for. So this proposal says
> "A
> > signer can be built to only sign if it sees a signature that itself has
> > signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
> > outputs, and if the output doesn't match it will reject and not sign"
> >
> > This creates a sort of "chain of trust" for the wallet.
> >
> > Currently the best way to prevent this (hacker swapping the send to
> > address) without using signatures is to reuse the same address every time
> > you want to send to the warm wallet, since after a few times, the signers
> > (people) will be able to remember the address.
> >
> > This is a huge HD drawback for high security requirement environments.
> > Having this data in the PSBT standard will allow Trezor etc. to create an
> > enforceable whitelist feature.
> >
> > Let me know if you have feedback on the details.
> >
> > Thanks,
> > Jon
> >
> > 2019年6月28日(金) 0:07 Peter D. Gray <peter@coinkite.com>:
> >
> > > I haven't studied the new proposal in depth, but my first impression
> is:
> > >
> > > Wouldn't it just be easier and better to just sign the entire "outputs"
> > > section of the PSBT?
> > >
> > > The signature would cover every byte, and therefore would cover any
> > > future BIP additions to the outputs area, and also help non-multisig
> > > cases today.
> > >
> > > ---
> > > Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG:
> > > A3A31BAD 5A2A5B10
> > >
> > >
> >
> > --
> > -----------------
> > Jonathan Underwood
> > ビットバンク社 チーフビットコインオフィサー
> > -----------------
> >
> > 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
> >
> > 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
>


-- 
-----------------
Jonathan Underwood
ビットバンク社 チーフビットコインオフィサー
-----------------

暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3

[-- Attachment #2: Type: text/html, Size: 10453 bytes --]

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Dmitry Petukhov]

In your proposed field key format,

{0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}

I think you can replace the signing pubkey with just a fingerprint of
the master key, that would save 29 bytes per 0x02 field.

If the only entity that is concerned about the validity of the
signature is those that possess the signing_privkey, it will check the
signature when it sees the 0x02 field starting with its own key
fingerprint, and will ignore the field if the signature does not match.

If someone other than the signer needs to check that this xpub-package
was signed by certain cold key, it will need to know signing_pubkey
anyway, before it parses PSBT, as it won't have the means to check if
certain pubkey found in 0x02 field in PSBT is related to certain
signer, without knowing anything about the pubkey beforehand.

I'm not sure if the ability of unrelated parties to verify that
xpub-package matches its signature is useful in practice. 29 bytes per
0x02 field is not a big saving of space, and if this ability is actually
useful, the saving may not be worh loosing this ability.

Other note: you have 'unused' value of 1 for `m` in your scheme, why
not require m=1 for single-sig case, and use 0 as indicator that there
are a serlal number following it?

The key for the field would be encoded as

{0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}

for usual case, and

{0x02}|{signing_pubkey}|0x00|{serial}|{m}|{xpub}|...|{xpub}

for the case when the signing scheme actually cares about different
versions of xpub packages signed by certain cold key

Going back to the idea of moving 'complex' usecases outside of BIP174:
maybe we could have a 'BIP-specific' field, that would have the key as

{0x0?}|{BIP-number}|{bip-specific-suffix-data}

so that the different usecases that are not general enough to be
included in BIP174 itself, may have their own BIPs. Vendor-specific
fields may also be done as a separate BIP.

В Thu, 27 Jun 2019 20:29:32 +0500
Dmitry Petukhov <dp@simplexum.com> wrote:

> Oh, I saw that you covered it in another mail:
> 
> > 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).  
> 
> The setup might not be 'all cold keys', but the keys with different
> levels of exposure to possible theft. In this config, compromise of
> one of the 'warm' keys might not necessary require changing the
> 'cold' key.
> 
> I'm not sure whether this usecase warrants adding extra 'serial'
> field, but on the other hand it is rather simple change, and those who
> does not care can always set 0. 
> 
> В Thu, 27 Jun 2019 18:14:29 +0500
> Dmitry Petukhov <dp@simplexum.com> wrote:
> 
> > What do you think about adding serial number to the xpub package ?
> > 
> > The key would be 
> > 
> > {0x02}|{signing_pubkey}|{serial}|{m}|{xpub}|...|{xpub}
> > 
> > and if the signer have the ability to store a counter, it can reject
> > 'outdated' xpub packages, and only accept those that was signed
> > using the serial number that it deems recent. This would allow a
> > limited mechanism to 'revoke' previously signed packages that have
> > compromized keys in them.
> > 
> > В Thu, 27 Jun 2019 17:16:14 +0900
> > Jonathan Underwood <junderwood@bitcoinbank.co.jp> 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 <dp@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@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@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@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
> > > > > > >      
> > > > > >
> > > > > >      
> > > > >      
> > > >
> > > >      
> > >     
> >   
> 

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 14909 bytes --]

replies in-line. Thanks!

2019年6月29日(土) 6:46 Dmitry Petukhov <dp@simplexum.com>:

> In your proposed field key format,
>
> {0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
>
> I think you can replace the signing pubkey with just a fingerprint of
> the master key, that would save 29 bytes per 0x02 field.
>

Good point.


> If the only entity that is concerned about the validity of the
> signature is those that possess the signing_privkey, it will check the
> signature when it sees the 0x02 field starting with its own key
> fingerprint, and will ignore the field if the signature does not match.
>
> If someone other than the signer needs to check that this xpub-package
> was signed by certain cold key, it will need to know signing_pubkey
> anyway, before it parses PSBT, as it won't have the means to check if
> certain pubkey found in 0x02 field in PSBT is related to certain
> signer, without knowing anything about the pubkey beforehand.
>
> I'm not sure if the ability of unrelated parties to verify that
> xpub-package matches its signature is useful in practice. 29 bytes per
> 0x02 field is not a big saving of space, and if this ability is actually
> useful, the saving may not be worh loosing this ability.
>

All good points, I think we'll just use the first 4 bytes of the hash160 of
the pubkey, aka fingerprint.


> Other note: you have 'unused' value of 1 for `m` in your scheme, why
> not require m=1 for single-sig case, and use 0 as indicator that there
> are a serlal number following it?
>

0x00 is single sig, aka, OP_CHECKSIG

0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG


> The key for the field would be encoded as
>
> {0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
>
> for usual case, and
>
> {0x02}|{signing_pubkey}|0x00|{serial}|{m}|{xpub}|...|{xpub}
>
> for the case when the signing scheme actually cares about different
> versions of xpub packages signed by certain cold key
>

since OP_CHECKMULTISIG only supports at most 15-of-15 due to stack item
size limitations, we could make 0xff into this serial marker.


> Going back to the idea of moving 'complex' usecases outside of BIP174:
> maybe we could have a 'BIP-specific' field, that would have the key as
>
> {0x0?}|{BIP-number}|{bip-specific-suffix-data}
>
> so that the different usecases that are not general enough to be
> included in BIP174 itself, may have their own BIPs. Vendor-specific
> fields may also be done as a separate BIP.
>

Definitely sounds good, but the currently proposed 0x01 global type is
being added to BIP174 directly under the assumption that it is useful for
all users of PSBT, and I would argue that 0x01 being an HD change verifying
method, it only seems logical to add a similar method of "verifying"
non-self keys, aka whitelisting for security purposes, and such a feature
would require this data be included into the PSBT sent into the device.

If the consensus is that this data is unneeded, 0x01 should probably also
be a separate BIP.

Though outside the scope of this BIP, one difficulty of a whitelist feature
would be revocation of signatures. If we pre-sign a revocation cert and
somehow make the wallet blacklist if seen... then the question is "if your
signer has a trustworthy store of state, why not store the whitelist
pubkeys?"

But that feature itself should be a separate BIP.

Also, POR_COMMITMENT being in BIP174 kind of set a precedent... :-/


> В Thu, 27 Jun 2019 20:29:32 +0500
> Dmitry Petukhov <dp@simplexum.com> wrote:
>
> > Oh, I saw that you covered it in another mail:
> >
> > > 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).
> >
> > The setup might not be 'all cold keys', but the keys with different
> > levels of exposure to possible theft. In this config, compromise of
> > one of the 'warm' keys might not necessary require changing the
> > 'cold' key.
> >
> > I'm not sure whether this usecase warrants adding extra 'serial'
> > field, but on the other hand it is rather simple change, and those who
> > does not care can always set 0.
> >
> > В Thu, 27 Jun 2019 18:14:29 +0500
> > Dmitry Petukhov <dp@simplexum.com> wrote:
> >
> > > What do you think about adding serial number to the xpub package ?
> > >
> > > The key would be
> > >
> > > {0x02}|{signing_pubkey}|{serial}|{m}|{xpub}|...|{xpub}
> > >
> > > and if the signer have the ability to store a counter, it can reject
> > > 'outdated' xpub packages, and only accept those that was signed
> > > using the serial number that it deems recent. This would allow a
> > > limited mechanism to 'revoke' previously signed packages that have
> > > compromized keys in them.
> > >
> > > В Thu, 27 Jun 2019 17:16:14 +0900
> > > Jonathan Underwood <junderwood@bitcoinbank.co.jp> 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 <dp@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@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@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@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
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 22494 bytes --]

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Dmitry Petukhov]

В Sat, 29 Jun 2019 09:19:41 +0900
Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote:

> Though outside the scope of this BIP, one difficulty of a whitelist
> feature would be revocation of signatures. If we pre-sign a
> revocation cert and somehow make the wallet blacklist if seen... then
> the question is "if your signer has a trustworthy store of state, why
> not store the whitelist pubkeys?"

In principle, if the hardware wallet can permanently store at least one
counter, it can have rich state, stored externally. It would sign a
state stored in RAM, and give out the state + signature to the
supporting app. The state will include a serial number, corresponding to
the internal counter stored in the hardware wallet. Next time, the app
will give the signed state to the hardware wallet along with
transaction data. Hardware wallet checks its signature over the state,
checks that serial matches its internal counter, uses and modifies the
state, then updates the internal counter and the serial number of the
state, and gives out the signed new state to the app. If the app
loses the state blob, though, there should be some mechanism to securely
override the hw wallet internal state.

This approach might have other limitations, as processing and storing
big enough state in the RAM of a resource-constrained device might
present a problem in itself.

The 'add serial to xpub-package' idea is in the same vein: you can
store this xpub-package serial inside the hw wallet directly, or inside
its 'external rich state blob', but it can take only one byte (unlikely
to need more than 255 xpub-package 'revocations', at that point you
are probably OK to change your cold keys already)

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Dmitry Petukhov]

В Sat, 29 Jun 2019 09:19:41 +0900
Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote:

> > Other note: you have 'unused' value of 1 for `m` in your scheme, why
> > not require m=1 for single-sig case, and use 0 as indicator that
> > there are a serlal number following it?
> >  
> 
> 0x00 is single sig, aka, OP_CHECKSIG
> 
> 0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG

This informatin is available in per-output redeem/witness script,
signer will be able to distinguish between multisig/single-sig by
looking at this script. I think it only need to know the total number
of keys participating in the signing, and check that this number
matches the particulars of redeem/witness script.

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

Even if the difference is apparent outside the signed data (in the output).
Signing the data explicitly is more secure.

ie. if some sort of vulnerability / way to break this system for 1-of-1
multisig is found, someone who signed a single sig xpub whitelist will not
be exposed.

2019年6月29日(土) 13:43 Dmitry Petukhov <dp@simplexum.com>:

> В Sat, 29 Jun 2019 09:19:41 +0900
> Jonathan Underwood <junderwood@bitcoinbank.co.jp> пишет:
>
> > > Other note: you have 'unused' value of 1 for `m` in your scheme, why
> > > not require m=1 for single-sig case, and use 0 as indicator that
> > > there are a serlal number following it?
> > >
> >
> > 0x00 is single sig, aka, OP_CHECKSIG
> >
> > 0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG
>
> This informatin is available in per-output redeem/witness script,
> signer will be able to distinguish between multisig/single-sig by
> looking at this script. I think it only need to know the total number
> of keys participating in the signing, and check that this number
> matches the particulars of redeem/witness script.
>

[-- Attachment #2: Type: text/html, Size: 1555 bytes --]

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

[Jonathan Underwood]

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

Hello All,

I have made a pull request based on the discussion currently. Please move
discussion there.

https://github.com/bitcoin/bips/pull/801

Thanks,
Jonathan

2019年6月29日(土) 17:11 Jonathan Underwood <junderwood@bitcoinbank.co.jp>:

> Even if the difference is apparent outside the signed data (in the
> output). Signing the data explicitly is more secure.
>
> ie. if some sort of vulnerability / way to break this system for 1-of-1
> multisig is found, someone who signed a single sig xpub whitelist will not
> be exposed.
>
> 2019年6月29日(土) 13:43 Dmitry Petukhov <dp@simplexum.com>:
>
>> В Sat, 29 Jun 2019 09:19:41 +0900
>> Jonathan Underwood <junderwood@bitcoinbank.co.jp> пишет:
>>
>> > > Other note: you have 'unused' value of 1 for `m` in your scheme, why
>> > > not require m=1 for single-sig case, and use 0 as indicator that
>> > > there are a serlal number following it?
>> > >
>> >
>> > 0x00 is single sig, aka, OP_CHECKSIG
>> >
>> > 0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG
>>
>> This informatin is available in per-output redeem/witness script,
>> signer will be able to distinguish between multisig/single-sig by
>> looking at this script. I think it only need to know the total number
>> of keys participating in the signing, and check that this number
>> matches the particulars of redeem/witness script.
>>
>
>

-- 
-----------------
Jonathan Underwood
ビットバンク社 チーフビットコインオフィサー
-----------------

暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3

[-- Attachment #2: Type: text/html, Size: 2745 bytes --]