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
Eric McCarthy
@bendyarm

About the YP maintenance issue.

We at Kestrel Institute find the YP invaluable
and we would like it to continue to be maintained.

It is also a historical document, so it would be good if the YP style
remained consistent. By that I don't mean that it has to be terse.
It is good to have more discussion and better references.

Having a diversity of specifications methods: math, K, Lem, Coq, etc.
is a good thing, just as having a diversity of node implementations is good.
Perhaps at some point in the future we can prove the specs equivalent,
or if not, it will show where some are deficient.

I saw thumbs up from @sorpaas @5chdn @holiman
We (@acoglio and me) could also help maintain some parts of it.
In fact, we have a growing list of small improvements that we would
like to make.
:thumbsup:
Can someone with authority help get that going?

Lane Rettig
@lrettig

Having a diversity of specifications methods: math, K, Lem, Coq, etc.
is a good thing

Agree, with one caveat: there will inevitably be disagreements among the specs, just as there are and have been disagreements between spec and implementation. In a world with multiple specs/reference implementations, we therefore also need a system to resolve such disagreements.

Lucas Saldanha
@lucassaldanha
@5chdn @holiman We have got a couple of Pantheon nodes up and running on Stureby :+1:
Greg Colvin
@gcolvin

@bendyarm @acoglio Volunteers are getting organized at https://gitter.im/ethereum/yellowpaper
Join them there and you too can be an authority ;)

@lrettig Typically one of the specs is considered canonical. and discrepancies between it and the clients must be resolved. For us, discrepancies that cause consensus failure are of course the worst. I think it falls to the core devs to resolve these discrepencies, and to the maintainers of the canonical spec and the clients to implement the resolutions.

I think cleaning up any other specs is up their respective maintainers. Multiple specs can serve as checks on each other, and different means of specification can serve different needs.

Lane Rettig
@lrettig
@gcolvin sounds reasonable, but in a sense it’s a recursive argument. If the question is “which spec should we maintain?” and the answer is, “we should have multiple specs” then we’re sort of back where we started: Which spec is the canonical one?
Greg Colvin
@gcolvin

@lrettig Yes, the main question is, “Which spec is canonical?”.

Right now the canonical spec is the Yellow Paper, and we aren’t maintaining is very well, but it’s the canonical spec that really must be maintained.

How to gain consensus on a different canonical spec is an open meta-question ;)

And it’s no a matter of whether we should have multiple specs: we already do.
Mikhail Kalinin
@mkalinin
@5chdn @holiman Harmony is running, synced up to block #4515
Martin Holst Swende
@holiman
@tkstanczak it seems @5chdn changed the chainid to 314158, which is fine, to not clash with anyone running my first suggestion. I'll set up some nodes and see if I can get a dashboard up today
5chdn
@5chdn
@tkstanczak Parity is stuck on block #4502, can you take a look at the chain spec if you have a minute? How to pass a chain spec to Nethermind?
ledgerwatch
@AlexeyAkhunov
I have synced Turbo-Geth to the Constaninopole fork point on Ropsten. Now I have invalid difficulty error when it tries to reorg around that point - investigating
Mikhail Kalinin
@mkalinin
@5chdn what is the reason?
ledgerwatch
@AlexeyAkhunov
Ok, that was just unupgraded chain, which was correctly rejected. My node is moving along on Ropsten, now at block 4230621
Martin Holst Swende
@holiman

Ok, deployed a geth node now,

enode://064c820d41e52ed7d426ac64b60506c2998235bedc7e67cb497c6faf7bb4fc54fe56fc82d0add3180b747c0c4f40a1108a6f84d7d0629ed606d504528e61cc57@boot.stureby.ethdevops.io:30303`

I'll try to spin up an ethstats after lunch

Tomasz Kajetan Stańczak
@tkstanczak
@5chdn chainspec is only partially supported by Nethermind - we load genesis block details there
we load allocations from chainspec as well
Nethermind is at 6012 now
Martin Holst Swende
@holiman
geth is at 6044.
Tomasz Kajetan Stańczak
@tkstanczak
@5chdn reviewed the chainspec reasonably carefully - cannot see why 4502 would fail in Parity - at neth we do not load params, seal engine or precompiles from chainspec so, only bootnodes, genesis and allocations
Martin Holst Swende
@holiman
A status page is now up, blahonga@ws://boot.stureby.ethdevops.io/ -- check it out if it works for you, I'm having some problems, but may be due to a local networking error
Mikhail Kalinin
@mkalinin
works for me
Martin Holst Swende
@holiman
Sure?
Nov 22 13:59:59 boot.stureby.ethdevops.io ethstats: 2018-11-22 12:59:59.848 [API] [CON] Connected harmonyOnStureby 
Nov 22 13:59:59 boot.stureby.ethdevops.io ethstats: 2018-11-22 12:59:59.887 [API] [CON] Connection with: MSxWNVN ended: undefined
Your node looks offline
Mikhail Kalinin
@mkalinin
hmm, at least node appeared there and last block is updated from time to time
maybe connection gets unstable from time to time
matrixbot
@matrixbot
Wei Tang There's an InvalidReceiptsRoot error in Parity at block #4502. Did geth enabled EIP-658 prior to block 30000?
Wei Tang (Getting this error means we have same gas used and state root, but only receipt root mismatched.)
Martin Holst Swende
@holiman
EIp-658 is byzantium , right?
From our geth node:
ChainID: 314158 Homestead: 10000 DAO: <nil> DAOSupport: false EIP150: 15000 EIP155: 23000 EIP158: 23000 Byzantium: 30000 Constantinople: 40000
matrixbot
@matrixbot
Wei Tang Yeah it's byzantium.
Martin Holst Swende
@holiman
What receipt root does parity think it should have? Our has 0x56e81...
no transactions in it
matrixbot
@matrixbot
Wei Tang Error: Error(Block(InvalidReceiptsRoot(Mismatch { expected: 0x5a9cf0c872057b5dd7d5176db53f55ff7370f5db711843269752c236d85a2394, found: 0x8c60ae2d3767f894e72b30fb6b46f85257f4de39c3d1c0ecb8b9e5f0f3312a47 })), State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })
Wei Tang Hmm let me check the actual block number.
Wei Tang It's block #4503.
Wei Tang Parity thinks receipt root is 0x5a9c....
Martin Holst Swende
@holiman
So does geth. One tx in there
matrixbot
@matrixbot
Wei Tang But it gets 0x8c60....
Martin Holst Swende
@holiman
perhaps you're talking to a bad peer?
matrixbot
@matrixbot
Wei Tang Yeah probably. Let me update the bootnodes.
Wei Tang A DNS record for boot.stureby.ethdevops.io points to 3.8.5.3. Is that correct?
Mikhail Kalinin
@mkalinin
Harmony's receipts root is also 0x5a9cf0...
Martin Holst Swende
@holiman
Hm, the stats-page works better for me now, had to remove the ending / . So it's blahonga@ws://boot.stureby.ethdevops.io
Holger Drewes
@holgerd77
Maybe you guys could consolidate your experiences into some temporary-testnet-setup tutorial or guide along the way?
Tomasz Kajetan Stańczak
@tkstanczak
can i have the stats password please?
is 'blahonga' the password?
Tomasz Kajetan Stańczak
@tkstanczak
ok, it works
Andrei Maiboroda
@gumb0
aleth node is synced and reporting to http://boot.stureby.ethdevops.io/
matrixbot
@matrixbot
Wei Tang Andrei Maiboroda (Gitter): What's aleth's enode address?