For me, it was a non-issue anyways, but i'd still like to detail my rationale as to why i (mis)called this one a doublespend based on the very limited research i did on this specific occurrence.
I didn't initially use any sources, but for this rationale, i've used https://en.bitcoin.it/wiki/Irreversible_Transactions because, let's face it, sometimes it's easier to quote a well-known source than it is to start from scratch
Quote
Double-spending is the result of successfully spending some money more than once. Bitcoin users protect themselves from double spending fraud by waiting for confirmations when receiving payments on the blockchain, the transactions become more irreversible as the number of confirmations rises.
source: https://en.bitcoin.it/wiki/Irreversible_TransactionsWhile it is true one cannot get two double spending transactions in the chain with the most difficulty, to my knowledge it IS possible to have 2 unconfirmed transactions spending the same unspent output floating around in the network node's mempools. So, in reality, those two (or more) unconfirmed transaction are double (or tripple, or quadriple) spending the same unspent output. It's only when one of the two (or more) transactions ends up in a block, the other one becomes invalid... Unless there is a re-org, in which case the "invalid" transaction could possibly end up in the chain with the most difficulty and make the initially "confirmed" transaction suddenly invalid. Which i tought was happening here, hence the term "double-spending" popped up.
Quote
Blockchain reorganization attack
Also called alternative history attack. This attack has a chance to work even if the merchant waits for some confirmations, but requires relatively high hashrate and risk of significant expense in wasted electricity to the attacking miner.
The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining an alternative blockchain fork in which a fraudulent double-spending transaction is included instead. After waiting for n confirmations, the merchant sends the product. If the attacker happened to find more than n blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network. If he never manages to do this then the attack fails, the attacker has wasted a significant amount of electricity and the payment to the merchant will not be reversed.
source: https://en.bitcoin.it/wiki/Irreversible_TransactionsAlso called alternative history attack. This attack has a chance to work even if the merchant waits for some confirmations, but requires relatively high hashrate and risk of significant expense in wasted electricity to the attacking miner.
The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining an alternative blockchain fork in which a fraudulent double-spending transaction is included instead. After waiting for n confirmations, the merchant sends the product. If the attacker happened to find more than n blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network. If he never manages to do this then the attack fails, the attacker has wasted a significant amount of electricity and the payment to the merchant will not be reversed.
I assumed this was a case of a blockchain reorganisation in which a transaction double spending the same output as a transaction that was in the other chain happened and said double spending tx ended up in the reorged chain... I mean, it was only $22 worth of BTC (at the exchange rate at that time). This is the reason why i didn't look any deeper: for god's sake, it was $22... It was clearly an accident (or in this case, somebody probably increased the fee of an rbf transaction).
Yup, everything worked exactly as it should have worked (i never claimed otherwise). Yup your funds are safe. Yup, it's a big bowl of FUD... But two unconfirmed transactions can spend the same unspent output... They can not end up in the same chain, but as long as they're unconfirmed, they can be double-spending... A re-org can happen, and both the stale chain as the longest can contain a different transaction spending the same unspent output. Hence the terminology i used.
