diff options
| author | Jonathan Underwood <junderwood@bitcoinbank.co.jp> | 2019-06-27 18:32:46 +0900 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-06-27 09:33:00 +0000 |
| commit | 9dbd509c7e2fc1cd7deef3e7049f638e27385863 (patch) | |
| tree | ea072997cf7b2c25b42009f99fc68054c2b160f1 | |
| parent | d4912f48f70d16a7d991584748944d10241d0bf7 (diff) | |
| download | pi-bitcoindev-9dbd509c7e2fc1cd7deef3e7049f638e27385863.tar.gz pi-bitcoindev-9dbd509c7e2fc1cd7deef3e7049f638e27385863.zip | |
Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)
| -rw-r--r-- | 33/d8cfdd779da9d43c71962918da034059c79644 | 907 |
1 files changed, 907 insertions, 0 deletions
diff --git a/33/d8cfdd779da9d43c71962918da034059c79644 b/33/d8cfdd779da9d43c71962918da034059c79644 new file mode 100644 index 000000000..996d6bd99 --- /dev/null +++ b/33/d8cfdd779da9d43c71962918da034059c79644 @@ -0,0 +1,907 @@ +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 B0B69E20 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 27 Jun 2019 09:33:00 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com + [209.85.219.172]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9086C710 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 27 Jun 2019 09:32:58 +0000 (UTC) +Received: by mail-yb1-f172.google.com with SMTP id k4so1167791ybo.6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 27 Jun 2019 02:32:58 -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=g8FwbPqLxweAHOT8rKc1nCRVLBUqOk5i5iZL1ZCm9Y8=; + b=SiUcjv/SXxNWMQHMV0wxw732aFMbmUsxYYndbb7hiqlpG8IptRHxapNhUXHGCCITfx + Px9YQ+k91AZDta20gDBCwIRuWSh51Rwcj99QHgSKw8VDX01tI+3G1c4V8VEJ/AaULHC0 + 4oVdYx/pA518Qn/UUxdJl0tz5r8g9nlICsNJwfuUwM7IrPiWGevINdKC8XCmrzMVVt+D + mb9v7Xa0eY7fiiZV++KEmYDLQA2GBqnFOTZQWSwfdHrVuN/b0Prtl0+oTI4QlEgqgFo9 + 7yTKIb9UfALNw8LbszhVQoWgdLCZlnPGRzH3PJOgEeydPl7ay6jv//Vt/RRY6qLoPIJl + d11A== +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=g8FwbPqLxweAHOT8rKc1nCRVLBUqOk5i5iZL1ZCm9Y8=; + b=sbV2ZD8MkXGKW/QUxvybB68N5LZlbT0pek/hBSFLkQtmmEt5V68hSoqyLnxL9XU9eL + BNBGzo+lsdmaTtfxaIME1TPkn7AtsdB1eLUfYMTHCuZSvdsfiQEmJzW3BK4D6jg/hRI4 + J8E4u1I3+Tjp29PCl14in9QmyWKUMHW1INJfR3yNvE9aEey3ETAzr8xjtaphupNDkNJ+ + n1CKH1THVEu9UyHU86ORXP5NRa4V0AvCUDixJ+yzHKHHbR3xlZdT3c/88EVmhLyCuHGe + e0oA7YAjIBqSLAz/IspuO5HTM2q5gvprWrwGwmor0iBWQrWICSJFh1iXv5wt+KFWwc5x + xmdw== +X-Gm-Message-State: APjAAAUYNi0LAPURCudRD+qePrgPZp01O60ZCel0IiKNMnSpvs+GeKm4 + ErgrkZPGR2xUChee/wYH8GfBLIh8ZWY+OR+TLbxi +X-Google-Smtp-Source: APXvYqwFtfX+D0MdwXOI27rzi0idUDWuCcdEaOoB/MGj8KHUe+AV0p5eJE3ESR7dqyjZJOq0RIxSdqWHUA6+yOrhaGA= +X-Received: by 2002:a25:e7d5:: with SMTP id e204mr1803441ybh.522.1561627977420; + Thu, 27 Jun 2019 02:32:57 -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> + <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> +In-Reply-To: <20190627142120.2c24fddb@simplexum.com> +From: Jonathan Underwood <junderwood@bitcoinbank.co.jp> +Date: Thu, 27 Jun 2019 18:32:46 +0900 +Message-ID: <CAMpN3m+0HJm+zZ81ZNP-BXpX_39BvHzwKRAPwpdHinJ13gdNeA@mail.gmail.com> +To: Dmitry Petukhov <dp@simplexum.com> +Content-Type: multipart/alternative; boundary="000000000000ddaf30058c4ad8fe" +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 09:33:00 -0000 + +--000000000000ddaf30058c4ad8fe +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +There is no need, as you can look at the number of xpubs and use that as n. + +Your wallet will not allow {m=3D2}{xpub1}{xpub2} signed message to vouch fo= +r +2 of 4 because you signed 2 of 2 where the n is shown by the number of +xpubs signed. + +There is no need to add the extra byte, except maybe to help people who are +implementing a wallet checking some features to remember to check for the +number of total keys. + +---- + +The expire / revoke problem is a larger problem than this feature can +handle. + +In general, if one of the cold keys is stolen, there is rarely a situation +where you are completely sure the other cold keys haven't been +compromised... so the best practice would be all signers generate new keys +and all funds are moved to a completely new multisig wallet (no common +xpubs). + +- Jonathan + +2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 18:20 Dmitry Petukhov <dp@sim= +plexum.com>: + +> You're right re order of the keys, I forgot that redeem/witness +> scripts are included in outputs. +> +> But regarding the number of the keys, you need to always include all of +> xpubs, because otherwise, if you only put `m` in PSBT, and you use +> 2of3, for example, attacker may put 2 as `m`, two of your xpubs, but +> then use redeem/witness scripts for 2of4, where two other keys are +> under attacker's control. +> +> If you only encode `n`, and allow any 'm of n' scheme, then in 2of3 +> case, if the attackers have control of only one of the keys, they can +> use redeem/witness scripts for 1of3, where two other keys are under +> their control. +> +> It seems to me that you need to sign the whole configuration: +> `n`, `m`, and the xpubs. +> +> And then there's a question of how to conveniently `expire` the keys +> that were compromized. If the attackers have a signature of +> `n+n+xpubs` package for some configuration that include the keys that +> was compromized, they can use that old signed package to fool the +> signer. +> +> Signer would need to somehow distinguish between old and new +> configurations, or you would need to change the keys in all the signers +> even if one is compromized, so the already-signed packages would become +> invalid. +> +> You could do without changing all the keys when only one is compromized +> by including a serial number in the xpub package (but that means signer +> will need to have a state where it would store the latest serial +> number), or you need some message to be included in the package that a +> human can check when manually signing, to ensure that 'obsolete' xpub +> package was not used. +> +> =D0=92 Thu, 27 Jun 2019 17:56:06 +0900 +> Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote: +> +> > The output will have redeemscript and witnessscript so order is not +> > necessary. I can just look at the multisig script and find the pubkey +> > inside it. +> > +> > -Jonathan +> > +> > 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 17:45 Dmitry Petukhov <dp= +@simplexum.com>: +> > +> > > > m value for a multisig (set 0 for non-multisig), followed by 1 or +> > > > more 78 byte serialized extended public keys sorted in canonical +> > > > order +> > > +> > > Sorting xpubs would work if the addresses also sort their pubkeys +> > > (like in BIP67) +> > > +> > > But if the pubkey order in address creation is fixed, you better +> > > have the fixed order for xpubs, otherwise you would need to try all +> > > combinations of derived pubkeys when checking if the addresss match +> > > the presented xpubs. That would be factorial of the number of keys, +> > > not feasible beyond very small number of keys. +> > > +> > > Bitcoin Core, for example, currently does not support BIP67 and +> > > supports only fixed pubkey positions in their script descriptors +> > > specification. +> > > +> > > You also need to include all xpubs to match the address, for m of n +> > > standard multisig, you need to include n and check that number of +> > > keys is exactly n. +> > > +> > > Otherwise your would not be able to construct the address to +> > > compare to the destination address that you need to check, as you +> > > need all pubkesy to construct P2SH or P2WSH address. +> > > +> > > With Shnorr-musig, you probably can interpolate the combined pubkey +> > > out of m paticpant pubkeys (but don't cite me on this, I might be +> > > wrong) +> > > +> > > =D0=92 Thu, 27 Jun 2019 17:16:14 +0900 +> > > Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote: +> > > +> > > > I see what you mean. +> > > > +> > > > What about this? +> > > > +> > > +> https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148= +e3027e?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@simplexum.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 Petu= +khov <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 + +--000000000000ddaf30058c4ad8fe +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">There is no need, as you can look at the number of xpubs a= +nd use that as n.<div><br></div><div>Your wallet will not allow {m=3D2}{xpu= +b1}{xpub2} signed message to vouch for 2 of 4 because you signed 2 of 2 whe= +re the n is shown by the number of xpubs signed.<br><br>There is no need to= + add the extra byte, except maybe to help people who are implementing a wal= +let checking some features to remember to check for the number of total key= +s.</div><div><br></div><div>----</div><div><br></div><div>The expire / revo= +ke problem is a larger problem than this feature can handle.</div><div><br>= +</div><div>In general, if one of the cold keys is stolen, there is rarely a= + situation where you are completely sure the other cold keys haven't be= +en compromised... so the best practice would be all signers generate new ke= +ys and all funds are moved to a completely new multisig wallet (no common x= +pubs).</div><div><br></div><div>- Jonathan</div></div><br><div class=3D"gma= +il_quote"><div dir=3D"ltr" class=3D"gmail_attr">2019=E5=B9=B46=E6=9C=8827= +=E6=97=A5(=E6=9C=A8) 18:20 Dmitry Petukhov <<a href=3D"mailto:dp@simplex= +um.com">dp@simplexum.com</a>>:<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">You're right re order of the keys, I forgot that rede= +em/witness<br> +scripts are included in outputs.<br> +<br> +But regarding the number of the keys, you need to always include all of<br> +xpubs, because otherwise, if you only put `m` in PSBT, and you use<br> +2of3, for example, attacker may put 2 as `m`, two of your xpubs, but<br> +then use redeem/witness scripts for 2of4, where two other keys are<br> +under attacker's control.<br> +<br> +If you only encode `n`, and allow any 'm of n' scheme, then in 2of3= +<br> +case, if the attackers have control of only one of the keys, they can<br> +use redeem/witness scripts for 1of3, where two other keys are under<br> +their control.<br> +<br> +It seems to me that you need to sign the whole configuration:<br> +`n`, `m`, and the xpubs.<br> +<br> +And then there's a question of how to conveniently `expire` the keys<br= +> +that were compromized. If the attackers have a signature of<br> +`n+n+xpubs` package for some configuration that include the keys that<br> +was compromized, they can use that old signed package to fool the<br> +signer.<br> +<br> +Signer would need to somehow distinguish between old and new<br> +configurations, or you would need to change the keys in all the signers<br> +even if one is compromized, so the already-signed packages would become<br> +invalid.<br> +<br> +You could do without changing all the keys when only one is compromized<br> +by including a serial number in the xpub package (but that means signer<br> +will need to have a state where it would store the latest serial<br> +number), or you need some message to be included in the package that a<br> +human can check when manually signing, to ensure that 'obsolete' xp= +ub<br> +package was not used.<br> +<br> +=D0=92 Thu, 27 Jun 2019 17:56:06 +0900<br> +Jonathan Underwood <<a href=3D"mailto:junderwood@bitcoinbank.co.jp" targ= +et=3D"_blank">junderwood@bitcoinbank.co.jp</a>> wrote:<br> +<br> +> The output will have redeemscript and witnessscript so order is not<br= +> +> necessary. I can just look at the multisig script and find the pubkey<= +br> +> inside it.<br> +> <br> +> -Jonathan<br> +> <br> +> 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 17:45 Dmitry Petukhov &l= +t;<a href=3D"mailto:dp@simplexum.com" target=3D"_blank">dp@simplexum.com</a= +>>:<br> +> <br> +> > > m value for a multisig (set 0 for non-multisig), followed by= + 1 or<br> +> > > more 78 byte serialized extended public keys sorted in canon= +ical<br> +> > > order=C2=A0 <br> +> ><br> +> > Sorting xpubs would work if the addresses also sort their pubkeys= +<br> +> > (like in BIP67)<br> +> ><br> +> > But if the pubkey order in address creation is fixed, you better<= +br> +> > have the fixed order for xpubs, otherwise you would need to try a= +ll<br> +> > combinations of derived pubkeys when checking if the addresss mat= +ch<br> +> > the presented xpubs. That would be factorial of the number of key= +s,<br> +> > not feasible beyond very small number of keys.<br> +> ><br> +> > Bitcoin Core, for example, currently does not support BIP67 and<b= +r> +> > supports only fixed pubkey positions in their script descriptors<= +br> +> > specification.<br> +> ><br> +> > You also need to include all xpubs to match the address, for m of= + n<br> +> > standard multisig, you need to include n and check that number of= +<br> +> > keys is exactly n.<br> +> ><br> +> > Otherwise your would not be able to construct the address to<br> +> > compare to the destination address that you need to check, as you= +<br> +> > need all pubkesy to construct P2SH or P2WSH address.<br> +> ><br> +> > With Shnorr-musig, you probably can interpolate the combined pubk= +ey<br> +> > out of m paticpant pubkeys (but don't cite me on this, I migh= +t be<br> +> > wrong)<br> +> ><br> +> > =D0=92 Thu, 27 Jun 2019 17:16:14 +0900<br> +> > Jonathan Underwood <<a href=3D"mailto:junderwood@bitcoinbank.c= +o.jp" target=3D"_blank">junderwood@bitcoinbank.co.jp</a>> wrote:<br> +> >=C2=A0 <br> +> > > I see what you mean.<br> +> > ><br> +> > > What about this?<br> +> > >=C2=A0 <br> +> > <a href=3D"https://github.com/junderw/bips/commit/57a57b4fae1ae14= +b77a2eebd99cd719148e3027e?short_path=3D82656c8#diff-82656c833e31e6751a412ce= +5e5c70920" rel=3D"noreferrer" target=3D"_blank">https://github.com/junderw/= +bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=3D82656c8#d= +iff-82656c833e31e6751a412ce5e5c70920</a>=C2=A0 <br> +> > ><br> +> > > Plus side: for single sig case, the key only increases by on= +e byte<br> +> > > (0x00 for the {m} value)<br> +> > ><br> +> > > This way if it was 2 of 3 like before, you sign the whole<br= +> +> > > "packet" so each key only signs the packet once. W= +ay better than<br> +> > > n!<br> +> > ><br> +> > > Anywho. Please send your feedback. Thanks.<br> +> > > Jonathan<br> +> > ><br> +> > > 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 16:27 Dmitry P= +etukhov <<a href=3D"mailto:dp@simplexum.com" target=3D"_blank">dp@simple= +xum.com</a>>:<br> +> > >=C2=A0 <br> +> > > > How would signer know that there _should_ be at least 3= +<br> +> > > > signatures signed by the key owned by this signer ?<br> +> > > ><br> +> > > > If it does not know that it should enforce 2of3 multisi= +g, for<br> +> > > > example, the attacker that control only one key A can f= +ool<br> +> > > > signer B by sending to 1of1 single-sig that is derived = +from A's<br> +> > > > xpub, and providing only sBxA in PSBT.<br> +> > > ><br> +> > > > If the signer does not have a hardcoded configuration t= +hat<br> +> > > > will mandate a particular multisig scheme, it will allo= +w<br> +> > > > sending to any scheme.<br> +> > > ><br> +> > > > If the signer has a rich enough state to store updatabl= +e<br> +> > > > configuration, it can just store the trusted xpubs dire= +ctly.<br> +> > > ><br> +> > > > Alternatively, signer can sign not individual xpubs, bu= +t whole<br> +> > > > xpub packages that correspond to particular multisig<br= +> +> > > > configuration, and enforce that destination addresses<b= +r> +> > > > correspond to this configuration.<br> +> > > ><br> +> > > > But this would not be possible with your PSBT scheme th= +at 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@bit= +coinbank.co.jp" target=3D"_blank">junderwood@bitcoinbank.co.jp</a>> wrot= +e:<br> +> > > >=C2=A0 <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 signatur= +es are:<br> +> > > > > sAxB<br> +> > > > > sAxC<br> +> > > > > sBxA<br> +> > > > > sBxC<br> +> > > > > sCxA<br> +> > > > > sCxB<br> +> > > > ><br> +> > > > > We can then create a wallet that says "when v= +erifying change<br> +> > > > > with 0x01 global type proposed by Andrew Chow, if = +the change<br> +> > > > > is multisig, we MUST require the other pubkeys to = +have<br> +> > > > > signatures via my 0x02 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<br> +> > > > > by deriving the xpub and checking equality to the<= +br> +> > > > > BIP_DERIVATION of the output... it will then check= + the OTHER<br> +> > > > > pubkeys via BIP32_DERIVATION to master fingerprint= +, then link<br> +> > > > > that fingerprint to a 0x02 sig from MY key, verify= +ing all<br> +> > > > > pubkeys.<br> +> > > > ><br> +> > > > > So this proposal of mine would not only fix the &q= +uot;send to<br> +> > > > > address verification" problem for HD, but als= +o the multisig<br> +> > > > > change problem with 0x01.<br> +> > > > ><br> +> > > > > Cool.<br> +> > > > ><br> +> > > > > Only thing that is kind of sad is having to includ= +e n! (of<br> +> > > > > m-of-n) signatures in every PSBT... but tbh, the P= +SBT size is<br> +> > > > > not of much 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:4= +9 Dmitry Petukhov <<a href=3D"mailto:dp@simplexum.com" target=3D"_blank"= +>dp@simplexum.com</a>>:<br> +> > > > >=C2=A0 <br> +> > > > > > Hi!<br> +> > > > > ><br> +> > > > > > I wonder how your scheme handles multisig ?<b= +r> +> > > > > ><br> +> > > > > > As I understand, you sign individual xpubs wi= +th cold keys,<br> +> > > > > > so that cold keys can check destination addre= +sses are<br> +> > > > > > trusted.<br> +> > > > > ><br> +> > > > > > I seems to me that if you sign individual xpu= +bs of a<br> +> > > > > > multisig warm wallet, and one key from that m= +ultisig is<br> +> > > > > > compromized, attackers can then create a sing= +le-sig<br> +> > > > > > destination address that they control, and mo= +ve the coins<br> +> > > > > > in a chain of two transactions, first to this= + single-sig<br> +> > > > > > address, and then to an address that they ind= +ependently<br> +> > > > > > control.<br> +> > > > > ><br> +> > > > > > My idea to prevent this [1] is to sign the wh= +ole 'xpub<br> +> > > > > > package' of the multisig wallet, but ther= +e is also an issue<br> +> > > > > > of 'partial compromize', where some o= +f the keys in a<br> +> > > > > > multisig warm wallet is compromized, and you = +do not want to<br> +> > > > > > regard a particular 'xpub package' as= + trusted. My idea was<br> +> > > > > > [2] to use an auxiliary message that would be= + signed along<br> +> > > > > > with the 'xpub package', and that mes= +sage can include<br> +> > > > > > specific 'epoch' word that hardware w= +allet can show<br> +> > > > > > prominently before signing, or have 'seri= +al number' for<br> +> > > > > > xpub packages (but that will require to store= + last known<br> +> > > > > > serial inside hw wallet, making it stateful).= +<br> +> > > > > ><br> +> > > > > > I like the idea to extend PSBT to accomodate = +these schemes,<br> +> > > > > > but given that the huge number of possible sc= +hemes that<br> +> > > > > > each may probably require its own PSBT field = +type, I think<br> +> > > > > > that this is better dealt with outside of PSB= +T, as 'PSBT<br> +> > > > > > metainformation', or using some form of &= +#39;vendor-specific',<br> +> > > > > > or 'metainformation-specific' PSBT fi= +eld. This way each<br> +> > > > > > usecase can be independently described in its= + own<br> +> > > > > > documentation, that would include the particu= +lars of the<br> +> > > > > > format for the metainformation. This would al= +so make it<br> +> > > > > > easier to implement PSBT for simple cases, be= +cause the<br> +> > > > > > 'core specification' would not grow t= +hat big.<br> +> > > > > ><br> +> > > > > > [1]<br> +> > > > > ><br> +> > > > > >=C2=A0 <br> +> > > >=C2=A0 <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> +> >=C2=A0 <br> +> > > > > ><br> +> > > > > > [2]<br> +> > > > > ><br> +> > > > > >=C2=A0 <br> +> > > >=C2=A0 <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> +> >=C2=A0 <br> +> > > > > ><br> +> > > > > ><br> +> > > > > > =D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonath= +an Underwood via<br> +> > > > > > bitcoin-dev <<a href=3D"mailto:bitcoin-dev= +@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda= +tion.org</a>> wrote:<br> +> > > > > >=C2=A0 <br> +> > > > > > > Hello all,<br> +> > > > > > ><br> +> > > > > > > Just wanted to pick your brains about an= + idea for PSBT<br> +> > > > > > > extension.<br> +> > > > > > ><br> +> > > > > > > One problem we try to solve with cold -&= +gt; warm and warm -><br> +> > > > > > > hot sends for our exchange wallet is &qu= +ot;How do I know that<br> +> > > > > > > the address I am sending to is not a hac= +ker's address<br> +> > > > > > > that was swapped in between unsigned tx = +creation and<br> +> > > > > > > first signature?"<br> +> > > > > > ><br> +> > > > > > > We have a proprietary JSON based encodin= +g system which we<br> +> > > > > > > are looking to move towards PSBT, but PS= +BT is missing<br> +> > > > > > > this key functionality.<br> +> > > > > > ><br> +> > > > > > > BIP32_DERIVATION does allow us to verify= + the address is<br> +> > > > > > > from a certain XPUB, but, for example, i= +t can not allow<br> +> > > > > > > us to verify a signature of that xpub.<b= +r> +> > > > > > ><br> +> > > > > > > I have made a rough draft of the propose= +d key value<br> +> > > > > > > specification.=C2=A0 <br> +> > > > > >=C2=A0 <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> +> > > >=C2=A0 <br> +> > > > > > ><br> +> > > > > > > The signing key path used in the spec is= + just randomly<br> +> > > > > > > chosen 31 x 4 bits shown as numbers with= + hardened paths.<br> +> > > > > > ><br> +> > > > > > > Since this issue seems similar to the ch= +ange address<br> +> > > > > > > issue, I started from that as a base. Wi= +th the HW wallet<br> +> > > > > > > case, I can verify the xpub by just deri= +ving it locally<br> +> > > > > > > and comparing equality, however, in our = +case, we need to<br> +> > > > > > > verify an xpub that we do not have acces= +s to via<br> +> > > > > > > derivation from our cold key(s) (since w= +e don't want to<br> +> > > > > > > import our warm private key into our col= +d 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 t= +he xpub with all<br> +> > > > > > > cold keys. 3. Upload the signature/xpub = +pairs to the<br> +> > > > > > > online unsigned transaction generator.<b= +r> +> > > > > > > 4. Include one keyval pair per coldkey/x= +pub pairing.<br> +> > > > > > > 5. When offline signing, if the wallet d= +etects there is a<br> +> > > > > > > global keyval XPUB_SIGNATURE with its pu= +bkey in the key,<br> +> > > > > > > it must verify that all outputs have BIP= +32_DERIVATION and<br> +> > > > > > > that it can verify the outputs through t= +he derivation, to<br> +> > > > > > > the xpub, and to the signature.<br> +> > > > > > ><br> +> > > > > > > In my attempt to fitting this into PSBT,= + I am slightly<br> +> > > > > > > altering our current system, so don'= +t take this as an<br> +> > > > > > > indication 100% of how we work in the ba= +ckend.<br> +> > > > > > ><br> +> > > > > > > However, I would like to hear any feedba= +ck on this<br> +> > > > > > > proposal.<br> +> > > > > > ><br> +> > > > > > > Thanks,<br> +> > > > > > > Jonathan<br> +> > > > > > >=C2=A0 <br> +> > > > > ><br> +> > > > > >=C2=A0 <br> +> > > > >=C2=A0 <br> +> > > ><br> +> > > >=C2=A0 <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> + +--000000000000ddaf30058c4ad8fe-- + |