Skip to content
/ bch-vm-limits Public

Re-targets virtual machine (VM) limits to enable more advanced Bitcoin Cash contracts, reduce transaction sizes, and reduce full node compute requirements.

10 stars 9 forks Branches Tags Activity
Star
Notifications You must be signed in to change notification settings

bitjson/bch-vm-limits

BranchesTags

Repository files navigation

CHIP-2021-05 VM Limits: Targeted Virtual Machine Limits

    Title: Targeted Virtual Machine Limits
    Type: Standards
    Layer: Consensus
    Maintainer: Jason Dreyzehner
    Status: Draft
    Initial Publication Date: 2021-05-12
    Latest Revision Date: 2024-11-11
    Version: 3.1.2
Table of Contents

Summary

This proposal re-targets virtual machine (VM) limits to enable more advanced Bitcoin Cash contracts, reduce transaction sizes, and reduce full node compute requirements.

Motivation & Benefits

This proposal enables:

  • More advanced contracts – The 201 opcode limit and 520-byte, Pay-to-Script-Hash (P2SH) contract length limit each raise the cost of developing Bitcoin Cash products by requiring contract authors to remove important features or otherwise complicate products with harder-to-audit, multi-input systems. Replacing these limits reduces the cost of contract development and security audits.

  • Larger stack items – Re-targeted limits enable new post-quantum cryptographic applications, stronger escrow and settlement strategies, larger hash preimages, more practical zero-knowledge proofs, homomorphic encryption, and other important developments for the future security and competitiveness of Bitcoin Cash.

Additionally, this proposal renders the number length limit (A.K.A. nMaxNumSize) unnecessary. Following cross-implementation verification work, an additional proposal was created to enable:

  • Simpler, easier-to-audit, high-precision math – Lowers the cost of developing, maintaining, and auditing contract systems relying on high-precision math: automated market makers, decentralized exchanges, decentralized stablecoins, collateralized loan protocols, cross-chain and sidechain bridges, and other decentralized financial applications. By allowing Bitcoin Cash to offer contracts maximum-efficiency, native math operations, this proposal would significantly reduce transaction sizes, block space usage, and node CPU utilization vs. existing emulated-math solutions.

Deployment

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

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

Technical Summary

  • The 201 operation limit is removed.
  • The 520-byte stack element length limit is raised to 10,000 bytes, a constant equal to the consensus-maximum VM bytecode length (A.K.A. MAX_SCRIPT_SIZE) prior to this proposal.
  • A new operation cost limit is introduced, limiting contracts to approximately 700 bytes pushed to the stack per spending input byte, with increased costs for hashing, signature checking, and expensive arithmetic operations; constants are derived from the effective limit(s) prior to this proposal.
  • A new hashing limit is introduced, limiting contracts to approximately 3.5 hash digest iterations per spending input byte, a constant rounded up from the effective standard limit prior to this proposal, and further limiting standard contracts to approximately 0.5 hash digest iterations per spending input byte, the maximum-known, theoretically-useful hashing density.
  • A new control stack limit is introduced, limiting control flow operations (OP_IF and OP_NOTIF) to a depth of 100, the effective limit prior to this proposal.

This proposal intentionally avoids modifying other existing properties of the VM:

  • Other existing limits are not modified:
    • Signature operation count (A.K.A. SigChecks) density,
    • Maximum cumulative stack and altstack depth (A.K.A. MAX_STACK_SIZE; 1000 items),
    • Maximum standard input bytecode length (A.K.A. MAX_TX_IN_SCRIPT_SIG_SIZE; 1,650 bytes),
    • Consensus-maximum VM bytecode length (A.K.A. MAX_SCRIPT_SIZE; 10,000 bytes),
    • Maximum standard transaction byte-length (A.K.A. MAX_STANDARD_TX_SIZE; 100,000 bytes), and
    • Consensus-maximum transaction byte-length (A.K.A. MAX_TX_SIZE; 1,000,000 bytes).
  • The cost and incentives around blockchain “data storage” are not measurably affected.
  • The worst-case processing and memory requirements of the VM are not measurably affected.

Technical Overview of Changes to C++ Clients

