When generating the stake modifier, the current proof-of-stake algorithm backtracks from the current block, logging previous block hashes and timestamps and then uses this information to generate a stake modifier. During this process, the list of timestamps and hashes is sorted (not sure why they chose to do this as it makes little sense). This is causing some issues due to the way the equality operator for Uint256 is implemented in the newer Bitcoin codebase vs the legacy Cloak codebase.
I think the preferred solution would be to work around this sorting case in the PoS code (by using a custom sort that mirrors the legacy behaviour). It is only causing issues due to a run of blocks with matching timestamps early in the blockchain. However, there could be instances in the Enigma code where this crops up, but I am doubtful that it will be an issue. I much prefer this approach to the alternative of changing the Uint256 to match the legacy code.
r3rcloak
commented
5 years ago
When generating the stake modifier, the current proof-of-stake algorithm backtracks from the current block, logging previous block hashes and timestamps and then uses this information to generate a stake modifier. During this process, the list of timestamps and hashes is sorted (not sure why they chose to do this as it makes little sense). This is causing some issues due to the way the equality operator for Uint256 is implemented in the newer Bitcoin codebase vs the legacy Cloak codebase.
I think the preferred solution would be to work around this sorting case in the PoS code (by using a custom sort that mirrors the legacy behaviour). It is only causing issues due to a run of blocks with matching timestamps early in the blockchain. However, there could be instances in the Enigma code where this crops up, but I am doubtful that it will be an issue. I much prefer this approach to the alternative of changing the Uint256 to match the legacy code.