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
ledgerwatch
@AlexeyAkhunov
Turbo-Geth also transitioned OK while I was asleep. Though of course it still has reorg issues (I know because I did not fix them yet)
Adrian Sutton
@ajsutton
Nethermind was on the Constantinople chain but then stopped. I think the block numbers with the Byzantium chain just happen to@be similar at the moment
Fabrice Cheng
@fabdarice
Currently running into some Error while syncing on stureby (geth 1.8.14-stable):
ERROR[11-27|00:35:00.306]
########## BAD BLOCK #########
Chain config: {ChainID: 314158 Homestead: 10000 DAO: <nil> DAOSupport: false EIP150: 15000 EIP155: 23000 EIP158: 23000 Byzantium: 30000 Constantinople: 40000 Engine: ethash}

Number: 40329
Hash: 0x15ba92be2338e402d9e42d17ad4ffa045263628082635b6e6ccfb8f149c5a957


Error: invalid merkle root (remote: a29c3a29f1ac8f0060536548be587b0b17f17f9ca92d7a8286a0287ad60d8825 local: 0eabb651e7c907accdd9f628483512be51851fc3eb285b4ba6fba781d664b798)
##############################
Mikhail Kalinin
@mkalinin

Is the Geth 1.8.15 mining a Byzantium chain? If yes, why is it at 40041 and the Harmony node at 39999?

@5chdn looks like they are not in touch

Martin Holst Swende
@holiman
@fabdarice I think you'll need 1.8.17 at least to handle constantinople. See https://github.com/ethereum/go-ethereum/releases
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!