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
|
