You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reorg cache is used in the case of an actual reorg, to allow the local txpool to be put back in a consistent state. We do not currently take advantage of it in the case of a short losing fork.
Say we have [tx1] in the txpool and we accept block B (containing the kernel for tx1), this evicts tx1 from the txpool.
If we then see block B' (a fork at same height as B), also containing the kernel for tx1
we don't see tx1 in the txpool and we currently go ask a peer for the full block B'.
But - we do have tx1 in the reorg cache, so we could go look for it in there (I think this would be safe to do).
We use the reorg cache to keep the txpool consistent, we don't currently take advantage of it directly when accepting blocks.
The text was updated successfully, but these errors were encountered:
The reorg cache is used in the case of an actual reorg, to allow the local txpool to be put back in a consistent state. We do not currently take advantage of it in the case of a short losing fork.
Say we have
[tx1]
in the txpool and we accept blockB
(containing the kernel fortx1
), this evictstx1
from the txpool.If we then see block
B'
(a fork at same height asB
), also containing the kernel fortx1
we don't see
tx1
in the txpool and we currently go ask a peer for the full blockB'
.But - we do have
tx1
in the reorg cache, so we could go look for it in there (I think this would be safe to do).We use the reorg cache to keep the txpool consistent, we don't currently take advantage of it directly when accepting blocks.
The text was updated successfully, but these errors were encountered: