path: root/52/51d73a8288e429acda7d82c3ae4f094e89ee23

Return-Path: <junderwood@bitcoinbank.co.jp>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 18918927
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jun 2019 08:16:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw1-f50.google.com (mail-yw1-f50.google.com
	[209.85.161.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E329B710
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jun 2019 08:16:26 +0000 (UTC)
Received: by mail-yw1-f50.google.com with SMTP id u134so968055ywf.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jun 2019 01:16:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=bitcoinbank.co.jp; s=google;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=7+6K7V2DZpz8NDTtFQeaXloyzO3xCKVwvq8bgCFcXeI=;
	b=krd99LUVlwwxVQZvBJNo+V8aOAPH6VsvtpY6udksqh3lgVxdC6F0YjHV8BIv4479OH
	2y3nI0RxWcrkD3HiWHUY8+xf7j7Qh8+w9tHLYrTKkwwLg9imJeSFP2n0lPzLmik6J+MP
	dlWIVaCCsx1Fm43nOrqclD0spx6hXOB8n0FfBbdBOYKXhweuRfLh/ClE2VPn9ncEBf6T
	kePDHAHJbmIWGbeIK6Re3RQwv2UTz1rNYZ3xeZ122krfRXReGRe4XpOAyZpXQ4cZC1lQ
	lPXg77s1eAZumfJm13Le3+EzH+s6gO87J/cUsdYR/GMkc1+ybIbgS/JrYNRDgtcBlitn
	rRZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=7+6K7V2DZpz8NDTtFQeaXloyzO3xCKVwvq8bgCFcXeI=;
	b=LBf5MVtD/JQ0rmjZO7l7ulejQpDnrOk0MnoxqqV6VEIN/zcQniBuPMgWp0bHaPKL/o
	LfjmIiJaMgtvnZC+TQaIetHQqzHEhGUz2tfLdqc7pv7Nylzqm5rVYDLA0lo1dwOGWSxH
	auII4vJtpdUCGA0wrWOM1Za340i+T88wXbheJXPbhzp6/lmOH6phTEk/Z2Zslzp70pMa
	jp7SSbOv3AfTTKf+3Ft+Efk8Pag8GSWNRbuDcB8O6ZevmBqsggGSj2JBwwOlUUOrFMd/
	srbAaXgNi13g2DkEYXGJcaDkiRQJNiD9tGh3K9fvwfAGPyPS5KQJZfekgW2I7y954y6H
	ra5A==
X-Gm-Message-State: APjAAAX3JZTNk73dWlKEzVd8j+IM6/5c9lT3ajtpx8IMxq7Zejj/9P5R
	WP7ZN1u6EOmpYpTiuLFXXo1LaqsuYYsHpdHgabpKgyCoGPv5
X-Google-Smtp-Source: APXvYqzofZ/fOcZj8eGri4Bt6sclxrLD+sM74Kwsp0BdmIqoGkmPxSOnsJXTfKuodbMLCkp2h7E214K/wYx5+YnYu14=
X-Received: by 2002:a0d:c306:: with SMTP id f6mr1474389ywd.214.1561623385790; 
	Thu, 27 Jun 2019 01:16:25 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <20190627122916.3b6c2c32@simplexum.com>
From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Date: Thu, 27 Jun 2019 17:16:14 +0900
Message-ID: <CAMpN3mL8tyP-6-nwn6dorcq7-dad6wYz8_pXinqHhgzUnrr_tg@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>
Content-Type: multipart/alternative; boundary="0000000000002ef169058c49c7f2"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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: Thu, 27 Jun 2019 14:26:10 +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: Thu, 27 Jun 2019 08:16:29 -0000

--0000000000002ef169058c49c7f2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I see what you mean.

What about this?
https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3=
027e?short_path=3D82656c8#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=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 16:27 Dmitry Petukhov <dp@sim=
plexum.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.
>
> =D0=92 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=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 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.h=
tml
> > >
> > > [2]
> > >
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.h=
tml
> > >
> > >
> > > =D0=92 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#specif=
ication
>
> > > >
> > > > 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
-----------------
Jonathan Underwood
=E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE =E3=83=81=
=E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83=B3=E3=
=82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC
-----------------

=E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB=E3=
=83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82=8A=E3=81=AE=E6=96=B9=E3=81=
=AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B=E9=8D=B5=E3=82=92=E3=81=94=
=E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3=80=82

=E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3

--0000000000002ef169058c49c7f2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I see what you mean.<div><br></div><div>What about this?</=
div><div><a href=3D"https://github.com/junderw/bips/commit/57a57b4fae1ae14b=
77a2eebd99cd719148e3027e?short_path=3D82656c8#diff-82656c833e31e6751a412ce5=
e5c70920">https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99=
cd719148e3027e?short_path=3D82656c8#diff-82656c833e31e6751a412ce5e5c70920</=
a><br></div><div><br></div><div>Plus side: for single sig case, the key onl=
y increases by one byte (0x00 for the {m} value)</div><div><br></div><div>T=
his way if it was 2 of 3 like before, you sign the whole &quot;packet&quot;=
 so each key only signs the packet once. Way better than n!</div><div><br><=
/div><div>Anywho. Please send your feedback. Thanks.</div><div>Jonathan<br>=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 16:27 Dmitry Petukhov &=
lt;<a href=3D"mailto:dp@simplexum.com">dp@simplexum.com</a>&gt;:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">How would signer know that=
 there _should_ be at least 3 signatures<br>
signed by the key owned by this signer ?<br>
<br>
If it does not know that it should enforce 2of3 multisig, for example,<br>
the attacker that control only one key A can fool signer B by<br>
sending to 1of1 single-sig that is derived from A&#39;s xpub, and providing=
<br>
only sBxA in PSBT.<br>
<br>
If the signer does not have a hardcoded configuration that<br>
will mandate a particular multisig scheme, it will allow sending to any<br>
scheme.<br>
<br>
If the signer has a rich enough state to store updatable configuration,<br>
it can just store the trusted xpubs directly.<br>
<br>
Alternatively, signer can sign not individual xpubs, but whole xpub<br>
packages that correspond to particular multisig configuration, and<br>
enforce that destination addresses correspond to this configuration.<br>
<br>
But this would not be possible with your PSBT scheme that uses<br>
individual key-xpub pairs.<br>
<br>
=D0=92 Thu, 27 Jun 2019 14:07:47 +0900<br>
Jonathan Underwood &lt;<a href=3D"mailto:junderwood@bitcoinbank.co.jp" targ=
et=3D"_blank">junderwood@bitcoinbank.co.jp</a>&gt; wrote:<br>
<br>
&gt; Thanks for the reply.<br>
&gt; <br>
&gt; The way we would do it is:<br>
&gt; <br>
&gt; Let&#39;s say we have 3 cold keys for multisig: A B and C<br>
&gt; <br>
&gt; Whose xpubs are: xA xB and xC<br>
&gt; <br>
&gt; We all sign each other&#39;s xpubs, whose signatures are:<br>
&gt; sAxB<br>
&gt; sAxC<br>
&gt; sBxA<br>
&gt; sBxC<br>
&gt; sCxA<br>
&gt; sCxB<br>
&gt; <br>
&gt; We can then create a wallet that says &quot;when verifying change with=
 0x01<br>
&gt; global type proposed by Andrew Chow, if the change is multisig, we<br>
&gt; MUST require the other pubkeys to have signatures via my 0x02<br>
&gt; proposal&quot;<br>
&gt; <br>
&gt; This way, all my PSBTs for my cold will have:<br>
&gt; 1. an 0x01 entry to tell me how to get my change.<br>
&gt; 2. All 6 of the signatures above.<br>
&gt; <br>
&gt; And the signer will then look at the change, check my pubkey by<br>
&gt; deriving the xpub and checking equality to the BIP_DERIVATION of the<b=
r>
&gt; output... it will then check the OTHER pubkeys via BIP32_DERIVATION<br=
>
&gt; to master fingerprint, then link that fingerprint to a 0x02 sig from<b=
r>
&gt; MY key, verifying all pubkeys.<br>
&gt; <br>
&gt; So this proposal of mine would not only fix the &quot;send to address<=
br>
&gt; verification&quot; problem for HD, but also the multisig change proble=
m<br>
&gt; with 0x01.<br>
&gt; <br>
&gt; Cool.<br>
&gt; <br>
&gt; Only thing that is kind of sad is having to include n! (of m-of-n)<br>
&gt; signatures in every PSBT... but tbh, the PSBT size is not of much<br>
&gt; concern.<br>
&gt; <br>
&gt; Thanks for the reply.<br>
&gt; - Jonathan<br>
&gt; <br>
&gt; <br>
&gt; 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 13:49 Dmitry Petukhov &l=
t;<a href=3D"mailto:dp@simplexum.com" target=3D"_blank">dp@simplexum.com</a=
>&gt;:<br>
&gt; <br>
&gt; &gt; Hi!<br>
&gt; &gt;<br>
&gt; &gt; I wonder how your scheme handles multisig ?<br>
&gt; &gt;<br>
&gt; &gt; As I understand, you sign individual xpubs with cold keys, so tha=
t<br>
&gt; &gt; cold keys can check destination addresses are trusted.<br>
&gt; &gt;<br>
&gt; &gt; I seems to me that if you sign individual xpubs of a multisig war=
m<br>
&gt; &gt; wallet, and one key from that multisig is compromized, attackers =
can<br>
&gt; &gt; then create a single-sig destination address that they control, a=
nd<br>
&gt; &gt; move the coins in a chain of two transactions, first to this<br>
&gt; &gt; single-sig address, and then to an address that they independentl=
y<br>
&gt; &gt; control.<br>
&gt; &gt;<br>
&gt; &gt; My idea to prevent this [1] is to sign the whole &#39;xpub packag=
e&#39; of<br>
&gt; &gt; the multisig wallet, but there is also an issue of &#39;partial<b=
r>
&gt; &gt; compromize&#39;, where some of the keys in a multisig warm wallet=
 is<br>
&gt; &gt; compromized, and you do not want to regard a particular &#39;xpub=
<br>
&gt; &gt; package&#39; as trusted. My idea was [2] to use an auxiliary mess=
age<br>
&gt; &gt; that would be signed along with the &#39;xpub package&#39;, and t=
hat<br>
&gt; &gt; message can include specific &#39;epoch&#39; word that hardware w=
allet can<br>
&gt; &gt; show prominently before signing, or have &#39;serial number&#39; =
for xpub<br>
&gt; &gt; packages (but that will require to store last known serial inside=
<br>
&gt; &gt; hw wallet, making it stateful).<br>
&gt; &gt;<br>
&gt; &gt; I like the idea to extend PSBT to accomodate these schemes, but<b=
r>
&gt; &gt; given that the huge number of possible schemes that each may<br>
&gt; &gt; probably require its own PSBT field type, I think that this is<br=
>
&gt; &gt; better dealt with outside of PSBT, as &#39;PSBT metainformation&#=
39;, or<br>
&gt; &gt; using some form of &#39;vendor-specific&#39;, or &#39;metainforma=
tion-specific&#39;<br>
&gt; &gt; PSBT field. This way each usecase can be independently described =
in<br>
&gt; &gt; its own documentation, that would include the particulars of the<=
br>
&gt; &gt; format for the metainformation. This would also make it easier to=
<br>
&gt; &gt; implement PSBT for simple cases, because the &#39;core specificat=
ion&#39;<br>
&gt; &gt; would not grow that big.<br>
&gt; &gt;<br>
&gt; &gt; [1]<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2019-May/016917.html" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html</a><br>
&gt; &gt;<br>
&gt; &gt; [2]<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2019-May/016926.html" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html</a><br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; =D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via bit=
coin-dev<br>
&gt; &gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt;=C2=A0 <br>
&gt; &gt; &gt; Hello all,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Just wanted to pick your brains about an idea for PSBT exten=
sion.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; One problem we try to solve with cold -&gt; warm and warm -&=
gt; hot<br>
&gt; &gt; &gt; sends for our exchange wallet is &quot;How do I know that th=
e address<br>
&gt; &gt; &gt; I am sending to is not a hacker&#39;s address that was swapp=
ed in<br>
&gt; &gt; &gt; between unsigned tx creation and first signature?&quot;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; We have a proprietary JSON based encoding system which we ar=
e<br>
&gt; &gt; &gt; looking to move towards PSBT, but PSBT is missing this key<b=
r>
&gt; &gt; &gt; functionality.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; BIP32_DERIVATION does allow us to verify the address is from=
 a<br>
&gt; &gt; &gt; certain XPUB, but, for example, it can not allow us to verif=
y a<br>
&gt; &gt; &gt; signature of that xpub.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I have made a rough draft of the proposed key value specific=
ation.<br>
&gt; &gt; &gt;=C2=A0 <br>
&gt; &gt; <a href=3D"https://github.com/junderw/bips/blob/addXpubSig/bip-01=
74.mediawiki#specification" rel=3D"noreferrer" target=3D"_blank">https://gi=
thub.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification</a>=
=C2=A0 <br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The signing key path used in the spec is just randomly chose=
n 31<br>
&gt; &gt; &gt; x 4 bits shown as numbers with hardened paths.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Since this issue seems similar to the change address issue, =
I<br>
&gt; &gt; &gt; started from that as a base. With the HW wallet case, I can<=
br>
&gt; &gt; &gt; verify the xpub by just deriving it locally and comparing<br=
>
&gt; &gt; &gt; equality, however, in our case, we need to verify an xpub th=
at we<br>
&gt; &gt; &gt; do not have access to via derivation from our cold key(s) (s=
ince<br>
&gt; &gt; &gt; we don&#39;t want to import our warm private key into our co=
ld signer)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; So the flow would be:<br>
&gt; &gt; &gt; 1. Securely verify the xpub of the warm / hot wallet.<br>
&gt; &gt; &gt; 2. Using the airgap signing tool, sign the xpub with all col=
d<br>
&gt; &gt; &gt; keys. 3. Upload the signature/xpub pairs to the online unsig=
ned<br>
&gt; &gt; &gt; transaction generator.<br>
&gt; &gt; &gt; 4. Include one keyval pair per coldkey/xpub pairing.<br>
&gt; &gt; &gt; 5. When offline signing, if the wallet detects there is a gl=
obal<br>
&gt; &gt; &gt; keyval XPUB_SIGNATURE with its pubkey in the key, it must ve=
rify<br>
&gt; &gt; &gt; that all outputs have BIP32_DERIVATION and that it can verif=
y the<br>
&gt; &gt; &gt; outputs through the derivation, to the xpub, and to the sign=
ature.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; In my attempt to fitting this into PSBT, I am slightly alter=
ing<br>
&gt; &gt; &gt; our current system, so don&#39;t take this as an indication =
100% of<br>
&gt; &gt; &gt; how we work in the backend.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; However, I would like to hear any feedback on this proposal.=
<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thanks,<br>
&gt; &gt; &gt; Jonathan<br>
&gt; &gt; &gt;=C2=A0 <br>
&gt; &gt;<br>
&gt; &gt;=C2=A0 <br>
&gt; <br>
<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div dir=
=3D"ltr"><div>-----------------<br></div><div>Jonathan Underwood</div><div>=
=E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE=E3=80=80=E3=
=83=81=E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83=
=B3=E3=82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC</div><div>----------------=
-</div><div><br></div><div>=E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3=
=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82=
=8A=E3=81=AE=E6=96=B9=E3=81=AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B=
=E9=8D=B5=E3=82=92=E3=81=94=E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3=
=80=82</div><div><br></div><div>=E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3=
FDAD998682F3590FEA3</div></div></div></div></div></div>

--0000000000002ef169058c49c7f2--