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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bip@mattwhitlock.name>) id 1WTty9-0006D6-64
for bitcoin-development@lists.sourceforge.net;
Sat, 29 Mar 2014 14:10:45 +0000
X-ACL-Warn:
Received: from qmta14.westchester.pa.mail.comcast.net ([76.96.59.212])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WTty8-0000NY-Cv for bitcoin-development@lists.sourceforge.net;
Sat, 29 Mar 2014 14:10:45 +0000
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76])
by qmta14.westchester.pa.mail.comcast.net with comcast
id jRqg1n0031ei1Bg5ESAfTU; Sat, 29 Mar 2014 14:10:39 +0000
Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:219:d1ff:fe75:dc2f])
by omta24.westchester.pa.mail.comcast.net with comcast
id jSAe1n00B4VnV2P3kSAeys; Sat, 29 Mar 2014 14:10:38 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: bitcoin-development@lists.sourceforge.net
Date: Sat, 29 Mar 2014 10:10:38 -0400
Message-ID: <1894130.91FUH3Vu6n@crushinator>
User-Agent: KMail/4.12.3 (Linux/3.12.13-gentoo; KDE/4.12.3; x86_64; ; )
In-Reply-To: <CANEZrP0WAMGV_ki3+9eFPaLQQVS7BJQ1c1c7KDuQatTeun-VwA@mail.gmail.com>
References: <1878927.J1e3zZmtIP@crushinator>
<CAJHLa0N0YCHfBeDq+QLqK3ZVWD-rAx85MXvX4OBqSoQqgCXm2w@mail.gmail.com>
<CANEZrP0WAMGV_ki3+9eFPaLQQVS7BJQ1c1c7KDuQatTeun-VwA@mail.gmail.com>
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.59.212 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: 1WTty8-0000NY-Cv
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 14:10:45 -0000
On Saturday, 29 March 2014, at 2:36 pm, Mike Hearn wrote:
> Right - the explanation in the BIP about the board of directors is IMO a
> little misleading. The problem is with splitting a private key is that at
> some point, *someone* has to get the full private key back and they can
> then just remember the private key to undo the system. CHECKMULTISIG avoids
> this.
The implication is that every director would want to retain the board's private key for himself but also would want to prevent every other director from successfully retaining the private key for himself, leading to a perpetual stalemate in which no director ever gets to retain the private key.
> I can imagine that there may be occasional uses for splitting a wallet seed
> like this, like for higher security cold wallets, but I suspect an ongoing
> shared account like a corporate account is still best off using
> CHECKMULTISIG or the n-of-m ECDSA threshold scheme proposed by Ali et al.
Multisig does not allow for the topology I described. Say the board has seven directors, meaning the majority threshold is four. This means the organization needs the consent of six individuals in order to sign a transaction: the president, the CFO, and any four of the board members. A 6-of-9 multisig would not accomplish the same policy, as then any six board members could successfully sign a transaction without the consent of the president or CFO. Of course the multi-signature scheme could be expanded to allow for hierarchical threshold topologies, or Shamir's Secret Sharing can be used to distribute keys at the second level (and further, if desired).
|
