summaryrefslogtreecommitdiff
path: root/c7/6f9e5f2ed3ea57804b48edf101f41400177d8b
blob: 9dc021f7f106e86a2b2f5b56f43428acc0241650 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <c1.sf-bitcoin@niftybox.net>) id 1WTxMy-0005G6-Ht
	for bitcoin-development@lists.sourceforge.net;
	Sat, 29 Mar 2014 17:48:36 +0000
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; 
Received: from i3.hyper.to ([95.142.167.147])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1WTxMx-0005ZS-9U for bitcoin-development@lists.sourceforge.net;
	Sat, 29 Mar 2014 17:48:36 +0000
Received: from localhost (localhost [127.0.0.1])
	by i3.hyper.to (Postfix) with ESMTP id 14C0BE03CF;
	Sat, 29 Mar 2014 18:48:29 +0100 (CET)
Received: from i3.hyper.to ([127.0.0.1])
	by localhost (i3.hyper.to [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id UXtuDUBspWAf; Sat, 29 Mar 2014 18:48:28 +0100 (CET)
Received: from [192.168.4.81] (50-1-105-185.dsl.dynamic.sonic.net
	[50.1.105.185]) by i3.hyper.to (Postfix) with ESMTPSA id 812D6E03C5;
	Sat, 29 Mar 2014 18:48:27 +0100 (CET)
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"
X-Mailer: Evolution 3.8.4-0ubuntu1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1WTxMx-0005ZS-9U
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret
 Sharing of Bitcoin private keys
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 29 Mar 2014 17:48:36 -0000

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