search

circle-free / ethereum_adress

0 stars 0 forks source link

Continuing checksum discussion #1

Open richardpringle opened 4 years ago

richardpringle commented 4 years ago

@elpiel - continuing our discussion here:

Btw do you even need to take a &str? For what purposes and how do you need to use it? We have one type atm that is Deserialized (prefixed or not) into bytes. https://github.com/AdExNetwork/adex-validator-stack-rust/blob/3ff99e9db02a3ded3d02d5a60bd9e2a4ca63c850/primitives/src/validator.rs#L19

If we don't have a case for handling strings maybe we don't need to impl it?

I don't have an actual need for string addresses right now beyond the serde support for the H160, but I would like to have the ability to input smart-contract addresses into my system by configuration, and it would be better if those addresses were checksum validated. I also print addresses from time to time and it would also be better if I printed checksum addresses.

Beyond checksum addresses, I would imagine that this crate could also take a public key (as bytes) as input and output an H160 address. I realize that hashing the public key and taking the last 20 bytes is pretty simple, but I haven't found any good libraries that abstract this away for me. Higher-level projects should not concern themselves with hashing algorithms and how an address is derived from a public key, only that it can be done.

elpiel commented 4 years ago

I just want to mention how we are solving our problem atm if we want String input of some address: https://github.com/AdExNetwork/adex-validator-stack-rust/blob/master/primitives/src/validator.rs#L61

It's not even Checksum-ed, but rather on serialization we checksum it or interaction with ABI, etc. This way you avoid having issues if you've input an incorrect address (i.e. not checksum-ed correctly) in configuration.

PS: I've just realized this is a different repo already :sweat_smile: