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
{{ message }}
This repository has been archived by the owner on Mar 14, 2023. It is now read-only.
Non-monotone changes (i.e. SparseChain changesets) must be generated and applied in order. If in between generating a changeset and applying it you apply another changeset that changeset must be thrown away. This is especially likely to happen if you need to do some IO after generating a changeset before you apply it and so you drop your mutex lock on the chain allowing another thread to make modifications while you wait for the result of your IO.
We current have baked in this mistake into our electrum example and the idea the "inflate_changeset" API on chaingraph. There we first generate a sparse chain changeset, we do some IO to get the full transactions (and drop the lock), and then inflate the changeset and apply it. What if another thread makes contradictory changes to the blockchain during this time i.e. there is a new block and the blocks and transactions have moved position since then? It breaks. This particular approach can be changed by instead of keeping a changeset over the IO boundry we inflate to a full ChainGraph and apply that -- this will enforce consistency.
We may wan to come up with a more general solution that makes it impossible to make this mistake:
Do not allow applying changesets API but rather stage them inside the objects themselves and commit them when appropriate to return the changeset which can be persisted.
This does not need to be fixed for first release.
The text was updated successfully, but these errors were encountered:
Non-monotone changes (i.e.
SparseChain
changesets) must be generated and applied in order. If in between generating a changeset and applying it you apply another changeset that changeset must be thrown away. This is especially likely to happen if you need to do some IO after generating a changeset before you apply it and so you drop your mutex lock on the chain allowing another thread to make modifications while you wait for the result of your IO.We current have baked in this mistake into our electrum example and the idea the "inflate_changeset" API on chaingraph. There we first generate a sparse chain changeset, we do some IO to get the full transactions (and drop the lock), and then inflate the changeset and apply it. What if another thread makes contradictory changes to the blockchain during this time i.e. there is a new block and the blocks and transactions have moved position since then? It breaks. This particular approach can be changed by instead of keeping a changeset over the IO boundry we inflate to a full
ChainGraph
and apply that -- this will enforce consistency.We may wan to come up with a more general solution that makes it impossible to make this mistake:
This does not need to be fixed for first release.
The text was updated successfully, but these errors were encountered: