CHIP 2025-05 Native Elliptic Curve Arithmetic Operations

[lightswarm]

@ShadowOfHarbringer

Since we are touching consensus again, it would generally make most sense to collect up multiple of these math operations together and implement them as a single upgrade.

Dividing mutiple small simple changes between multiple upgrades will create chaos and increase implementation cost across the entire ecosystem.

Here are some other math operations that we could consider on top of ECADD and ECMUL.

Opcode	Description	Benefit (vs. emulation)	Cost to Emulate in Script	Risk/Complexity	Notes & Recommendation
Basic Operations
OP_ECADD	Point addition: given two secp256k1 points P, Q on the stack, pushes P+Q.	≈ >1000× faster than doing field operations + curve math in script.	~ 4000+ big‑int ops + looping (~200 K “unit” ops)	Moderate: must validate inputs lie on curve, constant‑time implementation.	Include: core building block for any EC work.
OP_ECMUL	Scalar multiplication: given a point P and scalar k, pushes k·P.	≈ >10 000× faster than repeated doubling/add in script.	~ 100× OP_ECADD via double‑and‑add loop (≈ 400 K “unit” ops)	Moderate: enforce 0<k<order, constant‑time ladder.	Include: required to do any signature‑style verification or covenant logic.
Highly Useful
OP_MODINV	Modular inversion: given nonzero a in 𝔽ₚ, returns a⁻¹ mod p.	O(1) native vs. O(n²) exponentiation in script (≈ thousands of ops).	~ 5000+ big‑int ops + loops	Must be constant‑time; must detect & reject a=0.	Recommend: needed for slope computation in ECADD/ECDOUBLE and other field work.
OP_ECMULTGEN	Generator mul: like OP_ECMUL(k, G), but 3× faster using precomputed G tables.	≈ 3× faster than generic ECMUL when one operand is known generator G.	≈ same cost as generic ECMUL in script	Same checks as ECMUL; uses fixed-window tables.	Strongly recommend if you plan any on‑chain Schnorr or MuSig verification.
Optional
OP_ECDOUBLE	Point doubling: given a point P, pushes 2·P.	≈ 30–50% speedup in windowed ECMUL or multi‑add loops vs. two ECADD.	N/A (would be 2× OP_ECADD)	Same as ECADD.	Optional: skip if you have ECMUL, but useful to speed up multi‑scalar routines.
OP_ECNEG	Point negation: given P=(x,y), pushes –P=(x,−y).	Native constant‑time negate vs. a handful of big‑int ops in script.	~ 20 big‑int ops	Negligible.	Optional: very cheap to emulate; lowest priority.
High‑Risk / Specialized
OP_DECOMPRESS	Point decompress: given 33‑byte compressed P, pushes full 65‑byte (x,y).	Saves 32 bytes per output + ~10× faster than script‑level sqrt.	Emulate via modular sqrt ≈ O(p^¼) exponentiation → millions of ops	Needs constant‑time sqrt, parity check, heavy code.	Use with care: big chain‑savings but very tricky and DoS‑sensitive.
OP_ECMULTMULTI	Multi‑scalar mult: given [kᵢ, Pᵢ] for i=1…n, pushes ∑kᵢ·Pᵢ sub‑linearly in n.	Sub‑linear speedup vs. doing n separate ECMULs in script.	≥ n× generic ECMUL (linear)	Must cap n, fixed-window, careful memory use.	Only for very large batch ops (e.g. MuSig with many keys); otherwise too complex.
OP_PAIRING_CHECK	BN‑pairing: verify pairing equation e(P, Q)… for SNARKs/BLS.*	On‑chain SNARK/BLS proof with a single op vs. infeasible in script.	Impossible in script	Massive code size, DoS risk, consensus complexity.	Not recommended—far too heavy & risky for BCH today.

For right now, it might be worth considering adding MODINV and ECMULTIGEN as these seem fairly useful without having cheap substitutes while still keeping to relatively safe computation. There are some like the one for on-chain SNARK/BLS proof, but I don’t think they are really needed for the near-term future until the tech gets a bit more mature

[ABLA]

Might be worth looking into this chip for confidential amounts on BCH via bulletproofs. If i understand right, OP_ECADD/OP_ECMUL/OP_ECMULTMULTI + OP_MODINV would cover the range proofs with no trusted setup.

