I think they might make third-party escrow easier;
Why is it necessary to rely on a third party escrow service when most transactions could be made without?
For example #bitcoin-otc could provide a list of trusted representatives along with their bitcoin addresses which people can use as arbitrators. An (A + B) or (c) transaction where C is the arbitrator. Using CHECKMULTISIG I could imagine a form in the client with the destination address, a checkbox saying "Require authorisation from self" and an additional field "Add arbitrator" - relatively straight forward and the majority of transaction would not need to involve #bitcoin-otc or the arbitrator. However with P2SH hash #bitcoin-otc needs to have a web service to construct the transaction, users need to copy their public keys into the web service and once the script hash is constructed add it to their bitcoin client.
But the use case I REALLY care about is the secure, multiple-signatures-required-to-spend wallet.
I started trying to think of different ways split key wallets could maintain compatibility with the existing widespread use of pay to address. The easiest way would be for wallet services to mange the private keys of a number of User's public addresses and automatically forward payments received using a user defined CHECKMULTISIG template.
The other method I came up with started getting a bit complex, but i'll post it anyway:
Redefine OP_NOP1 as a new opcode
OP_ATTACH_SCRIPT. Conceptually it would allow the owner of an address to pre register a script which must be run before funds can be redeemed allowing them to change authentication method at their own free without needing to move funds.
After an OP_ATTACH_SCRIPT any successful call to OP_CHECKSIG will cause the top stack item to be inserted into an index using the pubKey as the primary key.
All calls to OP_CHECKSIG in a scriptSig that reference a public key which has an attached script cause the script to be retrieved and executed using the current stack. If the scriptSig contains a OP_ATTACH_SCRIPT it is executed after.
You first need to attach a script to an address by using a transaction with a scriptSig in the following format (example two signature transaction (A + B)).
scriptSig: OP_PUSHDATA1 33 {[pubkey2] OP_CHECKSIG} <sig><pubKey> OP_ATTACH_SCRIPT
Execution:
OP_PUSHDATA1 33 {[pubkey2] OP_CHECKSIG} <sig> <pubKey> OP_ATTACH_SCRIPT OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<script> <sig> <pubKey> OP_ATTACH_SCRIPT OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<script> <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<script> <sig> <pubKey> <pubKey> OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<script> <sig> <pubKey> <pubKeyA> <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<script> <sig> <pubKey> OP_CHECKSIG
On success
** attachedScripts.put(<pubKey>, <script>) **Funds are sent to the address using the a standard scriptPubKey template.
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Once a script is attached subsequent scriptSigs need to prepended with each additional signature and then the standard scriptSig template.
scriptSig: <sig> <sig> <pubKey>
For new clients this is executed as follows:
<sig> <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<sig> <sig> <pubKey> <pubKey> OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<sig> <sig> <pubKey> <pubHashA> <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<sig> <sig> <pubKey> OP_CHECKSIG
On success
** attachedScripts.find(<pubKey>) **<sig> {[pubkey2] OP_CHECKSIG}
The script will validate for old clients as :
scriptSig: <sig> <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Remove multi sig support using:
scriptSig: OP_PUSHDATA1 1 OP_TRUE OP_ATTACH_SCRIPT <sig> <sig> <pubKey>
Redefine multi sig as A + (B or C) using:
scriptSig: OP_PUSHDATA1 67 {1 [pubkey1] [pubkey2] 2 OP_CHECKMULTISIG} OP_ATTACH_SCRIPT <sig> <sig> <pubKey>
Advantages:
1) Maintain full out of the box compatibility with existing pay to pubKeyHash - payments will appear in all existing bitcoin clients.
2) Needs only to include additional [pubKeys] once on script attach, not in every scriptsig. This would potential save 32 bytes per 2 key transactions, 64 bytes per 3 key transactions etc.
4) Maintain consistency of the scripting language
5) You can change the authentication required for a particular address. People can enable multiSig on their existing vanity addresses, You can change "Wallet protection services" without needing to change address.
6) Potentially allow people to "trade" addresses for example you could buy a popular vanity and change the authentication type by hand removing the need to trust that the original key was removed. Same concept can be applied to physical bitcoins, or bitbills.
Disadvantages:
2) Client needs to track what pub keys have a Script attached. An index like this is needed:
std::map<uint256, CScript> attachedScripts
This would need to be updated during re-org.
3) Like P2SH this needs 50% miners adoption - old clients may find themselves on the shorter side of the blockchain.
4) Need to "register" an address by sending at least one transaction from it, addresses would be more permanent and less disposable.
