Eth2.0-specs: Remove implicit big-int requirement
Issue
"ties broken by favoring lower shard_block_root values" requires big integer comparison. We intend to not have big integer requirement in the beacon chain.
djrtwo
All 2 comments
That could be handled with string comparison.... although the fact that we now use little endian makes this ambiguous forcing us to explicitly state that we are using string comparison and not integer comparison (gah I hate little endian more :laughing:). Most programming languages support string comparison so I don't see this being a problem.
vbuterin
on 1 Feb 2019
string / lexicographical comparison of the byte sequence of the SSZ serialization of the hash seems like an easy and unambiguous way to do it?
fwiw, in statically typed languages we usually don't look at the hash as an integer at all - it's just a blob, so the bigint interpretation left things a bit open and would require going backwards through the serialization anyway, to actually implement it
arnetheduck
on 12 Feb 2019
Related issues
paulhauner
路
15Comments
JustinDrake
路
12Comments
JustinDrake
路
24Comments
JustinDrake
路
33Comments
hwwhww
路
13Comments
Most helpful comment
That could be handled with string comparison.... although the fact that we now use little endian makes this ambiguous forcing us to explicitly state that we are using string comparison and not integer comparison (gah I hate little endian more :laughing:). Most programming languages support string comparison so I don't see this being a problem.