toTwos error report boundary

[start940315]

Ethers Version

6.1.0

Search Terms

No response

Describe the Problem

76132430147301787307387321647360254710447941205250659333197368533072997592449n is smaller than 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffn, but toTwos(76132430147301787307387321647360254710447941205250659333197368533072997592449n, 256) report a rangeError:
RangeError: too high (operation="toTwos", fault="overflow", value=76132430147301787307387321647360254710447941205250659333197368533072997592449, code=NUMERIC_FAULT, version=6.1.0)

Code Snippet

toTwos(76132430147301787307387321647360254710447941205250659333197368533072997592449n, 256)

Contract ABI

No response

Errors

RangeError: too high (operation="toTwos", fault="overflow", value=76132430147301787307387321647360254710447941205250659333197368533072997592449, code=NUMERIC_FAULT, version=6.1.0)

Environment

node.js (v12 or newer)

Environment (Other)

No response

[ricmoo]

The maximum two-compliment number is 0x7fff…ff. It needs a bit at the top to accommodate the compliment bit. So, you get the range -0x8000…00 through 0x7fff…ff, inclusive.

[ricmoo]

What do you mean? Twos-compliment is a very specific encoding. A 256-bit two complement number represents a value from -0x80..00 to 0x7f..ff. If you have a uint, it is not twos-compliment encoded; it’s just stored as a regular big-endian value.

The twos-compliment encoding is specifically for storing (roughly) an n-bit value which can be negative as a positive integer using n+1 bits, but without the consequence of having complex logic of having two values for zero.

My guess is you do not want to use two-compliment if you are only storing positive values, but here is more info on twos-compliment encoding. :)

[start940315]

Actually, I found in ethers6.1.0, it has some code like this:

{
        const match = type.match(/^(u?)int(\d*)$/);
        if (match) {
            const signed = (match[1] === "");
            const width = parseInt(match[2] || "256");
            assertArgument(width % 8 === 0 && width !== 0 && width <= 256 && (match[2] == null || match[2] === String(width)), "invalid numeric width", "type", type);
            const boundsUpper = mask(BN_MAX_UINT256, signed ? (width - 1) : width);
            const boundsLower = signed ? ((boundsUpper + BN_1) * BN__1) : BN_0;
            return function (_value) {
                const value = getBigInt(_value, "value");
                assertArgument(value >= boundsLower && value <= boundsUpper, `value out-of-bounds for ${type}`, "value", value);
                return toBeHex(toTwos(value, 256), 32);
            };
        }
    }

the value I mentioned passed the assertArgument check but the toTwos reported a error, please check those code

[start940315]

Hello, do you still remember this problem? I found a bug in typed-data.js, you need to change:
return toBeHex(toTwos(value, 256), 32);
to this:
return toBeHex(signed ? toTwos(value, 256) : value, 32);

[insulineru]

I also encountered this problem. In [email protected] I was able to sign TypedData, in which values were set 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff. In [email protected] the signature does not work because overflow too high.

[ricmoo]

FYI, you are absolutely right! This is a bug. I was looking in the wrong place before (thinking this was an ABI coder issue, which was correct), but I see now this is specific to the TypedDataCoder.

Adding the fix now (after creating a test case to identify it).

[ricmoo]

Sorry. Looking into this now.

[ricmoo]

Sorry for the delay. Fixed in v6.3.0.

Thanks!