CHIP 2024-12 P2S: Pay to Script

BitcoinCashPodcast · May 16, 2025, 9:59pm

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.

BitcoinCashPodcast · May 24, 2025, 11:49am

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.

github.com

bitjson/bch-p2s/blob/master/rationale.md#non-impact-on-data-carrier-outputs-aka-op_return-outputs

# Rationale

This section documents design decisions made in this specification.

<details>

<summary><strong>Table of Contents</strong></summary>

- [Rationale](#rationale)
  - [Relationship Between the Modified Limits](#relationship-between-the-modified-limits)
  - [Selection of Maximum Locking Bytecode Length](#selection-of-maximum-locking-bytecode-length)
  - [Selection of Maximum Token Commitment Length](#selection-of-maximum-token-commitment-length)
  - [Unification of Standard and Consensus Unlocking Bytecode Length](#unification-of-standard-and-consensus-unlocking-bytecode-length)
  - [Exclusion of P2S CashAddress Format](#exclusion-of-p2s-cashaddress-format)
  - [Non-Impact on Data-Carrier Outputs (A.K.A. OP_RETURN Outputs)](#non-impact-on-data-carrier-outputs-aka-op_return-outputs)
  - [Non-Reliance on Miscalculated 220-Byte Limit](#non-reliance-on-miscalculated-220-byte-limit)

</details>

### Relationship Between the Modified Limits

This file has been truncated. show original

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.