Nit: this is probably quite obvious but scriptUnsignedIntegerBits is more accurate (or just scriptUintBits)

Should it be 0x7fffffffffffffffn to avoid negative values ?

same question

Dito, maxScriptUint

This comment confused me, I thought you were referring to the max supply somehow with this 21M value :) Please use 2^31 to clarify

hmm, I get your point, but I don't really like either of those names, the "unsigned" seems misleading.

we could also keep scriptIntegerBits, but then have it be 32 (and 64) respectively, and simply subtract the sign bit

or maybe better numScriptIntegerBits

No, this is what the SLP spec allows, so we should follow it.

We could go higher (and truncate more), but that ofc woudn't make sense since these numbers couldn't be represented in SLP

same here, this is simply the max number for ALP values

here it's literally the max script integer, so I think this is fine

good point :)

I like the idea of setting to 32 and apply -1 on the sign bit

This works and I might just be too used to bit masks, but I prefer this version. Your call.

Same, feel free to ignore if you disagree

what is the most inaccurate prices can be in this current implementation?

There's some degenerate cases, especially when accepting just 1 token of something

The tests go through different scenarios, some are exactly accurate, some are quite a bit off. For example, "AgoraPartial.approximateParams 2p63-1, small price" is off by 190x (15258 nsats/token instead of 80) for accepting 0x10000000000 tokens, but that's an extreme example.

You can see the others are mostly within 5% for the smallest accept amount, and if you even accept like 5 or 10 accuracy goes up quickly.

We can refine the estimation later over time, without changing the script, so only makers would need to upgrade to get the better precision.

I tried this version but it turned out more complicated IMO.

Also while this may be very normal bit arithmetic for C++ devs, it's more novel for TS devs, so I try to use simpler operations (like shifting right then left is IMO easier to understand than shifting and then subtracting 1)

Yes, again I'm just not convinced this is more obvious to a TS dev this way