From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 18918927 for ; 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 ; Thu, 27 Jun 2019 08:16:26 +0000 (UTC) Received: by mail-yw1-f50.google.com with SMTP id u134so968055ywf.6 for ; 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: <20190627095031.4d5817b8@simplexum.com> <20190627122916.3b6c2c32@simplexum.com> In-Reply-To: <20190627122916.3b6c2c32@simplexum.com> From: Jonathan Underwood Date: Thu, 27 Jun 2019 17:16:14 +0900 Message-ID: To: Dmitry Petukhov 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 : > 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 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 : > > > > > 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 > > > 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
I see what you mean.

What about this?



2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 16:27 Dmitry Petukhov &= lt;dp@simplexum.com>:
<= 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
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<= br> > verification" problem for HD, but also the multisig change proble= m
> 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 &l= t;dp@simplexum.com>:
>
> > Hi!
> >
> > I wonder how your scheme handles multisig ?
> >
> > As I understand, you sign individual xpubs with cold keys, so tha= t
> > cold keys can check destination addresses are trusted.
> >
> > I seems to me that if you sign individual xpubs of a multisig war= m
> > wallet, and one key from that multisig is compromized, attackers = can
> > then create a single-sig destination address that they control, a= nd
> > move the coins in a chain of two transactions, first to this
> > single-sig address, and then to an address that they independentl= y
> > control.
> >
> > My idea to prevent this [1] is to sign the whole 'xpub packag= e' 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 mess= age
> > that would be signed along with the 'xpub package', and t= hat
> > message can include specific 'epoch' word that hardware w= allet 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&#= 39;, or
> > using some form of 'vendor-specific', or 'metainforma= tion-specific'
> > PSBT field. This way each usecase can be independently described = in
> > its own documentation, that would include the particulars of the<= br> > > format for the metainformation. This would also make it easier to=
> > implement PSBT for simple cases, because the 'core specificat= ion'
> > would not grow that big.
> >
> > [1]
> >
> > https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html
> >
> > [2]
> >
> > https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html
> >
> >
> > =D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via bit= coin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >=C2=A0
> > > Hello all,
> > >
> > > Just wanted to pick your brains about an idea for PSBT exten= sion.
> > >
> > > One problem we try to solve with cold -> warm and warm -&= gt; hot
> > > sends for our exchange wallet is "How do I know that th= e address
> > > I am sending to is not a hacker's address that was swapp= ed in
> > > between unsigned tx creation and first signature?"
> > >
> > > We have a proprietary JSON based encoding system which we ar= e
> > > 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 verif= y a
> > > signature of that xpub.
> > >
> > > I have made a rough draft of the proposed key value specific= ation.
> > >=C2=A0
> > https://gi= thub.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification= =C2=A0
> > >
> > > The signing key path used in the spec is just randomly chose= n 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<= br> > > > verify the xpub by just deriving it locally and comparing > > > equality, however, in our case, we need to verify an xpub th= at we
> > > do not have access to via derivation from our cold key(s) (s= ince
> > > we don't want to import our warm private key into our co= ld 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 col= d
> > > keys. 3. Upload the signature/xpub pairs to the online unsig= ned
> > > transaction generator.
> > > 4. Include one keyval pair per coldkey/xpub pairing.
> > > 5. When offline signing, if the wallet detects there is a gl= obal
> > > keyval XPUB_SIGNATURE with its pubkey in the key, it must ve= rify
> > > that all outputs have BIP32_DERIVATION and that it can verif= y the
> > > outputs through the derivation, to the xpub, and to the sign= ature.
> > >
> > > In my attempt to fitting this into PSBT, I am slightly alter= ing
> > > 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
> > >=C2=A0
> >
> >=C2=A0
>



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

=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: 0xCE5EA9476DE7D3E45EBC3= FDAD998682F3590FEA3
--0000000000002ef169058c49c7f2--