public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Stepan Snigirev <snigirev.stepan@gmail.com>
To: Peter Gray <peter@coinkite.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Adding xpub field to PSBT to make multisig more secure
Date: Tue, 7 May 2019 11:23:44 +0200	[thread overview]
Message-ID: <CACL8y1tesev2OLrkfYfvmkgbR2xuk-0JPqdmYGtrUcser9GPfg@mail.gmail.com> (raw)
In-Reply-To: <20190503132945.GR810@coinkite.com>

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

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

I agree that it makes sense to put xpubs to the global scope.
But I am not sure that restricting xpubs to have only hardened derivation
is necessary.
People may want to share non-hardened xpubs with co-signers and keep parent
xpub on there watch-only wallet.
For example, in bip45 cosigner_index is not hardened, and sharing top level
xpub is not necessary.

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

I would like to keep hardware wallets state-less, otherwise wiping and
recovering them would be problematic.
At the setup phase the user can verify a multisignature address (or xpub)
on the screens of all devices,
after that we just need to verify that xpubs in the inputs and in the
change output are the same.

Andrew, regarding your question:
> 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?

As PSBT is a binary format I think it makes sense to use extension
serialization format without any encodings.
I am not sure if we need the whole xpub or keeping chain_code and
public_key is enough, but I would suggest to keep other data
just in case. For example, keeping prefix that defines if the key is used
for testnet or mainnet may be useful.

Best regards,
Stepan

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

  reply	other threads:[~2019-05-07 10:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-26 15:21 [bitcoin-dev] Adding xpub field to PSBT to make multisig more secure Stepan Snigirev
2019-05-01 16:57 ` Andrew Chow
2019-05-03 13:29 ` Peter D. Gray
2019-05-07  9:23   ` Stepan Snigirev [this message]
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=CACL8y1tesev2OLrkfYfvmkgbR2xuk-0JPqdmYGtrUcser9GPfg@mail.gmail.com \
    --to=snigirev.stepan@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=peter@coinkite.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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