Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
Fabrice Cheng
@fabdarice
Indeed, fixed with 1.8.18
Mikhail Kalinin
@mkalinin

looks like they are not in touch

I am wrong. They are in touch but since Constantinople nodes have higher TD it doesn't pick up that Geth node, interesting whether reputation system will manage that

Noel Maersk
@veox
@5chdn Yes, my geth v1.8.15 is mining a Byzantium chain of its own.
The one node that it seems to have permanently in peers reports as Ethereum(J)/v1.9.1/Linux/Release/Java/Dev.
From enode, I see that is the "Harmony Byzantium" node; it is possible that there is an ethstats display issue, e.g. it stopped updating. Does Harmony have its own code for ethstats, or does it use eth-net-intelligence-api?..
My parity node should've forked off also, but I guess there haven't been any Constantinople-specific transactions yet?.. I can get to this when properly woken up.
Noel Maersk
@veox

BTW, I could increase the number of threads on the geth node to catch up the Byzantium chain to the Constantinople chain, if that's a desirable experiment.

(Could also do same with parity, but no sense yet until it's forked off.)

Mikhail Kalinin
@mkalinin

From enode, I see that is the "Harmony Byzantium" node; it is possible that there is an ethstats display issue, e.g. it stopped updating. Does Harmony have its own code for ethstats, or does it use eth-net-intelligence-api?..

This is not a problem with ethstats, the node tries to follow heaviest chain. Which seems to be a bug, similar to those that we had during Ropsten transition but due to other circumstances.

My parity node should've forked off also, but I guess there haven't been any Constantinople-specific transactions yet?.. I can get to this when properly woken up.

It should've forked off due to change in difficulty calculation rule that starts from first Constantinople block

5chdn
@5chdn

My parity node should've forked off also, but I guess there haven't been any Constantinople-specific transactions yet?.. I can get to this when properly woken up.

what spec are you using for Parity, @veox

It should fork off at block 40000 even without transactions

Noel Maersk
@veox
Parity v2.1.1 is the first to boast full support of Constantinople; it's possible that v2.1.0 (that the node is running) already had the diff change, but not the new opcodes. (I only skimmed the version changes on the github releases page, so not 100% sure if true; I needed a version that already supported the all-in-one chainspec file.)
@5chdn I'm using the chainspec from revision 9 of your gist, if I remember correctly. Downloaded file is dated "Nov 23".
5chdn
@5chdn
@veox Parity 2.1 supports Constantinople, it just contains some "bugs"
If you want to disable Constantinople, you would have to edit the chain spec
The fact that it works with the chainspec you provided, shows that it's supported
Try 2.0.5
Noel Maersk
@veox
To charify, I started the sync (using that chainspec file) using a much newer version, and then downgraded.
2.0.5 didn't work, because of a change in chainspec format.
5chdn
@5chdn
Yeah exactly, because it does not support Constantinople
If it works with the chainspec I provided, it supports Const
Noel Maersk
@veox
OK, understood.
5chdn
@5chdn
But since your version has bugs, It will probably fork off once someone creates transactions
But that's expected behaviour at this point
Noel Maersk
@veox
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.
5chdn
@5chdn
Yeah, probably, but it's not worth going down that rabbit hole as we want to find new bugs, not confirm known bugs :)
Mikhail Kalinin
@mkalinin
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.
Martin Holst Swende
@holiman
@mkalinin just so I understand: harmony byzantium is a non -constantinople client right? So it's perfectly as expected for it to get stuck, right?
Mikhail Kalinin
@mkalinin
yes, it's right. but it should import fork that is being created by veox-geth-renegade node. I investigated why it's not happening and came to above conclusion.
Martin Holst Swende
@holiman
Oh that one is minig? I thought it had fast-synched into between a rock and a hard place and couldn't go forward. Now I get it. So 'tries to follow' seems like a good idea, but it should also track other (less heavy) sidechains
Mikhail Kalinin
@mkalinin
in a network with working difficulty rule it would reject heaviest chains on early stage and eventually stick only with byzantium nodes, even if the heaviest chain is constantinople chain
Noel Maersk
@veox
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...
Martin Holst Swende
@holiman
That's very odd @veox ...
Noel Maersk
@veox
There are several extraData variants, so would guess not the same miner.
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. :/
Noel Maersk
@veox
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.
Noel Maersk
@veox
@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.
Noel Maersk
@veox
I've restarted the geth node, and now there's just one bad block. Sadly, turns out the node wasn't flushing to disk regularly, so that long chain is "lost".
Martin Holst Swende
@holiman
No, it won't flush to disk unless it either eats too much mem, or too much time (5 mins) of total block processing time. UNless you set gcmode=archive
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)
Noel Maersk
@veox
@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. :(
Martin Holst Swende
@holiman
cool thanks!
Noel Maersk
@veox
Should've taken the time to set this node up on a VM also. "Oh well".
ledgerwatch
@AlexeyAkhunov
@veox I think you have put quite a lot of work in this, thank you so much for your efforts!
Noel Maersk
@veox
Heh, I must really need those SHL/SHR. :) (Or have nothing better to do.)
Martin Holst Swende
@holiman
Yeah, that log shows some strange things happening... https://gist.github.com/holiman/324bfb5d6fae520cec01fe71a102c317 Thanks for the report @veox !
Lane Rettig
@lrettig
@/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.