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
Along with #8457, the PXE should also take into account the re-orgs. Namely, if a note have been inserted during a block that is later pruned, we will need to also remove it from our PXE such that we don't think we could spend it later.
The exact mechanism for catching the re-orgs is to be decided, but could be as simple at storing the block number and expected archive along with the notes and then ask the node occaisionally if there have been any re-orgs and then delete if deeper than specified.
The text was updated successfully, but these errors were encountered:
Something to consider when working on this. It might be insufficient to rely on the archiver providing information around when it have seen a reorg, since a PXE might end up pointing at different nodes, which might have seen different reorgs.
It seems like the most stable method for figuring out if some information is indeed in the chain would be to store the block hashes as part of the note data on device, and then if that block is added to the proven chain mark is as included and periodically check the notes that don't have been marked.
Along with #8457, the PXE should also take into account the re-orgs. Namely, if a note have been inserted during a block that is later pruned, we will need to also remove it from our PXE such that we don't think we could spend it later.
The exact mechanism for catching the re-orgs is to be decided, but could be as simple at storing the block number and expected archive along with the notes and then ask the node occaisionally if there have been any re-orgs and then delete if deeper than specified.
The text was updated successfully, but these errors were encountered: