diff options
author | Jonathan Underwood <junderwood@bitcoinbank.co.jp> | 2019-06-27 17:16:14 +0900 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2019-06-27 08:16:29 +0000 |
commit | 3fac7fb093ea48acfce332e7d08f9304b157106e (patch) | |
tree | 445ea847f8292cbf474d8d8f02fee2f8961b600c | |
parent | 84b3804f6594624bc6d8764ab56748850f57d74c (diff) | |
download | pi-bitcoindev-3fac7fb093ea48acfce332e7d08f9304b157106e.tar.gz pi-bitcoindev-3fac7fb093ea48acfce332e7d08f9304b157106e.zip |
Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)
-rw-r--r-- | 52/51d73a8288e429acda7d82c3ae4f094e89ee23 | 572 |
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 "packet"= + 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>>:<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'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 <<a href=3D"mailto:junderwood@bitcoinbank.co.jp" targ= +et=3D"_blank">junderwood@bitcoinbank.co.jp</a>> wrote:<br> +<br> +> Thanks for the reply.<br> +> <br> +> The way we would do it is:<br> +> <br> +> Let's say we have 3 cold keys for multisig: A B and C<br> +> <br> +> Whose xpubs are: xA xB and xC<br> +> <br> +> We all sign each other's xpubs, whose signatures are:<br> +> sAxB<br> +> sAxC<br> +> sBxA<br> +> sBxC<br> +> sCxA<br> +> sCxB<br> +> <br> +> We can then create a wallet that says "when verifying change with= + 0x01<br> +> global type proposed by Andrew Chow, if the change is multisig, we<br> +> MUST require the other pubkeys to have signatures via my 0x02<br> +> proposal"<br> +> <br> +> This way, all my PSBTs for my cold will have:<br> +> 1. an 0x01 entry to tell me how to get my change.<br> +> 2. All 6 of the signatures above.<br> +> <br> +> And the signer will then look at the change, check my pubkey by<br> +> deriving the xpub and checking equality to the BIP_DERIVATION of the<b= +r> +> output... it will then check the OTHER pubkeys via BIP32_DERIVATION<br= +> +> to master fingerprint, then link that fingerprint to a 0x02 sig from<b= +r> +> MY key, verifying all pubkeys.<br> +> <br> +> So this proposal of mine would not only fix the "send to address<= +br> +> verification" problem for HD, but also the multisig change proble= +m<br> +> with 0x01.<br> +> <br> +> Cool.<br> +> <br> +> Only thing that is kind of sad is having to include n! (of m-of-n)<br> +> signatures in every PSBT... but tbh, the PSBT size is not of much<br> +> concern.<br> +> <br> +> Thanks for the reply.<br> +> - Jonathan<br> +> <br> +> <br> +> 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= +>>:<br> +> <br> +> > Hi!<br> +> ><br> +> > I wonder how your scheme handles multisig ?<br> +> ><br> +> > As I understand, you sign individual xpubs with cold keys, so tha= +t<br> +> > cold keys can check destination addresses are trusted.<br> +> ><br> +> > I seems to me that if you sign individual xpubs of a multisig war= +m<br> +> > wallet, and one key from that multisig is compromized, attackers = +can<br> +> > then create a single-sig destination address that they control, a= +nd<br> +> > move the coins in a chain of two transactions, first to this<br> +> > single-sig address, and then to an address that they independentl= +y<br> +> > control.<br> +> ><br> +> > My idea to prevent this [1] is to sign the whole 'xpub packag= +e' of<br> +> > the multisig wallet, but there is also an issue of 'partial<b= +r> +> > compromize', where some of the keys in a multisig warm wallet= + is<br> +> > compromized, and you do not want to regard a particular 'xpub= +<br> +> > package' as trusted. My idea was [2] to use an auxiliary mess= +age<br> +> > that would be signed along with the 'xpub package', and t= +hat<br> +> > message can include specific 'epoch' word that hardware w= +allet can<br> +> > show prominently before signing, or have 'serial number' = +for xpub<br> +> > packages (but that will require to store last known serial inside= +<br> +> > hw wallet, making it stateful).<br> +> ><br> +> > I like the idea to extend PSBT to accomodate these schemes, but<b= +r> +> > given that the huge number of possible schemes that each may<br> +> > probably require its own PSBT field type, I think that this is<br= +> +> > better dealt with outside of PSBT, as 'PSBT metainformation&#= +39;, or<br> +> > using some form of 'vendor-specific', or 'metainforma= +tion-specific'<br> +> > PSBT field. This way each usecase can be independently described = +in<br> +> > its own documentation, that would include the particulars of the<= +br> +> > format for the metainformation. This would also make it easier to= +<br> +> > implement PSBT for simple cases, because the 'core specificat= +ion'<br> +> > would not grow that big.<br> +> ><br> +> > [1]<br> +> ><br> +> > <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> +> ><br> +> > [2]<br> +> ><br> +> > <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> +> ><br> +> ><br> +> > =D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via bit= +coin-dev<br> +> > <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ= +et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +> >=C2=A0 <br> +> > > Hello all,<br> +> > ><br> +> > > Just wanted to pick your brains about an idea for PSBT exten= +sion.<br> +> > ><br> +> > > One problem we try to solve with cold -> warm and warm -&= +gt; hot<br> +> > > sends for our exchange wallet is "How do I know that th= +e address<br> +> > > I am sending to is not a hacker's address that was swapp= +ed in<br> +> > > between unsigned tx creation and first signature?"<br> +> > ><br> +> > > We have a proprietary JSON based encoding system which we ar= +e<br> +> > > looking to move towards PSBT, but PSBT is missing this key<b= +r> +> > > functionality.<br> +> > ><br> +> > > BIP32_DERIVATION does allow us to verify the address is from= + a<br> +> > > certain XPUB, but, for example, it can not allow us to verif= +y a<br> +> > > signature of that xpub.<br> +> > ><br> +> > > I have made a rough draft of the proposed key value specific= +ation.<br> +> > >=C2=A0 <br> +> > <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> +> > ><br> +> > > The signing key path used in the spec is just randomly chose= +n 31<br> +> > > x 4 bits shown as numbers with hardened paths.<br> +> > ><br> +> > > Since this issue seems similar to the change address issue, = +I<br> +> > > started from that as a base. With the HW wallet case, I can<= +br> +> > > verify the xpub by just deriving it locally and comparing<br= +> +> > > equality, however, in our case, we need to verify an xpub th= +at we<br> +> > > do not have access to via derivation from our cold key(s) (s= +ince<br> +> > > we don't want to import our warm private key into our co= +ld signer)<br> +> > ><br> +> > > So the flow would be:<br> +> > > 1. Securely verify the xpub of the warm / hot wallet.<br> +> > > 2. Using the airgap signing tool, sign the xpub with all col= +d<br> +> > > keys. 3. Upload the signature/xpub pairs to the online unsig= +ned<br> +> > > transaction generator.<br> +> > > 4. Include one keyval pair per coldkey/xpub pairing.<br> +> > > 5. When offline signing, if the wallet detects there is a gl= +obal<br> +> > > keyval XPUB_SIGNATURE with its pubkey in the key, it must ve= +rify<br> +> > > that all outputs have BIP32_DERIVATION and that it can verif= +y the<br> +> > > outputs through the derivation, to the xpub, and to the sign= +ature.<br> +> > ><br> +> > > In my attempt to fitting this into PSBT, I am slightly alter= +ing<br> +> > > our current system, so don't take this as an indication = +100% of<br> +> > > how we work in the backend.<br> +> > ><br> +> > > However, I would like to hear any feedback on this proposal.= +<br> +> > ><br> +> > > Thanks,<br> +> > > Jonathan<br> +> > >=C2=A0 <br> +> ><br> +> >=C2=A0 <br> +> <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-- + |