path: root/5c/7e2f897060153d44cbc0b55494b3459fe786c3

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 A5030C7D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 15:00:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com
	[209.85.219.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4A80D834
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 15:00:34 +0000 (UTC)
Received: by mail-yb1-f169.google.com with SMTP id y67so3947114yba.8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 08:00:34 -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=m70/PbFaedw3vGeKeGfMyabAISun97PHOXxAchHG1V4=;
	b=S8ay9mwgrCinl9c4WTfUDYJY7TGWnf2IkyBzHJoI93b3rtWiUgTy10J7EfUFwfxgcv
	A0ZLU8jaQAHdXVGQ+TX9XSAIt23xOR3dpKLli/1gfGbzWQwjrLBSQDE59s//b+mauGs6
	ysoXxy29zAmtHiRnjUZ5NqYydyalMBbNRyfZHb4Xunwgv0V50e8DvFq8QTET/zEFdqd1
	bQz/YnRDscyRVlOo5sSw0ejF8hIHG6DoTIdUcqihyN7/xL6OXwSmcidVPNpeJqdKEfb3
	+OyeismBxpsUwkkkZN6jiwRlg7SjRh/JHUFaT+au7N8wtcRHEzJeNz3dOjQD/D+kc1fk
	lQ4g==
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=m70/PbFaedw3vGeKeGfMyabAISun97PHOXxAchHG1V4=;
	b=D2C7vyyBb3e6YnWPFzDWx4DRAJsLXw7f3MVJce7lYMZIWWvSQ+zYuLS/awWB4u0WML
	bZGho8Id17pv6HbOEqZLSEC2On/wM75Diupu9YkM6gAg0aM/5Ik2L9SUX3gn+28Db7E8
	S3u6Cve+ZTUAT+AD5JfhH3/hcc1L7ReowQHtJnE8uyB7q5xShiZe949aCeMAtVE6hexm
	77mMGWIbZk7Gs2a8pozUXYHjQSM7FUXIw+rDVJlaunNeApNEmDxsJYmr5JV8Djkwx1j7
	+bHxkRZ1Leyc4geLgtqiEuxIHGATbvZOAb6apRymKyRfjw2wJQt50DSJl1tgqlSbA1/+
	eNXA==
X-Gm-Message-State: APjAAAXEMH5KcSmo4CfXMMq2QTAGx6VS2oVN/Ws87hgkPcltBMcmkxFU
	2uBixX61M25chu/eqYg2Ac9CfEgAfXFDLgsC6x4D
X-Google-Smtp-Source: APXvYqyf2cXQT5KGkreZ9n2j/KTAgASjdy7aBBJ5gH/1AoO7EWdr7Wjojvegrq7iOtH6Hp9VeJwXnKpWW4SzzZB3+rA=
X-Received: by 2002:a25:5557:: with SMTP id j84mr6161457ybb.25.1561734033232; 
	Fri, 28 Jun 2019 08:00:33 -0700 (PDT)
MIME-Version: 1.0
References: <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>
	<20190627134628.4d131264@simplexum.com>
	<CAMpN3m+LiSW=kRCQio+C_2To66o_SEq-d_0Z122j+BUxvh=LDQ@mail.gmail.com>
	<20190627142120.2c24fddb@simplexum.com>
	<CAMpN3m+0HJm+zZ81ZNP-BXpX_39BvHzwKRAPwpdHinJ13gdNeA@mail.gmail.com>
	<20190627150745.GA1897@coinkite.com>
	<CAMpN3mKyKjSPs2SgC0pUbFMNXFZt7UOu4ktnbfBSDmLrDbafFA@mail.gmail.com>
	<20190628143755.GD1897@coinkite.com>
In-Reply-To: <20190628143755.GD1897@coinkite.com>
From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Date: Sat, 29 Jun 2019 00:00:22 +0900
Message-ID: <CAMpN3mKZiQXrctWp9KxahdBHeeyu4pWPQP83LzRPLWXRWKBhAw@mail.gmail.com>
To: Peter Gray <peter@coinkite.com>
Content-Type: multipart/alternative; boundary="0000000000004904c2058c638afe"
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: Fri, 28 Jun 2019 20:05:14 +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 15:00:35 -0000

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

Thanks for the reply Peter. Comments inline:

2019=E5=B9=B46=E6=9C=8828=E6=97=A5(=E9=87=91) 23:37 Peter D. Gray <peter@co=
inkite.com>:

> Thanks I get the idea better now: You want the PSBT creator to be
> able to indicate to the signers that it (the PSBT creator) controls
> specific outputs that don't otherwise look like change.
>
> Some problems:
>
> > extended private key of the current signer derived from the
> > signer's root to m/2042083607'/959190427'/1400854130'/990526201'
>
> 1) The PSBT creator would need to know that private key, and the Coldcard=
,
> as a matter
>    of policy, will never export a private subkey.
>

