Add state for transactions with a nonce that has already been processed for an address

[314159265359879]

Please review the existing enhancement issues at the link below before creating a new one to ensure you do not create a duplicate request.
I see #1003 was merged. That is awesome.
I believe no addition was made based on the comment I send about "nonce already used"? I see such a transaction remains pending now.

Is your feature request related to a problem? Please describe.
Here is an a practical example.

1. User send transaction to withdraw from Arkadiko vault (n591 fee 0.003 STX)
2. User doesn't like confirmation speed and RBF's increasing the fee 10x
3. Original transaction gets mined (nonce 591) fee 0.003 STX https://explorer.stacks.co/txid/0xe2dc5346bf1990365f50bc04374dc5e928364936ff0e064e03fb77675c55b9de?chain=mainnet
4. withdraw transaction with increased fee remains pending (nonce 591) fee 0.03 STX https://explorer.stacks.co/txid/0x7918e7ca77b74b64933fe612788ae4a80fa7f4341ab55244c5ffdd891fb955d9?chain=mainnet

Describe the solution you'd like
Although "dropped" isn't the right term here because it could still get mined in case of a reorg I do believe an additional state could be helpful here to indicate the transaction is unlikely to get processed. Without a reorg it will not happen.
"Unprocessable" could be a helpful label? I think it helps with what to expect for a user at least.

Describe alternatives you've considered

• Not showing it at all, leads to more questions and impossibility to troubleshoot.
• Leaving it pending, doesn't help the users expectations.

[Hero-Gamer]

wen

[andresgalante]

Will this tx be dropped after some time? What would the state be? unprocessed? 😆

[314159265359879]

Will this tx be dropped after some time? What would the state be? unprocessed? 😆

Yes dropped after 256 blocks, unprocessable/unprocessed before that.

I see this is ready, when is it set to go live?

[andresgalante]

Ready means that we pick it up to do, but at the moment, we are very low in capacity, so it might be some time before we ship it.

Having said that we want to prioritize tx status information tasks like this one.

[BLuEScioN]

@andresgalante
I think it ma not be do-able atm because the category for the unprocessable tx is:

1. There is already another tx with the same nonce that has been processed
2. It has been less than 256 blocks (dropped threshold) since the tx was sent

The issue I see is with 2. I don't think the API has an endpoint to search for a tx by nonce, which would be required to know whether a tx with the same nonce has been mined already. If we had this endpoint, this feature would then also require an additional network request to assess the tx status, and I don't think the explorer is the place to add and handle this complexity. If we want to assign another tx status for these tx scenarios I think it should be done on the API/Node layer. Perhaps, when an account tx gets mined, we could check all txs for that account and see if there is a tx with the same nonce and in the situation update the state.

[andresgalante]

@BLuEScioN Those are fair points. Considering your findings, let's hold this issue for now and work on it when we take on improving tx status

[314159265359879]

Bump, any chance this could be prioritized prior to or soon after the Nakamoto activation?

I see transactions like these are causing quiet some confusion among new users.

[markmhendrickson]

Do we primarily need this state from the API, then both the explorer and wallets can use it? If so, let's create an issue in the API repo?

[314159265359879]

Does this addition mean these transactions can now be filtered out? hirosystems/stacks-blockchain-api#2011

Lets not show pending transactions with a nonce that has already been processed in the explorer or the wallet anymore? If you insist on showing them because they can be used in a reorg... then show them for 6 bitcoin blocks after transmitting or after a transaction with that nonce has been processed. The likelyhood of a reorg after that is close to 0 anyway.