In transactions/computeAddress, why do you drop the first byte after 0x?

[dangdennis]

Why is it necessary to drop the first byte? After retrieving the publicKey value from computePublicKey, I get a value of 0x04f77..... Next, you perform a hexDataSlice to drop the 04, passing on a new0xf77.... to the keccak call.

transactions/src.ts/index.ts

export function computeAddress(key: BytesLike | string): string {
    const publicKey = computePublicKey(key);
    return getAddress(hexDataSlice(keccak256(hexDataSlice(publicKey, 1)), 12));
}

---

Where can I learn the meaning and impact of the differing lengths of a public key? I understand that all ethereum addresses are 20 bytes in length, padded to 32 bytes. But when would it be compressed or uncompressed (a re? When would it be 65 or 33?

signing-key/src.ts/index.ts

    if (bytes.length === 32) {
        const signingKey = new SigningKey(bytes);
        if (compressed) {
            return "0x" + getCurve().keyFromPrivate(bytes).getPublic(true, "hex");
        }
        return signingKey.publicKey;

    } else if (bytes.length === 33) {
        if (compressed) { return hexlify(bytes); }
        return "0x" + getCurve().keyFromPublic(bytes).getPublic(false, "hex");

    } else if (bytes.length === 65) {
        if (!compressed) { return hexlify(bytes); }
        return "0x" + getCurve().keyFromPublic(bytes).getPublic(true, "hex");
    }

Etherjs has been a fun entrypoint into the world of cryptography, thanks alot! I'm learning OCaml and some basic cryptography + eth workings by porting ethers over to OCaml.

[dangdennis]

I finally incanted the correct google search terms and came up with a stackexchange answer.

The 04 prefix indicates that a public key is uncompressed. 03 for negative compressed. So it seems correct to always drop the prefix indicator to yield the "clean" public key.

[dangdennis]

Next up is to understand the varying logic around the use of getCurve().keyFromPrivate(bytes).getPublic.

[ricmoo]

That just computes the public (x, y) public key from the private exponent E private key.

And to round out the nomenclature, a signature is an (Rx, S, v) tuple where Rx uses the same math to compute the Ry using the v (a single bit); the point (Rx, Ry) is a challenge (aka Reference) point and the value S is the solution which only the owner of E could compute efficiently, but that anyone with (x, y) can verify.

[dangdennis]

Then I suspect keyFromPublic behaves similarly. I notice that when applying this pub key 02f7737e45b43dce88b03a0efba377b733dc21a65559fda9f015c3532337877619 to getCurve().keyFromPublic(bytes).getPublic(false, "hex") it returns a much lengthier 0x04f7737e45b43dce88b03a0efba377b733dc21a65559fda9f015c35323378776192753ecba14089a0325b7788fed7265568f943fe3f55f738a79224f4515d13d4c.

Ah, actually this makes sense. I typically notice that public keys are indeed lengthier. But this former public key is generated by web3auth and their tkey infra. The former public key must be one of the shares of the private key, but getCurve().getPublic(bytes) is still able to compute the original public key.

[ricmoo]

Yes, you can trivially convert between compressed and uncompressed key. Honestly, I wish uncompressed keys didn’t exist since 255 bits of the key are completely redundant and can be discarded and recomputed from the other 257 bits.

[ricmoo]

Public keys come in several flavours. Raw, compressed and uncompressed. Raw are 64 bytes long and represent the padded x and y values for the public key. Uncompressed begin with a 04, which is then followed by the standard raw public key.

An important observation when looking at compressed keys, is that for any x, there are only two possible (canonical) y values (to simplify things, we will make some simplifying nomenclature), which means for an x the two keys are (x, y) and (x, -y), where y is dependant on x.

Because of this, we can instead store just the x and a single extra bit to indicate whether to take the y or -y; so we use the 02 prefix to indicate y, and 03 to indicate -y.

All these prefixes were decided back in the day of bitcoin, so a given prefix can indicate whether something is an address, compressed public key, uncompressed public key, private key, encrypted private key, xpub, xpriv, etc.

Ethereum tends to (internally) use raw keys when computing ecrecover-based things, but ethers prefers to keep keys in the standard formats (externally), which simplifies interacting with other libraries and the prefix makes it easier to detect what type of key is being used during debugging and logging. It also makes several situations non-ambiguous which would otherwise have no safe way to automatically detect what the input is.

Does that make sense?

[dangdennis]

Thank you! This is excellent, useful knowledge.

Then is it by ethersjs design decision to handle varying lengths of keys below related the different forms of keys based on their prefix? I snuck in a second question above Where can I learn the meaning and impact of the differing lengths of a public key?.

    if (bytes.length === 32) {
        const signingKey = new SigningKey(bytes);
        if (compressed) {
            return "0x" + getCurve().keyFromPrivate(bytes).getPublic(true, "hex");
        }
        return signingKey.publicKey;

    } else if (bytes.length === 33) {
        if (compressed) { return hexlify(bytes); }
        return "0x" + getCurve().keyFromPublic(bytes).getPublic(false, "hex");

    } else if (bytes.length === 65) {
        if (!compressed) { return hexlify(bytes); }
        return "0x" + getCurve().keyFromPublic(bytes).getPublic(true, "hex");
    }

[ricmoo]

Ethers tries to be compatible with other libraries, but luckily because of these decisions early on in the bitcoin community, it is easy to use key length and prefixes to non-ambiguously determine what was passed in. But ethers will never guess; it only makes these decisions when it is definitive what was intended.

And so ethers pays it forward and normalizes everything into these nice formats on the way out. :)

I don’t have any resource off the top of my head; but stack overflow is a good place, as well as the bitcoin documentation and reading the source code for the elliptic library on npm. The more you use them, the more you will suffer, but that suffering translates quite well into learning lots of new things. :)

[dangdennis]

wonderful! i've def experienced some of that suffering you've alluded to - well worth it now.

Discovered the bitcoinbook and ethereumbook. Perhaps these will be my next studies.

thanks again @ricmoo!