Peter D. Gray [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-03 📝 Original message:On Fri, Apr 26, 2019 at ...
📅 Original date posted:2019-05-03
📝 Original message:On Fri, Apr 26, 2019 at 05:21:06PM +0200, Stepan Snigirev wrote:
...
> Currently in PSBT there is no way to reliably say if the output uses the
> keys derived from the same root keys as the inputs aside from the key owned
Writing the multisig support for Coldcard, I've come to the same conclusion. I've
exchanged some helpful mail with Andrew Chow on this subject.
...
> I suggest to add the following key-value pairs to PSBT:
> Type: BIP 32 public key `PSBT_IN_BIP32_XPUB = 0x10`
...
> Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB = 0x03`
I'd rather see the xpubs shared in the global section of the file,
with the restriction that they must/should only include the hardened
prefix of the path. The existing bip32 derivation path included in
individual inputs and outputs be merged in as needed.
After all in a typical PSBT, we would expect the same master keys
to be used on all inputs, and at least one output, and there might
be as many as 20 co-signers. No need to repeat all that information.
Even with this additions to the PSBT format, I think PSBT-signing
devices still need to store the xpubs of their co-signers. It's not
possible to safely show an incoming address to the user without a
full understanding of the other keys in a "multisig wallet". Also,
it represents data that should not change between PSBT instances
(ie. tomorrow's co-signers should match today's).
Having said that, the xpubs in the PSBT would allow a "trust on first
use" which I think can be a good feature.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
> Hi list,
>
> I was looking at the bip174 PSBT specs, in particular for multisignature
> setup, and I think with current spec there is a way to steal user funds in
> M of N setup with M ≤ N/2.
>
> I made a small write-up on this:
> https://github.com/stepansnigirev/random_notes/blob/master/psbt_multisig.md
>
> To compress:
>
> Currently in PSBT there is no way to reliably say if the output uses the
> keys derived from the same root keys as the inputs aside from the key owned
> by the signer => there is no way to verify that the output is a change
> output in multisig setup.
>
> Therefore an attacker can replace half of the keys in the change address by
> his own keys and still get the transaction signed.
>
> I suggest to add an xpub field to the inputs and outputs metadata, then
> signers can verify that the same xpubs are used for public keys in inputs
> and outputs => output is indeed a change.
>
> Normally change and receiving addresses are derived from the same xpub with
> non-hardened derivation pathes, so providing xpub after the last hardened
> index should be enough to see that public keys of inputs and change output
> are derived from the same xpub.
>
> I suggest to add the following key-value pairs to PSBT:
>
> Type: BIP 32 public key `PSBT_IN_BIP32_XPUB = 0x10`
> - Key: derivation path for xpub
> `{0x10}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
> `{xpub}`
>
> Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB = 0x03`
> - Key: derivation path for xpub
> `{0x03}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
> `{xpub}`
>
> Derivation paths are in the key of the key-value pair as they are used for
> lookup, and xpub itself is the actual value being looked up.
>
> I also want to mention that Trezor for example doesn't suffer from this
> problem as they use xpubs to verify change outputs. So it may make sense to
> go through the communication protocols of existing hardware /
> multisignature wallets and see if there is something else we are missing.
>
> If everyone is happy about the proposal I would prepare a pull request to
> the bip.
>
> Best regards,
> Stepan Snigirev.
📝 Original message:On Fri, Apr 26, 2019 at 05:21:06PM +0200, Stepan Snigirev wrote:
...
> Currently in PSBT there is no way to reliably say if the output uses the
> keys derived from the same root keys as the inputs aside from the key owned
Writing the multisig support for Coldcard, I've come to the same conclusion. I've
exchanged some helpful mail with Andrew Chow on this subject.
...
> I suggest to add the following key-value pairs to PSBT:
> Type: BIP 32 public key `PSBT_IN_BIP32_XPUB = 0x10`
...
> Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB = 0x03`
I'd rather see the xpubs shared in the global section of the file,
with the restriction that they must/should only include the hardened
prefix of the path. The existing bip32 derivation path included in
individual inputs and outputs be merged in as needed.
After all in a typical PSBT, we would expect the same master keys
to be used on all inputs, and at least one output, and there might
be as many as 20 co-signers. No need to repeat all that information.
Even with this additions to the PSBT format, I think PSBT-signing
devices still need to store the xpubs of their co-signers. It's not
possible to safely show an incoming address to the user without a
full understanding of the other keys in a "multisig wallet". Also,
it represents data that should not change between PSBT instances
(ie. tomorrow's co-signers should match today's).
Having said that, the xpubs in the PSBT would allow a "trust on first
use" which I think can be a good feature.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
> Hi list,
>
> I was looking at the bip174 PSBT specs, in particular for multisignature
> setup, and I think with current spec there is a way to steal user funds in
> M of N setup with M ≤ N/2.
>
> I made a small write-up on this:
> https://github.com/stepansnigirev/random_notes/blob/master/psbt_multisig.md
>
> To compress:
>
> Currently in PSBT there is no way to reliably say if the output uses the
> keys derived from the same root keys as the inputs aside from the key owned
> by the signer => there is no way to verify that the output is a change
> output in multisig setup.
>
> Therefore an attacker can replace half of the keys in the change address by
> his own keys and still get the transaction signed.
>
> I suggest to add an xpub field to the inputs and outputs metadata, then
> signers can verify that the same xpubs are used for public keys in inputs
> and outputs => output is indeed a change.
>
> Normally change and receiving addresses are derived from the same xpub with
> non-hardened derivation pathes, so providing xpub after the last hardened
> index should be enough to see that public keys of inputs and change output
> are derived from the same xpub.
>
> I suggest to add the following key-value pairs to PSBT:
>
> Type: BIP 32 public key `PSBT_IN_BIP32_XPUB = 0x10`
> - Key: derivation path for xpub
> `{0x10}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
> `{xpub}`
>
> Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB = 0x03`
> - Key: derivation path for xpub
> `{0x03}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
> `{xpub}`
>
> Derivation paths are in the key of the key-value pair as they are used for
> lookup, and xpub itself is the actual value being looked up.
>
> I also want to mention that Trezor for example doesn't suffer from this
> problem as they use xpubs to verify change outputs. So it may make sense to
> go through the communication protocols of existing hardware /
> multisignature wallets and see if there is something else we are missing.
>
> If everyone is happy about the proposal I would prepare a pull request to
> the bip.
>
> Best regards,
> Stepan Snigirev.