Fix/4793 #4817
Fix/4793 #4817
Conversation
…d cycle ID, by sortition ID, etc.)
…d-and-unknown' status
…til a later date, and it's in the git history so we can fetch it later)
…ortition tip. Do not attempt to get the canonical stacks or burnchain tips.
…est module, where it is still required for test coverage
…aggregate public keys
…t the block in reward cycle N at reward cycle index 0 was signed by the signers of reward cycle N - 1
…t an extension of a previously-started tenure, or a newly-started tenure), and clarify that the existing API for getting the highest Nakamoto tenure only pertains to the highest *started* tenure (not extended)
…ed reward set of the anchor block is not yet known
| self.current_reward_sets.insert(rc, reward_cycle_info); | ||
| self.current_reward_set_ids.insert(rc, reward_cycle_sort_id); |
There was a problem hiding this comment.
Would current_reward_sets: BTreeMap<u64, (SortitionId, RewardCycleInfo)> work for tracking the information? Or is there a case where current_reward_sets.get(x).is_some() && current_reward_set_ids.get(x).is_none()?
There was a problem hiding this comment.
The downloader logic expects HashMap<u64, RewardCycleInfo> all over the place, and it's cleaner to just store these two data in separate tables than force the downloader to deconstruct the tuple each time it wants to access the reward cycle info.
There was a problem hiding this comment.
Okay, if its really easier, that's fine, but please add to both docstrings that there's a 1-1 correspondence between entries in current_reward_sets and current_reward_set_ids, which is an invariant that must be enforced by any method that adds or removes elements from those sets.
|
I really only have non blocking nits. aside from that, if we don;t plan to keep v1 tests in working state, might want to remove filter_bad_transactions from CI. Otherwise, maybe we can maintain this test? |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This PR updates the Nakamoto chainstate and networking stack to use the reward cycle's signers instead of the aggregate public key to authenticate Nakamoto blocks (#4793). In order to do this, this PR also fixes #4813.
Note that the fix for #4813 does not need a schema migration for nodes today which have erroneously stored a
SelectedAndUnknownreward set, because the impact of doing so is nonexistent. This would only have required a schema migration if the last reward 2.5 cycle was erroneously set toSelectedAndUnknown.