The following overview summarizes all changes proposed by this document to C++ implementations following the general structure of the original Satoshi client, e.g. Bitcoin Cash Node:

  1. MAX_SCRIPT_ELEMENT_SIZE increases from 520 to 10000.
  2. nOpCount becomes nOpCost (used to measure stack-pushed bytes and operation costs)
  3. A new static inline pushstack is added to match popstack; pushstack increments nOpCost by the item length.
  4. if (opcode > OP_16 && ++nOpCount > MAX_OPS_PER_SCRIPT) { ... } becomes nOpCost += 100; (not conditional, so also added for unexecuted and push operations).
  5. case OP_ROLL: adds nOpCost += depth;
  6. case OP_AND/OP_OR/OP_XOR: adds nOpCost += result.size();
  7. case OP_1ADD...OP_0NOTEQUAL: adds nOpCost += bn.size();, case OP_ADD...OP_MAX: adds nOpCost += bn1.size() + bn2.size();, case OP_WITHIN: adds nOpCost += bn1.size() + bn2.size() + bn3.size();
  8. case OP_MUL/OP_DIV/OP_MOD: adds nOpCost += a.size() * b.size();
  9. Hashing operations add 1 + ((message_length + 8) / 64) to nHashDigestIterations, and nOpCost += 192 * iterations;.
  10. Same for signing operations (count iterations only for the top-level preimage, not hashPrevouts/hashUtxos/hashSequence/hashOutputs), plus nOpCost += 26000 * sigchecks; (and nOpCount += nKeysCount; is removed)
  11. SigChecks limits remain unchanged; similar density checks apply to nHashDigestIterations and nOpCost.
  12. Adds if (vfExec.size() > 100) { return set_error(...

Technical Specification

The existing Stack Element Length Limit is raised; two new limits are introduced: a Control Stack Limit and a Hashing Limit; and the 201 Operation Limit is replaced by an Operation Cost Limit.

Increased Stack Element Length Limit

The existing 520-byte stack element length limit (A.K.A. MAX_SCRIPT_ELEMENT_SIZE) is raised to 10,000 bytes.

Note on Maximum Standard Input Bytecode Length

This increases the maximum length of stack elements to be equal to the maximum allowed VM bytecode length (A.K.A. MAX_SCRIPT_SIZE – 10,000 bytes). To narrow the scope of this proposal, the maximum standard input bytecode length (A.K.A. MAX_TX_IN_SCRIPT_SIG_SIZE – 1,650 bytes) is unchanged.

Control Stack Limit

To retain the existing limit of 100 on control stack depth, a direct limit is placed on operations which push to the control stack (A.K.A. vfExec or ConditionStack). See Rationale: Retention of Control Stack Limit.

This limit impacts only the OP_IF and OP_NOTIF operations. For the purpose of enforcing this limit, OP_IFDUP is not considered to internally push to the control stack, i.e. an OP_IFDUP executed at a depth of 100 does not violate the Control Stack Limit.

Hashing Limit

To prevent excessive hashing function usage, a direct limit is placed on OP_RIPEMD160 (0xa6), OP_SHA1 (0xa7), OP_SHA256 (0xa8), OP_HASH160 (0xa9), OP_HASH256 (0xaa), OP_CHECKSIG (0xac), OP_CHECKSIGVERIFY (0xad), OP_CHECKMULTISIG (0xae), OP_CHECKMULTISIGVERIFY (0xaf), OP_CHECKDATASIG (0xba), and OP_CHECKDATASIGVERIFY (0xbb).

Before a hashing function is performed, its expected cost – in terms of digest iterations – is added to a cumulative total for the transaction input. If the cumulative total for the transaction input exceeds the maximum allowed density, the operation produces an error. See Rationale: Hashing Limit by Digest Iterations.

Note that hash digest iterations are cumulative across all evaluation stages of a transaction input: unlocking bytecode, locking bytecode, and redeem bytecode (of P2SH evaluations). This differs from the behavior of the existing operation limit (A.K.A. nOpCount), which resets its count to 0 prior to each evaluation stage.

Density Control Length

The Density Control Length is computed by adding the unlocking bytecode length to the constant 41 – the minimum possible per-input overhead of version 1 and 2 transactions. See Rationale: Selection of Input Length Formula.

Maximum Hashing Density

For standard transactions, the maximum density is 0.5 hash digest iterations per Density Control Length byte. For block validation, the maximum density is 3.5 hash digest iterations per Density Control Length byte. See Rationale: Selection of Hashing Limit and Rationale: Use of Input-Length Based Densities.

Given the spending input's unlocking_bytecode_length (A.K.A. scriptSig length), hash digest iteration limits (0.5 and 3.5, respectively) may be calculated with the following C functions:

int max_standard_iterations (int unlocking_bytecode_length) {
    return (41 + unlocking_bytecode_length) / 2;
}
int max_consensus_iterations (int unlocking_bytecode_length) {
    return ((41 + unlocking_bytecode_length) * 7) / 2;
}
Calculate Maximum Digest Iterations in JavaScript 
const maxStandardIterations = (unlockingBytecodeLength) =>
  (41n + unlockingBytecodeLength) / 2n;
const maxConsensusIterations = (unlockingBytecodeLength) =>
  ((41n + unlockingBytecodeLength) * 7n) / 2n;

Note that this formula relies on the transaction input's Density Control Length rather than the precise encoded length of the input. See Rationale: Selection of Input Length Formula.

Digest Iteration Count

The hashing limit caps the number of iterations required by all hashing functions over the course of verifying an input. This places an upper limit on the sum of bytes hashed, including padding.

Given a message length, digest iterations may be calculated with the following C function:

int digest_iterations(int message_length, bool is_double) {
  return 1 + ((message_length + 8) / 64) + (is_double ? 1 : 0);
}

Note that the double-hashing operations (OP_HASH160 and OP_HASH256) and all Transaction Signature Checking Operations (but not the Data Signature Checking Operations) perform a final hash digest iteration on the result produced by the initial round of hashing; for these operations, the is_double parameter must be set to true to increment the final count by one.

Calculate Digest Iterations in JavaScript 
const digestIterations = (messageLength, isDouble) =>
  1n + (messageLength + 8n) / 64n + (isDouble ? 1n : 0n);
Digest Iteration Count Test Vectors

These test vectors reflect the required hash digest iterations for a variety of message lengths, without accounting for double hashing. For double-hashed messages, the Digest Iterations shown must be further incremented by one.

Message Length (Bytes) Digest Iterations
0 1
1 1
55 1
56 2
64 2
119 2
120 3
183 3
184 4
247 4
248 5
488 8
503 8
504 9
520 9
1015 16
1016 17
63928 1000
63991 1000
63992 1001
Explanation of Digest Iteration Formula

Each VM-supported hashing algorithm – RIPEMD-160, SHA-1, and SHA-256 – uses a Merkle–Damgård construction with a 512-bit (64-byte) message block length, so the number of message blocks/digest iterations required for every message length is equal among all VM-supported hashing functions. The specified formula correctly accounts for padding: hashed messages are padded with a 1 bit, followed by enough 0 bits and a 64-bit (8-byte) message length to produce a padded message with a length that is a multiple of 512 bits. Note that even small messages require at least one hash digest iteration, and an additional hash digest iteration is required for each additional 512-bit message block in the padded message.

Hashing Operations

The OP_RIPEMD160 (0xa6), OP_SHA1 (0xa7), OP_SHA256 (0xa8), OP_HASH160 (0xa9), and OP_HASH256 (0xaa) operations must compute the expected digest iterations for the length of the message to be hashed, adding the result to the spending transaction input's cumulative count. If the new total exceeds the hashing limit, validation fails.

Note that evaluations triggering P2SH20 and P2SH32 evaluations must also account for the (2 or more) hash digest iterations required to test validity of the redeem bytecode (OP_HASH160 <20_bytes> OP_EQUAL or OP_HASH256 <32_bytes> OP_EQUAL, respectively).

Note on Two-Round Hashing Operations

The two-round hashing operations – OP_HASH160 (0xa9) and OP_HASH256 (0xaa) – pass the 32-byte result of their initial SHA-256 hashing round into their second round, each requiring one additional digest iteration beyond the single-round OP_SHA256.

Transaction Signature Checking Operations

Before each signature check, the OP_CHECKSIG (0xac), OP_CHECKSIGVERIFY (0xad), OP_CHECKMULTISIG (0xae), and OP_CHECKMULTISIGVERIFY (0xaf) operations must add the count of hash digest iterations required for the length of the signing serialization (including the iteration in which the final result is double-hashed) to the spending transaction input's cumulative count. If the new total exceeds the hashing limit, validation fails.

Note that the hash digest iteration count is incremented each time a non-null signature is checked, even if a previous signature check used the same signing serialization. See Rationale: Stateless Costing of Signing Serialization Hashing.

Note that hash digest iterations required to produce components of the signing serialization (i.e. hashPrevouts, hashUtxos, hashSequence, and hashOutputs) are excluded from the hashing limit, as implementations should cache these components across signature checks. See Rationale: Exclusion of Signing Serialization Components from Hashing Limit.

Data Signature Checking Operations

The OP_CHECKDATASIG (0xba) and OP_CHECKDATASIGVERIFY (0xbb) operations must compute the expected digest iterations for the length of the message to be hashed, adding the result to the spending transaction input's cumulative count. If the new total exceeds the limit, validation fails.

In counting digest iterations, note that these operations perform only a single round of hashing.

Operation Cost Limit

An Operation Cost Limit is introduced, limiting transaction inputs to a cumulative operation cost of 800 per spending Density Control Length byte. See Rationale: Selection of Operation Cost Limit and Rationale: Use of Input-Length Based Densities.

Given the spending input's unlocking bytecode length (A.K.A. scriptSig), the operation cost limit may be calculated with the following C function:

int max_operation_cost (int unlocking_bytecode_length) {
    return (41 + unlocking_bytecode_length) * 800;
}
Calculate Maximum Operation Cost in JavaScript 
const maxOperationCost = (unlockingBytecodeLength) =>
  (41n + unlockingBytecodeLength) * 800n;

Note that this formula relies on the Density Control Length rather than the precise encoded length of the input. See Rationale: Selection of Input Length Formula.

Replacement of 201-Operation Limit with Operation Cost Limit

The existing 201-operation limit per evaluation (A.K.A. MAX_OPS_PER_SCRIPT) is removed and replaced by the Operation Cost Limit.

Note on Zero-Signature, Multisignature Operations

Note that prior to this proposal, the OP_CHECKMULTISIG (0xae) and OP_CHECKMULTISIGVERIFY (0xaf) operations incremented the operation count by the count of public keys, even if zero signatures were checked. Since the total operation count of any contract evaluation was limited to 201 operations, the overall density of OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY was restricted by the remaining operation count in applicable contracts.

Following the removal of the operation limit, both OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are limited only by the SigChecks and hashing limits; implementations should ensure that evaluations of OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY requiring zero signature checks are sufficiently performant. See Rationale: Increased Usability of Multisig Stack Clearing.

Base Instruction Cost

For each evaluated instruction (including unexecuted and push operations), operation cost is incremented by 100. See Rationale: Selection of Base Instruction Cost.

Cumulative Cost Across Evaluation Stages

Note that operation costs are cumulative across all evaluation stages: unlocking bytecode, locking bytecode, and redeem bytecode (of P2SH evaluations). This differs from the behavior of the existing operation limit (A.K.A. nOpCount), which resets its count to 0 prior to each evaluation stage.

Measurement of Stack-Pushed Bytes

For all operations which push to the primary stack, operation cost is additionally incremented by the byte length of the pushed stack item. See Rationale: Limitation of Pushed Bytes.

This specification codifies the pushing behavior of each operation based on v27.0.0 of Bitcoin Cash Node, an implementation written in 2008 by Satoshi Nakamoto and continuously improved by various contributors. Counting of pushed bytes are consistent with this implementation with the exception of OP_ROLL and the bitwise operations (OP_AND, OP_OR, and OP_XOR). See Operation Cost by Operation.

Bitwise operations

In addition to the aforementioned costs, the bitwise operations (OP_AND, OP_OR, and OP_XOR) are considered to push their result, even if an implementation performs bitwise operations in-place (e.g. for performance reasons).

OP_ROLL

In addition to the aforementioned costs, the operation cost of OP_ROLL is incremented by the numeric value indicating the depth of the roll, between 0 and 999 (the maximum-depth roll).

OP_ROLL Cost Example

For example, <'a'> <'b'> <'c'> <2> OP_ROLL (producing <'b'> <'c'> <'a'>) is incremented by 2 for a total cost of 100 (the base instruction cost), plus 1 (the byte length of 'a'), plus 2 (the roll depth): 103.

Arithmetic Operation Cost

To account for the cost of encoding VM numbers, the sum of all numeric output lengths with the potential to exceed 2**32 are added to the operation cost of all operations with such outputs: OP_1ADD (0x8b), OP_1SUB (0x8c), OP_NEGATE (0x8f), OP_ABS (0x90), OP_ADD (0x93), OP_SUB (0x94), OP_MUL (0x95), OP_DIV (0x96), OP_MOD (0x97), OP_MIN (0xa3), and OP_MAX (0xa4); e.g. given terms a b -> c (such as in <a> <b> OP_ADD), the operation cost is: the base cost (100), plus the cost of re-encoding the output (c.length), plus the byte length of the result (c.length), for a final formula of 100 + (2 * c.length). See Rationale: Inclusion of Numeric Encoding in Operation Costs.

To account for O(n2) worst-case performance, the operation cost of OP_MUL (0x95), OP_DIV (0x96), and OP_MOD (0x97) are also increased by the product of their input lengths, i.e. given terms a b -> c, the operation cost is: the base cost (100) plus the cost of re-encoding the output (c.length), plus the byte length of the result (c.length), plus the product of the input lengths (a.length * b.length), for a final formula of 100 + (2 * c.length) + (a.length * b.length).

Hash Digest Iteration Cost

All operations which increase the cumulative total of hash digest iterations must simultaneously increase the cumulative operation cost by the product of the additional iterations and the Hash Digest Iteration Cost. See Rationale: Unification of Limits into Operation Cost.

The Hash Digest Iteration Cost is set to 64 for block validation (by consensus) and 192 for transaction relay ("standard") validation. See Rationale: Selection of Hash Digest Iteration Cost.

Signature Checking Operation Cost

All operations which increase the cumulative total of SigChecks (as defined by the 2020-05 SigChecks specification) must simultaneously increase the cumulative operation cost by the product of the additional sigchecks and 26000. See Rationale: Selection of Signature Verification Operation Cost.

Notice of Possible Future Expansion

While unusual, it is possible to design pre-signed transactions, contract systems, and protocols which rely on the rejection of otherwise-valid transactions that exceed current VM limits. Contract authors are advised that future upgrades may further expand VM limits by increasing allowable operation cost density, reducing the accounted cost of particular operations, or otherwise.

This proposal interprets such failure-reliant constructions as intentional – the constructions are designed to fail unless/until a possible future network upgrade in which such limits are increased, e.g. upgrade-activation futures contracts. See Rationale: Inclusion of "Notice of Possible Future Expansion".

Notes

The security of a contract is the responsibility of the entity locking funds in that contract; funds can always be locked in insecure contracts (e.g. "Anyone-Can-Spend addresses"). This notice is provided to warn contract authors and explicitly codify a network policy: the possible existence of poorly-designed contracts will not preclude future upgrades from further expanding VM limits.

To ensure an otherwise-valid transaction will always fail when some limit is exceeded (in the rare case that such a behavior is desirable), that behavior must be either 1) explicitly validated or 2) introduced to the protocol or contract system in question prior to the activation of any future upgrade which expands the requisite limit.

