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-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1WW6vi-0006dz-3o
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Apr 2014 16:25:22 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.51 as permitted sender)
client-ip=209.85.215.51; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f51.google.com;
Received: from mail-la0-f51.google.com ([209.85.215.51])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WW6vh-0001qN-1P
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Apr 2014 16:25:22 +0000
Received: by mail-la0-f51.google.com with SMTP id pv20so2723132lab.10
for <bitcoin-development@lists.sourceforge.net>;
Fri, 04 Apr 2014 09:25:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.203.129 with SMTP id kq1mr1707061lac.6.1396628714402;
Fri, 04 Apr 2014 09:25:14 -0700 (PDT)
Received: by 10.112.89.68 with HTTP; Fri, 4 Apr 2014 09:25:14 -0700 (PDT)
In-Reply-To: <12583269.b0SUbSGuCb@crushinator>
References: <CAC7yFxSE8-TWPN-kuFiqdPKMDuprbiVJi7-z-ym+AUyA_f-xJw@mail.gmail.com>
<CAC7yFxQXn=c7CEC326yMx4bF7Cv7Gc62shS7xU0XvSp5sQSGZw@mail.gmail.com>
<CAAS2fgQd6_DAPnYtXUKN8sL=MfrySBaRZWHfPtoKUw=p2=9OYA@mail.gmail.com>
<12583269.b0SUbSGuCb@crushinator>
Date: Fri, 4 Apr 2014 09:25:14 -0700
Message-ID: <CAAS2fgTD7D2SiEOcNkq+MfOPnPJ-D7dOFwO0umwTF0WGQd5d3w@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1WW6vh-0001qN-1P
Cc: bitcoin-development <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: Fri, 04 Apr 2014 16:25:22 -0000
On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock <bip@mattwhitlock.name> wrote=
:
> On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote:
>> I still repeat my concern that any private key secret sharing scheme
>> really ought to be compatible with threshold ECDSA, otherwise we're
>> just going to have another redundant specification.
>
> I have that concern too, but then how can we support secrets of sizes oth=
er than 256 bits? A likely use case for this BIP (even more likely than usi=
ng it to decompose Bitcoin private keys) is using it to decompose BIP32 mas=
ter seeds, which can be 512 bits in size. We can't use secp256k1_n as the m=
odulus there.
Well, if you're not doing anything homorphic with the result the
computation should probably be over a small field (for computational
efficiency and implementation simplicity reasons) and the data split
up, this also makes it easier to deal with many different data sizes,
since the various sizes will more efficiently divide into the small
field. The field only needs to be large enough to handle the number
of distinct shares you wish to issue, so even an 8 bit field would
probably be adequate (and yields some very simple table based
implementations).
If that route is taken, rather than encoding BIP32 master keys, it
would probably be prudent to encode the encryption optional version
https://bitcointalk.org/index.php?topic=3D258678.0 ... and if we're
talking about a new armored private key format then perhaps we should
be talking about Mark Friedenbach's error correcting capable scheme:
https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki
(though it would be nicer if we could find a decoding scheme that
supported list decoding without increasing the complexity of a basic
implementation, since an advanced recovery tool could make good use of
a list decode)
I'd think that changing to a small field with a simple implementation,
and encoding the form with encryption, etc. probably makes it distinct
enough from an implementation of ECDSA thresholding that redundancy
isn't a problem.
|
