path: root/33/d8cfdd779da9d43c71962918da034059c79644

Return-Path: <junderwood@bitcoinbank.co.jp>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B0B69E20
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jun 2019 09:33:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com
	[209.85.219.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9086C710
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jun 2019 09:32:58 +0000 (UTC)
Received: by mail-yb1-f172.google.com with SMTP id k4so1167791ybo.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jun 2019 02:32:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=bitcoinbank.co.jp; s=google;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=g8FwbPqLxweAHOT8rKc1nCRVLBUqOk5i5iZL1ZCm9Y8=;
	b=SiUcjv/SXxNWMQHMV0wxw732aFMbmUsxYYndbb7hiqlpG8IptRHxapNhUXHGCCITfx
	Px9YQ+k91AZDta20gDBCwIRuWSh51Rwcj99QHgSKw8VDX01tI+3G1c4V8VEJ/AaULHC0
	4oVdYx/pA518Qn/UUxdJl0tz5r8g9nlICsNJwfuUwM7IrPiWGevINdKC8XCmrzMVVt+D
	mb9v7Xa0eY7fiiZV++KEmYDLQA2GBqnFOTZQWSwfdHrVuN/b0Prtl0+oTI4QlEgqgFo9
	7yTKIb9UfALNw8LbszhVQoWgdLCZlnPGRzH3PJOgEeydPl7ay6jv//Vt/RRY6qLoPIJl
	d11A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=g8FwbPqLxweAHOT8rKc1nCRVLBUqOk5i5iZL1ZCm9Y8=;
	b=sbV2ZD8MkXGKW/QUxvybB68N5LZlbT0pek/hBSFLkQtmmEt5V68hSoqyLnxL9XU9eL
	BNBGzo+lsdmaTtfxaIME1TPkn7AtsdB1eLUfYMTHCuZSvdsfiQEmJzW3BK4D6jg/hRI4
	J8E4u1I3+Tjp29PCl14in9QmyWKUMHW1INJfR3yNvE9aEey3ETAzr8xjtaphupNDkNJ+
	n1CKH1THVEu9UyHU86ORXP5NRa4V0AvCUDixJ+yzHKHHbR3xlZdT3c/88EVmhLyCuHGe
	e0oA7YAjIBqSLAz/IspuO5HTM2q5gvprWrwGwmor0iBWQrWICSJFh1iXv5wt+KFWwc5x
	xmdw==
X-Gm-Message-State: APjAAAUYNi0LAPURCudRD+qePrgPZp01O60ZCel0IiKNMnSpvs+GeKm4
	ErgrkZPGR2xUChee/wYH8GfBLIh8ZWY+OR+TLbxi
X-Google-Smtp-Source: APXvYqwFtfX+D0MdwXOI27rzi0idUDWuCcdEaOoB/MGj8KHUe+AV0p5eJE3ESR7dqyjZJOq0RIxSdqWHUA6+yOrhaGA=
X-Received: by 2002:a25:e7d5:: with SMTP id e204mr1803441ybh.522.1561627977420;
	Thu, 27 Jun 2019 02:32:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAMpN3mLvY+kuUGqzMW6SAMZ=h46_g=XLhDPhSY=X6xhLxvi15Q@mail.gmail.com>
	<20190627095031.4d5817b8@simplexum.com>
	<CAMpN3mKPkCPtYkN-JVku1r217-aBK=Rh3UEhvRPS_Y6DixJ9Dw@mail.gmail.com>
	<20190627122916.3b6c2c32@simplexum.com>
	<CAMpN3mL8tyP-6-nwn6dorcq7-dad6wYz8_pXinqHhgzUnrr_tg@mail.gmail.com>
	<20190627134628.4d131264@simplexum.com>
	<CAMpN3m+LiSW=kRCQio+C_2To66o_SEq-d_0Z122j+BUxvh=LDQ@mail.gmail.com>
	<20190627142120.2c24fddb@simplexum.com>
In-Reply-To: <20190627142120.2c24fddb@simplexum.com>
From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Date: Thu, 27 Jun 2019 18:32:46 +0900
Message-ID: <CAMpN3m+0HJm+zZ81ZNP-BXpX_39BvHzwKRAPwpdHinJ13gdNeA@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>
Content-Type: multipart/alternative; boundary="000000000000ddaf30058c4ad8fe"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 27 Jun 2019 14:26:10 +0000
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP174 extension proposal (Global Type:
	PSBT_GLOBAL_XPUB_SIGNATURE)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 09:33:00 -0000

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

There is no need, as you can look at the number of xpubs and use that as n.

Your wallet will not allow {m=3D2}{xpub1}{xpub2} signed message to vouch fo=
r
2 of 4 because you signed 2 of 2 where the n is shown by the number of
xpubs signed.

There is no need to add the extra byte, except maybe to help people who are
implementing a wallet checking some features to remember to check for the
number of total keys.

----

The expire / revoke problem is a larger problem than this feature can
handle.

In general, if one of the cold keys is stolen, there is rarely a situation
where you are completely sure the other cold keys haven't been
compromised... so the best practice would be all signers generate new keys
and all funds are moved to a completely new multisig wallet (no common
xpubs).

- Jonathan

2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 18:20 Dmitry Petukhov <dp@sim=
plexum.com>:

> You're right re order of the keys, I forgot that redeem/witness
> scripts are included in outputs.
>
> But regarding the number of the keys, you need to always include all of
> xpubs, because otherwise, if you only put `m` in PSBT, and you use
> 2of3, for example, attacker may put 2 as `m`, two of your xpubs, but
> then use redeem/witness scripts for 2of4, where two other keys are
> under attacker's control.
>
> If you only encode `n`, and allow any 'm of n' scheme, then in 2of3
> case, if the attackers have control of only one of the keys, they can
> use redeem/witness scripts for 1of3, where two other keys are under
> their control.
>
> It seems to me that you need to sign the whole configuration:
> `n`, `m`, and the xpubs.
>
> And then there's a question of how to conveniently `expire` the keys
> that were compromized. If the attackers have a signature of
> `n+n+xpubs` package for some configuration that include the keys that
> was compromized, they can use that old signed package to fool the
> signer.
>
> Signer would need to somehow distinguish between old and new
> configurations, or you would need to change the keys in all the signers
> even if one is compromized, so the already-signed packages would become
> invalid.
>
> You could do without changing all the keys when only one is compromized
> by including a serial number in the xpub package (but that means signer
> will need to have a state where it would store the latest serial
> number), or you need some message to be included in the package that a
> human can check when manually signing, to ensure that 'obsolete' xpub
> package was not used.
>
> =D0=92 Thu, 27 Jun 2019 17:56:06 +0900
> Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote:
>
> > The output will have redeemscript and witnessscript so order is not
> > necessary. I can just look at the multisig script and find the pubkey
> > inside it.
> >
> > -Jonathan
> >
> > 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 17:45 Dmitry Petukhov <dp=
@simplexum.com>:
> >
> > > > m value for a multisig (set 0 for non-multisig), followed by 1 or
> > > > more 78 byte serialized extended public keys sorted in canonical
> > > > order
> > >
> > > Sorting xpubs would work if the addresses also sort their pubkeys
> > > (like in BIP67)
> > >
> > > But if the pubkey order in address creation is fixed, you better
> > > have the fixed order for xpubs, otherwise you would need to try all
> > > combinations of derived pubkeys when checking if the addresss match
> > > the presented xpubs. That would be factorial of the number of keys,
> > > not feasible beyond very small number of keys.
> > >
> > > Bitcoin Core, for example, currently does not support BIP67 and
> > > supports only fixed pubkey positions in their script descriptors
> > > specification.
> > >
> > > You also need to include all xpubs to match the address, for m of n
> > > standard multisig, you need to include n and check that number of
> > > keys is exactly n.
> > >
> > > Otherwise your would not be able to construct the address to
> > > compare to the destination address that you need to check, as you
> > > need all pubkesy to construct P2SH or P2WSH address.
> > >
> > > With Shnorr-musig, you probably can interpolate the combined pubkey
> > > out of m paticpant pubkeys (but don't cite me on this, I might be
> > > wrong)
> > >
> > > =D0=92 Thu, 27 Jun 2019 17:16:14 +0900
> > > Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote:
> > >
> > > > I see what you mean.
> > > >
> > > > What about this?
> > > >
> > >
> https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148=
e3027e?short_path=3D82656c8#diff-82656c833e31e6751a412ce5e5c70920
>
> > > >
> > > > Plus side: for single sig case, the key only increases by one byte
> > > > (0x00 for the {m} value)
> > > >
> > > > This way if it was 2 of 3 like before, you sign the whole
> > > > "packet" so each key only signs the packet once. Way better than
> > > > n!
> > > >
> > > > Anywho. Please send your feedback. Thanks.
> > > > Jonathan
> > > >
> > > > 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 16:27 Dmitry Petukhov=
 <dp@simplexum.com>:
> > > >
> > > > > How would signer know that there _should_ be at least 3
> > > > > signatures signed by the key owned by this signer ?
> > > > >
> > > > > If it does not know that it should enforce 2of3 multisig, for
> > > > > example, the attacker that control only one key A can fool
> > > > > signer B by sending to 1of1 single-sig that is derived from A's
> > > > > xpub, and providing only sBxA in PSBT.
> > > > >
> > > > > If the signer does not have a hardcoded configuration that
> > > > > will mandate a particular multisig scheme, it will allow
> > > > > sending to any scheme.
> > > > >
> > > > > If the signer has a rich enough state to store updatable
> > > > > configuration, it can just store the trusted xpubs directly.
> > > > >
> > > > > Alternatively, signer can sign not individual xpubs, but whole
> > > > > xpub packages that correspond to particular multisig
> > > > > configuration, and enforce that destination addresses
> > > > > correspond to this configuration.
> > > > >
> > > > > But this would not be possible with your PSBT scheme that uses
> > > > > individual key-xpub pairs.
> > > > >
> > > > > =D0=92 Thu, 27 Jun 2019 14:07:47 +0900
> > > > > Jonathan Underwood <junderwood@bitcoinbank.co.jp> wrote:
> > > > >
> > > > > > Thanks for the reply.
> > > > > >
> > > > > > The way we would do it is:
> > > > > >
> > > > > > Let's say we have 3 cold keys for multisig: A B and C
> > > > > >
> > > > > > Whose xpubs are: xA xB and xC
> > > > > >
> > > > > > We all sign each other's xpubs, whose signatures are:
> > > > > > sAxB
> > > > > > sAxC
> > > > > > sBxA
> > > > > > sBxC
> > > > > > sCxA
> > > > > > sCxB
> > > > > >
> > > > > > We can then create a wallet that says "when verifying change
> > > > > > with 0x01 global type proposed by Andrew Chow, if the change
> > > > > > is multisig, we MUST require the other pubkeys to have
> > > > > > signatures via my 0x02 proposal"
> > > > > >
> > > > > > This way, all my PSBTs for my cold will have:
> > > > > > 1. an 0x01 entry to tell me how to get my change.
> > > > > > 2. All 6 of the signatures above.
> > > > > >
> > > > > > And the signer will then look at the change, check my pubkey
> > > > > > by deriving the xpub and checking equality to the
> > > > > > BIP_DERIVATION of the output... it will then check the OTHER
> > > > > > pubkeys via BIP32_DERIVATION to master fingerprint, then link
> > > > > > that fingerprint to a 0x02 sig from MY key, verifying all
> > > > > > pubkeys.
> > > > > >
> > > > > > So this proposal of mine would not only fix the "send to
> > > > > > address verification" problem for HD, but also the multisig
> > > > > > change problem with 0x01.
> > > > > >
> > > > > > Cool.
> > > > > >
> > > > > > Only thing that is kind of sad is having to include n! (of
> > > > > > m-of-n) signatures in every PSBT... but tbh, the PSBT size is
> > > > > > not of much concern.
> > > > > >
> > > > > > Thanks for the reply.
> > > > > > - Jonathan
> > > > > >
> > > > > >
> > > > > > 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 13:49 Dmitry Petu=
khov <dp@simplexum.com>:
> > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > I wonder how your scheme handles multisig ?
> > > > > > >
> > > > > > > As I understand, you sign individual xpubs with cold keys,
> > > > > > > so that cold keys can check destination addresses are
> > > > > > > trusted.
> > > > > > >
> > > > > > > I seems to me that if you sign individual xpubs of a
> > > > > > > multisig warm wallet, and one key from that multisig is
> > > > > > > compromized, attackers can then create a single-sig
> > > > > > > destination address that they control, and move the coins
> > > > > > > in a chain of two transactions, first to this single-sig
> > > > > > > address, and then to an address that they independently
> > > > > > > control.
> > > > > > >
> > > > > > > My idea to prevent this [1] is to sign the whole 'xpub
> > > > > > > package' of the multisig wallet, but there is also an issue
> > > > > > > of 'partial compromize', where some of the keys in a
> > > > > > > multisig warm wallet is compromized, and you do not want to
> > > > > > > regard a particular 'xpub package' as trusted. My idea was
> > > > > > > [2] to use an auxiliary message that would be signed along
> > > > > > > with the 'xpub package', and that message can include
> > > > > > > specific 'epoch' word that hardware wallet can show
> > > > > > > prominently before signing, or have 'serial number' for
> > > > > > > xpub packages (but that will require to store last known
> > > > > > > serial inside hw wallet, making it stateful).
> > > > > > >
> > > > > > > I like the idea to extend PSBT to accomodate these schemes,
> > > > > > > but given that the huge number of possible schemes that
> > > > > > > each may probably require its own PSBT field type, I think
> > > > > > > that this is better dealt with outside of PSBT, as 'PSBT
> > > > > > > metainformation', or using some form of 'vendor-specific',
> > > > > > > or 'metainformation-specific' PSBT field. This way each
> > > > > > > usecase can be independently described in its own
> > > > > > > documentation, that would include the particulars of the
> > > > > > > format for the metainformation. This would also make it
> > > > > > > easier to implement PSBT for simple cases, because the
> > > > > > > 'core specification' would not grow that big.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > > >
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.h=
tml
> > >
> > > > > > >
> > > > > > > [2]
> > > > > > >
> > > > > > >
> > > > >
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.h=
tml
> > >
> > > > > > >
> > > > > > >
> > > > > > > =D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via
> > > > > > > bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > > Hello all,
> > > > > > > >
> > > > > > > > Just wanted to pick your brains about an idea for PSBT
> > > > > > > > extension.
> > > > > > > >
> > > > > > > > One problem we try to solve with cold -> warm and warm ->
> > > > > > > > hot sends for our exchange wallet is "How do I know that
> > > > > > > > the address I am sending to is not a hacker's address
> > > > > > > > that was swapped in between unsigned tx creation and
> > > > > > > > first signature?"
> > > > > > > >
> > > > > > > > We have a proprietary JSON based encoding system which we
> > > > > > > > are looking to move towards PSBT, but PSBT is missing
> > > > > > > > this key functionality.
> > > > > > > >
> > > > > > > > BIP32_DERIVATION does allow us to verify the address is
> > > > > > > > from a certain XPUB, but, for example, it can not allow
> > > > > > > > us to verify a signature of that xpub.
> > > > > > > >
> > > > > > > > I have made a rough draft of the proposed key value
> > > > > > > > specification.
> > > > > > >
> > > > >
> > >
> https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specif=
ication
>
> > > > >
> > > > > > > >
> > > > > > > > The signing key path used in the spec is just randomly
> > > > > > > > chosen 31 x 4 bits shown as numbers with hardened paths.
> > > > > > > >
> > > > > > > > Since this issue seems similar to the change address
> > > > > > > > issue, I started from that as a base. With the HW wallet
> > > > > > > > case, I can verify the xpub by just deriving it locally
> > > > > > > > and comparing equality, however, in our case, we need to
> > > > > > > > verify an xpub that we do not have access to via
> > > > > > > > derivation from our cold key(s) (since we don't want to
> > > > > > > > import our warm private key into our cold signer)
> > > > > > > >
> > > > > > > > So the flow would be:
> > > > > > > > 1. Securely verify the xpub of the warm / hot wallet.
> > > > > > > > 2. Using the airgap signing tool, sign the xpub with all
> > > > > > > > cold keys. 3. Upload the signature/xpub pairs to the
> > > > > > > > online unsigned transaction generator.
> > > > > > > > 4. Include one keyval pair per coldkey/xpub pairing.
> > > > > > > > 5. When offline signing, if the wallet detects there is a
> > > > > > > > global keyval XPUB_SIGNATURE with its pubkey in the key,
> > > > > > > > it must verify that all outputs have BIP32_DERIVATION and
> > > > > > > > that it can verify the outputs through the derivation, to
> > > > > > > > the xpub, and to the signature.
> > > > > > > >
> > > > > > > > In my attempt to fitting this into PSBT, I am slightly
> > > > > > > > altering our current system, so don't take this as an
> > > > > > > > indication 100% of how we work in the backend.
> > > > > > > >
> > > > > > > > However, I would like to hear any feedback on this
> > > > > > > > proposal.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Jonathan
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

--=20
-----------------
Jonathan Underwood
=E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE =E3=83=81=
=E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83=B3=E3=
=82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC
-----------------

=E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB=E3=
=83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82=8A=E3=81=AE=E6=96=B9=E3=81=
=AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B=E9=8D=B5=E3=82=92=E3=81=94=
=E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3=80=82

=E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3

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

<div dir=3D"ltr">There is no need, as you can look at the number of xpubs a=
nd use that as n.<div><br></div><div>Your wallet will not allow {m=3D2}{xpu=
b1}{xpub2} signed message to vouch for 2 of 4 because you signed 2 of 2 whe=
re the n is shown by the number of xpubs signed.<br><br>There is no need to=
 add the extra byte, except maybe to help people who are implementing a wal=
let checking some features to remember to check for the number of total key=
s.</div><div><br></div><div>----</div><div><br></div><div>The expire / revo=
ke problem is a larger problem than this feature can handle.</div><div><br>=
</div><div>In general, if one of the cold keys is stolen, there is rarely a=
 situation where you are completely sure the other cold keys haven&#39;t be=
en compromised... so the best practice would be all signers generate new ke=
ys and all funds are moved to a completely new multisig wallet (no common x=
pubs).</div><div><br></div><div>- Jonathan</div></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">2019=E5=B9=B46=E6=9C=8827=
=E6=97=A5(=E6=9C=A8) 18:20 Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplex=
um.com">dp@simplexum.com</a>&gt;:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">You&#39;re right re order of the keys, I forgot that rede=
em/witness<br>
scripts are included in outputs.<br>
<br>
But regarding the number of the keys, you need to always include all of<br>
xpubs, because otherwise, if you only put `m` in PSBT, and you use<br>
2of3, for example, attacker may put 2 as `m`, two of your xpubs, but<br>
then use redeem/witness scripts for 2of4, where two other keys are<br>
under attacker&#39;s control.<br>
<br>
If you only encode `n`, and allow any &#39;m of n&#39; scheme, then in 2of3=
<br>
case, if the attackers have control of only one of the keys, they can<br>
use redeem/witness scripts for 1of3, where two other keys are under<br>
their control.<br>
<br>
It seems to me that you need to sign the whole configuration:<br>
`n`, `m`, and the xpubs.<br>
<br>
And then there&#39;s a question of how to conveniently `expire` the keys<br=
>
that were compromized. If the attackers have a signature of<br>
`n+n+xpubs` package for some configuration that include the keys that<br>
was compromized, they can use that old signed package to fool the<br>
signer.<br>
<br>
Signer would need to somehow distinguish between old and new<br>
configurations, or you would need to change the keys in all the signers<br>
even if one is compromized, so the already-signed packages would become<br>
invalid.<br>
<br>
You could do without changing all the keys when only one is compromized<br>
by including a serial number in the xpub package (but that means signer<br>
will need to have a state where it would store the latest serial<br>
number), or you need some message to be included in the package that a<br>
human can check when manually signing, to ensure that &#39;obsolete&#39; xp=
ub<br>
package was not used.<br>
<br>
=D0=92 Thu, 27 Jun 2019 17:56:06 +0900<br>
Jonathan Underwood &lt;<a href=3D"mailto:junderwood@bitcoinbank.co.jp" targ=
et=3D"_blank">junderwood@bitcoinbank.co.jp</a>&gt; wrote:<br>
<br>
&gt; The output will have redeemscript and witnessscript so order is not<br=
>
&gt; necessary. I can just look at the multisig script and find the pubkey<=
br>
&gt; inside it.<br>
&gt; <br>
&gt; -Jonathan<br>
&gt; <br>
&gt; 2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 17:45 Dmitry Petukhov &l=
t;<a href=3D"mailto:dp@simplexum.com" target=3D"_blank">dp@simplexum.com</a=
>&gt;:<br>
&gt; <br>
&gt; &gt; &gt; m value for a multisig (set 0 for non-multisig), followed by=
 1 or<br>
&gt; &gt; &gt; more 78 byte serialized extended public keys sorted in canon=
ical<br>
&gt; &gt; &gt; order=C2=A0 <br>
&gt; &gt;<br>
&gt; &gt; Sorting xpubs would work if the addresses also sort their pubkeys=
<br>
&gt; &gt; (like in BIP67)<br>
&gt; &gt;<br>
&gt; &gt; But if the pubkey order in address creation is fixed, you better<=
br>
&gt; &gt; have the fixed order for xpubs, otherwise you would need to try a=
ll<br>
&gt; &gt; combinations of derived pubkeys when checking if the addresss mat=
ch<br>
&gt; &gt; the presented xpubs. That would be factorial of the number of key=
s,<br>
&gt; &gt; not feasible beyond very small number of keys.<br>
&gt; &gt;<br>
&gt; &gt; Bitcoin Core, for example, currently does not support BIP67 and<b=
r>
&gt; &gt; supports only fixed pubkey positions in their script descriptors<=
br>
&gt; &gt; specification.<br>
&gt; &gt;<br>
&gt; &gt; You also need to include all xpubs to match the address, for m of=
 n<br>
&gt; &gt; standard multisig, you need to include n and check that number of=
<br>
&gt; &gt; keys is exactly n.<br>
&gt; &gt;<br>
&gt; &gt; Otherwise your would not be able to construct the address to<br>
&gt; &gt; compare to the destination address that you need to check, as you=
<br>
&gt; &gt; need all pubkesy to construct P2SH or P2WSH address.<br>
&gt; &gt;<br>
&gt; &gt; With Shnorr-musig, you probably can interpolate the combined pubk=
ey<br>
&gt; &gt; out of m paticpant pubkeys (but don&#39;t cite me on this, I migh=
t be<br>
&gt; &gt; wrong)<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">junderwood@bitcoinbank.co.jp</a>&gt; wrote:<br>
&gt; &gt;=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;=C2=A0 <br>
&gt; &gt; <a href=3D"https://github.com/junderw/bips/commit/57a57b4fae1ae14=
b77a2eebd99cd719148e3027e?short_path=3D82656c8#diff-82656c833e31e6751a412ce=
5e5c70920" rel=3D"noreferrer" target=3D"_blank">https://github.com/junderw/=
bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=3D82656c8#d=
iff-82656c833e31e6751a412ce5e5c70920</a>=C2=A0 <br>
&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<br=
>
&gt; &gt; &gt; &quot;packet&quot; so each key only signs the packet once. W=
ay better than<br>
&gt; &gt; &gt; n!<br>
&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">dp@simple=
xum.com</a>&gt;:<br>
&gt; &gt; &gt;=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<br>
&gt; &gt; &gt; &gt; sending 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<b=
r>
&gt; &gt; &gt; &gt; correspond 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">junderwood@bitcoinbank.co.jp</a>&gt; wrot=
e:<br>
&gt; &gt; &gt; &gt;=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"=
>dp@simplexum.com</a>&gt;:<br>
&gt; &gt; &gt; &gt; &gt;=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<br>
&gt; &gt; &gt; &gt; &gt; &gt; each may probably require its own PSBT field =
type, I think<br>
&gt; &gt; &gt; &gt; &gt; &gt; that this is better dealt with outside of PSB=
T, 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 <br>
&gt; &gt; &gt; &gt;=C2=A0 <br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2019-May/016917.html" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html</a><br>
&gt; &gt;=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 <br>
&gt; &gt; &gt; &gt;=C2=A0 <br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2019-May/016926.html" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html</a><br>
&gt; &gt;=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">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt;=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<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; first 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<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; this 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<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; us to verify a signature of that xpub.<b=
r>
&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 <br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 <br>
&gt; &gt; &gt; &gt;=C2=A0 <br>
&gt; &gt; <a href=3D"https://github.com/junderw/bips/blob/addXpubSig/bip-01=
74.mediawiki#specification" rel=3D"noreferrer" target=3D"_blank">https://gi=
thub.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification</a>=
=C2=A0 <br>
&gt; &gt; &gt; &gt;=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 <br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 <br>
&gt; &gt; &gt; &gt; &gt;=C2=A0 <br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;=C2=A0 <br>
&gt; &gt; &gt;=C2=A0 <br>
&gt; &gt;<br>
&gt; &gt;=C2=A0 <br>
&gt; <br>
<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div dir=
=3D"ltr"><div>-----------------<br></div><div>Jonathan Underwood</div><div>=
=E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE=E3=80=80=E3=
=83=81=E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83=
=B3=E3=82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC</div><div>----------------=
-</div><div><br></div><div>=E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3=
=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82=
=8A=E3=81=AE=E6=96=B9=E3=81=AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B=
=E9=8D=B5=E3=82=92=E3=81=94=E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3=
=80=82</div><div><br></div><div>=E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3=
FDAD998682F3590FEA3</div></div></div></div></div></div>

--000000000000ddaf30058c4ad8fe--