256-bit. I didn’t realize it wasn’t in the proposal
It’s perfect, thank you.
This EIP is well past last call date. Will the process to move from Last Call to Accepted be activated?
I have https://github.com/ethereum/EIPs/pull/1994 open for that.
With recommended inclusion into Istanbul, I am hoping we can move this to Accepted soon so that implementers may be able to reference this proposal in a Solidified state.
I’m still working on the reference implementation into Trinity, but the Aleth implementation is here: https://github.com/ethereum/aleth/pull/5696
To clear this part of the confusion: that was added after the adoption of EIP-155 in a hard fork as well as the update of YP.
I clearly remember the ACD calls (around 2016 or 2017) where a 1 byte value was agreed on.
While I think this is a clever idea, in the worst case it means the calculation for the transaction exceeds 256 bits.
Thank you. Maybe more clever (read: risky) is an alternate implementation that does not depend on concatenation:
sha3(sha3(tar_gz(reference_implementation)) ^ sha3(genesis_block)) ^ sha3(genesis_block)
Maybe the 64-bit unsigned integer (
uint64) would be enough? I don’t like planning for use cases that may be never needed. Even if you want to use a hash function, truncating the output to 64 bits seems good enough (@axic’s tip).
I’m strongly in favour not making it 256-bit wide. Allowing it to be 256-bit wide means that the RLP encoding of a transaction must use >256-bit arithmetic to calculate the
64 bits is a decent amount of entropy to avoid hash collisions with normal use, and there would likely be other mitigating factors if chain ID were hash-based and someone wished to exploit it to fake out other network node’s network discovery phases (or however it might be used). Given @axic’s observation of the need to change RLP encoding of transactions to support a larger field, I think this is a reasonable request.
What’s the worst case scenario for the
If there’s consensus for this, I can update the EIP
block.number >= FORK_BLKNUMand
v = CHAIN_ID * 2 + 35or
v = CHAIN_ID * 2 + 36, then when computing the hash of a transaction for purposes of signing or recovering,
To make sure I understand. Do you want to set max chain id value such that
v = CHAIN_ID * 2 + 36 will fit in 64-bits? Then I’d recommend targeting 63 bits - then you would allow this computation with signed types.
No, he was saying that the max value of chain ID must be less than
MAX_UNIT256/2-36 to fit in 256-bit arithmetic. 64 bits is well inside that
I have no strong opinion whether the
chain id or the complete calculation should be 64-bit, but I’d argue on the RLP level calculations must be able to support 256-bit so either way should be fine.
I’d also argue that eventually the transaction format should be cleared up and this workaround be removed as it was only added to minimize the impact of changes back in 2016/2017. By this logic
chain id could be 64-bit.
I am also writing up an “errata” EIP to EIP-155 to clarify what we’re discussing here – as EIP-1344 only discusses EVM.
Will you make this change to the EIP?
Also noticed some of the links were broken, so updating those separately.
Edit: Links PR here: https://github.com/ethereum/EIPs/pull/2264
I just noticed that this opcode is absent from the yellow paper. Does anyone fancy adding it?
Hmmm I would look into it