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?
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.
@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.
@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 ;)
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.)
ChainID: 314158 Homestead: 10000 DAO: <nil> DAOSupport: false EIP150: 15000 EIP155: 23000 EIP158: 23000 Byzantium: 30000 Constantinople: 40000Wei 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....
Wei Tang A DNS record for boot.stureby.ethdevops.io points to 3.8.5.3. Is that correct?