I think you have misunderstood. The signature inserted into this 0x02 field
is generated BY the signer (Coldkey) airgapped ahead of time. Then the
signature (and all the xpubs that were signed, since basically the "key"
value contains the "pubkey" and "message" while the "value" part has the
"signature". so all data items for verification are present.) will be
stored on the unsigned transaction preparing app. (MyTrezor dot com etc.
have an encrypted storage through Dropbox + encrypting with Trezor, so
they, for instance, could store the "whitelist signatures" on that dropbox
feature.


> 2) The 'm' in that path depends on who is reading the PSBT file, in the
> multisig
>    case. Each cosigner would need a different version of the PSBT file


Again, this is the m of the signer's root. The signer should have an xprv,
or some sort of seed (a la BIP39 or aezeed or Electrum phrase etc.) that
gets turned into a xprv. That xprv is m in this case... in the case that
some offline signer is storing the xprv of some path like "xprv/25'/42'" or
something, then the signer's "identity" is whatever xprv that signer holds
and not any of the xprvs derived from that first xprv.

The reason we want only one HD key to sign it is because we want the signer
to be able to generate that path from the root xprv they hold, check that
the pubkey matched the pubkey for verification, then verify. Now the signer
knows "oh, I have signed this xpub / multisig setup before, therefore I
trust it"


> 3) XPUB's are big and hard to parse, and this addition is using lots of
> them.
>

Any app requiring this level of security would gladly add a few millisecond
for parsing some xpubs.
Any HD wallet that can sign using HD derived keys already has the necessary
tools to parse an xpub.


> 4) Coinjoins, and more complex script types, will want to authorize
>    outputs that the PSBT signer may not fully understand. Your proposal
>    would only help P2PKH and M-of-N multisig users.
>

Yes. This proposal is not a requirement. It is just a reservation for a
slot in the key-value scheme for a use case that many exchanges and
hardware wallets should implement. We have implemented something similar to
this using JSON format internally, but since HW wallet makers seem to be
moving toward PSBT adoption, I would love for this info to be possible to
be sent into an HW wallet so that Trezor etc. can implement this
"whitelist" type situation in a way that the Trezor can trust. (remember, a
"whitelist" that just lives in my trezor dot com website cache etc. is
prone to modification, whereas with my proposal the worst case is a hacker
deletes a signature, so Trezor doesn't trust something it should have, and
fails signing. It can not add itself to the "whitelist" without the HW
wallet private key.)

To fix, may I propose:
>
>
The following suggestions seems to be predicated on a misunderstanding of
my proposal, so I will hold off for now.


