chain: handle accumulator reorg #498
Conversation
98940bc to
633775f
Compare
a25ce25 to
95045a7
Compare
13e5167 to
c5bb5c1
Compare
|
rebased and updated with @jaoleal's comments. |
|
ACK 9754a71 |
|
Updated with @JoseSK999's comments. Also fixed the numbers under |
|
@JoseSK999 fixed! |
bf77cd3 to
fecf9f2
Compare
|
Rebased and addressed @JoseSK999's comments. |
|
Fixed a problem with |
|
Wtf? Can anyone reproduce this error? I not only can't reproduce it, the line where it claims to panic doesn't have any |
@Davidson-Souza I reproduced this! GitHub Actions will not run on your version of the code but on the merged version with After rebasing the |
Ohhh it's a silent merge conflict! Thanks @JoseSK999 |
|
The |
In this case it's a block. But yeah, terrible naming |
Right now, if we ever encounter ourselves in a reorg of the chain, we will get into a corrupted state, because we won't update our accumulator for the no most-work-chain. Therefore, causing us to get stuck. This commit adds logic to save an retrieve accumulators from different heights, allowing a full reorg of our chain.
This commit adds a functional test for reorg, where we: - Create an utreexod and florestad instance - Connect them - Mine 10 blocks using utreexod - Wait for florestad to catch up - Use `invalidateblock` on utreexod to cause a fork on block 5 - Mine 20 more blocks on top of the tip - Check if both have the same tip and accumulator at the end
|
More than just the name I meant making the variant wrap a string or something that provides context about where this error originates. Good for another PR. |
What is the purpose of this pull request?
Which crates are being modified?
Description
Right now, if we ever encounter ourselves in a reorg of the chain, we will get into a corrupted state, because we won't update our accumulator for the no most-work-chain. Therefore, causing us to get stuck.
This commit adds logic to save an retrieve accumulators from different heights, allowing a full reorg of our chain.