Topic: How is this possible ? A Recent transaction suddenly becomes invalid (Read 756 times)

This is a big warning for all of us here to consider the 0 transactrion as not yet broadcast and wait for the confirmation to happen before making a move to send the product or confirmed payment, we should know how transaction works in the first place because we are investing in Cryptocurency.

You can read the requirements for an RBF transaction on the BIP125 proposal which nc50lc linked on the previous page - https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki

In summary, the main requirements are that the initial transaction is opted in to RBF, the replacement transaction pays a higher fee than the one it is replacing, and the replacement transaction spends one or more of the same inputs. There is no stipulation made about spending all the same inputs or sending coins to the same addresses as the first transaction. Theoretically, a transaction could take 20 different inputs and send them to 20 different addresses, and could be replaced by a transaction sending just one of those inputs back to the same address it came from.

If you also see my post on the previous page here, there is a type of RBF called "First Seen Safe" which essentially does as you are describing, but it is not used.

Nothing is ever 100%, and there are some nodes out there which reject all RBF transactions. However, if the first transaction isn't confirmed and is opted in, and the second transaction meets the requirements as above, then there is a high likelihood the first will be replaced.

@nc50lc and @HCP

I always thought that an RBF transaction can only spend the same UTXO with higher fees to the same address as the original transaction, not a new one like in OPs case. What is the success rate for such a double spend? Are we talking 100%, taking into consideration that the 1st transaction doesn't get confirmed in the meantime and that the fees are much higher?

Would the same procedure work with additional "fake" transactions or does it somehow lower the success rate? if someone were to invalidate 3, 5, 10... transactions trying to trick several people at once. 

 

There are no such things like for x amount of USD wait for y confirmations.

You protect yourself by waiting for at-least one confirmation. Very simple. If you have very large amount of coins like say 20 BTC or more then wait for six confirmation. Don't complicated it or over think it.

Nodes can't possibly see every single transaction that's being broadcast. A transaction is not permanent until it get confirmed.

How do you protect yourself again this then?


Make sure if someone send you btc, it need to have x amount of confirmations before you send them online money or give them cash?  So if its smaller amount, less confirmations?  What would be a good rule?


Anything small like ten and under, one confirmation


Anything one hundred and under, two confirmation


Anything like a thousand or so... 6 confirmation?


Anything higher than that.. 8 confirmation?


What about ppl who do like 5k or 50k usd transactions?  Those like ten confirmations?

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".

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.

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.

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.

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.

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. 

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.

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.

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.

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.

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.

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.



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


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.


That's how RBF is designed.


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

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?

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

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.

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:
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

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.

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.

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.

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.

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.

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 ?

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.

Correct 100%
In other words, do not complete a deal until the tx has minimum 1 confirmation @HelpMePleaseIbegofYou.
Again sorry for the loss, we all learn from our own experience or someone else's experience.

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.

I am still trying to get this in my head. Very tricky for me to understand although o_e_l_e_o tried to explain in the post above you. I did make a test tx but I messed up with something and now stuck with some error, nothing wrong and it will be confirmed though. I will let this tx to confirm and then try with a fresh one then will share the flow.

That error suck me, it is saying not sufficient fund for fees. Not sure if this is connected with the goal I am trying to achieve. But as I said I will try again once the tx confirms.

this looks soo like magic LOL..

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.

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.

Even although the 1CKnh... address still had enough funds on it for the first transaction, they were now part of a different output, and so the first transaction was still invalid. Transactions spend specific outputs. If I have an address with 5 outputs each of 1 BTC, and I make two different transactions using the same output, only 1 will confirm and 1 will become invalid, even though there are 4 other outputs of 1 BTC at that address.

When I responded I did not check the tx but explained the possibility now I see the tx history of that address (output address of the sender).

Tx in question is this: 2f362caac5d3fa3a1cc586f5bdbb36bcfe6446cfc112eb1cb097d9669688204a
and this tx has OPs address 34Y9ZwTsT3H9zcnffirc2NM4XMkNmaLws6

Then the sender somehow removed the OPs address and replaced it with this address 1HrtBS3eM1wG7UKuP39fqnRQVX6FJvc8An
And used higher fees. The tx is 31c444900939113ad1c57277fc2904b20f77e57f76f95eee45ec119e72a6342c

In both cases the change address was the same address as the output which is 1CKnhZmHzj45xdvvsAf3DbLWfYSX53NVMs

First tx (2f362caac5d3fa3a1cc586f5bdbb36bcfe6446cfc112eb1cb097d9669688204a) had less fees and had this address (1CKnhZmHzj45xdvvsAf3DbLWfYSX53NVMs) as changed.
Address 1CKnhZmHzj45xdvvsAf3DbLWfYSX53NVMs has unconfirmed coin, and he went to spend that unconfirmed coin. Once he made the 2nd tx then the first tx was effected because it had its input and output same address. And as a reason the first Tx dropped?

I never experienced that but the dry run takes me to this path for the drop of the first tx. Please correct me where I am wrong.

PS: I might do a test tx to see it myself. This is interesting for me.

The only legitimate benefit I can think of is to 'unstuck' a transaction.
If I initiate a transaction using a very low fee without setting the RBF option, my transaction is likely going to get stuck, (how long would depend on how clogged up the network is);
• Once a transaction is signed and broadcasted, it is validated by nodes and appears in the mempool, where it would then be picked up by miners and included in blocks for confirmations. A transaction can stay in the mempool for approximately 2 weeks before it is dropped if no miner takes it up.
• To avoid waiting this long the sender can initiate a double spend or use CPFP ~ Child Pays For Parent, to unstuck the transaction. So they send the exact same UTXO to another address and can then perform the initial transaction with a higher fee.

