Title: Pay to Script
    Type: Standards
    Layer: Consensus
    Maintainer: Jason Dreyzehner
    Initial Publication Date: 2024-12-12
    Latest Revision Date: 2024-09-05
    Version: 1.0.3 (c144f03f)
    Status: Frozen for Lock-In

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.

• 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.

Deployment of this specification is proposed for the May 2026 upgrade.

• Activation is proposed for 1763208000 MTP, (2025-11-15T12:00:00.000Z) on chipnet.
• Activation is proposed for 1778846400 MTP, (2026-05-15T12:00:00.000Z) on the BCH network (mainnet), testnet3, testnet4, and scalenet.

Standard output validation is relaxed to allow Pay to Script (P2S) outputs, and the limits on maximum token commitment length and maximum standard unlocking bytecode length are increased.

The existing output standardness validation requiring spendable outputs to match a known pattern (P2PK, P2PKH, P2SH20, P2SH32, OP_RETURN, or BMS) is replaced by:

1. Length check: the locking bytecode of standard outputs must have a length less than or equal to 201, the maximum length of currently standard bare multi-signature (BMS) outputs. See Rationale: Selection of Maximum Locking Bytecode Length.
2. Data-carrier validation: locking bytecode which exceeds the length check but matches the existing data-carrier pattern (OP_RETURN) is standard if accepted by the existing data-carrier validation (the cumulative 223-byte limit across all transaction outputs).

Note that UTXO standardness checks must also retain the additional allowance for bare multi-signature patterns; these remain nonstandard to create beyond the existing 3-key limit, but UTXOs exceeding the limit remain spendable in standard transactions (matching the existing behavior for these cases).

The limit on maximum length of token commitments is raised from 40 bytes to 128 bytes. See Rationale: Selection of Maximum Token Commitment Length.

The limit on maximum standard input bytecode length (A.K.A. MAX_TX_IN_SCRIPT_SIG_SIZE – 1,650 bytes) is removed such that the maximum unlocking bytecode length is equal for both standard and consensus validation: 10,000 bytes (A.K.A. MAX_SCRIPT_SIZE). See Rationale: Unification of Standard and Consensus Unlocking Bytecode Length.

• Appendix: Rationale →
  • Relationship Between the Modified Limits
  • Selection of Maximum Locking Bytecode Length
  • Selection of Maximum Token Commitment Length
  • Unification of Standard and Consensus Unlocking Bytecode Length
  • Exclusion of P2S CashAddress Format
  • Non-Impact on Data-Carrier Outputs (A.K.A. OP_RETURN Outputs)
  • Non-Reliance on Miscalculated 220-Byte Limit

• Appendix: Evaluations of Alternatives →
  • Locking Bytecode Standardness Alternatives
    • Status Quo: Pattern Matching
    • Alternative: Reduced Locking Bytecode Standardness Limit
    • Alternative: Increased Locking Bytecode Standardness Limit
      • Alternative: 220-Byte Locking Bytecode Standardness Limit
      • Alternative: 10,000-Byte Locking Bytecode Limit
      • Alternative: 100,000-Byte Locking Bytecode Limit
  • Token Commitment Length Alternatives
    • Status Quo: 40-Byte Token Commitments
    • Alternative: 201-Byte Token Commitments
    • Alternative: 220-Byte Token Commitments
    • Alternative 10,000-Byte Token Commitments
    • Alternative 100,000-Byte Token Commitments
  • Unlocking Bytecode Length Alternatives
    • Status Quo: 1,650-Byte Unlocking Bytecode Standardness Limit
    • Alternative: 100,000-Byte Unlocking Bytecode Limit

• Appendix: Risk Assessment →
  • Risks & Security Considerations
    • User Impact Risks
      • Reduced or Equivalent Node Validation Costs
      • Increased or Equivalent Contract Capabilities
    • Consensus Risks
      • Full-Transaction Test Vectors
      • Additional Performance Benchmarks
      • Chipnet Preview Activation
    • Denial-of-Service (DoS) Risks
      • Node Performance Safety Margin
    • Protocol Complexity Risks
      • Support for Post-Activation Simplification
      • Evaluation of Alternatives
  • Upgrade Costs
    • Node Upgrade Costs
    • Ecosystem Upgrade Costs
  • Maintenance Costs
    • Node Maintenance Costs
    • Ecosystem Maintenance Costs

This proposal includes a suite of functional tests and benchmarks to verify the performance of all operations within virtual machine implementations.

Please see the following implementations for additional examples and test vectors:

• C++:
  • Bitcoin Cash Node (BCHN) – A professional, miner-friendly node that solves practical problems for Bitcoin Cash. Merge Request !1937.
• JavaScript/TypeScript:
  • Libauth – An ultra-lightweight, zero-dependency JavaScript library for Bitcoin Cash. Branch next.
  • Bitauth IDE – An online IDE for bitcoin (cash) contracts. Branch next.

Stakeholder Responses & Statements →

• Pay to Script CHIP Issues
• Relaxing output standardness - Bitcoin Cash Research
• CHIP 2024-12 P2S: Pay to Script - Bitcoin Cash Research

This section summarizes the evolution of this proposal.

• v1.0.3 – 2025-09-05 (c144f03f – diff vs. master)
  • Update VMB tests and benchmarks
• v1.0.2 – 2025-05-15 (a8862008)
  • Expand Rationale
  • Add Evaluation of Alternatives
  • Add Risk Assessment
  • Scaffold Stakeholder Responses & Statements
• v1.0.1 – 2025-05-02 (3b3ef913)
  • Note that multisig standardness behavior is not modified (#1)
  • Commit latest test vectors
  • Link to BCHN implementation
• v1.0.0 – 2024-12-12 (e6f01ab1)
  • Initial publication

This document is placed in the public domain.