feat: add ct functions and new operations to secp256k1

[LesterEvSe]

• This PR suggests a bug fix and I've added the necessary tests.
• This PR introduces a new feature and I've discussed the update in an Issue or with the team.
• This PR is just a minor change like a typo fix.

---

[apoelstra]

For computing vH it's plausibly cheaper to directly compute this by an addition ladder. If the asset ID is known, you can embed a lookup table in your program which is potentially very fast (at an extreme, you could plausibly compute an entire 2^64 sized lookup table and then it's one lookup, though with a deep merkle tree). But even if it's not, because you can bound the size of v at 2^64 even just double-and-adding 64 times is probably cheaper than a linear verify.

Then I suspect that to verify an asset commitment, it'd be faster to take an "exact value proof", which is basically a Schnorr signature on commit - vH, rather than to take an abf and vbf.

Lots of options here. We should probably make a harness that can generate all these, including lots of different kinds of lookup tables, and compare the cost.

[LesterEvSe]

Ok, thanks. I will think how to do it better

[LesterEvSe]

I built a harness with Claude, Opus 5.5 (AI-generated code, last two commits in bench/ct-funcs; I reviewed the methods and results). Costs are for the pruned program, measured above a baseline.

Computing v·H for a 64-bit v

method	mWU	bytes
linear_verify_1 (v·h + 0·G == c)	63,985	76
jet::scale	96,287	81
jet::scale, H0 embedded	79,279	85
hash_to_curve + jet::scale	146,973	52
double-and-add	1,816,576	292
lookup table, 1-bit windows	710,989 – 1,042,936	6,283
lookup table, 2-bit windows	440,653 – 603,992	5,310
lookup table, 4-bit windows	384,845 – 463,880	3,959
lookup table, 8-bit windows	379,437 – 416,320	3,348
lookup table, 1-bit windows, select entry	991,632 – 1,061,688	6,549
lookup table, 2-bit windows, select entry	526,672 – 561,144	5,462
lookup table, 4-bit windows, select entry	321,200 – 337,880	4,039
lookup table, 8-bit windows, select entry	240,960 – 248,744	3,394

The table ranges are over v: cost grows with the number of nonzero windows. In the plain tables, the match over each window's bits adds the entry to the accumulator, carrying it through every level. In the "select entry" tables, the match only returns the entry as an Option<Ge>, and one addition outside it adds it.

The EC jets have flat costs: 64 gej_double alone cost 64 × 1,764 = 113k mWU, more than a whole scale (72,675) or linear_verify_1 (43,364), so double-and-add can't win. The tables lose for a different reason. They do few additions (at v = 1, exactly one), but they still decide all 64 bits of v one match at a time, whatever the window width. The select-entry costs fit 161k + 10k × (number of windows), so a 16-bit table would cost about 200k mWU and need 262,140 precomputed points, and no width gets below about 160k.

Opening a confidential (asset, amount) pair

method	mWU	bytes
abf, vbf: rebuild points, compare x-coordinates	308,991	434
abf, vbf: decode points, two linear_verify_1	280,761	583
exact value proof, (v+1)·H0 by jet::scale	343,975	628
exact value proof, (v+1)·H0 by double-and-add	2,063,495	649
unsound: abf, vbf with H0 given	196,723	490
unsound: exact value proof with (v+1)·H0 given	172,171	427

The two unsound rows take H0 and (v+1)·H0 from the witness unchecked, to price both approaches as if those points were free. Their difference means the exact value proof wins only if (v+1)·H0 costs under about 24.5k mWU. The cheapest way we have is about 78k (scale with H0 embedded), so taking abf and vbf stays cheaper. Decoding the points saves about 28k mWU but adds about 150 bytes, so we kept the x-coordinate version.

[LesterEvSe]

@apoelstra, could you check this one so we can merge it if everything is fine?