path: root/b6/522b2d117b799f176716fd9228e6914e9cb222

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 5B667C9E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Jun 2019 00:19:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw1-f50.google.com (mail-yw1-f50.google.com
	[209.85.161.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1820A2C6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Jun 2019 00:19:54 +0000 (UTC)
Received: by mail-yw1-f50.google.com with SMTP id t2so5224896ywe.10
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 17:19:54 -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=+re3TxeDp7i1F0HCXHRWt3lZ7IJvPnfj6CYdCm5G6xQ=;
	b=UVsY+GUIykFOi2CEOdABRz4ksvK5LsD1cRlB6gtQ+i44fH/eldlb/ZofcOFhWrkNq6
	7A+Bgfj0ChMBkUgbbWhqDH1oDpY3Aql9TKudH1KSV2qS1S4cGWZdhSq88L/zF6cv3rG+
	gISeZ6m9TVy2jsk7Ko8SMwoMMp2mT2aK79p3Bhv+ksctP5LJUHp0p9FjJBt1wSixOolT
	7IXWofd6j53vb8i2vaun5jfnAOU1KI2WhNa7kObKsIG7+cqrXAgaCwiWkLk6U94OoPdj
	AZK/YZs9WemnTxMR6rIovWIHHD/TjDIzfNpOQDH0sFL6URI2ZACexLnx63KzIg4QAhZh
	GgHg==
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=+re3TxeDp7i1F0HCXHRWt3lZ7IJvPnfj6CYdCm5G6xQ=;
	b=iuv/MzoH6dCpWR+z/E4qpuvXN+zPjRjvcHC2cYivTPhvwKxXWeOCt1cdBi+QyTgx+V
	PBUhHUIPbVCk9vOhfOWKNMPCYWrKNBqLIkNwe80l6SOMa2sGAk8K0fz0C/F+Zn859W73
	3qR9OG4zRwdiJVIrkO25LpV/Go0V1eCqEG+oIbFtE0zjjLVpydGkPIFGppMb6/F6AVGU
	iFHcOkNPZNBwnfwMu+rsXJLGxynDPc5fVNJ/2Rfi50MXouNPTlx4j8CI79CVyuWZ3s9x
	DNsENcUs3WnB1XUCCgXLe9Frv7497ssGJfQsWL3OWv3KTXSTn5gVrcRIB8hhBBJnWuHm
	Z2EA==
X-Gm-Message-State: APjAAAWqWNMjgMv7n6RdPeDOs2G76pC4YS4ilb5LyYrctanQxZyaZLOy
	H3RGZLEcpwJACUBZw4aqmc4/tCss+FAQatAIy5V8
X-Google-Smtp-Source: APXvYqycxJ3qOsPTVcndpsaNd7cLgP51AYpAp0qdCo0eUBXcmxY8374G2Jnq7LSGU6LZ2JcIXK1xaV+rdWXGuWTQt+A=
X-Received: by 2002:a81:23d6:: with SMTP id j205mr8215310ywj.333.1561767593959;
	Fri, 28 Jun 2019 17:19:53 -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>
	<20190627181429.15dda570@simplexum.com>
	<20190627202932.1cb4d727@simplexum.com>
	<20190629024816.2193363e@simplexum.com>
In-Reply-To: <20190629024816.2193363e@simplexum.com>
From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Date: Sat, 29 Jun 2019 09:19:41 +0900
Message-ID: <CAMpN3m+Oa6oPzAmhoioOkuf8__NSPPNoSEMHJwo9PhjXosMwhg@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>
Content-Type: multipart/alternative; boundary="000000000000a90c50058c6b5af1"
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: Sat, 29 Jun 2019 06:20:23 +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: Sat, 29 Jun 2019 00:19:57 -0000

--000000000000a90c50058c6b5af1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

replies in-line. Thanks!

2019=E5=B9=B46=E6=9C=8829=E6=97=A5(=E5=9C=9F) 6:46 Dmitry Petukhov <dp@simp=
lexum.com>:

> In your proposed field key format,
>
> {0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
>
> I think you can replace the signing pubkey with just a fingerprint of
> the master key, that would save 29 bytes per 0x02 field.
>

Good point.


> If the only entity that is concerned about the validity of the
> signature is those that possess the signing_privkey, it will check the
> signature when it sees the 0x02 field starting with its own key
> fingerprint, and will ignore the field if the signature does not match.
>
> If someone other than the signer needs to check that this xpub-package
> was signed by certain cold key, it will need to know signing_pubkey
> anyway, before it parses PSBT, as it won't have the means to check if
> certain pubkey found in 0x02 field in PSBT is related to certain
> signer, without knowing anything about the pubkey beforehand.
>
> I'm not sure if the ability of unrelated parties to verify that
> xpub-package matches its signature is useful in practice. 29 bytes per
> 0x02 field is not a big saving of space, and if this ability is actually
> useful, the saving may not be worh loosing this ability.
>

All good points, I think we'll just use the first 4 bytes of the hash160 of
the pubkey, aka fingerprint.


> Other note: you have 'unused' value of 1 for `m` in your scheme, why
> not require m=3D1 for single-sig case, and use 0 as indicator that there
> are a serlal number following it?
>

0x00 is single sig, aka, OP_CHECKSIG

0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG


> The key for the field would be encoded as
>
> {0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
>
> for usual case, and
>
> {0x02}|{signing_pubkey}|0x00|{serial}|{m}|{xpub}|...|{xpub}
>
> for the case when the signing scheme actually cares about different
> versions of xpub packages signed by certain cold key
>

since OP_CHECKMULTISIG only supports at most 15-of-15 due to stack item
size limitations, we could make 0xff into this serial marker.


> Going back to the idea of moving 'complex' usecases outside of BIP174:
> maybe we could have a 'BIP-specific' field, that would have the key as
>
> {0x0?}|{BIP-number}|{bip-specific-suffix-data}
>
> so that the different usecases that are not general enough to be
> included in BIP174 itself, may have their own BIPs. Vendor-specific
> fields may also be done as a separate BIP.
>

Definitely sounds good, but the currently proposed 0x01 global type is
being added to BIP174 directly under the assumption that it is useful for
all users of PSBT, and I would argue that 0x01 being an HD change verifying
method, it only seems logical to add a similar method of "verifying"
non-self keys, aka whitelisting for security purposes, and such a feature
would require this data be included into the PSBT sent into the device.

If the consensus is that this data is unneeded, 0x01 should probably also
be a separate BIP.

Though outside the scope of this BIP, one difficulty of a whitelist feature
would be revocation of signatures. If we pre-sign a revocation cert and
somehow make the wallet blacklist if seen... then the question is "if your
signer has a trustworthy store of state, why not store the whitelist
pubkeys?"

But that feature itself should be a separate BIP.

Also, POR_COMMITMENT being in BIP174 kind of set a precedent... :-/


> =D0=92 Thu, 27 Jun 2019 20:29:32 +0500
> Dmitry Petukhov <dp@simplexum.com> wrote:
>
> > Oh, I saw that you covered it in another mail:
> >
> > > 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).
> >
> > The setup might not be 'all cold keys', but the keys with different
> > levels of exposure to possible theft. In this config, compromise of
> > one of the 'warm' keys might not necessary require changing the
> > 'cold' key.
> >
> > I'm not sure whether this usecase warrants adding extra 'serial'
> > field, but on the other hand it is rather simple change, and those who
> > does not care can always set 0.
> >
> > =D0=92 Thu, 27 Jun 2019 18:14:29 +0500
> > Dmitry Petukhov <dp@simplexum.com> wrote:
> >
> > > What do you think about adding serial number to the xpub package ?
> > >
> > > The key would be
> > >
> > > {0x02}|{signing_pubkey}|{serial}|{m}|{xpub}|...|{xpub}
> > >
> > > and if the signer have the ability to store a counter, it can reject
> > > 'outdated' xpub packages, and only accept those that was signed
> > > using the serial number that it deems recent. This would allow a
> > > limited mechanism to 'revoke' previously signed packages that have
> > > compromized keys in them.
> > >
> > > =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
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>

--000000000000a90c50058c6b5af1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>replies in-line. Thanks!<br><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">2019=E5=B9=B46=E6=9C=8829=E6=
=97=A5(=E5=9C=9F) 6:46 Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.c=
om">dp@simplexum.com</a>&gt;:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In yo=
ur proposed field key format,<br>
<br>
{0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}<br>
<br>
I think you can replace the signing pubkey with just a fingerprint of<br>
the master key, that would save 29 bytes per 0x02 field.<br></blockquote></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Good point.</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><br></blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the only entity that is concerned about the validity of the<br>
signature is those that possess the signing_privkey, it will check the<br>
signature when it sees the 0x02 field starting with its own key<br>
fingerprint, and will ignore the field if the signature does not match.<br>
<br>
If someone other than the signer needs to check that this xpub-package<br>
was signed by certain cold key, it will need to know signing_pubkey<br>
anyway, before it parses PSBT, as it won&#39;t have the means to check if<b=
r>
certain pubkey found in 0x02 field in PSBT is related to certain<br>
signer, without knowing anything about the pubkey beforehand.<br>
<br>
I&#39;m not sure if the ability of unrelated parties to verify that<br>
xpub-package matches its signature is useful in practice. 29 bytes per<br>
0x02 field is not a big saving of space, and if this ability is actually<br=
>
useful, the saving may not be worh loosing this ability.<br></blockquote></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto">All good points, I =
think we&#39;ll just use the first 4 bytes of the hash160 of the pubkey, ak=
a fingerprint.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Other note: you have &#39;unused&#39; value of 1 for `m` in your scheme, wh=
y<br>
not require m=3D1 for single-sig case, and use 0 as indicator that there<br=
>
are a serlal number following it?<br></blockquote></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">0x00 is single sig, aka, OP_CHECKSIG</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">0x01 is multisig, aka, 1-of-3=
, 1-of-2 OP_CHECKMULTISIG</div><div dir=3D"auto"><br></div><div dir=3D"auto=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The key for the field would be encoded as<br>
<br>
{0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}<br>
<br>
for usual case, and<br>
<br>
{0x02}|{signing_pubkey}|0x00|{serial}|{m}|{xpub}|...|{xpub}<br>
<br>
for the case when the signing scheme actually cares about different<br>
versions of xpub packages signed by certain cold key<br></blockquote></div>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">since OP_CHECKMULTISIG =
only supports at most 15-of-15 due to stack item size limitations, we could=
 make 0xff into this serial marker.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Going back to the idea of moving &#39;complex&#39; usecases outside of BIP1=
74:<br>
maybe we could have a &#39;BIP-specific&#39; field, that would have the key=
 as<br>
<br>
{0x0?}|{BIP-number}|{bip-specific-suffix-data}<br>
<br>
so that the different usecases that are not general enough to be<br>
included in BIP174 itself, may have their own BIPs. Vendor-specific<br>
fields may also be done as a separate BIP.<br></blockquote></div></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">Definitely sounds good, but the c=
urrently proposed 0x01 global type is being added to BIP174 directly under =
the assumption that it is useful for all users of PSBT, and I would argue t=
hat 0x01 being an HD change verifying method, it only seems logical to add =
a similar method of &quot;verifying&quot; non-self keys, aka whitelisting f=
or security purposes, and such a feature would require this data be include=
d into the PSBT sent into the device.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">If the consensus is that this data is unneeded, 0x01 should p=
robably also be a separate BIP.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Though outside the scope of this BIP, one difficulty of a whiteli=
st feature would be revocation of signatures. If we pre-sign a revocation c=
ert and somehow make the wallet blacklist if seen... then the question is &=
quot;if your signer has a trustworthy store of state, why not store the whi=
telist pubkeys?&quot;</div><div dir=3D"auto"><br></div><div dir=3D"auto">Bu=
t that feature itself should be a separate BIP.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Also, POR_COMMITMENT being in BIP174 kind of set a =
precedent... :-/</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
=D0=92 Thu, 27 Jun 2019 20:29:32 +0500<br>
Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.com" target=3D"_blank" r=
el=3D"noreferrer">dp@simplexum.com</a>&gt; wrote:<br>
<br>
&gt; Oh, I saw that you covered it in another mail:<br>
&gt; <br>
&gt; &gt; The expire / revoke problem is a larger problem than this feature=
<br>
&gt; &gt; can handle.=C2=A0 <br>
&gt; <br>
&gt; &gt; In general, if one of the cold keys is stolen, there is rarely a<=
br>
&gt; &gt; situation where you are completely sure the other cold keys haven=
&#39;t<br>
&gt; &gt; been compromised... so the best practice would be all signers<br>
&gt; &gt; generate new keys and all funds are moved to a completely new<br>
&gt; &gt; multisig wallet (no common xpubs).=C2=A0 <br>
&gt; <br>
&gt; The setup might not be &#39;all cold keys&#39;, but the keys with diff=
erent<br>
&gt; levels of exposure to possible theft. In this config, compromise of<br=
>
&gt; one of the &#39;warm&#39; keys might not necessary require changing th=
e<br>
&gt; &#39;cold&#39; key.<br>
&gt; <br>
&gt; I&#39;m not sure whether this usecase warrants adding extra &#39;seria=
l&#39;<br>
&gt; field, but on the other hand it is rather simple change, and those who=
<br>
&gt; does not care can always set 0. <br>
&gt; <br>
&gt; =D0=92 Thu, 27 Jun 2019 18:14:29 +0500<br>
&gt; Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.com" target=3D"_bla=
nk" rel=3D"noreferrer">dp@simplexum.com</a>&gt; wrote:<br>
&gt; <br>
&gt; &gt; What do you think about adding serial number to the xpub package =
?<br>
&gt; &gt; <br>
&gt; &gt; The key would be <br>
&gt; &gt; <br>
&gt; &gt; {0x02}|{signing_pubkey}|{serial}|{m}|{xpub}|...|{xpub}<br>
&gt; &gt; <br>
&gt; &gt; and if the signer have the ability to store a counter, it can rej=
ect<br>
&gt; &gt; &#39;outdated&#39; xpub packages, and only accept those that was =
signed<br>
&gt; &gt; using the serial number that it deems recent. This would allow a<=
br>
&gt; &gt; limited mechanism to &#39;revoke&#39; previously signed packages =
that have<br>
&gt; &gt; compromized keys in them.<br>
&gt; &gt; <br>
&gt; &gt; =D0=92 Thu, 27 Jun 2019 17:16:14 +0900<br>
&gt; &gt; Jonathan Underwood &lt;<a href=3D"mailto:junderwood@bitcoinbank.c=
o.jp" target=3D"_blank" rel=3D"noreferrer">junderwood@bitcoinbank.co.jp</a>=
&gt; wrote:<br>
&gt; &gt;=C2=A0 =C2=A0<br>
&gt; &gt; &gt; I see what you mean.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; What about this?<br>
&gt; &gt; &gt; <a href=3D"https://github.com/junderw/bips/commit/57a57b4fae=
1ae14b77a2eebd99cd719148e3027e?short_path=3D82656c8#diff-82656c833e31e6751a=
412ce5e5c70920" rel=3D"noreferrer noreferrer" target=3D"_blank">https://git=
hub.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_=
path=3D82656c8#diff-82656c833e31e6751a412ce5e5c70920</a><br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Plus side: for single sig case, the key only increases by on=
e byte<br>
&gt; &gt; &gt; (0x00 for the {m} value)<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; This way if it was 2 of 3 like before, you sign the whole &q=
uot;packet&quot;<br>
&gt; &gt; &gt; so each key only signs the packet once. Way better than n!<b=
r>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Anywho. Please send your feedback. Thanks.<br>
&gt; &gt; &gt; Jonathan<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 16:27 Dmitry P=
etukhov &lt;<a href=3D"mailto:dp@simplexum.com" target=3D"_blank" rel=3D"no=
referrer">dp@simplexum.com</a>&gt;:<br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0<br>
&gt; &gt; &gt; &gt; How would signer know that there _should_ be at least 3=
<br>
&gt; &gt; &gt; &gt; signatures signed by the key owned by this signer ?<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; If it does not know that it should enforce 2of3 multisi=
g, for<br>
&gt; &gt; &gt; &gt; example, the attacker that control only one key A can f=
ool<br>
&gt; &gt; &gt; &gt; signer B by sending to 1of1 single-sig that is derived =
from A&#39;s<br>
&gt; &gt; &gt; &gt; xpub, and providing only sBxA in PSBT.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; If the signer does not have a hardcoded configuration t=
hat<br>
&gt; &gt; &gt; &gt; will mandate a particular multisig scheme, it will allo=
w sending<br>
&gt; &gt; &gt; &gt; to any scheme.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; If the signer has a rich enough state to store updatabl=
e<br>
&gt; &gt; &gt; &gt; configuration, it can just store the trusted xpubs dire=
ctly.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Alternatively, signer can sign not individual xpubs, bu=
t whole<br>
&gt; &gt; &gt; &gt; xpub packages that correspond to particular multisig<br=
>
&gt; &gt; &gt; &gt; configuration, and enforce that destination addresses c=
orrespond<br>
&gt; &gt; &gt; &gt; to this configuration.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; But this would not be possible with your PSBT scheme th=
at uses<br>
&gt; &gt; &gt; &gt; individual key-xpub pairs.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; =D0=92 Thu, 27 Jun 2019 14:07:47 +0900<br>
&gt; &gt; &gt; &gt; Jonathan Underwood &lt;<a href=3D"mailto:junderwood@bit=
coinbank.co.jp" target=3D"_blank" rel=3D"noreferrer">junderwood@bitcoinbank=
.co.jp</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; Thanks for the reply.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; The way we would do it is:<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; Let&#39;s say we have 3 cold keys for multisig: A =
B and C<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; Whose xpubs are: xA xB and xC<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; We all sign each other&#39;s xpubs, whose signatur=
es are:<br>
&gt; &gt; &gt; &gt; &gt; sAxB<br>
&gt; &gt; &gt; &gt; &gt; sAxC<br>
&gt; &gt; &gt; &gt; &gt; sBxA<br>
&gt; &gt; &gt; &gt; &gt; sBxC<br>
&gt; &gt; &gt; &gt; &gt; sCxA<br>
&gt; &gt; &gt; &gt; &gt; sCxB<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; We can then create a wallet that says &quot;when v=
erifying change<br>
&gt; &gt; &gt; &gt; &gt; with 0x01 global type proposed by Andrew Chow, if =
the change<br>
&gt; &gt; &gt; &gt; &gt; is multisig, we MUST require the other pubkeys to =
have<br>
&gt; &gt; &gt; &gt; &gt; signatures via my 0x02 proposal&quot;<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; This way, all my PSBTs for my cold will have:<br>
&gt; &gt; &gt; &gt; &gt; 1. an 0x01 entry to tell me how to get my change.<=
br>
&gt; &gt; &gt; &gt; &gt; 2. All 6 of the signatures above.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; And the signer will then look at the change, check=
 my pubkey<br>
&gt; &gt; &gt; &gt; &gt; by deriving the xpub and checking equality to the<=
br>
&gt; &gt; &gt; &gt; &gt; BIP_DERIVATION of the output... it will then check=
 the OTHER<br>
&gt; &gt; &gt; &gt; &gt; pubkeys via BIP32_DERIVATION to master fingerprint=
, then link<br>
&gt; &gt; &gt; &gt; &gt; that fingerprint to a 0x02 sig from MY key, verify=
ing all<br>
&gt; &gt; &gt; &gt; &gt; pubkeys.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; So this proposal of mine would not only fix the &q=
uot;send to<br>
&gt; &gt; &gt; &gt; &gt; address verification&quot; problem for HD, but als=
o the multisig<br>
&gt; &gt; &gt; &gt; &gt; change problem with 0x01.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; Cool.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; Only thing that is kind of sad is having to includ=
e n! (of<br>
&gt; &gt; &gt; &gt; &gt; m-of-n) signatures in every PSBT... but tbh, the P=
SBT size is<br>
&gt; &gt; &gt; &gt; &gt; not of much concern.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; Thanks for the reply.<br>
&gt; &gt; &gt; &gt; &gt; - Jonathan<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 13:4=
9 Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.com" target=3D"_blank"=
 rel=3D"noreferrer">dp@simplexum.com</a>&gt;:<br>
&gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt; Hi!<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; I wonder how your scheme handles multisig ?<b=
r>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; As I understand, you sign individual xpubs wi=
th cold keys,<br>
&gt; &gt; &gt; &gt; &gt; &gt; so that cold keys can check destination addre=
sses are<br>
&gt; &gt; &gt; &gt; &gt; &gt; trusted.<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; I seems to me that if you sign individual xpu=
bs of a<br>
&gt; &gt; &gt; &gt; &gt; &gt; multisig warm wallet, and one key from that m=
ultisig is<br>
&gt; &gt; &gt; &gt; &gt; &gt; compromized, attackers can then create a sing=
le-sig<br>
&gt; &gt; &gt; &gt; &gt; &gt; destination address that they control, and mo=
ve the coins<br>
&gt; &gt; &gt; &gt; &gt; &gt; in a chain of two transactions, first to this=
 single-sig<br>
&gt; &gt; &gt; &gt; &gt; &gt; address, and then to an address that they ind=
ependently<br>
&gt; &gt; &gt; &gt; &gt; &gt; control.<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; My idea to prevent this [1] is to sign the wh=
ole &#39;xpub<br>
&gt; &gt; &gt; &gt; &gt; &gt; package&#39; of the multisig wallet, but ther=
e is also an issue<br>
&gt; &gt; &gt; &gt; &gt; &gt; of &#39;partial compromize&#39;, where some o=
f the keys in a<br>
&gt; &gt; &gt; &gt; &gt; &gt; multisig warm wallet is compromized, and you =
do not want to<br>
&gt; &gt; &gt; &gt; &gt; &gt; regard a particular &#39;xpub package&#39; as=
 trusted. My idea was<br>
&gt; &gt; &gt; &gt; &gt; &gt; [2] to use an auxiliary message that would be=
 signed along<br>
&gt; &gt; &gt; &gt; &gt; &gt; with the &#39;xpub package&#39;, and that mes=
sage can include<br>
&gt; &gt; &gt; &gt; &gt; &gt; specific &#39;epoch&#39; word that hardware w=
allet can show<br>
&gt; &gt; &gt; &gt; &gt; &gt; prominently before signing, or have &#39;seri=
al number&#39; for<br>
&gt; &gt; &gt; &gt; &gt; &gt; xpub packages (but that will require to store=
 last known<br>
&gt; &gt; &gt; &gt; &gt; &gt; serial inside hw wallet, making it stateful).=
<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; I like the idea to extend PSBT to accomodate =
these schemes,<br>
&gt; &gt; &gt; &gt; &gt; &gt; but given that the huge number of possible sc=
hemes that each<br>
&gt; &gt; &gt; &gt; &gt; &gt; may probably require its own PSBT field type,=
 I think that<br>
&gt; &gt; &gt; &gt; &gt; &gt; this is better dealt with outside of PSBT, as=
 &#39;PSBT<br>
&gt; &gt; &gt; &gt; &gt; &gt; metainformation&#39;, or using some form of &=
#39;vendor-specific&#39;,<br>
&gt; &gt; &gt; &gt; &gt; &gt; or &#39;metainformation-specific&#39; PSBT fi=
eld. This way each<br>
&gt; &gt; &gt; &gt; &gt; &gt; usecase can be independently described in its=
 own<br>
&gt; &gt; &gt; &gt; &gt; &gt; documentation, that would include the particu=
lars of the<br>
&gt; &gt; &gt; &gt; &gt; &gt; format for the metainformation. This would al=
so make it<br>
&gt; &gt; &gt; &gt; &gt; &gt; easier to implement PSBT for simple cases, be=
cause the<br>
&gt; &gt; &gt; &gt; &gt; &gt; &#39;core specification&#39; would not grow t=
hat big.<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; [1]<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2019-May/016917.html" rel=3D"noreferrer noreferrer" target=3D"_=
blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016=
917.html</a>=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; [2]<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2019-May/016926.html" rel=3D"noreferrer noreferrer" target=3D"_=
blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016=
926.html</a>=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; =D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonath=
an Underwood via<br>
&gt; &gt; &gt; &gt; &gt; &gt; bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Hello all,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Just wanted to pick your brains about an=
 idea for PSBT<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; extension.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; One problem we try to solve with cold -&=
gt; warm and warm -&gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; hot sends for our exchange wallet is &qu=
ot;How do I know that<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; the address I am sending to is not a hac=
ker&#39;s address<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; that was swapped in between unsigned tx =
creation and first<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; signature?&quot;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; We have a proprietary JSON based encodin=
g system which we<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; are looking to move towards PSBT, but PS=
BT is missing this<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; key functionality.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; BIP32_DERIVATION does allow us to verify=
 the address is<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; from a certain XPUB, but, for example, i=
t can not allow us<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; to verify a signature of that xpub.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; I have made a rough draft of the propose=
d key value<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; specification.=C2=A0 =C2=A0 =C2=A0<br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; <a href=3D"https://github.com/junderw/bips/blob/addXpub=
Sig/bip-0174.mediawiki#specification" rel=3D"noreferrer noreferrer" target=
=3D"_blank">https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediaw=
iki#specification</a><br>
&gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; The signing key path used in the spec is=
 just randomly<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; chosen 31 x 4 bits shown as numbers with=
 hardened paths.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Since this issue seems similar to the ch=
ange address<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; issue, I started from that as a base. Wi=
th the HW wallet<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; case, I can verify the xpub by just deri=
ving it locally<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; and comparing equality, however, in our =
case, we need to<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; verify an xpub that we do not have acces=
s to via<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; derivation from our cold key(s) (since w=
e don&#39;t want to<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; import our warm private key into our col=
d signer)<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; So the flow would be:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; 1. Securely verify the xpub of the warm =
/ hot wallet.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; 2. Using the airgap signing tool, sign t=
he xpub with all<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; cold keys. 3. Upload the signature/xpub =
pairs to the<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; online unsigned transaction generator.<b=
r>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; 4. Include one keyval pair per coldkey/x=
pub pairing.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; 5. When offline signing, if the wallet d=
etects there is a<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; global keyval XPUB_SIGNATURE with its pu=
bkey in the key,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; it must verify that all outputs have BIP=
32_DERIVATION and<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; that it can verify the outputs through t=
he derivation, to<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; the xpub, and to the signature.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; In my attempt to fitting this into PSBT,=
 I am slightly<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; altering our current system, so don&#39;=
t take this as an<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; indication 100% of how we work in the ba=
ckend.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; However, I would like to hear any feedba=
ck on this<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; proposal.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Thanks,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Jonathan<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 <br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0<br>
&gt; &gt;=C2=A0 =C2=A0<br>
&gt; <br>
<br>
</blockquote></div></div></div>

--000000000000a90c50058c6b5af1--