CHIP 2024-12 P2S: Pay to Script

CHIPs Standards Track
#3

Thanks for bringing it up!

I don’t have a strong opinion on data carrier outputs right now. In talking with stakeholders about it over the past few years, there’s a lot of technical disagreement on whether or not it should be limited at all (and if so, to what extent).

I don’t see the current ~223-byte limit as a barrier to contract development right now, so I’ve tried to avoid any impact to that status quo in the initial P2S CHIP draft. That being said:

(edit: adding headings to link to later)

Miscalculation in existing data carrier limit

There was a misunderstanding in the calculation behind the ~223-byte data carrier limit; assuming the original justification(s) for extending standard OP_RETURN to 220 bytes, that limit should arguably be higher. (And of course, the most relevant limit is currently ~100KB.)

I’m not advocating for an increase in that limit, but the issue is relevant here if we were to try to simplify by raising the P2S limit from 201 to 223 bytes. Sticking instead to the existing 201-byte bare multisig limit is probably most conservative, especially if the data carrier limit is eventually corrected upward.

Standard locking bytecode length < standard data-carrier length

Under the existing rules, the maximum-length standard locking bytecode (201-byte multisig) is a little shorter than the max-length data carrier output (220 bytes). There may be a slight impact to some incentives if this proposal were to make them equivalent.

Data carrier outputs are still “slightly cheaper” in that they can have a value set to zero (no dust limit), but their longer contiguous limit may currently help to incentivize some use cases toward data carrier vs. less- or non-prunable data commitment techniques. (Again, arguably not important, but the P2S CHIP avoids changing the status quo out of an abundance of caution.)

If I understand the question, no – evaluation stages would work exactly as today: unlocking bytecode is evaluated first (10KB limit, restricted to push ops), then the stack is copied + intermediate validation. Then the locking bytecode is evaluated: limit of 201 bytes in standard mode (replacing most of the script-type pattern matching that happens today), or the current 10KB limit in nonstandard mode (block validation). P2SH and various follow up validation also remains the same.

The CHIP can’t invalidate any existing UTXOs/use cases, and it doesn’t create a difference between output (creation time) and UTXO (spend time) standardness validation. In the interest of staying as minimal as possible, I don’t think we should add any new schemes for e.g. extending the spending-standardness length limit if the unlocking bytecode is shorter than its maximum. After all, the remaining argument for keeping any standardness limit on locking bytecode length centers around UTXO set growth, and unlocking bytecode length is irrelevant there. (@bitcoincashautist did that answer your question?)

Bitcoin Cash Shielded Addresses & ZKP OP_Code
#4

Posted some FAQs here:

Pay to Script (P2S) CHIP FAQs:

How are the 3 limits – Locking Bytecode Length, Token Commitment Length, and Unlocking Bytecode Length – related?

The currently-inconsistent behavior of these limits each produce the same unintended effect for contract authors: they force one or more unnecessary hashes to be placed into other part(s) of the transaction where they don’t logically belong, wasting storage/bandwidth for no gain to either the user or the wider network.

The P2S CHIP recommends the most conservative change to each constant to make these limits logically consistent + eliminate today’s most common sources of waste in transaction sizes.

But if the P2S CHIP is about wasted hashes in transactions, why is it called “Pay to Script”?

It’s not a perfect name. We could call it the “Reduce Unnecessary Hashing in Transactions” CHIP, or we could pick an amorphous name like “Beetroot” that doesn’t attempt to be meaningfully descriptive.

I’m open to suggestions, but for now, I think its best that the name highlights the biggest user-facing impact of the CHIP: right now we can only use “Pay to Script Hash” (P2SH), after this upgrade, we’d be able to use “Pay to Script” (P2S), too.

Most news sources covering the upgrade proposal probably won’t attempt to describe the technical details beyond that, but if they do, the intro offers plenty of material to clarify (and the rationale section includes even more):

Summary

This proposal makes Pay to Script (P2S) outputs standard and increases the length limits on token commitments and standard unlocking bytecode.

These changes improve wallet ecosystem safety, simplify contract design, and reduce transaction sizes for many vault, multi-party covenant, and decentralized financial applications.

Motivation & Benefits

  • Improve wallet ecosystem safety - Many kinds of contracts should not by “randomly payable” by naive wallets, but because P2SH contracts always have payable addresses, it’s easy for confused users to mistakenly send funds to unrecoverable locations. This proposal gives contract authors a new primitive that is both more byte efficient and safer for end users.

  • Simplify contracts - This proposal avoids the need for intermediate construction of P2SH contracts in a variety of use cases, simplifying inspection and modification of the active bytecode, and avoiding wasted bytes and hashing – both in packing (validating the P2SH address within the covenant) and unpacking (at spending time) the P2SH contract. This reduces the overhead of most covenant systems by at least 34 bytes per output.