Double spend is a bit different from a typical rebroadcast. In double spend you're not rebroadcasting as a new transaction is created with a different output and a much higher fee.

It's not cancelling a transaction it's basically rebroadcasting a transaction. It's like redoing your homework when you did it incorrectly the first time.
This is why it is expected for us to wait until 1-2 confirmations to make sure that the transaction is valid and is broadcasted correctly on the blockchain.
And only after 6 confirmations we can conclude that the amount is transferred from his wallet to our wallet.
These are some basic things one should learn before making trading bitcoin.

This is the first time I've heard that someone can cancel the first transaction which fee less and be replaced with a second transaction that fee more. This is a valuable lesson I learned today if I wanted to shop online. Before fund enter the wallet, no transaction is secure.
I think it's a trap that anyone looking to sell something online should avoid. I hope there are no other victim with similar cases, and for the OP I hope you can make this a valuable experience in terms of buying and selling online. It's safer to use Escrow if you want to make a larger transaction.

Double spending mean cheating but the use of RBF is not really to cheat anyone its to avoid the transaction waiting time, if you made a transaction with lower fee earlier but now you really wants to make it in a hurry then you can simply use the high fee is your wallet supports RBF.When you are in the receiving end never confirm anything until it has one confrimation.

I don't think it was. It looks like a fairly standard double spend.

The sender had 0.10494256 BTC in one output on address 1CKnhZmHzj45xdvvsAf3DbLWfYSX53NVMs. This output already had 100+ confirmations.
He made an initial transaction to OP with TXID 2f362caac5d3fa3a1cc586f5bdbb36bcfe6446cfc112eb1cb097d9669688204a, which spent that output with a fee of 1 sat/vbyte.
He then made a second transaction with TXID 31c444900939113ad1c57277fc2904b20f77e57f76f95eee45ec119e72a6342c, which spen the same output to a different address (presumably his own) with a fee of 20.2 sats/vbyte.

It's actually the Replace by fee exploit that is used to carry out such a type of double-spending. Minus their unconfirmed transactions being RBF enabled, the cheat wouldn't have been able to rebroadcast a new transaction with higher fees. Just like anything else, there are always pros and cons. You have just got to be smart to avoid getting scammed 

There's no benefit of double-spending unless you want to cheat and scam people. That's why people should always make this a practice to wait at least 1 confirmation before you consider the transaction valid. Exchanges accept a transaction/deposit at least 3-6 confirmations before it reflects on the user's account.

It was a replace by fee and he has done it with the first transaction which was to the address A in my example. But since the other transaction which gone from address A and the input of A which is the output of first transaction was changed hence the tx that was to you was dropped.

The idea is a miner needs to pick up the transaction.

Thanks so much guys. really do not know Double Spend can do this. but really such feature does not make good to me.
replace by fee feature is Ok and helps when you want to accelerate confirmation. this double spend..whats the benefit ? only good for cheating or ?

It does but it needs at least 1 confirmation. But here again one can also reverse the coin after a confirmation but it will cost you so much power and resources that if this is not huge amount of money then it is not worth it. Once a transaction gets 6 confirmation then you are looking at million dollar expense to reverse the transaction which is does not simply make sense to spend.

For small amount it is advisable to wait for at least one confirmation and for big amount waiting for 6 confirmation is safe.

If I'm not mistaken, this is a double-spend transaction that was performed in a very simple way. Customer is first sent the transaction with very low fee (1.004 sat/B), and after he receives file he generated another transaction with the same funds, but this time with a much higher fee (20.191 sat/B) -> https://www.blockchain.com/btc/address/1CKnhZmHzj45xdvvsAf3DbLWfYSX53NVMs

This is a lesson that only cost $100, I hope this is the first and last time the OP will send someone something without getting at least 1 confirmation.

That’s amazing way to cancel it however I did not know this can be done with the bitcoin chain as well ?
I mean I have done this in case of Ethereum transaction but never with bitcoin.

What is the exact principle behind this technique? Isn’t the transaction once broadcasted is captured with the nodes and it permanently sits there?

You should have wait for at least 1 confirmation unless you trust the guy. This is what happened in my guess:

- The guy sent coins to an address A which he owns and the fees were less of course
- He then sent the coins from the address A, and the coins of the address A (input)were not confirmed yet.
- He then gone back to the first transaction and rebroadcast the first transaction with a higher fee. And in rebroadcasting process, the tx you had with address A gone dropped.

hello everyone, Good evening

sorry to bother you about this issue i got from a customer. i sold a product to him for $100
i gave him wallet and he sent btc $100 and paste me txid which i saw the payment in my wallet ( Unconfirmed )

surprisingly, this guy logoff the chat and i wonder why he left so hurriedly just after i gave him the passwords to the achieved file.

i had to recheck if the payment has gotten any confirmation but surprisingly this transaction stated its INVALID with a error message at the top of the page
rechecked my wallet and i did not see the transaction again. 

below is the txid of the transaction, you can see the error message there.

https://www.blockchain.com/btc/tx/2f362caac5d3fa3a1cc586f5bdbb36bcfe6446cfc112eb1cb097d9669688204a

my wallet:  34Y9ZwTsT3H9zcnffirc2NM4XMkNmaLws6

Please. how is this possible. i really want to know this to avoid another of this.

chat screenshot
https://i.imgur.com/GLy3rhD.png