Skip to content

Instantly share code, notes, and snippets.

@Mengerian

Mengerian/BCH_Script_Roadmap.md

Last active January 21, 2020 22:23
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Mengerian/7ae4c4abbc6f4d1664507c817a51da2f to your computer and use it in GitHub Desktop.
Save Mengerian/7ae4c4abbc6f4d1664507c817a51da2f to your computer and use it in GitHub Desktop.
Download ZIP
Bitcoin Cash Script Roadmap - A framework for assessing incremental upgrades to BCH Script
Raw
BCH_Script_Roadmap.md

BCH Script Roadmap

Goal and Scope

The goal of this document is to provide a framework for organizing and evaluating potential consensus changes to the Bitcoin Cash Script system. First, an overall approach for Script will be presented, and then several potential changes will be listed, and discussed within the context of the overall roadmap.

The scope of this document is to consider incremental upgrades to BCH Script. More overarching proposals such as a new transaction format (eg. MITRA), should be evaluated separately.

Approach

The overall goal of Bitcoin Cash is to be “peer-to-peer electronic cash” that is usable by everyone in the world. As such, BCH script should help advance this goal. In particular, Script provides value by empowering the “electronic” portion of the goal, by enabling flexible and useful spending conditions. In short, Script should make BCH to function as better electronic cash.

Criteria for changes to BCH Script:

  1. It should fill a current gap, and/or complements other parts of the Script language.
  2. Fully consider impact on current Script components, as well as planned future changes.
  3. Generic, simple operator (ie, avoid “OP_DOTHIS”).
  4. Enables use-cases that further BCH’s goal to function as better electronic cash.
  5. High confidence that it does not introduce high resource usage, or potential attack vectors.

Items on the Bitcoin Cash Script Roadmap

Note: Listing an item does not signify endorsement. Some of the items may turn out to bad ideas, and can be rejected. This is simply a list of items that have been proposed, in order to keep track of them and their status.

  • Bigger integers

    • Description: Currently, the integers used as inputs to arithmetic operators are limited to signed 32-bit integers (output may overflow). Various proposals would increase this to 64 or 128 bits.
    • Status: Discussion phase. There seems to be general agreement that this is a good idea, but no-one leading the charge to organize an effort to implement this change.
    • Interactions: This change would need to consider overflow behavior of current and potential future arithmetic opcodes (OP_MUL).
    • Use-cases: There are several known use-cases affected by this. One example would be simpler manipulation of “amount” field in the transaction.
    • Concerns and Comments: Although many people think this is a good idea in concept, details still need to be worked out. It also touches many areas in script, so moving forward will require a very careful design and review process.

  • OP_MUL

    • Description: Script includes arithmetic operators such as addition, subtraction, and division. Multiplication, however, has been disabled. This proposal would re-enable multiplication.
    • Status: Discussion Phase. This opcode was activated on BSV, but there does not seem to be much impetus within the BCH community to work on activating it.
    • Interactions: The design of how MUL handles overflow needs to be considered in conjunction with possible future increases to the allowed integer size. This opcode is a generic “building block” operatore that fits well with the other arithmetic operators.
    • Use-cases: MUL is missed right now by people doing price actions in covenants. It is a generic basic operator that makes sense to include along with the other aritmetic operators.
    • Concerns and Comments: It would be important to ensure that overflow behavior does not interfere with possible future increase to the allowed integer size. This seems like a good fit, but lacks pressing use-case.

  • OP_REVERSEBYTES

    • Description: Reverse the order of the bytes in a string. This can be used to convert big-endian numbers to little-endian.
    • Status: Proposal/Discussion phase. A draft specification has been proposed (bitcoincashorg/bitcoincash.org#358). Implementation in progress (https://reviews.bitcoinabc.org/D4871).
    • Interactions: No known interactions with other parts of Script.
    • Use-cases: Would ease handling big-endian numbers, in particular the “amount” field in SLP transactions. This currently must be done using up to byte manipulation 30 opcodes. OP_BSWAP would also allow flipping txids that people sometimes embed in data.
    • Concerns and Comments: It is unclear whether there are many use-cases for this, other than handling SLP amount field.

  • Push transaction context to stack (“OP_PUSHSTATE”)

    • Description: Push items from the sighash preimage onto the stack. This is useful for covenants, and is more efficient than the sighash pre-image “trick” that is used currently.
    • Status: Discussion phase. A preliminary draft specification has been created (https://blog.bitjson.com/rfc-op-pushstate-draft-spec-6a32fb6434a5?) This specification is under heavy discussion and subject to change.
    • Interactions: None known.
    • Use-cases: Covenants, emulation of “Sighash NoInput, or other esoteric sighash schemes. Possibly more.
    • Concerns and Comments: Still at a very preliminary stage of discussion.

  • Reverse OP_ROLL

    • Description: Script currently has many weird and wonderful opcodes for manipulating the arrangement of items on the stack (for example OP_2ROT "The fifth and sixth items back are moved to the top of the stack."), however it lacks an opcode for inserting the top stack element to an arbitrary lower depth. This ability is something that would help higher level languages compile code efficiently.
    • Status: Discussion phase.
    • Interactions: It fits well within the set of stack opcodes, and fills and obvious gap.
    • Use-cases: Is useful for higher level languages which compile down to BCH Script.
    • Concerns and Comments: It could be implemented in a number of ways, including allowing negative input to OP_ROLL. Pieter Wuille mentions Reverse OP_ROLL here.

  • Registers

    • Description: As a suplement to the stack, add opcodes that push and pop items to a series of "registers". For example, 8 registers could be implemented with 16 opcodes that push and pop values.
    • Status: Discussion phase (very preliminary).
    • Interactions: None known.
    • Use-cases: Similarly to "Reverse OP_ROLL", is particularly useful for higher-level languages.
    • Concerns and Comments: Would potentially use up several opcode numbers. There are concerns that registers are not a good idea in a stack based language, as you end up having to define calling convention and all to assemble subscripts into larger ones, whereas it naturally works for stackbased systems.

  • Increase script size limit and opcode count limits

    • Description: Script developers are starting to run up against size limits woth some of the more complex scripts being created. This proposal is to increase some of those limits.
    • Status: Discussion Phase.
    • Interactions: This interacts with many parts of the script system, especially if different limits are applied to opcodes that have the potential for super-linear resource usage. Changing the counting for unexecuted branches could go hand in hand with this.
    • Use-cases: Complex scripts, especially those compiled from higher-level languages.
    • Concerns and Comments: As something that has the potential to increase attack surface, any limit increases would have to be evaluated very carfully.

Acknowledgements

Thanks to Mark Lundeberg and Amaury Séchet for providing feedback and suggestions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment