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
Noel Maersk
@veox
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.
Danny Ryan
@djrtwo
eth2.0 (serenity!) call tomorrow at 14:00 UTC ethereum/eth2.0-pm#17
Nick Johnson
@Arachnid
3AM here, so I won't make it unfortunately.
Yang Cui
@yangnation_twitter
Devs are the heart and mind of Ethereum. Show us your thoughts; don't be ashamed of it. Open your conversations. They turn the doubters into supporters.
And be warned. Closing your open conversation is the first step in killing this project.
Lane Rettig
@lrettig
@Arachnid you are in probably the most difficult timezone in the world for these calls, God bless you! haha
are you going to become noctural or asocial?
Fredrik Harrysson
@folsen
one of my best friends is in auckland, we get one hour to talk when i wake up and one hour before i go to bed :P
Paweł Bylica
@chfast
Is there any job for ethereum devs in auckland?
Alex Beregszaszi
@axic
aren’t most of them working remotely anyway?
5chdn
@5chdn
It would be so much easier, if the earth was flat
Paweł Bylica
@chfast
@axic it does not count if you need a permit to stay
ledgerwatch
@AlexeyAkhunov
I will not join Eth2.0 call today (have nothing to contribute), but I will be listening
Adrian Sutton
@ajsutton
Most of the Pantheon dev team is in Brisbane Australia and we have one in NZ. We don’t tend to make it to these calls often. :)
Danny Ryan
@djrtwo
eth2.0 call in 35 minutes
ethereum/eth2.0-pm#17
Danny Ryan
@djrtwo