From: Andrew Chow <achow101-lists@achow101•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Adding xpub field to PSBT to make multisig more secure
Date: Wed, 01 May 2019 16:57:38 +0000 [thread overview]
Message-ID: <-9vv_PTO55EHqObZe3e3wBo_sNF34p0IWbK-rkrcW4q31pQwahpqy4xJw9dq_CB2UCo1FvOz6I3EMcQM_9u5Ht3y9VFYAB2uJGkZjds84nI=@achow101.com> (raw)
In-Reply-To: <CACL8y1v9fpZ+gWLVHMx-bGUCaSd0=0ecHU-u4FF=LnhT7s1zTg@mail.gmail.com>
Hi Stepan,
I think that this would be a good extension.
Just for clairty, by xpub, do you mean the extended serialization format
defined in BIP 32 or the Base58 check encoded string of that serialization?
Andrew
On 4/26/19 11:21 AM, Stepan Snigirev via bitcoin-dev wrote:
> 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.
>
next prev parent reply other threads:[~2019-05-01 16:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-26 15:21 Stepan Snigirev
2019-05-01 16:57 ` Andrew Chow [this message]
2019-05-03 13:29 ` Peter D. Gray
2019-05-07 9:23 ` Stepan Snigirev
2019-05-07 13:40 ` Dmitry Petukhov
2019-05-08 7:54 ` jan matejek
2019-05-09 17:08 ` Dmitry Petukhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='-9vv_PTO55EHqObZe3e3wBo_sNF34p0IWbK-rkrcW4q31pQwahpqy4xJw9dq_CB2UCo1FvOz6I3EMcQM_9u5Ht3y9VFYAB2uJGkZjds84nI=@achow101.com' \
--to=achow101-lists@achow101$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox