This repository has been archived by the owner on Feb 21, 2019. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Track delegate ids and other ids separately in slate_records; #1358
- Loading branch information
1 parent
4a73089
commit d4e9b35
Showing
10 changed files
with
41 additions
and
40 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
d4e9b35
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the client wants to use an int in other_slate that is currently a delegate ID? What if the client uses an int that is currently not a delegate ID, but between the time the signed transaction is broadcast and included (before expiration) into the blockchain, someone registers a delegate that happens to have that same ID? I don't think the system compares to the state of account registration at the time the transaction was signed, does it? If not, that means that the transaction would have inadvertently voted for that delegate. And even if so, time would not be good enough because of possible forks (the transaction would need to include the hash of the last block it saw prior to crafting the transaction).
There needs to be a clearer separation in the slate definition of a transaction between an int meant as a vote for a delegate and an arbitrary int used for non-binding proposal systems. Perhaps you can require that all positive ints in the slate be for currently registered delegates (whether retracted or not), and allow negative ints to be included in the slate (which would be stored in other_slate) for whatever non-binding proposal purposes people want to use them for. Although the disadvantage there is that we cannot efficiently upvote or downvote a proposal ID and would instead require two proposals representing an upvote or a downvote of the actual proposal they both refer to (that is a hack, but then again the entire non-binding proposal system is a hack for now).
d4e9b35
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the negatives idea--this will ensure that we have no collisions. So I will restore the original requirement that all positives be existing delegates, and save the negatives but ignore them for now.
d4e9b35
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am modifying this to use the negative numbers and also check for hash collisions on the 64 bit slate id.