Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.179 as permitted sender)
	client-ip=209.85.160.179; envelope-from=watsonbladd@gmail.com;
	helo=mail-yk0-f179.google.com; 
MIME-Version: 1.0
Sender: watsonbladd@gmail.com
In-Reply-To: <1894130.91FUH3Vu6n@crushinator>
References: <1878927.J1e3zZmtIP@crushinator>
	<CAJHLa0N0YCHfBeDq+QLqK3ZVWD-rAx85MXvX4OBqSoQqgCXm2w@mail.gmail.com>
	<CANEZrP0WAMGV_ki3+9eFPaLQQVS7BJQ1c1c7KDuQatTeun-VwA@mail.gmail.com>
	<1894130.91FUH3Vu6n@crushinator>
Date: Sat, 29 Mar 2014 10:28:20 -0400
Message-ID: <CACsn0cn8cFn79dMi7M3uALE5KDFJOzxK4PdFyRR8j56FygnQZg@mail.gmail.com>
From: Watson Ladd <wbl@uchicago.edu>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret
 Sharing of Bitcoin private keys
Precedence: list

On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock <bip@mattwhitlock.name> wro=
te:
> 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 a=
t
>> 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 avo=
ids
>> this.
>
> The implication is that every director would want to retain the board's p=
rivate key for himself but also would want to prevent every other director =
from successfully retaining the private key for himself, leading to a perpe=
tual stalemate in which no director ever gets to retain the private key.

This is not the case: one can use MPC techniques to compute a
signature from shares without reconstructing the private key. There is
a paper on this for bitcoin, but I don't know where it is.

>
>> I can imagine that there may be occasional uses for splitting a wallet s=
eed
>> like this, like for higher security cold wallets, but I suspect an ongoi=
ng
>> 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 s=
even directors, meaning the majority threshold is four. This means the orga=
nization needs the consent of six individuals in order to sign a transactio=
n: the president, the CFO, and any four of the board members. A 6-of-9 mult=
isig would not accomplish the same policy, as then any six board members co=
uld successfully sign a transaction without the consent of the president or=
 CFO. Of course the multi-signature scheme could be expanded to allow for h=
ierarchical threshold topologies, or Shamir's Secret Sharing can be used to=
 distribute keys at the second level (and further, if desired).
>
> -------------------------------------------------------------------------=
-----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--=20
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin