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). ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
