I'm following "Mastering Bitcoin" from Andreas Antonopoulos in order to understande the Bitcoin implementation.
In the chapter about transactions, he points some advantages of P2SH transactions:
- Complex scripts are replaced by shorter fingerprints in the transaction output, making the transaction smaller.
- Scripts can be coded as an address, so the sender and the sender’s wallet don’t need complex engineering to implement P2SH.
- P2SH shifts the burden of constructing the script to the recipient, not the sender.
- P2SH shifts the burden in data storage for the long script from the output (which is in the UTXO set) to the input (stored on the blockchain).
- P2SH shifts the burden in data storage for the long script from the present time (payment) to a future time (when it is spent).
- P2SH shifts the transaction fee cost of a long script from the sender to the recipient, who has to include the long redeem script to spend it.
About item 4, it still looks suboptimal to me.
Imagine that I have a firm where in order to spend the payment from customers I also have to get the signatures from at least 1 of 2 other partners. My script would look like:
2 <My PubKey> <Partner 1's PubKey> <Partner 2's PubKey> 3 OP_CHECKMULTISIG
So, for every incoming payments that I'd like to spend, my
scriptSig would have to be bloated with the script above plus 2 signatures
Imagine that I'll have thousands of these transactions, this would be bloating the blockchain, probably decreasing the processing capabilities of the network.
I was wondering: is there any way of mantaining these scripts as "accounts" in "script wallets" and not storing it inside the blockchain?
When there is need for validation, I could simply retrieve this script form the "wallet" and check the transaction.
How would it be possible?