1 Like
#5

Thanks for writing this CHIP :smiley: :pray:

I’m very enthusiastic about this CHIP and the three rules it changes! The proposal transitions 2 ‘non-standard’ rules into ‘standardness’. The increased commitment length was never added as a ‘non-standard’ rule but nevertheless also this rule deserves to be relaxed to solve the current need for hashing contract state larger than 40 bytes. :100:

Transitioning non-standardness

It will be great that the rules for custom lockingscripts and 1650-10,000 byte unlocking scripts are no longer only available for use by miner-assisted developers. Currently these use-cases really only are a possible vector for malicious actors but not usable by normal contract authors.

With the ‘Unification of Standard and Consensus Unlocking Bytecode Length’ the effective limits for smart contract authors will increase 6x. As pointed out in the CHIP this will not come at any cost for the worst-case-validation scenario, so it’s a clear win for contract developers! :rocket:

Custom Locking Scripts

It’s interesting to think about what class of smart contracts would/will benefit the most from directly using a custom locking script versus using the pay-to-scripthash wrapping. With the bytesize limit of 201 for custom locking scripts, the space savings in percentage terms for each contract using it will be high, as P2SH adds 23 or 35 bytes overhead depending on the type.

Effect on user-space and developer tooling

It’s an important benefit worth repeating that the ecosystem cost is very self-contained, this doesn’t have to be supported in any of the wallets/tooling focused on simply sending/receiving Bitcoin Cash for transaction purposes. Because there is no new address type, there clearly is not the need for the wider ecosystem to support a new address type (unlike BTC with their different segwit and taproot address types) :sweat_smile:

I know you mean ‘user-facing’ loosely here, but end-users really won’t see this new scripts, as there is no address format by design. It’s mainly smart contract-capable wallets and smart contract application developers who’ll be in contact with these new custom locking types.

Eliminating the need for offchain script-backups

Additionally, the property of P2SH that it hides the underlying script can definitely be a drawback, as it can result in losing/forgetting the exact script containing your money. For smart contracts which already have unlocked UTXOs on the P2SH address this does not present a problem, but for contracts using custom initialization params, your address will be unique which leads to off-chain storage/backup requirements.

Relaxing the NFT commitment length

As you describe, an increase in the NFT commitment length would eliminate unnecessary hashing which would currently be needed by smart contracts which want to keep more than 40 bytes state. I want to emphasize that this hashing comes with the same need for offchain script-backups described above:

If you as a developer need to hash your state to fit it into an NFT commitment, this state should either be backed up off chain (with the risks that come with it) or for self-replicating covenants the new state should be derived from the previous state + latest the state transition. Eliminating the hashing means no more need for off-chain state backups or no need for emulating contract state transitions.

I hope we see the P2S CHIP activate in 2026, it builds further upon the robust foundation laid by the VM Limits CHIP and relaxes the conservative commitment limit introduced in the CashTokens CHIP

2 Likes
CHIP-2025-01 TXv5: Transaction Version 5
#6

In cases where users initialize unique instances of a smart contract with different parameters, p2sh works against developers in many cases because the obfuscation is currently not possible to opt-out of this.

This creates 3 related issues:

  1. server requirement : the smart contract application needs to store contract params on a server when there are different unique instances so the contract can be found
  2. not interoperable : unique instances of p2sh smart contract utxos are not interoperable/findable across different front-ends
  3. no backups : there’s no standardized way to back-up smart contract params + their script logic, so the contract params/full script can be ‘forgotten’ for p2sh

This is discussed in more detail in On-chain opreturn markers for protocols and smart contracts

With the proposed P2S CHIP there would be an easy way to opt-out of the P2SH contract obfuscation.

3 Likes
#7

Then we should relax the limitation on data carrier to be per-output rather than total per-transaction, else people who need more than 223 bytes in a transaction would just use multiple P2S outputs to get around not being able to use multiple data carrier outputs.

3 Likes
#8

People can already do exactly that without P2S (bare multisig and/or input data). The primary difference is whether or not the dust limit is enforced: data carrier outputs can have a value of 0, while P2S outputs are required to “pay rent” via dust just like P2PKH, P2SH, BMS, etc. No change from the status quo.

Note that I wouldn’t be against a different CHIP simply removing the data carrier limit – again, the most relevant limit is currently ~100KB. The surface-level 223 byte limit was based on a misunderstanding, and it’s simply a mechanical inconvenience to protocols requiring larger data commitments. (Regardless, bandwidth is already paid by transaction fees, and transaction fees from all sources contribute equally to long-term network security and monetary soundness.)

