How is this possible ? A Recent transaction suddenly becomes invalid

[hosseinimr93]

So the first transaction dropped because the second transaction spent the same input as the first transaction. Once it was spent by the second transaction, it was no longer available to be spent in the first, and so the first became invalid.

I wonder why nodes didn't reject the second transaction. As far as I know, nodes reject the second transaction even if the fee paid for it is much higher.
How did the scammer managed to do this? I don't think that's easy to implement a double spend attack.

[HelpMePleaseIbegofYou]

How is it possible i could spend a money that already deduct from my account and move it to another wallet..

Because until the transaction is confirmed, the money has not left your wallet yet. By broadcasting a transaction, all you've done is essentially send out a message saying "I want to move money from here to there". Until the transaction is confirmed, no money has actually moved.

You can send out two different messages sending the same money to different places. Whichever one is confirmed first is where the money will go, and the other one will be made invalid.

your responds is very clear.
my little confusion. this is possible only if i have more money in the wallet correct ? lets say if i had $120 and i sent $100 with low fee and my wallet balance turns $20. will i still be able to do this double spend , i guess No ?

[AB de Royse777]

your responds is very clear.
my little confusion. this is possible only if i have more money in the wallet correct ? lets say if i had $120 and i sent $100 with low fee and my wallet balance turns $20. will i still be able to do this double spend , i guess No ?

With the logic we are applying here, yes - you should be as long as you have $20 left in the same address that had $120 to send $100 to another address.

I think 3 confirmation is the safest to be sure that the transactions are going to be confirmed. I have some transactions that get a lot of issues depending on the wallet that I'm using.

If my the amount of a tx is not large then I would not mind with a 1 confirmation. It still takes a lot of resources to reverse a 1 confirmation tx. I think leo had a post about it that how much it could cost to reverse a 1 confirmation tx.

[ralle14]

what i do not understand is this. lets say i have $200 in my wallet on blockchain.info, then i send $100 to someone, even if its unconfirmed or low fee i am sure
the money $100 will be deducted from my account. How is it possible i could spend a money that already deduct from my account and move it to another wallet..

i wish to see a video demonstration of this.  This is very very interesting. very smart trick.

On blockchain.info's wallet this isn't possible since they don't have an option increase the fee aka the RBF feature which the others have mentioned already.

Here's a step by step guide if you want a bit of explanation on how it works.

[o_e_l_e_o]

my little confusion. this is possible only if i have more money in the wallet correct ?

No. Even if the address would be empty after the first transaction confirms, it is still possible to attempt a double spend.

The key issue here is that you are making two transactions using the exact same bitcoin. It would be like if I have a $20 bill in my wallet, and nothing else. I can still promise that $20 bill to two different people, but only one of them is going to get it.

[Lucius]

So many ways to trick somebody in the crypto

No one can fool you if you have knowledge of how the world of cryptocurrencies works - and I'm really surprised that some older members are not aware that there is a double-spend option, and that a BTC transaction that does not have at least 1 confirmation should not be considered a transaction at all.

These are basic things that everyone should learn before they even take possession of a cryptocurrency - and fraudsters are successful in their dirty business precisely because they take advantage of the ignorance, unfortunately of a large part of cryptocurrency users who are not even aware of what they are doing. It is not easy to be your own bank, if that were the case then BTC would be used by many more people than is the case today.

[nc50lc]

i wish to see a video demonstration of this.  This is very very interesting. very smart trick.

It's very easy to do if your wallet can create signed raw transactions that can skip broadcast and has coin-control feature.
Electrum for example.

The easiest way is to create a signed raw "send-to-own" transaction before sending the "send-to-the-target" transaction.
That way, you won't be needing extra steps of removing the already-broadcast transaction from your wallet's history.
Will a posted guide with images suffice?

A. Create a back-to-wallet signed raw transaction.

1. Open Electrum and go to "coins" tab (View->Show coins), right-click and click "spend" to select a UTXO(s) that's enough to pay the target.

It will be highlighted in green when selected.

2. Get an address from your own wallet and go to "send" tab, paste your address to the "pay to" box and input any amount or max.
Click "send" but do not click the next "send" on the next window, click "Advance" instead.
In the advanced window, increase the fee to an insanely huge amount and make sure "replace-by-fee" is ticked, click "finalize".

A new window will open, here you need to click "sign" (this is a must!):


3. In the same Window, click "Export->Copy to clipboard":

4.Save it to a text file:

5. Then close the window and disregard the warning that it wont be saved by clicking "yes":


B. Send the coins to the "target"

1. If you have closed the wallet or the coin selection was reset, just repeat the step one above and select (one of) the coin that you've previously selected.
2. Send it like a normal transaction but use 1sat/vB fee and you should be able to see it on blockexplorers as well as the other party.


