📅 Original date posted:2014-03-29
📝 Original message:On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> 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.
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 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).
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
Watson Ladd [ARCHIVE] /
npub108…sr4hp
2023-06-07 15:16:38
in reply to nevent1q…vyar
Author Public Key
npub108dfgewsuqzm6cvllzmxsv0xnn69rrjnyg5pa32a727k89ndh3xqmsr4hpSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:16:38Event JSON
{
"id": "e145189734aed2ee317be62a6e5c792288d7da430f5cba9a63b09a508726bd44",
"pubkey": "79da9465d0e005bd619ff8b66831e69cf4518e5322281ec55df2bd63966dbc4c",
"created_at": 1686150998,
"kind": 1,
"tags": [
[
"e",
"cd470d06d90a3107c21da4b48b344ebdd3b4ab813362bb85b0e7a02311012700",
"",
"root"
],
[
"e",
"f17dcd762c73071e6d1fbb5630ea8a4b60f7493d07e64ff62502b2956ec71a84",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-03-29\n📝 Original message:On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e wrote:\n\u003e On Saturday, 29 March 2014, at 2:36 pm, Mike Hearn wrote:\n\u003e\u003e Right - the explanation in the BIP about the board of directors is IMO a\n\u003e\u003e little misleading. The problem is with splitting a private key is that at\n\u003e\u003e some point, *someone* has to get the full private key back and they can\n\u003e\u003e then just remember the private key to undo the system. CHECKMULTISIG avoids\n\u003e\u003e this.\n\u003e\n\u003e 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.\n\nThis is not the case: one can use MPC techniques to compute a\nsignature from shares without reconstructing the private key. There is\na paper on this for bitcoin, but I don't know where it is.\n\n\u003e\n\u003e\u003e I can imagine that there may be occasional uses for splitting a wallet seed\n\u003e\u003e like this, like for higher security cold wallets, but I suspect an ongoing\n\u003e\u003e shared account like a corporate account is still best off using\n\u003e\u003e CHECKMULTISIG or the n-of-m ECDSA threshold scheme proposed by Ali et al.\n\u003e\n\u003e 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).\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n\n\n-- \n\"Those who would give up Essential Liberty to purchase a little\nTemporary Safety deserve neither Liberty nor Safety.\"\n-- Benjamin Franklin",
"sig": "2014e2856514892fc01b277f821c93335e8ab05e0197133685ea17d7544d55061f0adf9fb36ca644f8274ef6268f8a3d8dee32491849acd994bcaa820f20bef4"
}