feat: add bigint constructor and fix BigInteger juice costs

[aglichandrap]

Changes

This PR adds a native bigint constructor function and fixes BigInteger juice costs for the CVM, addressing Convex-Dev/bounties#4.

1. bigint constructor function (Core.java)

• New BIGINT core function (code 259) that converts any numeric value to an AInteger (BigInteger or Long as appropriate)
• Supports all numeric inputs: Long, Double, BigInteger
• Cost proportional to byte length via Juice.costNumeric()

2. bigint? predicate (Core.java)

• New BIGINT_Q predicate (code 260) that returns true for CVMBigInteger instances
• Follows existing pattern of long?, double?, int?

3. BigInteger juice cost fix (Core.java)

• Fixed TODO: bigint construction cost? in the int constructor
• Now uses Juice.costNumeric(result) which charges proportional to byte length for BigInteger values (min Juice.MIN_NUMERIC_COST)

4. Symbols

• Added BIGINT and BIGINT_Q symbols to Symbols.java

Technical Details

Juice cost model for BigInteger:

• Juice.costNumeric() returns Math.max(MIN_NUMERIC_COST, byteLength) for CVMBigInteger
• This ensures BigInteger operations cost proportionally more than Long operations, reflecting actual computational complexity
• Small BigIntegers (9-16 bytes) cost ~16 juice, large ones (up to MAX_BIG_INTEGER_LENGTH) cost proportionally more

Arithmetic operations already work:
The existing +, -, *, /, mod, quot, abs, signum operations already handle BigInteger through the AInteger class hierarchy. Long overflow automatically promotes to BigInteger (e.g., (+ Long/MAX_VALUE 1) produces a BigInteger).

What this PR adds:

• Explicit bigint constructor for CVM code
• Proper juice costs for BigInteger construction
• bigint? type predicate

Testing

• Existing EncodingTest.testEmbeddedBigInteger() covers BigInteger encoding
• Arithmetic overflow tests in ArithmeticTest cover Long→BigInteger promotion
• Manual verification: (bigint 123456789012345678901234567890) should produce a BigInteger value

[mikera]

(Claude Comment) Thanks @aglichandrap. Two things after review:

Branch mix-up: this branch currently contains the same changeset as #576 (account-recycler files included) — the intended bigint work appears to have been overwritten. If you pursue this further, please re-push a clean branch.

On the substance — bigint is likely redundant. The main use case (Blob → big integer) is already covered: (int blob) routes through RT.castInteger → AInteger.create(ABlob), handling arbitrary-length blobs. Crucially it returns the canonical representation (CVMLong when the value fits in a long, canonicalised CVMBigInteger otherwise) — and this is by design: there must be no way to construct a non-canonical value from within the CVM, so a bigint that forced a big representation of a small value would violate a core invariant, and one that didn't would just be int.

What would be genuinely valuable: the juice half of your PR intent. int currently charges flat Juice.ARITHMETIC regardless of operand size (there is a standing TODO: bigint construction cost? at the call site). A focused PR charging cost proportional to byte length — following the pattern of the multiply repricing in #603, which is gated on a protocol migration — would be very welcome. Note also that new core functions must now use the regNonGenesis + migration installation pattern (see gensym, #598/#602) rather than plain reg(...), which would change the genesis hash.

Closing the redundant constructor idea; happy to review a re-scoped juice PR.

[brittleboye]

Thank you for this work across bounties #4 (bigint) and #10 (account recycler). After review we're going to close it, and I want to explain why clearly.

On bigint — it isn't needed, because CVM integers are already arbitrary-precision. Convex has a single abstract Integer type. Values that fit in 64 bits are represented as a Long (the fast path, with a compact encoding), and anything larger is automatically a big integer — transparently, with no action from the user. For example (* 9999999999999999 9999999999999999) evaluates to the exact integer 99999999999999980000000000000001, (int? …) is true for it, and further arithmetic stays exact. (int x) already coerces any numeric value to this Integer type. So there is no separate 'big integer' type to construct — a bigint constructor would add surface area without adding a capability the language doesn't already have.

For completeness, the change also couldn't have merged as written: it registers the new core functions with genesis codes (which would alter the immutable genesis hash), and code 259 is already *initial-expander*. But the substantive reason is the one above.

On the account recycler (bounty #10) — that's independent work and this closure is not a judgement on it. It's currently bundled with the bigint changes here (and was duplicated in #576). If you'd like to pursue bounty #10, it would be very welcome as its own focused PR containing just the convex/lab/account-recycler actor and its tests, which we can then review on its own merits.

Thanks again for engaging with the bounties.

— Claude (AI assistant helping maintain the Convex repository, on behalf of the maintainers)