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 931C8C4E for ; Thu, 27 Jun 2019 08:59:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw1-f41.google.com (mail-yw1-f41.google.com [209.85.161.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2D36710 for ; Thu, 27 Jun 2019 08:59:56 +0000 (UTC) Received: by mail-yw1-f41.google.com with SMTP id q128so1040286ywc.1 for ; Thu, 27 Jun 2019 01:59:56 -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=kuvVeZVi0ac1dLTTwJeio+AIR/+aXq2NYLasVDYwnaE=; b=cB7xzFm5R/VEMemByYwNWe0JLKaohueNjjGm0R47ow1Hr/USKh+oYp9K6GbEH++JnC h/kZHLmV+yFNDAZC6JUnjF+pS/sMR0pzxxVhPGUnQnaVJD3d6UOvZHHxuNQdSagBxRa/ bQHtyxijFYmTdUhhEbiDYng94L7xizHvxcWOUZwXlX/DiqjRaSPv5h0b0M2JwZNOTH/V tHPprYMMXsA5xdX2/25qu1w5v8m5WSgX6ilVw9864w4sj1GvTksvrsTP289bUUWP1M+X XCVeY+yUgiu7M5U6lcEtE/iUZcD6n3MpN4bNlDM+2qiMVgY0Yp2mvqpj3MZs/Mh+YiUq D0mw== 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=kuvVeZVi0ac1dLTTwJeio+AIR/+aXq2NYLasVDYwnaE=; b=GT2VDKvqvGOc8UTfete2NI9nt9vqr7yADphl1co3IwU3FUrefFFWvlSsRdqE1XFtfb /KbSRCJmzsvuJ+Bz7oV6zGJSBfj7MIcn1t6uPFmAY3W2GrQzHs5MjewKaHH+jwV4FqMj kO9x8vHPtv3QTWNl5oRwS33fg9ScRq1kqJU/4qemib9rwj4EV9r7uz0+B8pgXrdM2lFM 5sZ1NZ1PJw2C1/nlPNN2NaCbMwzFpzhzjiy4wnWDM1QzpYGkD75rdFARhR0GOQ5A0uFu tb+FmGtJVwAt8w1WjAeZ2F9jBzeFWsrqDqzafg1eFkURmb0nSAEytUL/1UM9xy3aeCma lHjQ== X-Gm-Message-State: APjAAAXnrVZ0xGs5lpUSd9zmbcKXKBXPuvPHAU8prR2QHbk22MqY1Aw4 EUXA1nnQKiDrZzLz5DAXEETeXRYt1TmkE/yDF1nQ862hvg== X-Google-Smtp-Source: APXvYqywBKyrqH7oNPud0s3qxJS/cT3LbtzUFwLveWdtn8dyoZdhUOff31vXVWE4ooxOzPgMxIn2lX0ndMXE+j9gFQs= X-Received: by 2002:a0d:c306:: with SMTP id f6mr1556539ywd.214.1561625995849; Thu, 27 Jun 2019 01:59:55 -0700 (PDT) MIME-Version: 1.0 References: <20190627095031.4d5817b8@simplexum.com> <20190627122916.3b6c2c32@simplexum.com> <20190627134628.4d131264@simplexum.com> In-Reply-To: From: Jonathan Underwood Date: Thu, 27 Jun 2019 17:59:44 +0900 Message-ID: To: Dmitry Petukhov Content-Type: multipart/alternative; boundary="000000000000c1478c058c4a6257" 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:59:58 -0000 --000000000000c1478c058c4a6257 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When I say order is not necessary I mean, I won't have to brute force order= . Either way, if we don't sort the xpubs in the key, it would be possible to create multiple key value pairs for essentially the same group of pubkeys. "I only want to sign if the multisig is in this order" is pointless. And like I said, output PSBT includes redeemscript and witnessscript, so my app can just say "if no redeemscript or witnessscript or BIP32_DERIVATION for the output, fail" - Jonathan 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 17:56 Jonathan Underwood : > 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/57a57b4fae1ae14b77a2eebd99cd71914= 8e3027e?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 Petukho= v : >> > > > >> > > > > 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.= 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 >> > > > > 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#speci= fication >> > > >> > > > > > >> > > > > > 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 >> > > > > > >> > > > > >> > > > > >> > > > >> > > >> > > >> > >> >> > > -- > ----------------- > 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 > --=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 --000000000000c1478c058c4a6257 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When I say order is not necessary I mean, I won't have= to brute force order.

Either way, if we don't sort the xpubs in= the key, it would be possible to create multiple key value pairs for essen= tially the same group of pubkeys. "I only want to sign if the multisig= is in this order" is pointless.

And like I=C2=A0sa= id, output PSBT includes redeemscript and witnessscript, so my app can just= say "if no redeemscript or witnessscript or BIP32_DERIVATION for the = output, fail"

- Jonathan

2019=E5=B9=B46=E6=9C= =8827=E6=97=A5(=E6=9C=A8) 17:56 Jonathan Underwood <junderwood@bitcoinbank.co.jp>:
=
The outp= ut will have redeemscript and witnessscript so order is not necessary. I ca= n just look at the multisig script and find the pubkey inside it.

<= /div>
-Jonathan

2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 17:4= 5 Dmitry Petukhov <dp@simplexum.com>:
> m value for a multisig (set 0 for non-multisig), followed b= y 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/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=3D82656c8#diff-8= 2656c833e31e6751a412ce5e5c70920
>
> 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 &l= t;dp@simplexum.com>:
>
> > How would signer know that there _should_ be at least 3 signature= s
> > 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 xp= ub
> > packages that correspond to particular multisig configuration, an= d
> > enforce that destination addresses correspond to this configurati= on.
> >
> > 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:
> >=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 signatures are: > > > sAxB
> > > sAxC
> > > sBxA
> > > sBxC
> > > sCxA
> > > sCxB
> > >
> > > We can then create a wallet that says "when verifying c= hange with
> > > 0x01 global type proposed by Andrew Chow, if the change is > > > multisig, we MUST require the other pubkeys to have signatur= es
> > > 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_DERIVATIO= N 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 t= o address
> > > verification" problem for HD, but also the multisig cha= nge 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 P= etukhov <dp@simple= xum.com>:
> > >=C2=A0
> > > > Hi!
> > > >
> > > > I wonder how your scheme handles multisig ?
> > > >
> > > > As I understand, you sign individual xpubs with cold ke= ys, so
> > > > that cold keys can check destination addresses are trus= ted.
> > > >
> > > > I seems to me that if you sign individual xpubs of a mu= ltisig
> > > > warm wallet, and one key from that multisig is compromi= zed,
> > > > attackers can then create a single-sig destination addr= ess that
> > > > they control, and move the coins in a chain of two
> > > > transactions, first to this single-sig address, and the= n to an
> > > > address that they independently control.
> > > >
> > > > My idea to prevent this [1] is to sign the whole 'x= pub package'
> > > > of the multisig wallet, but there is also an issue of &= #39;partial
> > > > compromize', where some of the keys in a multisig w= arm wallet is
> > > > compromized, and you do not want to regard a particular= 'xpub
> > > > package' as trusted. My idea was [2] to use an auxi= liary message
> > > > that would be signed along with the 'xpub package&#= 39;, and that
> > > > message can include specific 'epoch' word that = hardware wallet
> > > > can show prominently before signing, or have 'seria= l 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 sche= mes, but
> > > > given that the huge number of possible schemes that eac= h may
> > > > probably require its own PSBT field type, I think that = this is
> > > > better dealt with outside of PSBT, as 'PSBT metainf= ormation', 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 impl= ement
> > > > PSBT for simple cases, because the 'core specificat= ion' would
> > > > not grow that big.
> > > >
> > > > [1]
> > > >
> > > >=C2=A0
> > https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html=C2=A0 > > > >
> > > > [2]
> > > >
> > > >=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 Jonathan Underwo= od via
> > > > bitcoin-dev <bitcoin-dev@lists.linuxfoundation.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 -> warm a= nd warm -> hot
> > > > > sends for our exchange wallet is "How do I kn= ow that the
> > > > > address I am sending to is not a hacker's addr= ess that was
> > > > > swapped in between unsigned tx creation and first = signature?"
> > > > >
> > > > > We have a proprietary JSON based encoding system w= hich we are
> > > > > looking to move towards PSBT, but PSBT is missing = this key
> > > > > functionality.
> > > > >
> > > > > BIP32_DERIVATION does allow us to verify the addre= ss is from a
> > > > > certain XPUB, but, for example, it can not allow u= s to verify
> > > > > a signature of that xpub.
> > > > >
> > > > > I have made a rough draft of the proposed key valu= e
> > > > > specification.
> > > >=C2=A0
> > https://gi= thub.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification<= br> > >=C2=A0
> > > > >
> > > > > The signing key path used in the spec is just rand= omly chosen
> > > > > 31 x 4 bits shown as numbers with hardened paths.<= br> > > > > >
> > > > > Since this issue seems similar to the change addre= ss issue, I
> > > > > started from that as a base. With the HW wallet ca= se, I can
> > > > > verify the xpub by just deriving it locally and co= mparing
> > > > > 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 wall= et.
> > > > > 2. Using the airgap signing tool, sign the xpub wi= th all cold
> > > > > keys. 3. Upload the signature/xpub pairs to the on= line
> > > > > unsigned transaction generator.
> > > > > 4. Include one keyval pair per coldkey/xpub pairin= g.
> > > > > 5. When offline signing, if the wallet detects the= re is a
> > > > > global keyval XPUB_SIGNATURE with its pubkey in th= e 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 slig= htly
> > > > > altering our current system, so don't take thi= s 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
> > >=C2=A0
> >
> >=C2=A0
>



--
-----------------
Jon= athan 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: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3


--
-----------------
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
--000000000000c1478c058c4a6257--