A similar notice also appeared in CHIP-2021-03: Bigger Script Integers.

Rationale

Tests & Benchmarks

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

Implementations

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

Evaluations of Alternatives

This proposal evaluates notable alternatives for each design decision made in the technical specification. Reviewed alternatives are enumerated here for ease of review:

  • Statically-Defined, Per-Input Limits – Rather than this proposal's explicitly-specified limits, an alternative limits system could attempt to indirectly limit worst-case validation costs by specifying fixed per-input constant limits. This alternative would 1) create a minimum of ~244x variability in worst-case validation costs and 2) obfuscate the true limits such that worst-case costs are not predictable without exhaustive enumeration of optimally-packed attack cases. See Rationale: Use of Explicitly-Defined Density Limits and Rationale: Use of Density-Based Limits for details.

  • Financial Limitation of Computation (e.g. a "Gas" System) – This proposal does not attempt to introduce a separate "Gas" system of pricing on computation because Bitcoin Cash already has a many orders-of-magnitude scalability advantage over global-state systems like Ethereum. Beyond preventing denial-of-service risks, Bitcoin Cash has no pressing need to measure or charge fees for computation. See Rationale: Exclusion of "Gas System" Behaviors.

  • Unbounded or Contract-Length Bounded Control Stack Depth – This proposal preserves the existing practical limit on Control Stack depth. Alternatively, this proposal could increase or remove this limit, requiring all implementations to carefully implement a particular optimization and potentially complicating future upgrades. See Rationale: Retention of Control Stack Limit.

  • Transaction Length Based Densities – Rather than basing density limits on input length, the density limit could be shared across the entire transaction. While safely allowing for higher limits in some cases, this approach would prevent contract authors from reliably predicting available limits in some cases, increase protocol complexity of parallelized validation, and increase the worst-case performance of maliciously-invalid transactions. See Rationale: Use of Density-Based Limits for details.

  • UTXO Length Addition to Density Control Length – In addition to the computation limits afforded to contracts by this proposal, further allowance could be made based on the byte-length of the spent UTXO. However, this would increase the volatility of worst-case transaction validation and potentially incentivize would-be attackers to prepare attacks by first inflating the UTXO set. See Rationale: Use of Density-Based Limits for details.

  • Encoded Input Length Based Densities – This proposal avoids tightly associating precise encoding semantics with the limit system by using an always-safe constant (41) rather than requiring implementations to measure or calculate the expected encoded length of inputs, simplifying implementations and eliminating a potential pitfall for contract developers. See Rationale: Selection of Input Length Formula.

  • Byte-Length Based Hashing Limits – This proposal carefully limits hashing based on the internal number of hash digest iterations performed rather than a more naive, byte count-based limit, preventing an up to 55x magnification in worst-case validation costs. See Rationale: Hashing Limit by Digest Iterations.

  • Consensus-Only Hashing Limit – This proposal establishes a lower, standard hashing limit at the asymptotic maximum density of hashing operations in plausibly non-malicious, standard transactions. While this standardness limit could be omitted, its inclusion improves the worst-case performance of Bitcoin Cash transaction and block validation by nearly an order of magnitude. See Rationale: Selection of Hashing Limit.

  • Internal Hashing Limits Within Signing Serializations – Alternatively, this proposal could also require internally accounting for the cost of hashing within signing serialization components. However, such costs would need to be amortized across all of a transaction's signature checks to approximate their fixed, real-world cost. This would needlessly increasing protocol complexity, given both the ease of component caching and the presence of other limits on signature checking. See Rationale: Exclusion of Signing Serialization Components from Hashing Limit.

  • Additional Limitations on OP_CODESEPARATOR – If this proposal were to omit hashing limitations on signing serializations, additional limitations would be required to prevent abuse of OP_CODESEPARATOR. As OP_CODESEPARATOR remains useful, additional limitations would increase overall protocol complexity, and limitation of signing serialization hashing is otherwise prudent, this proposal instead avoid singling-out OP_CODESEPARATOR for special limitation. See Rationale: Exclusion of Signing Serialization Components from Hashing Limit.

  • Additional Limitations on OP_CHECKMULTISIG* – Because operation count currently limits the eccentric use of OP_CHECKMULTISIG for stack-dropping behavior, this proposal could attempt to place new restrictions on OP_CHECKMULTISIG to prevent expanded usage. However, because the unusual feature has been available to contract authors since Bitcoin Cash's 2009 launch, remains useful, and does not impact validation costs, this proposal does not attempt to apply new limitations for this case. See Increased Usability of Multisig Stack Clearing.

  • Continuous Tracking of Total Stack Usage – Instead of simply tracking total stack-pushed bytes, this proposal could limit memory usage by continuously tracking total usage and enforcing some maximum limit. However, this would increase implementation complexity, only implicitly limit memory bandwidth usage, and require additional limitations on linear-time operations. See Rationale: Limitation of Pushed Bytes.

  • Omit Base Instruction Cost – this proposal could alternatively omit Base Instruction Cost, limiting the cost of all instructions to their impact on the stack. However, instruction evaluation is not costless – a nonzero base cost properly accounts for the real world overhead of evaluating an instruction and verifying non-violation of applicable limits. See Rationale: Selection of Base Instruction Cost.

  • Omit Numeric Encoding Cost – this proposal could alternatively omit the cost of numeric encoding from arithmetic operation cost. However, if this proposal were to assume zero operation cost for encoding/decoding, this optimization would be required of all performance-critical VM implementations to avoid divergence of real performance from measured operation cost. See Rationale: Inclusion of Numeric Encoding in Operation Costs.

Risk Assessment

Stakeholders & Statements

Stakeholder Responses & Statements →

Feedback & Reviews

Acknowledgements

Thank you to the following contributors for reviewing and contributing improvements to this proposal, providing feedback, and promoting consensus among stakeholders: Calin Culianu, bitcoincashautist, Andrew#128, Fernando Pelliccioni, Mathieu Geukens, Joshua Green, OPReturnCode, Jeremy, Kallisti.cash, Corbin Fraser, imaginary_username, John Nieri, Jonathan Silverblood, Josh Ellithorpe, John Moriarty, minisatoshi, Andrew Groot, Tom Zander, Rosco Kalis, Richard Brady.

Changelog

This section summarizes the evolution of this document.

Copyright

This document is placed in the public domain.

About

Re-targets virtual machine (VM) limits to enable more advanced Bitcoin Cash contracts, reduce transaction sizes, and reduce full node compute requirements.

Topics

bitcoin-cash bitcoin-cash-chip

Resources

Readme
Activity

Stars

10 stars

Watchers

3 watching

Forks

9 forks
Report repository

Contributors 8