Sporadic bursts "E Key image already spent in blockchain" in logs

[j-berman]

Both u/coffnix and u/mayhem69 have reported sporadic bursts of the error "E Key image already spent in blockchain" in the logs. Here is a screenshot shared by u/coffnix in the stressnet matrix channel:

[nahuhh]

3rd

ive seen this as well. To me, looks like..

1. node a has synced new block 390
2. node b is re-relaying txs from pool to node a.
   node b is still on block 389 and should be pulling the new block 390 from node a, but that seems to have issues of its own.
3. node a recognizes these as already confirmed

[spackle-xmr]

Here is a level 2 log from a stressnet node with some of these entries:
log2.txt.gz

[j-berman]

From those logs, it looks like txs may be getting mined that spend the same inputs as some txs in the pool. Example:

Considering <210e964f61ad945add250ce1ea325cb945739cbc6347674acca663fa0e57795c>, weight 6498, current block weight 0/9435166, current coinbase 0.600000000000, relay method 4
Key image already spent in blockchain: f28285bc902bde525ccb8508b3050309cb151dfc87ec79d8972205a97bbd767e

Looking at my stressnet node, I don't see 210e964f61ad945add250ce1ea325cb945739cbc6347674acca663fa0e57795c in the chain, but I do see that f28285bc902bde525ccb8508b3050309cb151dfc87ec79d8972205a97bbd767e has been spent.

It's possible that spammers are relaying double spends that are relaying to some portions of the network, or relaying them to their own nodes and then mining them.

It's possible this will also be alleviated by #135.

[j-berman]

Note, the "Considering" log in log level 2 (which precedes every line of "Key image already spent in blockchain") executes when a daemon is filling a new block template immediately after adding a block. It doesn't receive new txs at that point, it already has the txs in its pool. That's why it looks like the daemon is adding a block that includes txs spending the same key images. The theory is testable by checking that key image f28285bc902bde525ccb8508b3050309cb151dfc87ec79d8972205a97bbd767e is spent in block ada807e84cc06ca13eb2c1ce1c6e70c9f435b3050b9b0cf5ff239c152798c639.

[j-berman]

Interestingly, the block in question ada807e84cc06ca13eb2c1ce1c6e70c9f435b3050b9b0cf5ff239c152798c639 doesn't appear to be in the main chain anymore (and I don't have an alt block for it). Possibly related to the issue at hand.

Would be interesting to see which block (and tx) that the key image f28285bc902bde525ccb8508b3050309cb151dfc87ec79d8972205a97bbd767e has been spent in. Could re-purpose blockchain_usage.cpp to search for the block and tx.

[j-berman]

Reiterating: this error can occur if users are actively attempting to double spend on the network.

If Node A sees a tx spending key image A, and Node B sees a distinct tx spending key image A, then both nodes might end up trying to re-relay the txs to each other, and get dropped here. Perhaps we don't want them to get dropped there.

[nahuhh]

"Reiterating: this error can occur if users are actively attempting to double spend on the network."

without more info, i believe some people producing txs/spamming might be flushing their tx pools, probably to clear double spend errors. ..Then they start submitting new txs before the old txpool is refetched.

(still unclear as to what causes the initial double spend errors, but rescan_spent seems to fix those wallets and correct the balances).

[j-berman]

#208 should help