Pay to Script (P2S) improves wallet ecosystem safety, simplifies contract design, and reduces transaction sizes for vault, multi-party, and DeFi applications.
CHIP:
Some discussion:
4 Likes
I think we should remove the data carrier rule, just set a consensus per-output limit to 223 bytes to avoid needing to make exceptions for this or that. One simple rule for locking script, and one simple rule for NFT commitment size.
This will simplify consensus/relay rules, and there won’t be any incentive to ever use some non-opreturn locking script to squeeze in more data.
Also, clarify: if locking script would be limited to 223, and unlocking script to 10k, does that mean that VM would execute a 10223-byte script (when put together)?
Also, clarify: there may exist some pre-activation UTXOs that have locking script size greater than the limit proposed here. Should they be allowed to be spent (provided total executed bytes would stay under 10223 or 10k) or should they be unspendable?
2 Likes
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?)
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.