> - the signer and PSBT creator must share a pubkey/private key out of band
> (setup time)
> - the origin of that key is out of scope of this standard (but it could b=
e
> derived via BIP32)
> - the PSBT creator can, optionally, sign any or all output sections by
> number using that key
>
> I would prefer the signatures are in the global section, and the
> signature is over all the bytes in the indicated output section,
> as originally serialized when it came into the signer's possession.
>
> We should be able to support multiple signers for individual outputs,
> and also multiple signatures for the same output section. That would
> support different derived keys per co-signer, and also quorum
> approval or other policies like that.
>
> Afterthought: Might be good to allow signature over the unsigned
> transaction, or
> maybe it should be part of the signature always.
>
> ---
> Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG:
> A3A31BAD 5A2A5B10
>
> On Fri, Jun 28, 2019 at 11:44:15AM +0900, Jonathan Underwood wrote:
> > Hi Peter,
> >
> > tl;dr The problem this solves is "How can a signer verify an address wi=
th
> > HD changing the address every time?"
> >
> > As an aside: (This is sort of explaining the current PR for the 0x01
> global
> > field (separate from mine))
> > The problem is more easily understood with change addresses: If someone
> can
> > alter my PSBT before signing, they could replace my change address with
> > their address, and my signer would not know unless the signer just
> guesses
> > all the path sets it knows, then derives thousands of change addresses
> and
> > searches (most likely a signer is offline, so gap limit doesn't work
> since
> > we can't tell which change addresses have tx history. So the 0x01 globa=
l
> > tag will tell the signer "here's how you get from your master private k=
ey
> > to the xpub used in the change output's output BIP32_DERIVATION tag...
> you
> > can then derive the same key and check it is yours before signing."
> >
> > Back to my proposal, this problem extends across wallets, since,
> > for example, if I want to send from my cold wallet to my warm wallet, I
> > don't want to give my cold signer my warm master key just so it can
> derive
> > and check the key. That's what signatures are for. So this proposal say=
s
> "A
> > signer can be built to only sign if it sees a signature that itself has
> > signed, then from that signed xpub(s) derives the BIP32_DERIVATION in t=
he
> > outputs, and if the output doesn't match it will reject and not sign"
> >
> > This creates a sort of "chain of trust" for the wallet.
> >
> > Currently the best way to prevent this (hacker swapping the send to
> > address) without using signatures is to reuse the same address every ti=
me
> > you want to send to the warm wallet, since after a few times, the signe=
rs
> > (people) will be able to remember the address.
> >
> > This is a huge HD drawback for high security requirement environments.
> > Having this data in the PSBT standard will allow Trezor etc. to create =
an
> > enforceable whitelist feature.
> >
> > Let me know if you have feedback on the details.
> >
> > Thanks,
> > Jon
> >
> > 2019=E5=B9=B46=E6=9C=8828=E6=97=A5(=E9=87=91) 0:07 Peter D. Gray <peter=
@coinkite.com>:
> >
> > > I haven't studied the new proposal in depth, but my first impression
> is:
> > >
> > > Wouldn't it just be easier and better to just sign the entire "output=
s"
> > > section of the PSBT?
> > >
> > > The signature would cover every byte, and therefore would cover any
> > > future BIP additions to the outputs area, and also help non-multisig
> > > cases today.
> > >
> > > ---
> > > Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG:
> > > A3A31BAD 5A2A5B10
> > >
> > >
> >
> > --
> > -----------------
> > 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
>


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

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

<div dir=3D"ltr"><div>Thanks for the reply Peter. Comments inline:</div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">2019=E5=
=B9=B46=E6=9C=8828=E6=97=A5(=E9=87=91) 23:37 Peter D. Gray &lt;<a href=3D"m=
ailto:peter@coinkite.com">peter@coinkite.com</a>&gt;:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">Thanks I get the idea better now: You=
 want the PSBT creator to be<br>
able to indicate to the signers that it (the PSBT creator) controls<br>
specific outputs that don&#39;t otherwise look like change.<br>
<br>
Some problems:<br>
<br>
&gt; extended private key of the current signer derived from the<br>
&gt; signer&#39;s root to m/2042083607&#39;/959190427&#39;/1400854130&#39;/=
990526201&#39;<br>
<br>
1) The PSBT creator would need to know that private key, and the Coldcard, =
as a matter<br>
=C2=A0 =C2=A0of policy, will never export a private subkey.<br></blockquote=
><div><br></div><div><font color=3D"#0000ff">I think you have misunderstood=
. The signature inserted into this 0x02 field is generated BY the signer (C=
oldkey) airgapped ahead of time. Then the signature (and all the xpubs that=
 were signed, since basically the &quot;key&quot; value contains the &quot;=
pubkey&quot; and &quot;message&quot; while the &quot;value&quot; part has t=
he &quot;signature&quot;. so all data items for verification are present.) =
will be stored on the unsigned transaction preparing app. (MyTrezor dot com=
 etc. have an encrypted storage through Dropbox=C2=A0+ encrypting with Trez=
or, so they, for instance, could store the &quot;whitelist signatures&quot;=
 on that dropbox feature.</font></div><div>=C2=A0<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">
2) The &#39;m&#39; in that path depends on who is reading the PSBT file, in=
 the multisig<br>
