Is FullRBF allowing double spend?

[albert0bsd]

Based on my experience, yes.

Here is the history, in my telegram group some users were talking about the RBF flag and how this allow you many things from bump the fee to increment the priority of your transaction, up to change the destination address and amounts, even return the balance minus fee to the source address or some other address under you control.

That is some OK in the most of the cases, but some user reach me privately to show me that is not necessary to have the RFB flag enable in a TX to be replaced or modified, this is a FullRBF

This user send me some dust amount to my address and some of his addresses. The original TX doesn’t have the RFB flag.

After some days of the TX waiting in mempool, he do a FullRBF twice, first of it was changing the destination address to another address and 8 minutes later a second FullRBF changing the destination once again to my address.

Images

Original TX


First FullRFB


Second FullRFB


Final TXID: 942a454340c5115d769a16aad85b85a19875bb2f5e544de1b776570b76294f62

If he hadn't performed that second FullRBF the dust amount would have ended in one of his addresses.

This makes me think about the post of satoshi about the vending machine.

What if a dishonest user sends a TX with low Fee (1 Sat/vB) to a vending machine, the machine releases the product, and after some time that user performs a FullRBF changing the destination address to one of his own addresses?

I like the FullRBF feature to bump the fee. But i also see it as some kind of loophole for those some scenarios

So the question about this is: what do you think about FullRBF, does it allow double spend or not?

[1714285963]

1714285963

[1714285963]

1714285963

[1714285963]

1714285963

[1714285963]

1714285963

[1714285963]

1714285963

[1714285963]

1714285963

[Zaguru12]

If I get you right the sender did an RBF to another address, that’s something i don’t think an RBF can do, because you can’t change the destination address using RBF. It can only be accomplished with the CPFP method.

With the images from picture the transaction wasn’t RBF enabled and I doubt after making that transaction you can do that. Once a transaction is initiated without Full RBF enabled you wait for the confirmation or the transaction been dropped.

Also about the issue giving out the product after making transaction with the venting machine I think that has been fixed by you/seller waiting for at least a single confirmation or for at most 6 confirmation. With six confirmation the transaction is agreed to be save already

[BlackHatCoiner]

First of all, I'd kindly ask you to lower the height of your images as they take too much space.

What if a dishonest user sends a TX with low Fee (1 Sat/vB) to a vending machine, the machine releases the product, and after some time that user performs a FullRBF changing the destination address to one of his own addresses?

The vending machine owner is at a loss, indeed. That's why they shouldn't be releasing the product under a 0-conf transaction. That was less likely to occur before Full-RBF, with RBF disabled, as it'd require to convince a mining pool operator to double-spend your transaction, but currently it's just really trivial. But, that's the normal state of the network; no confirmation, means can be double-spent.

Now the vending machine owner has two options;

