Bug/etcm 797#974
Conversation
… from connected peers
| val seedEpoch0 = ByteStringUtils.string2hash("0000000000000000000000000000000000000000000000000000000000000000") | ||
| val seedEpoch1 = ByteStringUtils.string2hash("290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563") | ||
| val seedEpoch382 = ByteStringUtils.string2hash("d3d0aa11197dcdcfcb3ad3c73d415af47299bddb47fda6081d31d9dd06462f6a") | ||
| val seedEpoch383 = ByteStringUtils.string2hash("bf532874eb434842e7a3e4acd113fe454541651872760d9b95d11d7f90ca25dc") |
There was a problem hiding this comment.
where did these hashes come from? maybe this would be a good inspiration https://github.com/iquidus/ecip-1099-data ?
There was a problem hiding this comment.
These are the seeds that correspond to the blocks, calculated with the Mantis code found to be working properly (valid blocks are valid.)
But the strings themselves are not so interesting for the purposes of this bug, just that they are the same across different blocks within a (ECIP-1099) epoch. (For the implementation itself the hashes are important of course.)
There was a problem hiding this comment.
(Also, the hash being all zeroes for epoch 0 is a good sign?)
dzajkowski
left a comment
dzajkowski
left a comment
There was a problem hiding this comment.
Please remove the "debug_" endpoint. We can groom it and bring it in properly.
… number) from connected peers" This reverts commit 48b39b5.
3 participants
Description
https://jira.iohk.io/browse/ETCM-797
Proposed Solution
calculate start epoch block, and calculate seed based on the epoch length and start epoch block