Transaction: 642bf8e3d46591485c5b0d9aef2349123a21378e784c3fac1014e907ac11bb36 (now marked as invalid).

C. Invalidating the transaction by broadcasting the replacement

1. After deciding to replace the transaction, all you have to do is to broadcast the previously created "signed raw transaction" using either the "console" tab (View->Show console) or online push/broadcast transaction service.
For electrum tab, enter:

Code:

broadcast("02000000000101c47926bed38d8c77ea6990aca56fab............................")

That includes the quotation marks, the 020000... is the raw transaction that you've saved in a note or text file.

After that it will replace the previous transaction as long as the previous is still unconfirmed, has a higher fee that's enough for additional 1sat/B fee and replace-by-fee was enabled:

Transaction: d5d5300996c661de9ffb4588ae0ac6a0be3ffdccc63d92e37c159f77ec97cbf0

[HCP]

This is not rocket surgery or brain science... the simple solution to all of this is: DO NOT consider a transaction as "confirmed"... until it is actually confirmed.

"zero-conf" transactions are exactly that... zero confirmations, they can potentially be altered, dropped, double spent etc... DO NOT send any goods to a buyer until the transaction has at least one confirmation.

[khaled0111]

I wonder why nodes didn't reject the second transaction. As far as I know, nodes reject the second transaction even if the fee paid for it is much higher.

each node has its own mempool and at a given moment a node might have a set of unconfirmed transaction which might be slightly different from other mempools. There is a possibility the second transaction was broadcasted to nodes that didn't receive the first transaction yet.
Also not all nodes follow the same policies. A node owner can remove the first-seen policy and configure it in a way to reject the transaction paying less fees even if it was seen first

[hosseinimr93]

I wonder why nodes didn't reject the second transaction. As far as I know, nodes reject the second transaction even if the fee paid for it is much higher.

each node has its own mempool and at a given moment a node might have a set of unconfirmed transaction which might be slightly different from other mempools. There is a possibility the second transaction was broadcasted to nodes that didn't receive the first transaction yet.
Also not all nodes follow the same policies. A node owner can remove the first-seen policy and configure it in a way to reject the transaction paying less fees even if it was seen first

Thanks for the explanation.
Doesn't a transaction need to be validated by majority of nodes, so it can be added to a block?
Don't nodes usually reject such transactions?

In the case OP is talking about, majority of nodes preferred to validate the second transaction. I know that some nodes may approve the second transaction. My question is why majority of nodes approved the second transaction?

The first transaction had been broadcast 6 minutes before the first one. So, majority of nodes likely received the first transaction before the second one. Why did majority of nodes replaced the first transaction with the second one?

The scammer was very very lucky. Such transactions don't have big chance to be confirmed. Because most of nodes validate the transaction they see first. Am I right?

[HCP]

Doesn't a transaction need to be validated by majority of nodes, so it can be added to a block?

No. Technically a transaction doesn't need to be "verified" by any nodes other than a miner that puts it into a block. Granted, a transaction with better propagation (ie. has been relayed by a larger number of nodes) is statisically more likely to be included in a block as it is more likely to have been received by mining pools etc... but it isn't technically necessary. Mining pools can insert transactions that no-one else even knows about until the block is mined.

Don't nodes usually reject such transactions?

If the transaction was marked as RBF, it didn't break any of the RBF rules.

In the case OP is talking about, majority of nodes preferred to validate the second transaction. I know that some nodes may approve the second transaction. My question is why majority of nodes approved the second transaction?

As above, it isn't because the majority of nodes "approved" it. (Note that nodes don't actually approve anything... all they do is relay transactions)... the 2nd transaction was put into a block by a miner (most likely because of the much higher fee)... at that point, assuming the transaction is actually valid, there is nothing that nodes can do.

The first transaction had been broadcast 6 minutes before the first one. So, majority of nodes likely received the first transaction before the second one. Why did majority of nodes replaced the first transaction with the second one?

That's how RBF is designed.

The scammer was very very lucky. Such transactions don't have big chance to be confirmed. Because most of nodes validate the transaction they see first. Am I right?

Not necessarily... if it was RBF, what the nodes did was perfectly acceptable from a technical point of view. They simply replaced the transaction with a new one with a higher fee. Obviously, what the scammer did is NOT acceptable from a moral point of view

[nc50lc]

Doesn't a transaction need to be validated by majority of nodes, so it can be added to a block?
Don't nodes usually reject such transactions?

If you read the implementation details of BIP-0125 (Opt-in Full RBF Signaling): bip-0125.mediawiki
You'll see that there's no "invalid when the outputs were changed" suggests that it's possible to change the outputs of a replacement transaction.

[o_e_l_e_o]

The first transaction had been broadcast 6 minutes before the first one.