• either make the user wait for 1 confirmation (nobody's going to wait 10 minutes for a coca cola, I know), or:
• adapt with second layers, like lightning.

[Ruttoshi]

what do you think about FullRBF, does it allow double spend or not?

Yea it prevents double spend. If a transaction is unconfirmed yet,you can use Replace By Fee (RBF) to change the transaction to a new address but you must bump the transaction fee to be higher than the previous one,so that miners will quickly add it to the blockchain.

Electrum wallet and blue wallet are example of walkers with RBF.

[stompix]

What if a dishonest user sends a TX with low Fee (1 Sat/vB) to a vending machine, the machine releases the product, and after some time that user performs a FullRBF changing the destination address to one of his own addresses?

If we're talking about soda can vending machines, the guy paid 2,974 sat / $0.77 plus he's ending with another output in in his wallet for which he is going to pay extra so if we take the value of a can of soda which is 80 cents here the last time I checked, you're wasting money !!!!
If you aim for anything higher than vending machines you're simply going to get yourself in trouble, maybe in poorer countries it works but in others, there is surveillance everywhere, do you really want to get in trouble for a few $? The correct answer is: No! And nobody is going to send you merchandise worth thousands of dollars with no confirmation.

Now the vending machine owner has two options;

• either make the user wait for 1 confirmation (nobody's going to wait 10 minutes for a coca cola, I know), or:
• adapt with second layers, like lightning.

Even before that, how many vending machines that accept direct payment in BTC (no third party cards or codes or LN)  are there?
Cause I have a feeling we're talking about an anti-tiger rock solution here!

[Z-tight]

Once a transaction is initiated without Full RBF enabled you wait for the confirmation or the transaction been dropped.  

For now most nodes still use opt-in RBF as default, but very soon more nodes will switch to full RBF and what that means is that you can bumb any unconfirmed tx even when you didn't opt-in to RBF when broadcasting the transaction.

because you can’t change the destination address using RBF. It can only be accomplished with the CPFP method.  

You can, you can spend the input to any address you want, but paying a higher fee for it, which will most likely get it confirmed faster than the initial transaction.

[Artemis3]

You didn't need RBF to double spend in the past, and "vending machines" or whatever online wait for like 3 or more confirmations before releasing anything because of this. Unless you want to put your trust in something like lightning...
So its not like removing RBF removes the double spend, its only a bit more complicated for normal users to unstuck their transactions thanks to blockchain spam, but not an issue for actual malicious use.
Changing RBF from opt in to always in, doesn't harm anything imo.

[o_e_l_e_o]

I opened this thread about Full RBF a year ago: https://bitcointalk.org/index.php?topic=5403730.0

So the question about this is: what do you think about FullRBF, does it allow double spend or not?

Any transaction which is not confirmed can be double spent. This has always been the case.

If I get you right the sender did an RBF to another address, that’s something i don’t think an RBF can do, because you can’t change the destination address using RBF.

Yes, you can. You can change the destination address or addresses, add addresses, remove addresses, change the amounts, change the fee, anything you like.

With the images from picture the transaction wasn’t RBF enabled and I doubt after making that transaction you can do that. Once a transaction is initiated without Full RBF enabled you wait for the confirmation or the transaction been dropped.

You don't "enable" full RBF for individual transactions. It is enabled for all transactions automatically by the nodes which support it.

That was less likely to occur before Full-RBF, with RBF disabled, as it'd require to convince a mining pool operator to double-spend your transaction, but currently it's just really trivial.

There were other possible attacks which did not rely on paying a miner to mine your double spend, such as the race attack.

[.gustafson]

You've hit on a real conundrum here. FullRBF's power is clear, but it's like giving a supercar to a teenager – it can be used responsibly or lead to chaos. That vending machine example is a head-scratcher. It's a reminder that technology's strength can also be its Achilles' heel. We're navigating the uncharted waters of crypto, and these discussions are vital to understanding its nuances.

[albert0bsd]

Seems that the “Vending machine” that satoshi idealize not longer exists on mainnet

So resuming

• The instant Vending machine is possible only with lightning network, in mainnet it need to wait
• On mainnet those vending machines are not instant and need to wait up to 3 confirmations of the TX.
• Without confirmations all UXTOs can be double spending with FullRBF feature. (This is not enabled by default, but seems that is getting widely adopted)

Thank you all for your replies and thoughts

First of all, I'd kindly ask you to lower the height of your images as they take too much space.

Let me change it, I used to use imgur and always used lower size images, but sadly that hosting is not longer working on bitcointalk.

[o_e_l_e_o]

On mainnet those vending machines are not instant and need to wait up to 3 confirmations of the TX.

3 confirmations is unnecessary for the amounts being spent at a vending machine. No one is going to attempt to reverse 3 blocks worth of block subsidy and fees for the price of a one dollar chocolate bar. One confirmation would be sufficient, but Lightning would be better.

Without confirmations all UXTOs can be double spending with FullRBF feature.

No. As I said above, without confirmation all UTXOs could always be double spent. Full RBF just standardizes the process.

Let me change it, I used to use imgur and always used lower size images, but sadly that hosting is not longer working on bitcointalk.

Just include a height or width parameter in the img code. For example:

Code:

[img width=800]https://www.talkimg.com/images/2023/09/03/mSaMD.jpeg[/img]

[BlackHatCoiner]

You've hit on a real conundrum here. FullRBF's power is clear, but it's like giving a supercar to a teenager – it can be used responsibly or lead to chaos.

How can Full RBF lead to chaos? 0-conf transactions can be double-spent, and that is true since 2009. This particular node policy will only standardize it. Nodes could have configured that out long before Full RBF, and I'm pretty sure some mining pools did pre-configure likewise.

Let me change it, I used to use imgur and always used lower size images, but sadly that hosting is not longer working on bitcointalk.

Consider using talkimg for uploading images on bitcointalk, as it's specifically created for that purpose.

[albert0bsd]

One confirmation would be sufficient, but Lightning would be better.

Thank you for the clarification.

Just include a height or width parameter in the img code. For example:

Code:

[img width=800]https://www.talkimg.com/images/2023/09/03/mSaMD.jpeg[/img]

Nice to know!

Consider using talkimg for uploading images on bitcointalk, as it's specifically created for that purpose.

Yes indeed i used talkimg for this images. Thanks again!

[franky1]

funniest part is people say double spending was possible since 2009.. yet there were no large scale complaints of zero-confirm back then.
people were aware of the risk but dampened their worry by only using it for small amounts

this is because old code knew that transactions relay around the network very quickly. and had policy to ("first see, first keep") reject any second spend attempts, thus mitigating many relay attack vectors. where the only main successes is to pushtx a second tx directly to a pool that subsequently bypasses standard policy of 'first seen' to add the second tx before the first tx is used in a block

however full RBF bypasses the "first seen. first keep" rule..

its done to force people not to accept risk/trust of using the mainnet for zero-confirms of any amount anymore, just so some capitalists can promote subnetworks as the go to service everyone should use.. yet doing zero-confirms on subnetworks are not to be trusted either due to MANY ways people can steal funds by their flaws(idiots call features)

[o_e_l_e_o]

funniest part is people say double spending was possible since 2009.. yet there were no large scale complaints of zero-confirm back then.

It's almost like there weren't any big bitcoin services back in 2009. The whole of 2009 only had 219 transaction which weren't coinbase transactions.

where the only main successes is to pushtx a second tx directly to a pool that subsequently bypasses standard policy of 'first seen' to add the second tx before the first tx is used in a block

No, it isn't. As I've already mentioned above, a race attack does not require cooperation from any pool.

its done to force people not to accept risk/trust of using the mainnet for zero-confirms of any amount anymore

You can still accept zero confirmation transactions if you personally want to do so. Doing so was never safe.

[franky1]

funniest part is people say double spending was possible since 2009.. yet there were no large scale complaints of zero-confirm back then.

It's almost like there weren't any big bitcoin services back in 2009. The whole of 2009 only had 219 transaction which weren't coinbase transactions.

where the only main successes is to pushtx a second tx directly to a pool that subsequently bypasses standard policy of 'first seen' to add the second tx before the first tx is used in a block

No, it isn't. As I've already mentioned above, a race attack does not require cooperation from any pool.

its done to force people not to accept risk/trust of using the mainnet for zero-confirms of any amount anymore

You can still accept zero confirmation transactions if you personally want to do so. Doing so was never safe.

PEOPLE SAID.. mainly the PEOPLE from your clan.. so before you try to poke that i mention 2009.. realise WHO said what about what first..

those people were trying to exaggerate the risk before RBF to sound like there is no difference and exagerate subtle hints that bitcoin was always broke and untrustable for certain things.. but before RBF there was more trust of zero confirm compared to post RBF times.. more users used to trust zero confirms back then, because it was not straight forward in just the node itself to cheat. its required pushtx knowledge and timing and and also the IP addresses of particular nodes to know where to relay and not. usually customising your node to achieve it, or use api access to other servers. and other needed things outside their own node to do it. but now that RBF is a feature. its now easier to double spend, just within someones own node without outside considerations.. . much much much easier.

again RBF has made it much more easier to double spend, it used to be safer. but now its not safe

[pooya87]

The big downside of Full-RBF is that it effectively made the risk assessment of received transactions harder, something that a service could perform before in order to give each transaction they received a "point" and if it were below a certain threshold they could accept the smaller risk and accept the tx without confirmation.

An example of such system to see was the one offered by the blockcypher explorer called Confidence Factor: https://www.blockcypher.com/dev/bitcoin/#confidence-factor

more users used to trust zero confirms back then, because it was not straight forward in just the node itself to cheat. its required pushtx knowledge and timing and and also the IP addresses of particular nodes to know where to relay and not.

Trusting unconfirmed transactions have always been discouraged in the Bitcoin community, but if we are talking about the early days like 2009 as in your previous comment, then it was a lot easier to perform double spend attacks for two reasons.
First was the smaller number of nodes in total that one could connect to and send a conflicting transaction to each and wait to get one confirmed.
And second was the fact that one could send out a transaction (the actual payment) to the network but mine the next block containing the double spend themselves since the difficulty was very low.

[o_e_l_e_o]

but before RBF there was more trust of zero confirm compared to post RBF times

Exactly. Trust. Not verification. Whatever happened to "Don't trust. Verify."? Accepting zero confirmation transactions has always been based on trusting the other party not to double spend the transaction.

again RBF has made it much more easier to double spend, it used to be safer. but now its not safe

It has only gone from unsafe to very unsafe. It was never safe.

And before you rant some more about certain "people" trying to change the protocol, let me just quote Satoshi on the subject:

As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation.  0/unconfirmed transactions are very much second class citizens.  At most, they are advice that something has been received, but counting them as balance or spending them is premature.

[franky1]

and now put that same mindset to your favoured subnetwork which are also zero confirm!!

by the way.. satoshis quote was related to something else. whereby people could not spend funds by rule unless it had a confirm. he made it into a rule.

but after satoshi left. code changed whereby zero confirm spending was allowed again. and they implemented relay policy about "first seen, first keep" meaning people could see and feel a bit more acceptable that small amounts would eventually confirm.. thats when the social PR campaign of 0 confirm candy 6 confirm mansion idea started spreading

but i do laugh with all the flaws of your favoured subnetwork that also uses zero confirm payments. you promote it as safer than bitcoin.. which is very much not true. your subnetwork has many ways to cheat

[citb0in]

We all know that this is not theoretically about the vending machine but about a potential real following practical case:

User Joe finds the private key of puzzle xx and empties the puzzle's account by performing a transaction to his own wallet (say for example with 30sat/vb). He now has to wait until at least one confirmation takes place before the coins arrive on his wallet. Now, dozens (maybe thousands) of pre-programmed bots are listening 24/7 on the Bitcoin network, waiting for just such a moment. The bots are triggered by the outgoing transaction of puzzle xx where coins are being spent , the pubkey of the transaction is revealed and is immediately chased through the prepared cracking machine to calculate the private key via Kangaroo. If the privkey was quickly and successfully found by user Mallory while the transaction of the actually successful puzzle hunter (=Joe) has not yet received a confirmation in the network, Mallory could generate a new transcation with RBF and enter 100sat/vb. The chances that the coins will reach Mallory's wallet first are high.

What Joe can do about it? Well, what do you think