CHIP 2025-05 Native Elliptic Curve Arithmetic Operations

Consensus
#41

After doing some research I think I can get behind narrowly adding OP_ECADD and OP_ECMUL.

I asked GPT Sol to benchmark native EC ops against a Script-based implementation and found that these two opcodes allow us some 400x efficiency gain in terms of opcost and 100x in byte cost for a secp256k1 DLEQ verifier.

Through this experiment I also come to the same conclusion as @lightswarm, that it’s probably not worth adding the other opcodes because the gains we get from them are quite modest.

Given the ubiquity of the secp256k curve in the Bitcoin/BCH realm, I think adding these two opcodes given the gains still makes sense even if the curve is eventually deprecated by a crypto-relevant quantum computer.

I would consider endorsing a well-specced, benchmarked, and tested CHIP for 2027 lock-in.

4 Likes
#42

Would it be possible to test this with hypothetical changed VM Limits consensus specification: reduce base opcode cost from 100 to 10, or to 1.

If lower base cost would be enough to have compact Script implementations, maybe we don’t need these opcodes and should instead CHIP the base cost reduction.

#43

@bitcoincashautist I just did a quick test with my machines. Seems that the opcode surcharges still dominate the bulk of the costs.

Base cost ECADD ECMUL ECMULTMULTI-8
100 5,393 37,761 331,165
10 4,763 37,221 328,645
1 4,700 37,167 328,393
1 Like
#44

Thanks! I guess the bulk is in operand stack item size costing. We can see diminishing returns between 100->10 and 10->1, and we can see that gains depend a lot on the particular script’s design.

1 Like
#45

That cross-chain perspective is valuable. Seeing how the same privacy problem is approached under different constraints could help explain BCH’s strengths in plain language. It will be interesting to see what practical use cases emerge from the work.

#46

Note, this CHIP has a page for sentiment indicating on Consensus.cash