Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B0B69E20 for ; 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 ; Thu, 27 Jun 2019 09:32:58 +0000 (UTC) Received: by mail-yb1-f172.google.com with SMTP id k4so1167791ybo.6 for ; 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: <20190627095031.4d5817b8@simplexum.com> <20190627122916.3b6c2c32@simplexum.com> <20190627134628.4d131264@simplexum.com> <20190627142120.2c24fddb@simplexum.com> In-Reply-To: <20190627142120.2c24fddb@simplexum.com> From: Jonathan Underwood Date: Thu, 27 Jun 2019 18:32:46 +0900 Message-ID: To: Dmitry Petukhov 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 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 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 : > 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 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 : > > > > > > 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 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= : > > > > > > > > > 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 Petu= khov : > > > > > > > > > > > > > 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 --000000000000ddaf30058c4ad8fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is no need, as you can look at the number of xpubs a= nd use that as n.

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.

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.

----

The expire / revo= ke 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 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).

- Jonathan

2019=E5=B9=B46=E6=9C=8827= =E6=97=A5(=E6=9C=A8) 18:20 Dmitry Petukhov <dp@simplexum.com>:
You're right re order of the keys, I forgot that rede= em/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' xp= ub
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<= br> > inside it.
>
> -Jonathan
>
> 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 17:45 Dmitry Petukhov &l= t;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 canon= ical
> > > order=C2=A0
> >
> > 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<= br> > > have the fixed order for xpubs, otherwise you would need to try a= ll
> > combinations of derived pubkeys when checking if the addresss mat= ch
> > the presented xpubs. That would be factorial of the number of key= s,
> > 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<= br> > > 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 pubk= ey
> > out of m paticpant pubkeys (but don't cite me on this, I migh= t be
> > wrong)
> >
> > =D0=92 Thu, 27 Jun 2019 17:16:14 +0900
> > Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote:
> >=C2=A0
> > > I see what you mean.
> > >
> > > What about this?
> > >=C2=A0
> > https://github.com/junderw/= bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=3D82656c8#d= iff-82656c833e31e6751a412ce5e5c70920=C2=A0
> > >
> > > Plus side: for single sig case, the key only increases by on= e 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. W= ay 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 P= etukhov <dp@simple= xum.com>:
> > >=C2=A0
> > > > 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 multisi= g, for
> > > > example, the attacker that control only one key A can f= ool
> > > > 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 t= hat
> > > > will mandate a particular multisig scheme, it will allo= w
> > > > sending to any scheme.
> > > >
> > > > If the signer has a rich enough state to store updatabl= e
> > > > configuration, it can just store the trusted xpubs dire= ctly.
> > > >
> > > > Alternatively, signer can sign not individual xpubs, bu= t 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 th= at uses
> > > > individual key-xpub pairs.
> > > >
> > > > =D0=92 Thu, 27 Jun 2019 14:07:47 +0900
> > > > Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrot= e:
> > > >=C2=A0
> > > > > 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 signatur= es are:
> > > > > sAxB
> > > > > sAxC
> > > > > sBxA
> > > > > sBxC
> > > > > sCxA
> > > > > sCxB
> > > > >
> > > > > We can then create a wallet that says "when v= erifying 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.<= br> > > > > > 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<= br> > > > > > 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, verify= ing all
> > > > > pubkeys.
> > > > >
> > > > > So this proposal of mine would not only fix the &q= uot;send to
> > > > > address verification" problem for HD, but als= o the multisig
> > > > > change problem with 0x01.
> > > > >
> > > > > Cool.
> > > > >
> > > > > Only thing that is kind of sad is having to includ= e n! (of
> > > > > m-of-n) signatures in every PSBT... but tbh, the P= SBT 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:4= 9 Dmitry Petukhov <dp@simplexum.com>:
> > > > >=C2=A0
> > > > > > Hi!
> > > > > >
> > > > > > I wonder how your scheme handles multisig ? > > > > > >
> > > > > > As I understand, you sign individual xpubs wi= th cold keys,
> > > > > > so that cold keys can check destination addre= sses are
> > > > > > trusted.
> > > > > >
> > > > > > I seems to me that if you sign individual xpu= bs of a
> > > > > > multisig warm wallet, and one key from that m= ultisig is
> > > > > > compromized, attackers can then create a sing= le-sig
> > > > > > destination address that they control, and mo= ve the coins
> > > > > > in a chain of two transactions, first to this= single-sig
> > > > > > address, and then to an address that they ind= ependently
> > > > > > control.
> > > > > >
> > > > > > My idea to prevent this [1] is to sign the wh= ole 'xpub
> > > > > > package' of the multisig wallet, but ther= e is also an issue
> > > > > > of 'partial compromize', where some o= f 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 mes= sage can include
> > > > > > specific 'epoch' word that hardware w= allet can show
> > > > > > prominently before signing, or have 'seri= al 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 sc= hemes that
> > > > > > each may probably require its own PSBT field = type, I think
> > > > > > that this is better dealt with outside of PSB= T, as 'PSBT
> > > > > > metainformation', or using some form of &= #39;vendor-specific',
> > > > > > or 'metainformation-specific' PSBT fi= eld. This way each
> > > > > > usecase can be independently described in its= own
> > > > > > documentation, that would include the particu= lars of the
> > > > > > format for the metainformation. This would al= so make it
> > > > > > easier to implement PSBT for simple cases, be= cause the
> > > > > > 'core specification' would not grow t= hat big.
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >=C2=A0
> > > >=C2=A0
> > https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html
> >=C2=A0
> > > > > >
> > > > > > [2]
> > > > > >
> > > > > >=C2=A0
> > > >=C2=A0
> > https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html
> >=C2=A0
> > > > > >
> > > > > >
> > > > > > =D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonath= an Underwood via
> > > > > > bitcoin-dev <bitcoin-dev@lists.linuxfounda= tion.org> wrote:
> > > > > >=C2=A0
> > > > > > > Hello all,
> > > > > > >
> > > > > > > Just wanted to pick your brains about an= idea for PSBT
> > > > > > > extension.
> > > > > > >
> > > > > > > One problem we try to solve with cold -&= gt; warm and warm ->
> > > > > > > hot sends for our exchange wallet is &qu= ot;How do I know that
> > > > > > > the address I am sending to is not a hac= ker's address
> > > > > > > that was swapped in between unsigned tx = creation and
> > > > > > > first signature?"
> > > > > > >
> > > > > > > We have a proprietary JSON based encodin= g system which we
> > > > > > > are looking to move towards PSBT, but PS= BT is missing
> > > > > > > this key functionality.
> > > > > > >
> > > > > > > BIP32_DERIVATION does allow us to verify= the address is
> > > > > > > from a certain XPUB, but, for example, i= t can not allow
> > > > > > > us to verify a signature of that xpub. > > > > > > >
> > > > > > > I have made a rough draft of the propose= d key value
> > > > > > > specification.=C2=A0
> > > > > >=C2=A0
> > > >=C2=A0
> > https://gi= thub.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification= =C2=A0
> > > >=C2=A0
> > > > > > >
> > > > > > > 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 ch= ange address
> > > > > > > issue, I started from that as a base. Wi= th the HW wallet
> > > > > > > case, I can verify the xpub by just deri= ving it locally
> > > > > > > and comparing equality, however, in our = case, we need to
> > > > > > > verify an xpub that we do not have acces= s to via
> > > > > > > derivation from our cold key(s) (since w= e don't want to
> > > > > > > import our warm private key into our col= d signer)
> > > > > > >
> > > > > > > So the flow would be:
> > > > > > > 1. Securely verify the xpub of the warm = / hot wallet.
> > > > > > > 2. Using the airgap signing tool, sign t= he xpub with all
> > > > > > > cold keys. 3. Upload the signature/xpub = pairs to the
> > > > > > > online unsigned transaction generator. > > > > > > > 4. Include one keyval pair per coldkey/x= pub pairing.
> > > > > > > 5. When offline signing, if the wallet d= etects there is a
> > > > > > > global keyval XPUB_SIGNATURE with its pu= bkey in the key,
> > > > > > > it must verify that all outputs have BIP= 32_DERIVATION and
> > > > > > > that it can verify the outputs through t= he 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 ba= ckend.
> > > > > > >
> > > > > > > However, I would like to hear any feedba= ck on this
> > > > > > > proposal.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Jonathan
> > > > > > >=C2=A0
> > > > > >
> > > > > >=C2=A0
> > > > >=C2=A0
> > > >
> > > >=C2=A0
> > >=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
--000000000000ddaf30058c4ad8fe--