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.
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.
1 Like
We can overload CHECKSIG with multiple signing schemes, conveniently the pubkey stack element encoding already has a prefix byte we can use as switch.
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 
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.
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.
2 Likes
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.
1 Like
It just became obvious we need this, thanks for the CHIP!
faster blocks + ECA OP’s in 2027, let’s do it. 
2 Likes
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.
3 Likes
For bulletproof, the op that matters besides OP_ECADD/OP_ECMUL is the multi-exponentiation or EC MSM
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.
2 Likes
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.
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.