Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BCH_2019_11 & BCH_2020_05 support #53

Open
1 of 4 tasks
rkalis opened this issue Jul 9, 2020 · 2 comments
Open
1 of 4 tasks

BCH_2019_11 & BCH_2020_05 support #53

rkalis opened this issue Jul 9, 2020 · 2 comments

Comments

@rkalis
Copy link
Contributor

rkalis commented Jul 9, 2020

Currently the most recent implemented instruction set is BCH_2019_05, while there is also a BCH_2019_11_SPEC option. To use modern functions such as OP_REVERSEBYTES we need to implement support for the newer hardforks.

According to the specs on GitHub (https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/), these are the features that were introduced by these hardforks. These should be added to libauth to support these newer instruction sets.

BCH_2019_11

  • Enable Schnorr signatures for OP_CHECKMULTISIG(VERIFY).
  • Enforce minimal push and minimal number encoding rules in Script.

BCH_2020_05

  • Bitcoin Cash's SigOps counting and limiting system is replaced with a new system, referred to as SigChecks.
  • A new opcode called OP_REVERSEBYTES has been added to the script system.
@bitjson
Copy link
Member

bitjson commented Jul 29, 2020

Just an update on this: my overall goal is to implement the latest instruction sets at the same time as developing a set of flag-less VM bytecode test vectors: #31. I’m also planning to refactor the source for each instruction set to be more verbose, where every instruction and associated method is clearly listed in a single place (to be easier to review vs. the large amount of indirection currently used).

Right now I'm focused on the transaction signing API in Libauth, so this may be a few months. However, if anyone would like to take a shot at implementing just the minimum necessary changes (no need to worry about the above), I'd love to take a PR!

@bitjson
Copy link
Member

bitjson commented Aug 7, 2020

Update: @rkalis knocked out a large part of this with PR #56, but I'll leave this open until we have full support for the latest VM version. (Likely will happen at the same time as #31.)

bitjson added a commit that referenced this issue May 14, 2022
… and compiler

BREAKING CHANGE: requires esm, modifies some crypto interfaces, renames many exports for
consistency, expands the program state available to vms and compilers

fixes #31, re #53, fixes #72
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants