path: root/74/3e5c1305f036484bddb2a4146c576c92f008b2

Return-Path: <dp@simplexum.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CC3F3D91
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 21:47:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6FF1813A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 21:46:59 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
	by mail.ruggedbytes.com (Postfix) with ESMTPS id A1DB02600550;
	Fri, 28 Jun 2019 21:46:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
	s=mail; t=1561758417;
	bh=H8Oa3cDXmlGNsFWJaVcQ6t+Nt70vC0NH+Fmk8cLTQYc=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References;
	b=PV8ubBLA+reIUhW1CCVP3wiPl2qiN4KTOgNnCEhjVhl9sxtFq2KVl99N8yhv/JTU2
	8ds1FvFgs8bYSFlaUGkjc3MgLqoAOVmkcfAmOntWJRq1eWRyCTZNObWAQrOjlAfsC7
	eNg3/6DF1U9WZB04o2fH5JIkWfaSpA2DvHWLa00c=
Date: Sat, 29 Jun 2019 02:48:16 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Message-ID: <20190629024816.2193363e@simplexum.com>
In-Reply-To: <20190627202932.1cb4d727@simplexum.com>
References: <CAMpN3mLvY+kuUGqzMW6SAMZ=h46_g=XLhDPhSY=X6xhLxvi15Q@mail.gmail.com>
	<20190627095031.4d5817b8@simplexum.com>
	<CAMpN3mKPkCPtYkN-JVku1r217-aBK=Rh3UEhvRPS_Y6DixJ9Dw@mail.gmail.com>
	<20190627122916.3b6c2c32@simplexum.com>
	<CAMpN3mL8tyP-6-nwn6dorcq7-dad6wYz8_pXinqHhgzUnrr_tg@mail.gmail.com>
	<20190627181429.15dda570@simplexum.com>
	<20190627202932.1cb4d727@simplexum.com>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 29 Jun 2019 00:13:44 +0000
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP174 extension proposal (Global Type:
 PSBT_GLOBAL_XPUB_SIGNATURE)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jun 2019 21:47:00 -0000

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=3D1 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.

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

> Oh, I saw that you covered it in another mail:
>=20
> > The expire / revoke problem is a larger problem than this feature
> > can handle. =20
>=20
> > 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). =20
>=20
> 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.
>=20
> 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.=20
>=20
> =D0=92 Thu, 27 Jun 2019 18:14:29 +0500
> Dmitry Petukhov <dp@simplexum.com> wrote:
>=20
> > What do you think about adding serial number to the xpub package ?
> >=20
> > The key would be=20
> >=20
> > {0x02}|{signing_pubkey}|{serial}|{m}|{xpub}|...|{xpub}
> >=20
> > 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.
> >=20
> > =D0=92 Thu, 27 Jun 2019 17:16:14 +0900
> > Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote:
> >  =20
> > > I see what you mean.
> > >=20
> > > What about this?
> > > https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd71=
9148e3027e?short_path=3D82656c8#diff-82656c833e31e6751a412ce5e5c70920
> > >=20
> > > Plus side: for single sig case, the key only increases by one byte
> > > (0x00 for the {m} value)
> > >=20
> > > 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!
> > >=20
> > > Anywho. Please send your feedback. Thanks.
> > > Jonathan
> > >=20
> > > 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 16:27 Dmitry Petukhov <=
dp@simplexum.com>:
> > >    =20
> > > > 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.
> > > >
> > > > =D0=92 Thu, 27 Jun 2019 14:07:47 +0900
> > > > Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote:
> > > >     =20
> > > > > 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=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 13:49 Dmitry Petukh=
ov <dp@simplexum.com>:
> > > > >     =20
> > > > > > 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]
> > > > > >
> > > > > >     =20
> > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/01=
6917.html     =20
> > > > > >
> > > > > > [2]
> > > > > >
> > > > > >     =20
> > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/01=
6926.html     =20
> > > > > >
> > > > > >
> > > > > > =D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via
> > > > > > bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > > > >     =20
> > > > > > > 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.    =20
> > > > > >     =20
> > > > https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#=
specification
> > > >     =20
> > > > > > >
> > > > > > > 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
> > > > > > >     =20
> > > > > >
> > > > > >     =20
> > > > >     =20
> > > >
> > > >     =20
> > >    =20
> >  =20
>=20