[Olumidex1]

Coming from the Solana/ZK payments side. I built a shielded payroll protocol using Groth16 and ran into the same amount hiding wall from a different direction. Native EC ops would make confidential transactions practical for builders without requiring hand-rolled assembly workarounds so strong support for this CHIP.

[bitcoincashautist]

@Olumidex1

Native EC ops

My only concern is quantum threat, should we go ahead with these ops knowing it’s possible their usefulness has an expiration date?

[BitcoinCashPodcast]

Welcome to BCH Research!

Glad to have you here. Especially good to see interest from Solana community members, who have a strong overlap with our philosophy but not as strong discussion channels between us. What was it that attracted you to BCH?

[ABLA]

In the case of shielded pools that have confidential amounts specifically, it’s worth noting: Pedersen hiding is information-theoretic, so a future QC replaying old chain data can’t open the commitments themselves. The retroactive leak in the Monero case is the ECDH channel, which is the kind of surface that ML-KEM note delivery or a PQ NIKE-based exchange protects against.

What a QC does break is binding, i.e. forging proofs going forward. That’s where the design matters with a transparent-backed pool (BCH locked visibly into a covenant, confidential notes inside, redeem back out), the covenant is consensus-enforced to not release more than was locked. In Monero a binding break means undetectable counterfeit; here the worst case is bounded theft inside one pool, not supply inflation. And there’s no compact PQ drop-in for Pedersen + Bulletproofs today, lattice replacements are still research; the PQ-sound route that exists in principle is hash-based STARKs proving the same range and balance statements, just heavier, tens of KB vs ~700 bytes for a bulletproof.

Notably, that path needs zero new opcodes, it’s hashing plus field arithmetic, all live on CashVM today (SHA256, BigInt, loops, functions), waiting mainly on the TXv5 limit raise (op-cost budget feasibility still to be measured). Even Monero devs own answer to this concern is a migration timeline (Luke Parker from Monero proposed a 5-year PQ plan), so I see no reason to avoid EC. And to be clear on why the EC ops are needed at all: hiding itself costs nothing, a Pedersen commitment is just bytes the chain could carry blindly. The opcodes are for enforcement, the covenant checking that hidden amounts still obey the rules: the balance check (sum of input commitments equals sum of output commitments) is point addition, and the range-proof verify is scalar mult / one big MSM. Without them the chain can’t hold anyone to the commitments. The ops are cheap, reusing libsecp256k1, and as noted upthread ECMUL costs less than a CHECKSIG, which already does one internally. The STARK path is the later for the same layer, not a reason to withhold the now.

[Olumidex1]

Fair concern. However EC ops enable Pedersen commitments and Bulletproofs which are useful now regardless of the long-term quantum picture. The expressive VM argument cuts both ways here: if the VM can express any verifier in script, then when PQ-friendly proof systems mature, you swap the verifier without a consensus fork. EC ops don’t lock you in, they unlock confidential transactions now while the PQ layer catches

[Olumidex1]

If im being honest, it wasn’t BCH specifically that attracted me. I wasn’t explicitly poking around on here.
I built a shielded payroll protocol on Solana, had some non technical issues and stumbled on a friends project and joined his telegram. Then I met someone there who was solving the same amount-hiding problem from a completely different direction on BCH. The Nostr coordination layer and the expressive VM philosophy were things I hadn’t seen approached that way before. Plus The overlap in goals with very different constraints was too interesting to ignore. And very good discussions so far. I’m intrigued.
Thank you guys for having me

[Kader]

We want Bitcoin Cash to be the most inclusive currency, the one most widely used. We don’t just want it to address the issue of transaction volume; we want it to provide privacy and smart contracts, and we need strong promotion.

[im_uname]

imo we should, because basic EC math (add/mul) already exists and is very mature, minimal tech debt is added as long as the implementation is spec’d well. When q-day comes it’ll just be obsolete… along with the biggest usecase of EC of all, CHECKSIG. Meanwhile we get to enjoy all the neat EC stuff as a bet on the quite plausible scenario of “what if quantum threat fails to materialize”.

The only real downside I can see is its existence may hinder momentum in terms of developing and adopting PQC schemes via competition for mindshare. But I haven’t heard any PQC scheme that even approaches the amount of magic EC enables, so the competition is kinda tangential.

[bitcoincashautist]

