Reduce address length to 20 bytes

[sebastien-forestier]

Using the opportunity of the change in address format with Blake3 hashing algorithm, we could now use 20 bytes addresses as Bitcoin, Ethereum etc, instead of 32 bytes, to improve performance, reduce bandwidth, ledger size, RAM etc.

Notes:

• there was approximately 2**90 hashes computed in the whole history of Bitcoin mining, so 160 bits is large enough in the foreseeable future
• the 20 bytes hash can be obtained through truncation of the 32 bytes hash

[damip]

I have mixed feelings about this one:

• 20 bytes bitcoin hashes have already been broken 5 years ago: https://lbc.cryptoguru.org/about
• if we can achieve 10ktxps + margin through other optimizations, we might not need that one
• it will only reduce bandwidth. Full hashes will still need to be computed before truncation, so no impact on CPU

That being said, we could use that in some settings and not others, eg. in caching and some transmissions but not in the ledger due to known security issues

[sebastien-forestier]

No bitcoin hashes haven't been broken otherwise we would not use Bitcoin :) it's only broken keys that have been broken

[sebastien-forestier]

it will only reduce bandwidth. Full hashes will still need to be computed before truncation, so no impact on CPU

No impact when hashing but less data transfered and less data stored also means less cpu used

[damip]

Ok I get your point.

The CPU impact should be minimal, but bandwidth could be slightly reduced. We could attempt this indeed but I'm scared of the outcomes.

[damip]

• in SC datastores, hashes computed from user-provided data should remain 256bits beacause of possible attacks on the datastore that could be unexpected by devs

• evaluate the impact of someone generating 2 private keys with the same (new) address. Is there a point in the code where we assume something about the 1-1 relationship between addresses and keys ?

• evaluate the impact of PoW attacks generating 2 blocks, operations, endorsements with the same hash => I guess there we should keep using 256bit in thoseexcept maybe for caching

• this one is important: more generally, if we go for it, we will need to tell SC devs to stop assuming a 1-1 relationship between native addresses and public keys, or they will make dangerous mistakes

[sebastien-forestier]

Ok so let's do this for address length only, and put a note somewhere that there can be several public keys for a given address (in case an attacker wants to burn €1 tn)

[damip]

Let's do it for operation announcements only for now. Address-related gains would me marginal, especially given the danger involved.

[damip]

closing for now