If you’re interested, I’d love to see another CHIP focus specifically on that topic. The P2S CHIP requires no change either way.

2 Likes
#9

I want to document that most libraries like CashScript, mainnet-js and bch-js would have to be upgraded to support fetching UTXOs for arbitrary scripts as P2S won’t use an address format.

I don’t think it is bad that there’s a need to upgrade ecosystem tooling to support the new functionality but I just want to note it won’t be automatically supported in most libraries by default. This is because most tooling wasn’t designed with this in front-of-mind.

Luckily most APIs for blockchain-data like Electrum, ChainGraph and Chronik already allow for lockingbytecode / script / scripthash encoding. I think most blockexplorers would also be fine.

I would be interested if anyone else has more insights into the ‘ecosystem costs’ for properly supporting P2S functionality :grinning_face_with_smiling_eyes:

3 Likes
#10

I think this CHIP could really benefit from fleshing out a couple of real world examples. Ok so I understand that P2S isn’t summarized into an easily payable address string that anyone could paste into their wallet & just send off funds to - but then how DO people pay to these addresses (given they have a supporting wallet and a need to do so)?? or is it that these contracts get funded & then just run autonomously? Surely there would be some kind of user interaction in many cases?

Is it supposed to always just be automated contracts sending to other automated contracts? How do they know where to send the funds if there is no address (do they copy the template and then hash it themselves for the locking bytecode)?

A couple of small examples would really help clarify this a lot I think.

#12

There is no “where.” There is only UTXO.

Inputs → Script → Outputs

“Where” is “inside the UTXO set.”

Your wallet needs to know about all of the UTXOs it can control. It’s easy to index and find them by address because p2p cash just uses p2pkh outputs.

But what if I wanted to interact with a cauldron LP, which is Anyone-Can-Spend? The transaction gets built the same way: Input → Script → Output. In our case, we’d learn that there’s a cauldron utxo at some transaction b411a9d3… and outpoint 0, and we can reference that utxo in the script we use to build the transaction.

This is the same way p2pkh works, we know we have some utxo on some transaction:outpoint, and it gets processed by a script that says “if the data from this input matches the hash on this output (your address), allow this spend”

So the address isn’t really a locator. It’s not your house address, it’s the shape of the inside of your deadbolt lock.

When we download some UTXOs and inspect their locking bytecode, you just get a blob of hex digits.
What we mentally think of as opcodes are just hex digits to the VM, being parsed sequentially.

So what P2S does is give us the raw hex blob - we know exactly what opcodes are in the locking bytecode. We transparently know every spend path for that output.

With P2SH, the hex blob is hashed, so the only way to know what the script does, you just have to hope you pass the correct data in your input to spend it. (or have some external knowledge of the contract)

4 Likes
#13

My question is though, how would your wallet know which of those Anyone-Can-Spend UTXOs it could possibly be interested in / able to interact with? Obviously you can’t find them by address. I guess that’s where wallet templates maybe come into it?

Do you have to query Fulcrum for the full UTXO set? I assume not, I assume there will be some kind of endpoint for just checking hanging P2S outputs, but do I need to grab all of those to sift through for the one I want? How do I know what I want?

Do wallet authors need to individually code wallets to recognise each type of script? Is there going to be a “BCMR” type registry for common script patterns?

1 Like
#14

With wallet templates, then you could scan the blockchain for UTXOs that match a template. Or you could use an indexer like chaingraph to look for outputs with certain fingerprints. Or you could have some other system… I think Cauldron in particular uses an OP_RETURN 'SUMMON' or something like that to identify cauldrons and make them indexable.

We don’t have to query Fulcrum for the full UTXO set, we index UTXOs by address because it’s easy to do that for P2PKH and P2SH. But as you noted, we need some other way to identify other utxos that I can spend.

I believe we can also use the existing BCMR spec to identify and authenticate wallet templates/contract metadata like we can with token metadata.

With P2S outputs we could theoretically scan the whole UTXO set and find out about every public contract that exists on-chain, since they wouldn’t be obscured by hash.

3 Likes
#15

Thanks for the comments everyone! Just a bump to note that the CHIP now links the BCHN implementation and directly commits the updated test vectors (now covering a few thousand more cases and benchmarks :rocket:)

4 Likes
#16

So, the “address” is on chain just a 20 bytes hash. Which, again on chain, is actually identical between the p2pkh and the p2sh usecases. Which could be an issue, obviously.
This is an old problem, and the solution is actually quite interesting.

What the difference is between the p2pkh and p2sh addresses, again on chain, is the opcodes that surround them. So, the original designers of the indexers (fulcrum, electrumx etc) considered that problem and came with the solution to have a output-script-hash. A sha256 hash of the opcodes plus the 20-byte address. Which obviously nicely makes the p2sh and p2pkh addresses have a different hash.

