If it works with the chainspec I provided, it supports Const
But that's expected behaviour at this point
Would seem that
CREATE2 test vectors should fork that version off (paritytech/parity-ethereum#9694), due to changes in gas costs?..
BTW I was wrong previously, v2.1.2 was the one that has the above fix.
The issue with Harmony Byzantium node is that in Stureby it's not possible to sort out incorrect chain by difficulty rule cause difficulty bomb is not yet activated, block numbers are too low for that. Even if it would be activated then bomb delay introduced in Byzantium would de-activate it again.
The node tries to stick with the heaviest chain which looks reasonable in this case. But when first Constantinople block is imported it gets a consensus break due to block rewards calculation and stuck on it.
The node tries to stick with the heaviest chain which looks reasonable in this case. But when first Constantinople block is imported it gets a consensus break due to block rewards calculation and stuck on it.
FTR, that
geth node of mine has 10 bad blocks currently, but all from the Byzantium range (between 30000 and 40000). Gist if someone's interested - some ellipsis in there, though...
Does anyone running proper Constantinople nodes also see these?..
5 variants in total; two are mine -
veox-geth-renegade or veox-parity-renegade. It would seem strange that a node would list a block it's produced itself as invalid. :/
Funnily enough, the complete log file contains 38 bad blocks. Apart from the proper Constantinople block 40000, all but one more are from the Byzantium range. There is one more, number 29763, that's being reported as invalid, but it first started showing after the Constantinople fork has already passed. :/
The log file is ~ 29 MiB ATM, so uploaded to https://veox.pw/dump/geth-stureby.log.
In fact, the first occurrence of a "BAD BLOCK" line is for block 40000.
@holiman Looks like it's literally printing any block it gets from a peer on the other side of the fork as "BAD BLOCK". E.g. I've taken the first block from the gist - hash
0xcb84c5e9a8d00ccfe5fb4887acff14fbd1d2c583a36531ab5c7ad1ef6a39f474, number 0x7a9a (decimal: 31386); and eth.getBlock() reports that same block, whether queried by hash or number.
But interesting that you had badblocks that were in canon chain. Definitely a bug. Do you have the logs by any chance?
(although, if you terminate geth gracefully, it should save to disk and continue where it left off next time)
@holiman The log is linked above - https://veox.pw/dump/geth-stureby.log - but no debug info there, so not very useful. I'm using the package from Arch Linux repos, which for some reason responds to CTRL+C in this ungraceful manner. :(
Yeah, that log shows some strange things happening... https://gist.github.com/holiman/324bfb5d6fae520cec01fe71a102c317 Thanks for the report @veox !
@/all The first call to discuss the Eth 1.x proposals has been scheduled for this Friday at 14:00 UTC. Agenda here, please feel free to add comments or proposed topics: ethereum/pm#65. Zoom link will be posted here the morning of the call. Per requests from several of the attendees please note that this call will NOT be livestreamed or recorded. Notes will be shared.
And be warned. Closing your open conversation is the first step in killing this project.
are you going to become noctural or asocial?
