What is P2SH? And why must it go?

P2SH or Pay-to-Script-Hash was a patch to Bitcoin added in 2012 which altered the way it validated transactions. It is most commonly identifiable as the addresses in Bitcoin that start with a “3” instead of a “1”.

Basically instead of the normal practice of paying to a public key hash or redeem script, it instead pays to the hash digest of the redeem script on chain, which ostensibly accomplished the following things:

1) Stores an annotated version of the locking (redeem) script, instead of the script itself, which may save some fees for the person who creates the transaction due to smaller size of the resultant transaction, at the expense of the party that receives the transaction (when they spend those funds)

2) Hides the locking script so that it is not public until the payee moves the coins elsewhere

3) A complete change to the validation logic of bitcoin, basically the hash of the script is validated first, then the locking script is then executed separately.

Sounds benign right? Well, actually even though the proponents probably meant well, there were a lot of negative side effects. These effects have in essence retarded the development of the smart contract market on bitcoin and instead helped to push this market segment into alternative projects like Ethereum. Not directly, but through the Fidelity Problem. I’ll address each of these weak points on a point by point basis, in a style similar to commentary.

The practical problems with P2SH:

It hides the contract logic, so that payees and payers cannot be observed by third parties.
This is a big issue for transparency, if the payees cannot be seen, then they cannot be third party audited unless the redeem script is made available by one of the parties.

It makes it possible to have money rendered unspend-able if both parties lose the contract (redeem script).
Because the redeem script only exists and is stored only by the parties of the transaction, if for whatever reason all copies of the redeem script have been lost, it may be impossible for the parties to move the funds, as they require BOTH the redeem script and the requisite keys to redeem. This makes wallet management software for multi-sig transactions more complex and error prone.

Plausible deniability is not a good thing for legally binding contracts.
If the contract is on the blockchain, then one counterpart can always dob on the other. However, in P2SH as the contract is kept only by active parties, if they are engaging in criminal activity, then it stands to reason that they would always destroy their copies, if the authorities wanted to investigate them. This makes contracts hard to enforce, and would also elicit shady activity.

Imagine if the system were used to facilitate illegal gambling. In this case, it would be beneficial for the bets to use P2SH, because it will make it impossible to identify the escrowed bets until the bet has been settled. If either the casino (escrow) or the parties to the bet were approached by the authorities, they could just say that they know nothing of the bet, and they can both deny having any involvement in the transaction. If this were a bare multisig or a transparent contract, the legal casino’s address would be visible and would be able to identify to the authorities who to approach if one of the parties funds’ origins were dubious and required investigation, thereby releasing the casino of the legal liability.

Wallet interfaces need to know what kind of smart contracts they should support. If the contract is hidden, then it becomes harder to know what kind of GUI interfaces need to be supported.
If smart contracts were transparently visible on the blockchain, then wallets whose job it is to create intuitive interfaces to sometimes complex signing processes would be easier to engineer because the outstanding body of contracts and locked funds on the entire network would be visible (while maintaining privacy), and more importantly the structure of the contracts would be scrutable. This allows for proper software development.

This goes for op_codes as well.
The idea of a scripting language (Bitcoin script) being used as the contract “intermediary” means that the language needs to support all outstanding contracts which may have long term tenures. If the use of particular op_code is done in an offline fashion (such as P2SH) so that nobody sees it, then the system is stuck having to support all op_code features (even ones deemed no longer useful), as it cannot know that somebody isn’t depending on it in a redeem script that they hold privately. This puts the system into a sort of paralysis in terms of upgradability, as nothing can ever be changed or upgraded.

So how do we get rid of it?

Prevent the creation of new P2SH outputs.
We first must make sure that no more P2SH outputs are created. This is a simple restriction and will be put into place with the Feb 4th Genesis upgrade.

We need to provide an upgrade path for all existing P2SH outputs where they will still be supported but they will not be allowed to pay into new P2SH outputs.
Secondly we need to support all the existing P2SH outputs which have not yet been redeemed. This means that although it may cause a lot of technical debt to be ‘rolled forward’, we must maintain the support and the ‘payablility’ of the old P2SH outputs.

However, when these outputs are paid they must be paid to either bare multisig or a standard Public key address or a transparent smart contract (redeem script) on-chain. With luck the body of existing P2SH outputs outstanding in the network will slowly decline until a time in the future when the backward compatibility mode can be switched off.

Finally, we need to provide an incentive for them to be migrated.
This one is optional, but desired. If you have a P2SH output, the instinct is to leave it there for as long as you can, for as long as there are some outstanding legacy outputs, it would be difficult for miners to support turning off the legacy code needed to process it. How do we sort out these potential freeloaders?

Thankfully Bitcoin was designed as an economic system. So we can apply the same economic pressures that we can exert on undesired behaviour in society: we can apply a cost to engage in it. When the miners are burdened with having to support legacy code, they may demand higher fees for the processing of P2SH outputs than normal.

For instance, instead of the standard 0.5sat/byte (only on BSV!), they may choose to impose an increasing fee ladder of 1sat, 2sat, 4sat, 8sats/byte until all the P2SH outputs are redeemed over time.

As P2SH defers the heavily sized fee obligation on the payee, this will likely prove very effective to pressure holders of these outputs to move them to the supported non-P2SH versions sooner rather than let them languish. Another consideration is the declining support of wallets overtime for P2SH payments. At some point it will be assumed that developers will not want to keep up support of the legacy code needed to process them.

So long, and thanks for all the fish
So I hope that you can see the need for P2SH to be deprecated in the upcoming Genesis release. It was a hasty patch put into Bitcoin long ago by developers acting without clear knowledge of how the system was supposed to work (Dr. Craig Wright as Satoshi left the active development team in 2011, P2SH came in 2012).

In order to solve some perceived problems with wallet UI for multisig transactions, core devs handicapped Bitcoin’s smart contract ability by damaging the transparency of the ledger and opened the door for its potential to be used for dubious purposes. They also created a negative environment of technical debt in the system, by hindering its upgradability.

Any business looking to use an enterprise system must be able to generate faithful records that are open to scrutiny by the respective authorities. In order for the blockchain to be the ‘golden copy’ or ‘ledger of records’ it must stand beyond reproach. This is why before the real smart contract explosion in Bitcoin can happen, we must first sweep away the vestiges of the past, so that we can build a strong foundation for the future.

In conjunction with the restorative changes that BSV has made by re-enabling OP_CODES necessary for full programmatic expression, (allowing for complex payment conditions and smart contracts to be once again possible), the sunsetting of P2SH will finally reset Bitcoin 99% of the way back to the original design as defined by the whitepaper and its original goal as a global peer-to-peer cash system.