The original multisig implementation put the signatures right there in the script. This makes the script bigger, and provides a way for "Bitcoin 2.0" schemes like Mastercoin and Colored Coin to use multisig to encode data into the blockchain.
Some see the inclusion of data into the Bitcoin Blockchain as a significant problem. In this context, one solution proposed a few weeks ago is P2SH. P2SH does not include the multisig script when the transaction output is created, but instead a check sum for a script to be provided at "spend time". Now since the signatures are not right there in the script, Bitcoin 2.0 layers are denied this avenue for encoding information into the blockchain, yet when the Transaction output is spent, a proper multisig script can be provided by the transaction spending the output. This provided script must be validated by rules restricting its construction as well as by the check sum provided by the unspent output.
Sounds grand, but I see a few issues with P2SH verification:
- Now the destination of output can be obscured. A bogus signature can be included that is always unique (so while the script of multiple outputs is really the same script, they each have their own unique check sum). This allows the engineering of inputs are only individually spendable, as each input would have its own check sum (and thus cannot be combined). This could increase the size of the unspent database.
- Obscured destinations can break deterministic wallets. You need not only your private keys, but the actual scripts used on transactions payable to you so you can properly spend payments to you. Any change to the signatures required on transactions must be accounted for.
- Given the IRS rules, computing tax liability could be impossible, since a multisig transaction might easily be "spent" when the unspent transaction output was created, or "spent" when the transaction output was spent. IOW I can "toss" BTC into the air where multiple parties (possibly including myself) may or may not claim control of the output at some future time. All P2SH unspent transactions carry this uncertainty. As a user, you may not have any access to the actual script for a transaction to prove you literally spent your bitcoin on the date that the transaction output was created.
- Obscurity in the destination of a spend potentially breaks the ability to audit transactions. A user cannot prove they provided Bitcoin to a particular address which can be provably controlled by a particular party unless that party has chosen to spend that particular output, or provide to the sender a signed script for use in an audit.
If these issues have been discussed, a pointer to those discussions would be appreciated.