@im_uname

along with the biggest usecase of EC of all, CHECKSIG

We can overload CHECKSIG with multiple signing schemes, conveniently the pubkey stack element encoding already has a prefix byte we can use as switch.

@im_uname

Meanwhile we get to enjoy all the neat EC stuff as a bet on the quite plausible scenario of “what if quantum threat fails to materialize”.

Yes, good argument. And to steel-man it, it’s not like it would be the first time some opcode becomes obsolete, we will carry OP_SHA1 forever

@im_uname

The only real downside I can see is its existence may hinder momentum in terms of developing and adopting PQC schemes via competition for mindshare.

We can just have both then. Pat’s CHIP lays out a framework that supports adding multiple schemes later, and SPHINCS+ is the safest bet now, big but reliable, so we can tick the “quantum ready” checkmark, and have a bunker if q-day materializes - and by then other more compact schemes may become available in which case we just add them to CHECKSIG’s registry.

@im_uname

But I haven’t heard any PQC scheme that even approaches the amount of magic EC enables, so the competition is kinda tangential.

Yeah, the only reliable schemes are hash-based, which are chunky, reliable and boring because they can’t do much but sign/verify. CHECKSIG supports adding multiple, so we might as well just start with the bunker option, and if some magical system later surfaces, add it, too.

---

For this CHIP, I would prefer it be deployed as a 2-byte opcode, so we can start with a smaller set and expand as needed and avoid taking too much opcode space for something that may have an expiration date.

[Tim]

Here again, nice work on this lightswarm. I build FlowGuard, treasury and payroll streaming live on BCH mainnet, and I want to add a builder’s support for this CHIP. The one wall we keep hitting is that amounts are public, and for payroll that is disqualifying. Nobody wants their salary readable by anyone who knows the contract address.

The design we want is two layers, and they need different things:

• Hiding who : membership + nullifier proofs over a Merkle set. This already runs on CashVM today (SHA256, BigInt, loops, functions), no new opcodes.

• Hiding how much : Pedersen commitments plus a Bulletproof range proof. This is the part that needs native EC. ECADD for the balance check (sum of input commitments equals sum of output commitments), ECMUL / one MSM for the range-proof verify. Without those the chain can only carry the commitments blindly, it cannot enforce them.

So from where we sit the minimum that unlocks confidential amounts is OP_ECADD and OP_ECMUL, with OP_MODINV making the bulletproof verifier practical and OP_ECMULTGEN useful for the Schnorr/multisig checks our treasury covenants already do. That lines up with what lightswarm and ABLA laid out above.

On the quantum question raised above: the hiding is information-theoretic, so old commitments do not open retroactively. What a QC threatens is binding, i.e. forging going forward. In a transparent-backed pool (BCH locked visibly into a covenant, confidential notes inside, redeem back out) the covenant is consensus-enforced never to release more than was locked, so a binding break is bounded to theft inside one pool, never supply inflation. And the PQ path is already expressible: swap the Bulletproof verifier for a hash-based STARK proving the same range and balance statements, which needs zero new opcodes. EC ops do not lock us in, they unlock the practical version now.

Concretely: if this activates, FlowGuard will implement confidential payroll amounts on it. Happy to be a test case and to help benchmark the verifier cost against a real covenant.

[CashDragon]

It just became obvious we need this, thanks for the CHIP!

faster blocks + ECA OP’s in 2027, let’s do it.

[Bastian]

Strong support for this CHIP from the BCH Cloak (formerly known as confidential transactions) side.

The main lesson from private-note design is that amount privacy is not just hiding values. The hard part is enforcing conservation while values stay hidden.

Pedersen commitments are the natural tool for that: they hide value and support additive balance checks. But for BCH covenants to enforce the balance rule, the VM needs point arithmetic. Otherwise the chain can carry commitments as bytes, but cannot cheaply verify that the hidden amounts obey the rules.

That is why OP_ECADD and OP_ECMUL are important. They are not a hard-coded ZKP system. They are general math primitives. Wallets and dapps can build Bulletproof-style, Sigma-style, STARK-hybrid, or future proof systems in libraries and contracts without asking consensus to ossify one verifier forever.

For BCH Cloak, the direction is:

Pedersen commitments for hidden additive balance
STARK/hash proofs for well-formedness, range, seal binding, and packet binding
BCH UTXO seals for double-spend uniqueness
aggregation for anonymity set

