path: root/f1/c1fd513d1e9e04af61e9c9b8a2fe5fdf627f77

Return-Path: <peter@coinkite.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 72F73D30
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 14:37:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from smtp89.iad3b.emailsrvr.com (smtp89.iad3b.emailsrvr.com
	[146.20.161.89])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA5EC13A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 14:37:57 +0000 (UTC)
X-Auth-ID: peter@coinkite.com
Received: by smtp12.relay.iad3b.emailsrvr.com (Authenticated sender:
	peter-AT-coinkite.com) with ESMTPSA id A54E1C0116; 
	Fri, 28 Jun 2019 10:37:56 -0400 (EDT)
X-Sender-Id: peter@coinkite.com
Received: from coinkite.com ([UNAVAILABLE]. [216.223.129.56])
	(using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384)
	by 0.0.0.0:465 (trex/5.7.12); Fri, 28 Jun 2019 10:37:56 -0400
Date: Fri, 28 Jun 2019 10:37:55 -0400
From: "Peter D. Gray" <peter@coinkite.com>
To: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Message-ID: <20190628143755.GD1897@coinkite.com>
Reply-To: Peter Gray <peter@coinkite.com>
References: <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>
	<CAMpN3m+0HJm+zZ81ZNP-BXpX_39BvHzwKRAPwpdHinJ13gdNeA@mail.gmail.com>
	<20190627150745.GA1897@coinkite.com>
	<CAMpN3mKyKjSPs2SgC0pUbFMNXFZt7UOu4ktnbfBSDmLrDbafFA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMpN3mKyKjSPs2SgC0pUbFMNXFZt7UOu4ktnbfBSDmLrDbafFA@mail.gmail.com>
Organization: Coinkite Cryptobank (www.coinkite.com)
User-Agent: Mutt/1.6.0 (2016-04-01)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Fri, 28 Jun 2019 14:40:14 +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: Fri, 28 Jun 2019 14:37:58 -0000

Thanks I get the idea better now: You want the PSBT creator to be
able to indicate to the signers that it (the PSBT creator) controls
specific outputs that don't otherwise look like change.

Some problems:

> extended private key of the current signer derived from the
> signer's root to m/2042083607'/959190427'/1400854130'/990526201'

1) The PSBT creator would need to know that private key, and the Coldcard, as a matter
   of policy, will never export a private subkey.

2) The 'm' in that path depends on who is reading the PSBT file, in the multisig
   case. Each cosigner would need a different version of the PSBT file.

3) XPUB's are big and hard to parse, and this addition is using lots of them.

4) Coinjoins, and more complex script types, will want to authorize
   outputs that the PSBT signer may not fully understand. Your proposal
   would only help P2PKH and M-of-N multisig users.

To fix, may I propose:

- the signer and PSBT creator must share a pubkey/private key out of band (setup time)
- the origin of that key is out of scope of this standard (but it could be derived via BIP32)
- the PSBT creator can, optionally, sign any or all output sections by number using that key

I would prefer the signatures are in the global section, and the
signature is over all the bytes in the indicated output section,
as originally serialized when it came into the signer's possession.

We should be able to support multiple signers for individual outputs,
and also multiple signatures for the same output section. That would
support different derived keys per co-signer, and also quorum
approval or other policies like that.

Afterthought: Might be good to allow signature over the unsigned transaction, or
maybe it should be part of the signature always.

---
Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31BAD 5A2A5B10

On Fri, Jun 28, 2019 at 11:44:15AM +0900, Jonathan Underwood wrote:
> Hi Peter,
> 
> tl;dr The problem this solves is "How can a signer verify an address with
> HD changing the address every time?"
> 
> As an aside: (This is sort of explaining the current PR for the 0x01 global
> field (separate from mine))
> The problem is more easily understood with change addresses: If someone can
> alter my PSBT before signing, they could replace my change address with
> their address, and my signer would not know unless the signer just guesses
> all the path sets it knows, then derives thousands of change addresses and
> searches (most likely a signer is offline, so gap limit doesn't work since
> we can't tell which change addresses have tx history. So the 0x01 global
> tag will tell the signer "here's how you get from your master private key
> to the xpub used in the change output's output BIP32_DERIVATION tag... you
> can then derive the same key and check it is yours before signing."
> 
> Back to my proposal, this problem extends across wallets, since,
> for example, if I want to send from my cold wallet to my warm wallet, I
> don't want to give my cold signer my warm master key just so it can derive
> and check the key. That's what signatures are for. So this proposal says "A
> signer can be built to only sign if it sees a signature that itself has
> signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
> outputs, and if the output doesn't match it will reject and not sign"
> 
> This creates a sort of "chain of trust" for the wallet.
> 
> Currently the best way to prevent this (hacker swapping the send to
> address) without using signatures is to reuse the same address every time
> you want to send to the warm wallet, since after a few times, the signers
> (people) will be able to remember the address.
> 
> This is a huge HD drawback for high security requirement environments.
> Having this data in the PSBT standard will allow Trezor etc. to create an
> enforceable whitelist feature.
> 
> Let me know if you have feedback on the details.
> 
> Thanks,
> Jon
> 
> 2019年6月28日(金) 0:07 Peter D. Gray <peter@coinkite.com>:
> 
> > I haven't studied the new proposal in depth, but my first impression is:
> >
> > Wouldn't it just be easier and better to just sign the entire "outputs"
> > section of the PSBT?
> >
> > The signature would cover every byte, and therefore would cover any
> > future BIP additions to the outputs area, and also help non-multisig
> > cases today.
> >
> > ---
> > Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG:
> > A3A31BAD 5A2A5B10
> >
> >
> 
> -- 
> -----------------
> Jonathan Underwood
> ビットバンク社 チーフビットコインオフィサー
> -----------------
> 
> 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
> 
> 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3