summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJonathan Underwood <junderwood@bitcoinbank.co.jp>2019-06-27 17:16:14 +0900
committerbitcoindev <bitcoindev@gnusha.org>2019-06-27 08:16:29 +0000
commit3fac7fb093ea48acfce332e7d08f9304b157106e (patch)
tree445ea847f8292cbf474d8d8f02fee2f8961b600c
parent84b3804f6594624bc6d8764ab56748850f57d74c (diff)
downloadpi-bitcoindev-3fac7fb093ea48acfce332e7d08f9304b157106e.tar.gz
pi-bitcoindev-3fac7fb093ea48acfce332e7d08f9304b157106e.zip
Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)
-rw-r--r--52/51d73a8288e429acda7d82c3ae4f094e89ee23572
1 files changed, 572 insertions, 0 deletions
diff --git a/52/51d73a8288e429acda7d82c3ae4f094e89ee23 b/52/51d73a8288e429acda7d82c3ae4f094e89ee23
new file mode 100644
index 000000000..c92e40fe0
--- /dev/null
+++ b/52/51d73a8288e429acda7d82c3ae4f094e89ee23
@@ -0,0 +1,572 @@
+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--
+