=C2=A0 =C2=A0case. Each cosigner would need a different version of the PSBT=
 file</blockquote><div><br></div><div><font color=3D"#0000ff">Again, this i=
s the m of the signer&#39;s root. The signer should have an xprv, or some s=
ort of seed (a la BIP39 or aezeed or Electrum phrase etc.) that gets turned=
 into a xprv. That xprv is m in this case... in the case that some offline =
signer is storing the xprv of some path like &quot;xprv/25&#39;/42&#39;&quo=
t; or something, then the signer&#39;s &quot;identity&quot; is whatever xpr=
v that signer holds and not any of the xprvs derived from that first xprv.<=
/font></div><div><font color=3D"#0000ff"><br></font></div><div><font color=
=3D"#0000ff">The reason we want only one HD key to sign it is because we wa=
nt the signer to be able to generate that path from the root xprv they hold=
, check that the pubkey matched the pubkey for verification, then verify. N=
ow the signer knows &quot;oh, I have signed this xpub / multisig setup befo=
re, therefore I trust it&quot;</font></div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">
3) XPUB&#39;s are big and hard to parse, and this addition is using lots of=
 them.<br></blockquote><div><font color=3D"#0000ff"><br></font></div><div><=
font color=3D"#0000ff">Any app requiring this level of security would gladl=
y add a few millisecond for parsing some xpubs.</font></div><div><font colo=
r=3D"#0000ff">Any HD wallet that can sign using HD derived keys already has=
 the necessary tools to parse an xpub.</font><br></div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">
4) Coinjoins, and more complex script types, will want to authorize<br>
=C2=A0 =C2=A0outputs that the PSBT signer may not fully understand. Your pr=
oposal<br>
=C2=A0 =C2=A0would only help P2PKH and M-of-N multisig users.<br></blockquo=
te><div><br></div><div><font color=3D"#0000ff">Yes. This proposal is not a =
requirement. It is just a reservation for a slot in the key-value scheme fo=
r a use case that many exchanges and hardware wallets should implement. We =
have implemented something similar to this using JSON format internally, bu=
t since HW wallet makers seem to be moving toward PSBT adoption, I would lo=
ve for this info to be possible to be sent into an HW wallet so that Trezor=
 etc. can implement this &quot;whitelist&quot; type situation in a way that=
 the Trezor can trust. (remember, a &quot;whitelist&quot; that just lives i=
n my trezor dot com website cache etc. is prone to modification, whereas wi=
th my proposal the worst case is a hacker deletes a signature, so Trezor do=
esn&#39;t trust something it should have, and fails signing. It can not add=
 itself to the &quot;whitelist&quot; without the HW wallet private key.)</f=
ont></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
To fix, may I propose:<br>
<br></blockquote><div><br></div><div><font color=3D"#0000ff">The following =
suggestions seems to be predicated on a misunderstanding of my proposal, so=
 I will hold off for now.</font></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
- the signer and PSBT creator must share a pubkey/private key out of band (=
setup time)<br>
- the origin of that key is out of scope of this standard (but it could be =
derived via BIP32)<br>
- the PSBT creator can, optionally, sign any or all output sections by numb=
er using that key<br>
<br>
I would prefer the signatures are in the global section, and the<br>
signature is over all the bytes in the indicated output section,<br>
as originally serialized when it came into the signer&#39;s possession.<br>
<br>
We should be able to support multiple signers for individual outputs,<br>
and also multiple signatures for the same output section. That would<br>
support different derived keys per co-signer, and also quorum<br>
approval or other policies like that.<br>
<br>
Afterthought: Might be good to allow signature over the unsigned transactio=
n, or<br>
maybe it should be part of the signature always.<br>
<br>
---<br>
Peter D. Gray=C2=A0 ||=C2=A0 Founder, Coinkite=C2=A0 ||=C2=A0 Twitter: @doc=
hex=C2=A0 ||=C2=A0 GPG: A3A31BAD 5A2A5B10<br>
<br>
On Fri, Jun 28, 2019 at 11:44:15AM +0900, Jonathan Underwood wrote:<br>
&gt; Hi Peter,<br>
&gt; <br>
&gt; tl;dr The problem this solves is &quot;How can a signer verify an addr=
ess with<br>
&gt; HD changing the address every time?&quot;<br>
&gt; <br>
&gt; As an aside: (This is sort of explaining the current PR for the 0x01 g=
lobal<br>
&gt; field (separate from mine))<br>
&gt; The problem is more easily understood with change addresses: If someon=
e can<br>
&gt; alter my PSBT before signing, they could replace my change address wit=
h<br>
&gt; their address, and my signer would not know unless the signer just gue=
sses<br>
&gt; all the path sets it knows, then derives thousands of change addresses=
 and<br>
