Skip to content

Latest commit

 

History

History
149 lines (103 loc) · 11.4 KB

readme.md

File metadata and controls

149 lines (103 loc) · 11.4 KB
Raw

CHIP-2024-07 BigInt: High-Precision Arithmetic for Bitcoin Cash

    Title: High-Precision Arithmetic for Bitcoin Cash
    Type: Standards
    Layer: Consensus
    Maintainer: Jason Dreyzehner
    Status: Draft
    Initial Publication Date: 2024-07-24
    Latest Revision Date: 2024-10-01
    Version: 1.1.0

Summary

This proposal augments CHIP: Targeted Virtual Machine Limits by removing one additional Bitcoin Cash Virtual Machine limit: the number length limit (A.K.A. nMaxNumSize).

Motivation

Many financial and cryptographic applications require higher-precision arithmetic than is currently available to Bitcoin Cash contracts.

While Bitcoin Cash's 2022 upgrade increased the maximum number length from 4 bytes to 8 bytes, the design of the Bitcoin Cash Virtual Machine's anti-Denial-Of-Service limits prevented further increase.

Following CHIP: Targeted Virtual Machine Limits, the Virtual Machine (VM) can correctly account for arithmetic operation costs, so higher-precision arithmetic operations can be enabled without increasing the processing or memory requirements of the VM.

Benefits

By allowing contracts to efficiently operate on larger numbers, this proposal improves contract security and reduces transaction sizes.

Safer Contracts

This proposal obviates the need for higher-precision math emulation. As a result, existing applications can be simplified, making them easier to develop and review. Additionally, by making arithmetic overflows less common, contracts are less likely to include vulnerabilities or faults which can expose users to attacks and losses.

Reduced Transaction Sizes

Because this proposal allows existing contracts to remove higher-precision math emulation, transactions employing these contracts are reduced in size. This reduces transaction fees for contract users, and it reduces storage and bandwidth costs for validators.

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.

This proposal requires CHIP: Targeted Virtual Machine Limits.

Technical Specification

The limit on the maximum length of Bitcoin Cash VM numbers (A.K.A. nMaxNumSize) is removed.

Note that the 10,000-byte stack element length limit (A.K.A. MAX_SCRIPT_ELEMENT_SIZE) continues to limit both numeric operands and numeric results, and Arithmetic Operation Cost prevents excessive usage of arithmetic operations.

Tests & Benchmarks

CHIP: Targeted Virtual Machine Limits includes a suite of functional tests and benchmarks to verify the behavior and performance of all operations within virtual machine implementations, including high-precision arithmetic operations. See CHIP Limits: Tests & Benchmarks for details.

Implementations

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

Risk Assessment

Rationale

Evaluation of Alternatives

Notable alternatives evaluated in the rationale are summarized here for ease of review:

  • Indefinitely retained 8-byte limit – Wasteful in every applicable measure when compared to this proposal, requiring: greater overall network bandwidth usage, larger individual transaction sizes, greater overall block storage requirements, and greater net computation costs of equivalent arithmetic operations across all validating nodes on the network. See Scenario: Never Increase.

  • Temporarily retained 8-byte limit – Wasteful of node implementation resources, requiring two entirely independent review cycles (separated by one or more years), with significantly greater implementation risks, significant discarded first-cycle effort in the second cycle, a potential decrease in new resources available to all node implementations, and non-trivial disruption risks. See Scenario: Delay Activation.

  • Selection of higher constant limit – Selection of any particular constant would be arbitrary. See Alternative: Select a Higher Constant Limit

  • Full removal of limit – This proposals chosen solution – reduces overall protocol complexity, simplifies contract review, and reduces future protocol complexity risks. See Full Removal Simplifies Protocol and Contract Review.

Stakeholder Responses & 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.