The cool thing is, you can put in any outputscript and hash it and ask fulcrum to treat it as “an address” which you show in your wallet and get balance from etc.

The only requirement is that you get the full output-script somehow.

To enable payments between two wallets, you would not show a QR with an cash-address (q* or somesuch), instead you’d need to set up a bit more complex communication between the payer and payee. BIP70 is actually already capable of this. It allows embedding the actual output script instead of the address.

Fulcrum calls this ‘scripthash’. Example: Protocol Methods — Electrum Cash Protocol Fulcrum Protocol Reference 1.5.1 documentation

1 Like
#17

Here’s a data point on what happens when the market for out-of-band transactions gets developed: https://x.com/ercwl/status/1919834472549118413

IMO we should entirely close the gap between relay and consensus rules. This CHIP is a good step in that direction, but it doesn’t yet do it fully. Maybe do it fully?

1 Like
Non-standard transactions & out of band miner submission
#18

same as you now pay to contract addresses through dapp frontends: the dapp generates the outputs for you, and you sign with WalletConnect

how do you discover them? well, instead of indexing on address, new indexers could index on data pushes and create an index of all utxos with 20-byte pushes, then you could look up your key hash and get a list of potential utxos you can spend, then check the contract fingerprint to know what you’re looking at

2 Likes
#19

From Selection of Maximum Token Commitment Length

The 128 byte limit is selected to remain below the existing data-carrier limit ( 220 bytes), while extending the usefulness of the commitment field (without added waste or complexity from a hash-unwrapping step) for notable use cases: bilinear pairing-based accumulators (e.g. BLS12-381 KZG commitments require ~48 bytes compressed or ~96 bytes uncompressed), two 64-byte Schnorr signatures, four 32-byte (OP_HASH256, birthday-collision resistant) hashes, or six 20-byte (OP_HASH160) hashes.

What is the reason not to set the Token Commitment limit also at 220 bytes so it matches the data-carrier-limit? I understand 128 is a “nice” number in base 2, but I feel like the trend is to unifying limits (removing edge cases & gaps, especially regarding miner or data storage incentives). Why wouldn’t that be the approach here?

2 Likes
#20

Note, this is something I have proposed before. Perhaps we can develop the discussion in that thread.

3 Likes
#21

Thanks! Added new sections on this:

RE unifying standardness and consensus: I’d support a future CHIP simplifying even further by setting commitment and bytecode length limits based on today’s most relevant ~100KB per-TX cumulative limit (minus some overhead, follows from MAX_STANDARD_TX_SIZE), but for the P2S CHIP I’ve avoided any new “plausible risks” to simplify review. See:

Given the updated VM limits approach, I think there’s also little remaining justification for limiting standard TX sizes below the consensus limit, so 1MB (MAX_TX_SIZE) may be just as reasonable for all of the above. (Again, cans-of-worms I’m not interested in building consensus on for 2026.)

3 Likes
#22

On the BLISS Technical Panel, discussion of P2S started out with everyone very positive on the idea but then refocussed on the risks (basically if not directly researched) of changes to relay-vs-consensus and shrinking that gap.

BCH is not the first place in the world people are looking to store lots of arbitrary data (being either more BTC or BSV inclined in general), but at some point we’re going to have those guys show up to ““spam”” our chain & we want to be well prepared for that.

1 Like
#23

I’ve been reviewing this further and it seems to all make sense to me. The changes around standardness regarding the unlocking byte code and token commitments seem very sensible and conservative, just like VM Limits they respect the existing worst case, and as noted in the CHIP it will be a separate project to investigate deeply the additional limits and incentives for data carrying.

But for P2S CHIP I’m feeling more confident.

Non-Impact on Data-Carrier Outputs (A.K.A. OP_RETURN Outputs)

This proposal carefully avoids impact to the costs and incentives of “on-chain data storage” use cases. Because the existing 220-byte content limit on OP_RETURN Data Carrier Outputs was originally selected due to a miscalculation, there is insufficient consensus among stakeholders as to whether or not the limit should exist, and future proposals can separately increase or remove this limit, this proposal considers changes impacting the status quo to be out of scope.

Non-Reliance on Miscalculated 220-Byte Limit

The 220-byte limit was originally established to, “disincentivize the use of other methods to embed data into the chain” (commit cbf44109 ). However, this rationale was based on earlier analysis which omitted more efficient strategies for recording arbitrary data in standard transactions. As such, this proposal avoids modifying or establishing any new limits based on the incorrect 220 byte constant; future proposals can separately address this topic.

1 Like