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
Currently, users do not have any mechanism to create a new transaction that contains an already used nullifier that isn't still in a block. One of the main usages of this feature would be allowing clients to re-send a transaction with a higher fee.
In order to implement this, two changes are needed:
If the user provides the commitments (for either value or fee), we simply need to check in the code that the commitment is not already nullified on chain instead of checking isNullified. Note: If no commitments are provided, our default algorithm will never use nullified commitments. (This is already implemented)
Database will need to be modified so that it is consistent with what is happening. This means that don't want to store obsolete commitments nor transactions. Also, we need to keep in mind that, even if the client sends a new transaction using the same nullifier, he doesn't know which transaction will be the one that will get into the blockchain. The idea here is that the user will save the transaction when submitted rather than when a block is proposed. And then, when the block is proposed, will search for transactions that was using the same commitment / nullifier and delete from both, commitments and transactions db.
The text was updated successfully, but these errors were encountered:
Currently, users do not have any mechanism to create a new transaction that contains an already used nullifier that isn't still in a block. One of the main usages of this feature would be allowing clients to re-send a transaction with a higher fee.
In order to implement this, two changes are needed:
If the user provides the commitments (for either value or fee), we simply need to check in the code that the commitment is not already nullified on chain instead of checking
isNullified
. Note: If no commitments are provided, our default algorithm will never use nullified commitments. (This is already implemented)Database will need to be modified so that it is consistent with what is happening. This means that don't want to store obsolete commitments nor transactions. Also, we need to keep in mind that, even if the client sends a new transaction using the same nullifier, he doesn't know which transaction will be the one that will get into the blockchain. The idea here is that the user will save the transaction when submitted rather than when a block is proposed. And then, when the block is proposed, will search for transactions that was using the same commitment / nullifier and delete from both, commitments and transactions db.
The text was updated successfully, but these errors were encountered: