search

stacks-network / stacks-core

The Stacks blockchain implementation
https://docs.stacks.co
GNU General Public License v3.0
3.01k stars 665 forks source link

Reject txs with used nonces from mempool #4129

Open obycode opened 10 months ago

obycode commented 10 months ago

Since there are no more reorgs in Nakamoto, we no longer need to accept transactions with nonces that have already been used into the mempool. This current behavior (which is necessary for forking) is very confusing to users, since it can cause a transaction that will remain pending for a couple days, until it is dropped from the mempool, and they can't understand why. With Nakamoto, we can update that behavior so that a transaction like this is rejected by the mempool, allowing wallets to show a clear error to users.

jcnelson commented 10 months ago

Not quite. Bitcoin can still fork, which means a tx can be mined twice (one on each fork).

On Wed, Dec 6, 2023, 9:27 AM Brice Dobry @.***> wrote:

Since there are no more reorgs in Nakamoto, we no longer need to accept transactions with nonces that have already been used into the mempool. This current behavior (which is necessary for forking) is very confusing to users, since it can cause a transaction that will remain pending for a couple days, until it is dropped from the mempool, and they can't understand why. With Nakamoto, we can update that behavior so that a transaction like this is rejected by the mempool, allowing wallets to show a clear error to users.

— Reply to this email directly, view it on GitHub https://github.com/stacks-network/stacks-core/issues/4129, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADQJK7BIE42KAWXCJSCFYTYIB6GRAVCNFSM6AAAAABAJPA2DOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGAZDQNRYGIZTANQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

obycode commented 10 months ago

But don't we plan to guarantee that the same transactions get replayed in the same order on a Bitcoin fork?

314159265359879 commented 10 months ago

How would you RBF (replace by fee) if you can't use the same nonce again?

Leather already rejects sending a transaction if the nonce is already confirmed. When it is still pending though we want users to have the option to RBF it.

Anytime a user RBF's there will be a time where the old and new transaction exists in the network until all the nodes have received the new transaction and replaced the other. I am sure there are other edge cases where users can send a transactions with the same nonce again. Especially once a transaction nonce is confirmed we shouldn't display these pending transactions (with the same nonce = unprocessable transaction) anymore in the wallet/API.

What about this solution: https://github.com/hirosystems/explorer/issues/1038 ? (to fix https://github.com/leather-wallet/extension/issues/1867)

obycode commented 10 months ago

How would you RBF (replace by fee) if you can't use the same nonce again?

The transaction would only get rejected if the nonce has already been confirmed in a block. RBFing has to happen before the transaction is confirmed.

314159265359879 commented 10 months ago

How would you RBF (replace by fee) if you can't use the same nonce again?

The transaction would only get rejected if the nonce has already been confirmed in a block. RBFing has to happen before the transaction is confirmed.

I understand. The current issues are caused by RBF though (Leather doesn't send transactions with nonces that are already confirmed). And if you allow RBF in Nakamoto how do you guarantee the same transaction is always mined in the same block when Bitcoin forks... because different Stacks nodes can have different views (at least temporarily) of which transaction (with nonce/fee i.e. tx (a) with nonce 42/0.1 STX fee and (b) nonce 42/0.2 STX fee) is available for including in a block.

Consider this situation: where (a) is mined before (b) is received by the miner. A miner on an other bitcoin fork did receive (b) and mines that and shortly thereafter that bitcoin chains proves the longest. Or is that not possible with Nakamoto?

obycode commented 10 months ago

Yeah, I don't think that problem is possible. There will be only one confirmed block recognized by the whole network, so if Bitcoin reorgs, then the Stacks blocks should be reconstructed from the same confirmed stacks blocks. Rebuilding one of those blocks with an alternative transaction (RBFing one that was previously included) will be illegal, and this new block should not be signed by the stackers.