HCP has already explained what happened, but one extra point to add: We do not know when the user broadcast the transactions. All you can say from those timestamps is that the node Blockchain.com is using to update its block explorer first saw the two transactions 6 minutes apart. The user could well have broadcast the second replacement transaction at the same time as the first, but broadcast it directly to a miner rather than the entire network.

You'll also see on the link nc50lc shared, under the heading "Motivation", that there is a type of RBF called "First Seen Safe" or FSS which will only accept a second transaction if it pays all the same outputs as the one it is replacing at least the same amount (or more) of bitcoin. It doesn't entirely solve the problem and has privacy implications as well, and even without RBF at all it is still possible to double spend a transaction, and so is a bit of a false sense of security.

Better to just wait for some confirmations.

[Pmalek]

Snip

Very detailed and easy to understand guide. Thumbs up! But you have just given many scammers, potential scammers and other jerkoffs many reasons to be happy. If they didn't know how to do an RBF-enabled double spend, they now have all the necessary information. Even if it's a great post, it will surely be misused. 

I still haven't upgraded my Electrum from 3.3.8 so the steps are a bit different on the old version.

[o_e_l_e_o]

If they didn't know how to do an RBF-enabled double spend, they now have all the necessary information. Even if it's a great post, it will surely be misused. 

RBF isn't exactly some top secret information. 10 minutes and the ability to use Google and anyone who wants to try to scam people by double spending with RBF will know what to do.

I still haven't upgraded my Electrum from 3.3.8 so the steps are a bit different on the old version.

Why? There's no good reason to use an outdated version. Even if you aren't interested in using Lightning, version 4 and up contains a couple of other nice new features and a whole ton of bug fixes.

[Pmalek]

Why? There's no good reason to use an outdated version. Even if you aren't interested in using Lightning, version 4 and up contains a couple of other nice new features and a whole ton of bug fixes.

I keep my Bitcoin on a hardware wallet. I use Electrum together with my hardware wallet only when sending Bitcoin, and I haven't been doing much of that since the new 4.0 versions came out. I like to wait before big upgrades to give the developers some time to fix bugs and glitches. I am planning to upgrade before my next consolidation transactions. 

[Stedsm]

I keep my Bitcoin on a hardware wallet. I use Electrum together with my hardware wallet only when sending Bitcoin, and I haven't been doing much of that since the new 4.0 versions came out. I like to wait before big upgrades to give the developers some time to fix bugs and glitches. I am planning to upgrade before my next consolidation transactions. 

Holding on your own, waiting to update your wallet software invites malware or internal server manipulation as well as hacks if the system has gone outdated. It's better to go with the flow and update each and every time you see it (without waiting of course) as it will only save you from the possible bad things that might happen with your coins just because you wanted to wait.

@OP, It has never been a good idea to provide any services and / or digital goods to anyone who sent you some coins but the coins didn't confirm. Ask them to wait for at least 6 confirmations because after that, it becomes impossible for them to double-spend that transaction and saves you from the hassle of getting scammed.

[nc50lc]

Snip

Very detailed and easy to understand guide. Thumbs up! But you have just given many scammers, potential scammers and other jerkoffs many reasons to be happy. If they didn't know how to do an RBF-enabled double spend, they now have all the necessary information. Even if it's a great post, it will surely be misused.  

Nah, it's only effective to those who accepts 0-confirmation.
It's only a detailed example on what happened to OP, plus he's looking for a video, I gave him a "how-to" guide with images instead.

It will never be an issue for usual bitcoiners that wait for a confirmation, Exhanges and "well-built" services that accepts 0-confirmation non-RBF deposits.

I still haven't upgraded my Electrum from 3.3.8 so the steps are a bit different on the old version.

It's pretty much the same except coin control will redirect you to the send tab and the button for "copy to clipboard" looks different but in the same spot.

[HCP]

It's pretty much the same except coin control will redirect you to the send tab and the button for "copy to clipboard" looks different but in the same spot.

I would say that the entire "send" workflow has changed... for instance, you can't select a fee until you click "Pay" which seems a little unintuitive at first... but kind of makes sense if you use the "Advanced Preview" which shows all the inputs/outputs and the estimated transaction size etc and you can see how things change depending on the fee you set etc.

[nc50lc]

It's pretty much the same except coin control will redirect you to the send tab and the button for "copy to clipboard" looks different but in the same spot.

I would say that the entire "send" workflow has changed... for instance, you can't select a fee until you click "Pay" which seems a little unintuitive at first... but kind of makes sense if you use the "Advanced Preview" which shows all the inputs/outputs and the estimated transaction size etc and you can see how things change depending on the fee you set etc.

Oh right, I totally missed the "preview" thing in 3.3.8 below.

@Pmalek So in 3.3.8, you need to click "preview" instead of "send" to display the advance preview.
And there's no RBF box in the preview, the only way to enable/disable it is to tick: "use replace-by-fee" option in "Tools->Preferences".