Use Cases

Split key wallets

Escrow Services - The author does not believe that (A + B) or C scripts are required for escrow transactions. Both parties must trust the holder of C anyway so that party can instead hold both A and B. The holders of A and B can either reach an agreement themselves or party C can act as the final arbitrator using A and B together.

What does affect security is ability to adjust M (either 1 or 2) without needing to generate a new SHA256 pair. This effectively halves the key space to 2^255 keys however it is still far far out of the realm of brute force possibility. Regardless use of a 20 byte hash limits the key space to 2^160 so it actually has no effect on security at all.

Rationale

This BIP replaces BIP 16, ("/P2SH/").

There is a general consensus that multi signature transactions need to be implemented ASAP without requiring the use extremely long "script addresses". A number of potential issues have been found with the proposals thus far:

CHV requires the scriptPubKey interacts with data from scriptSig which has not been push onto the stack

P2SH requires that standard templates become a mandatory part of the scripting language, meaning they can never be fully depreciated in future.

All of the these solutions risk a fork in the blockchain and require at least 50% miners approval. This proposal requires no changes to the block validation rules and can be implemented immediately. However it only allows for the most common use cases of pay to script transactions and has limited flexibility. Additionally the resulting scriptPubKey is 6 bytes larger than the standard "pay to address" scriptPubKey in common use.

Backwards Compatibility

Old clients will not relay transactions using the new template, however they will preform the same validation as new clients.

M-of-3

The following is not part of the specification for this proposal but it is worth mentioning that using the same technique you can support both M-of-2 and M-of-3 transactions.