Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of niftybox.net
	designates 95.142.167.147 as permitted sender)
	client-ip=95.142.167.147;
	envelope-from=c1.sf-bitcoin@niftybox.net; helo=i3.hyper.to; 
Message-ID: <1396115305.27001.8.camel@mimiz>
From: devrandom <c1.sf-bitcoin@niftybox.net>
To: Matt Whitlock <bip@mattwhitlock.name>
Date: Sat, 29 Mar 2014 10:48:25 -0700
In-Reply-To: <3760502.BsfnhHlzm1@crushinator>
References: <CACsn0ckScTWG4YxNCscxvtdsmcUkxtR2Gi-rdBs2HCkirPz5rA@mail.gmail.com>
	<4906130.DUyjhm1C93@crushinator> <1396113933.8809.91.camel@mimiz>
	<3760502.BsfnhHlzm1@crushinator>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret
 Sharing of Bitcoin private keys
Precedence: list

On Sat, 2014-03-29 at 13:38 -0400, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 10:25 am, Dev Random wrote:
> > On Sat, 2014-03-29 at 11:44 -0400, Matt Whitlock wrote:
> > > On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
> > > > https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
> > > 
> > > Thanks. This is great, although it makes some critical references to an
> > > ACM paper for which no URL is provided, and thus I cannot implement it.
> > > 
> > > A distributed ECDSA notwithstanding, we still need a way to decompose a
> > > BIP32 master seed into shares. I am envisioning a scenario in which I
> > 
> > It would seem that threshold ECDSA with keys derived from separate seeds
> > has better security properties than one seed that is then split up.  The
> > main thing is that there is no single point of attack in the generation
> > or signing.
> 
> No contest here. But can threshold ECDSA work with BIP32? In other
> words, can a threshold ECDSA public key be generated from separate,
> precomputed private keys, or can it only be generated interactively?
> Maybe the BIP32 master seeds have to be generated interactively, and
> then all sets of corresponding derived keys are valid signing groups?

That's a good point. In the paper, they have a deterministic wallet
scheme in section 3.3.  It is non-interactive, so that's good.  On the
other hand, it's not BIP32, so that adds complexity.

> 
> Threshold ECDSA certainly sounds nice, but is anyone working on a BIP
> for it? I would take it on myself, but I don't understand it well
> enough yet, and publicly available information on it seems lacking. I
> proposed this Shamir Secret Sharing BIP as an easily understood, easily
> implemented measure that we can use today, with no changes to existing
> Bitcoin software. It's low-hanging fruit.

Good points, although multisig is catching on quickly in the ecosystem.
AFAIK, all production wallets can send to p2sh addresses.

-- 
Miron / devrandom