Up to this point in the book, we’ve been doing single-key transactions, or transactions with only a single private key per input. What if we wanted something a little more complicated? A company that has $100 million in bitcoin might not want the funds locked to a single private key: if that single key were lost or stolen, all funds would then be lost. What can we do to reduce the risk of this single point of failure?
The solution is multisig, or multiple signatures. This was built into Bitcoin from the beginning, but was clunky at first and so wasn’t used. As we’ll discover later in this chapter, Satoshi probably didn’t test multisig, as it has an off-by-one error (see OP_CHECKMULTISIG Off-by-One Bug). The bug has had to stay in the protocol because fixing it would require a hard fork.
It is possible to “split” a single private key into multiple private keys and use an interactive method to aggregate signatures without ever reconstructing the private key, but this is not a common practice. Schnorr signatures will make aggregating signatures easier and perhaps more common in the future.
Bare multisig was the first attempt at creating transaction outputs that require signatures from multiple parties.
The idea is to change from a single point of failure to something a little more resilient to hacks.
To understand bare multisig, one must first understand the
OP_CHECKMULTISIG opcode. ...