Negative balance due to unprocessable transaction (already processed nonce)

[314159265359879]

RBF'ed transactions create a clone with the same nonce and a higher fee. The clone can remain pending in the wallet/API because we do not have a special state for it as suggested here: hirosystems/explorer#1038

This is different from negative balance due to incoming transactions and the fees which is described here: #3761

[314159265359879]

The workaround is: wait for the pending transaction to get dropped after 256 blocks (approx. 2 days) or use another wallet.

I am not sure if this problem always pops up or only when the new transaction isn't propagated through the network before the old one gets picked up by a miner or the other way around (the new one gets picked up without being propagated over the Stacks network to replace (RBF) all other instances with lower fee).

[alter-eggo]

hm, yeah, I managed to reproduce this problem and my pr actually doesn't solve this. wonder what can we do here 🤔
maybe don't subtract pending txs if current date - receipt_time < 'x' time? x === 1 hour maybe? 2 hours?
example of pending tx:

{
    "tx_id": "0x32611cde7277065fdb315114d023642cf95f0b2862d5707f611b2c9a2b84721f",
    "nonce": 1,
    "fee_rate": "544175",
    "sender_address": "ST3WSKSKGNFCDGJN9EXF6AC9NFF69XNNFXN2DQA7E",
    "sponsored": false,
    "post_condition_mode": "deny",
    "post_conditions": [],
    "anchor_mode": "any",
    "tx_status": "pending",
    "receipt_time": 1689261001,
    "receipt_time_iso": "2023-07-13T15:10:01.000Z",
    "tx_type": "token_transfer",
    "token_transfer": {
        "recipient_address": "ST5BQXGQJR6FQEEZMXT9TF20THFZ5ZE9NMQDAZZT",
        "amount": "2000000",
        "memo": "0x00000000000000000000000000000000000000000000000000000000000000000000"
    }
}

[alter-eggo]

wdyt @314159265359879 @markmhx

[314159265359879]

Interesting idea I think it will work in most cases but could set us up for disaster in times of congestion. Using the time it has been pending, anything more than two hours is good indication of an unprocessable/troublesome transaction, if there is no congestion on the network. It could be problematic if there is congestion though... it would lead to more unprocessable/double spend transaction as it gives "false positives" in such a case.

I think the following would be safer:
Is it possible to ignore transaction based on last executed transaction nonce for the address if the pending transaction nonce is equal or lower because then we can be certain it will not get mined.

[alter-eggo]

this will lead to that we will fetch all txs and all pending txs for all accounts in case user, e.g. opens select acc modal. I feel like we need some cheaper solution, or it's ok? @kyranjamie @markmhx

[314159265359879]

Ow I see, I didn't realize that.
Isn't "last executed tx nonce" something you can fetch without fetching all (confirmed) transactions?
(for example what if you derive, last executed tx nonce from this API [get account info](https://stacks-node-api.mainnet.stacks.co/v2/accounts/SP497E7RX3233ATBS2AB9G4WTHB63X5PBSP5VGAQ) it would be nonce minus 1)

Then you just need all the pending transactions (an account can have 25 max I believe, and an account having that many pending is quite rare).

Probably best if @kyranjamie comments on this.

[kyranjamie]

Spoke with @alter-eggo about this. Suggestion was to not subtract pending txs if nonce value exists in array of mined transactions