The PQ concern is real, but I do not think it is a reason to avoid EC. The STARK/hash route remains the heavier future/PQ-oriented path. EC ops unlock the practical confidential-amount path now, while still allowing contracts to upgrade proof systems later.

BCH Cloak can help benchmark the real costs: balance checks, range-proof verification, partial STARK checks, TXv5 verifier layouts, and what should stay client-side vs. consensus-enforced.

[ABLA]

@Bastian

Wallets and dapps can build Bulletproof-style,

For bulletproof, the op that matters besides OP_ECADD/OP_ECMUL is the multi-exponentiation or EC MSM

@lightswarm

Opcode	Description	Benefit (vs. emulation)	Cost to Emulate in Script	Risk/Complexity	Notes & Recommendation
OP_ECMULTMULTI	Multi‑scalar mult: given [kᵢ, Pᵢ] for i=1…n, pushes ∑kᵢ·Pᵢ sub‑linearly in n.	Sub‑linear speedup vs. doing n separate ECMULs in script.	≥ n× generic ECMUL (linear)	Must cap n, fixed-window, careful memory use.	Only for very large batch ops (e.g. MuSig with many keys); otherwise too complex.

As far as I understand, that “only for very large batch ops, otherwise too complex” note is the bulletproof case. A bulletproof verify is one big multiexp over hundreds of points (~2n + 2log₂n terms for n bits). Do it as ~2n + 2log₂n separate OP_ECMUL calls, which i think would blow the per-input budget. Native OP_ECMULTMULTI is what makes it fit comfortably.

Also, the only spot I can think OP_MODINV applies in bulletproof is the inverses, which are just the ~log₂n challenge inverses. Either hint each and check x·x⁻¹ ≡ 1 mod n (one OP_MUL + OP_MOD, soundness intact, and no scripted inversion), or batch invert with Montgomery (which inverts n values using a single inversion plus 3(n-1) muls, by multiplying them all into one product, inverting that once, then unwinding to recover each).

Either route is one real inversion for the whole proof plus a handful of OP_MUL. The s-vector inverses are free (reversed s), and mod n scalar math is already native bigint (OP_MUL + OP_MOD) since May 2025 upgrade. So OP_MODINV would only save that one inversion, ~5000 ops down to O(1), sitting next to a multiexp of hundreds of OP_ECMUL calls. Not the main bottleneck. However, OP_MODINV may still be worth having, just for other stuff: slope in script-level OP_ECADD/OP_ECDOUBLE, ECDSA s⁻¹ mod n, and Jacobian to affine.

[Bastian]

Yep, that distinction is helpful. ECADD/ECMUL are the minimum layer that unlocks the direction, but if the range/proof layer is Bulletproof-style and BCH-enforced, then MSM support is probably what makes it practical. ECMULTMULTI matters because Bulletproof verification checks one large linear combination of many curve points; doing that as many separate ECMUL calls can blow the budget, while native MSM can make the same check efficient.

[im_uname]

Just a reminder since this seems to be gaining momentum: It’s now June, so for an 2027 activation a fully specc’d out thing should be published soon, maybe with additional opcodes aside from ecadd/mul, maybe not. There’s also very limited capacity at bchn to code up and test things so perhaps some triage needs to be made between this and other unrelated chips, especially if more opcodes are added that have concerning notes in their risk column.

[lightswarm]

Happy to work on the code to include the opcode

[bitcoincashautist]

Code comes later, fully specced CHIP is paramount.

We must first agree what to code. Since we expect scope creep to more than just add/mul I suggest to now introduce a framework for the whole group, behind 1 code-point, e.g.:

• 0xbc - EC arithmetics prefix, operation byte will follow

so:

• 0xbc01 = OP_ECADD
• 0xbc02 = OP_ECMUL
• 0xbc… = future CHIP may add more as needed, even on other curves

[tom]

Additionally to the good point from imaginary, any new opcode should have actual real usage.

Which means that not only should the opcode be written into BCHN, there should be some actual scripts using it available that demonstrate the real use-case that you want to sell to the audience.
So to be clear, not a simple example script. It would be the actual zero knowledge script you are aiming to enable with this opcode so the goal of the new opcode is demonstrated in a way that we don’t invest in an upgrade that may never end up being used.