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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bip@mattwhitlock.name>) id 1WTxCz-0002t7-Lh
for bitcoin-development@lists.sourceforge.net;
Sat, 29 Mar 2014 17:38:17 +0000
X-ACL-Warn:
Received: from qmta01.westchester.pa.mail.comcast.net ([76.96.62.16])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WTxCy-0000YT-L8 for bitcoin-development@lists.sourceforge.net;
Sat, 29 Mar 2014 17:38:17 +0000
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60])
by qmta01.westchester.pa.mail.comcast.net with comcast
id jVZt1n0031HzFnQ51VeBfq; Sat, 29 Mar 2014 17:38:11 +0000
Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:219:d1ff:fe75:dc2f])
by omta14.westchester.pa.mail.comcast.net with comcast
id jVeA1n00Z4VnV2P3aVeB5f; Sat, 29 Mar 2014 17:38:11 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: Dev Random <c1.devrandom@niftybox.net>
Date: Sat, 29 Mar 2014 13:38:10 -0400
Message-ID: <3760502.BsfnhHlzm1@crushinator>
User-Agent: KMail/4.12.3 (Linux/3.12.13-gentoo; KDE/4.12.3; x86_64; ; )
In-Reply-To: <1396113933.8809.91.camel@mimiz>
References: <CACsn0ckScTWG4YxNCscxvtdsmcUkxtR2Gi-rdBs2HCkirPz5rA@mail.gmail.com>
<4906130.DUyjhm1C93@crushinator> <1396113933.8809.91.camel@mimiz>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [76.96.62.16 listed in list.dnswl.org]
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WTxCy-0000YT-L8
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:38:17 -0000
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?
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.
|
