MIME-Version: 1.0
From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Date: Thu, 27 Jun 2019 11:11:23 +0900
Message-ID: <CAMpN3mLvY+kuUGqzMW6SAMZ=h46_g=XLhDPhSY=X6xhLxvi15Q@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000644589058c44ae2c"
Subject: [bitcoin-dev] BIP174 extension proposal (Global Type:
	PSBT_GLOBAL_XPUB_SIGNATURE)
Precedence: list

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

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#specific=
ation

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

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

<div dir=3D"ltr">Hello all,<div><br></div><div>Just wanted to pick your bra=
ins about an idea for PSBT extension.</div><div><br></div><div>One problem =
we try to solve with cold -&gt; warm and warm -&gt; hot sends for our excha=
nge wallet is &quot;How do I know that the address I am sending to is not a=
 hacker&#39;s address that was swapped in between unsigned tx creation and =
first signature?&quot;</div><div><div><br></div><div>We have a proprietary =
JSON based encoding system which we are looking to move towards PSBT, but P=
SBT is missing this key functionality.<br><br>BIP32_DERIVATION does allow u=
s to verify the address is from a certain XPUB, but, for example, it can no=
t allow us to verify a signature of that xpub.<br><br>I have made a rough d=
raft of the proposed key value specification.<br><a href=3D"https://github.=
com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification">https://=
github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification</a=
><br></div><div><br></div><div>The signing key path used in the spec is jus=
t randomly chosen 31 x 4 bits shown as numbers with hardened paths.</div><d=
iv><br></div><div>Since this issue seems similar to the change address issu=
e, 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 c=
ase, we need to verify an xpub that we do not have access to via derivation=
 from our cold key(s) (since we don&#39;t want to import our warm private k=
ey into our cold signer)</div><div><br></div><div>So the flow would be:</di=
v><div>1. Securely verify the xpub of the warm / hot wallet.</div><div>2. U=
sing the airgap signing tool, sign the xpub with all cold keys.</div><div>3=
. Upload the signature/xpub pairs to the online unsigned transaction genera=
tor.<br>4. Include one keyval pair per coldkey/xpub pairing.<br>5. When off=
line 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_DER=
IVATION and that it can verify the outputs through the derivation, to the x=
pub, and to the signature.</div><div><br></div><div>In my attempt to fittin=
g this into PSBT, I am slightly altering our current system, so don&#39;t t=
ake this as an indication 100% of how we work in the backend.</div><div><br=
></div><div>However, I would like to hear any feedback on this proposal.</d=
iv><div><br></div><div>Thanks,</div><div>Jonathan</div><div><br></div>-- <b=
r><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signat=
ure"><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: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3</=
div></div></div></div></div></div></div></div>

--000000000000644589058c44ae2c--