Topic: How is this possible ? A Recent transaction suddenly becomes invalid (Read 745 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