&gt; searches (most likely a signer is offline, so gap limit doesn&#39;t wo=
rk since<br>
&gt; we can&#39;t tell which change addresses have tx history. So the 0x01 =
global<br>
&gt; tag will tell the signer &quot;here&#39;s how you get from your master=
 private key<br>
&gt; to the xpub used in the change output&#39;s output BIP32_DERIVATION ta=
g... you<br>
&gt; can then derive the same key and check it is yours before signing.&quo=
t;<br>
&gt; <br>
&gt; Back to my proposal, this problem extends across wallets, since,<br>
&gt; for example, if I want to send from my cold wallet to my warm wallet, =
I<br>
&gt; don&#39;t want to give my cold signer my warm master key just so it ca=
n derive<br>
&gt; and check the key. That&#39;s what signatures are for. So this proposa=
l says &quot;A<br>
&gt; signer can be built to only sign if it sees a signature that itself ha=
s<br>
&gt; signed, then from that signed xpub(s) derives the BIP32_DERIVATION in =
the<br>
&gt; outputs, and if the output doesn&#39;t match it will reject and not si=
gn&quot;<br>
&gt; <br>
&gt; This creates a sort of &quot;chain of trust&quot; for the wallet.<br>
&gt; <br>
&gt; Currently the best way to prevent this (hacker swapping the send to<br=
>
&gt; address) without using signatures is to reuse the same address every t=
ime<br>
&gt; you want to send to the warm wallet, since after a few times, the sign=
ers<br>
&gt; (people) will be able to remember the address.<br>
&gt; <br>
&gt; This is a huge HD drawback for high security requirement environments.=
<br>
&gt; Having this data in the PSBT standard will allow Trezor etc. to create=
 an<br>
&gt; enforceable whitelist feature.<br>
&gt; <br>
&gt; Let me know if you have feedback on the details.<br>
&gt; <br>
&gt; Thanks,<br>
&gt; Jon<br>
&gt; <br>
&gt; 2019=E5=B9=B46=E6=9C=8828=E6=97=A5(=E9=87=91) 0:07 Peter D. Gray &lt;<=
a href=3D"mailto:peter@coinkite.com" target=3D"_blank">peter@coinkite.com</=
a>&gt;:<br>
&gt; <br>
&gt; &gt; I haven&#39;t studied the new proposal in depth, but my first imp=
ression is:<br>
&gt; &gt;<br>
&gt; &gt; Wouldn&#39;t it just be easier and better to just sign the entire=
 &quot;outputs&quot;<br>
&gt; &gt; section of the PSBT?<br>
&gt; &gt;<br>
&gt; &gt; The signature would cover every byte, and therefore would cover a=
ny<br>
&gt; &gt; future BIP additions to the outputs area, and also help non-multi=
sig<br>
&gt; &gt; cases today.<br>
&gt; &gt;<br>
&gt; &gt; ---<br>
&gt; &gt; Peter D. Gray=C2=A0 ||=C2=A0 Founder, Coinkite=C2=A0 ||=C2=A0 Twi=
tter: @dochex=C2=A0 ||=C2=A0 GPG:<br>
&gt; &gt; A3A31BAD 5A2A5B10<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; <br>
&gt; -- <br>
&gt; -----------------<br>
&gt; Jonathan Underwood<br>
&gt; =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<br>
&gt; -----------------<br>
&gt; <br>
&gt; =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<br>
&gt; <br>
&gt; =E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3<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></div>

--0000000000004904c2058c638afe--