Doubt about double spending

[Csmiami]

Technical question from a non-technical guy... Sorry if it comes out as something stupid, but I rather seek an answer to my ideas than putting them in a dark corner.

I was thinking about how some wallet providers or even individuals do sometimes use fees that are just "too low" to get fast confirmations. This may not be an issue when we are transacting between individuals, but it can be a pain in the ass in some cases. One of such cases, and the one that has led to this query, is the casino deposit feature.

No need to explain what a deposit is, but most, if not all casinos require at least X confirmations from the network in order to credit the deposit. Nothing wrong with that, since they cover themselves from a double-spending attack. However, in some situations, transactions get stuck and the player is left to wait (bad luck fella, use a higher fee next time) for a long time. The main reason this feature exists is to prevent double spends, as I have already mentioned, but I'd like to know if there is an alternative to it.

I know transactions with RBF can be double spent (or accelerated, call it however you like it most), but is there any other way to actually do this? CPFP is a kind of RBF, IIRC; so, if transactions that don't have RBF active can not be double spent, could hypothetically a casino run a node that is able to tell if a transaction has this activated, and in the event of it being negative, instantly credit the money with no confirmations required?

Sorry if the explanation got a bit messy, I can try re-explain it again if that's the case. Thanks in advance for taking the time to read this

[1714786659]

1714786659

[1714786659]

1714786659

[1714786659]

1714786659

[1714786659]

1714786659

[n0nce]

[...]
I know transactions with RBF can be double spent (or accelerated, call it however you like it most), but is there any other way to actually do this? CPFP is a kind of RBF, IIRC; so, if transactions that don't have RBF active can not be double spent, could hypothetically a casino run a node that is able to tell if a transaction has this activated, and in the event of it being negative, instantly credit the money with no confirmations required?

Oh no, please no Don't confuse RBF with double-spend attacks! That's totally not the same thing. Double spending is an attack scenario where you spend the same funds twice (like, to 2 different addresses). RBF just allows you to bump the fee to have the transaction be verified quicker.

Transactions without RBF are absolutely also able to be 'double spent', i.e. the double spending attack is just as well possible no matter if you have RBF on or not.

If you don't wait for the transaction to be mined in a block and a few blocks extra, the sender can publish a second transaction coming from the same utxo thus spending their funds twice and fooling you into giving them the according account balance.

Bitcoin Wiki explains RBF nicely.
Here about double spending attacks

[Csmiami]

---

Awesome, thanks! I had a feeling it couldn't be just that easy, or someone else would have already invented it first. Thanks again for the clarification. Although, don't most wallet softwares not allow you to double spend something unless it can be RBF?

PS: I do repeat the "non-technical guy" before anyone tries to mob me

[n0nce]

---

Awesome, thanks! I had a feeling it couldn't be just that easy, or someone else would have already invented it first. Thanks again for the clarification. Although, don't most wallet softwares not allow you to double spend something unless it can be RBF?

PS: I do repeat the "non-technical guy" before anyone tries to mob me

No problem! Yes, I'm pretty sure most implementations already mark funds from a sent transaction as kind of 'spent' and don't allow you to sign and submit another transaction that uses the same utxos as inputs again. But probably mostly to not confuse users. Quite sure you can do it with Bitcoin Core or manually even with a bit of custom code. After all, Bitcoin transactions are no rocket science

There are pages like https://hashraw.com/#broadcast where you can broadcast a properly constructed transaction if you aren't running Bitcoin Core. In Bitcoin Core, it can be done directly with the sendrawtransaction command.

Hey don't worry, we are all here to learn

[khaled0111]

No need to explain what a deposit is, but most, if not all casinos require at least X confirmations from the network in order to credit the deposit... but I'd like to know if there is an alternative to it.

Some crypto businesses do accept zero-confirmation transactions. But they take some precautions to make sure you won't be able to cancel the transaction and even if you do, it shouldn't cause them any financial damage. In case of casinos, for example, they will instantly credit your account only when the transaction is non-RBF. But as this doesn't completely guarantee that the transaction can't be replaced (or get dropped from the mempool), they will let you place bets but they will lock withdrawals till the transaction gets enough confirmations.

[hosseinimr93]

It's true that accepting an unconfirmed RBF transaction is much riskier than accepting an unconfirmed non-RBF transaction, but there is no guarantee that a non-RBF transaction will finally be confirmed.

CPFP is a kind of RBF, IIRC;

Both CPFP and RBF can be used when you want to accelerate a transaction. But in my opinion, it's not true to call CPFP a kind of RBF.

In CPFP, you spend the outputs of the unconfirmed transaction with a high fee and encourage miners to include both transactions in a same block. In this method, you don't make any change in the original transaction. CPFP must be done by the receiver. (It can be done by the sender if there's a change in the transaction)
In RBF, you replace the original transaction with a new one and make it invalid. RBF can be done only by the sender.

RBF just allows you to bump the fee to have the transaction be verified quicker.

RBF also allows you to change the inputs and outputs. A requirement is that the replacing transaction has to have at least 1 same input.

[pooya87]

Don't confuse RBF with double-spend! That's totally not the same thing. Double spending is an attack scenario where you spend the same funds twice (like, to 2 different addresses). RBF just allows you to bump the fee to have the transaction be verified quicker.

Actually RBF is like a sub-category of double spend.
Technically speaking when the same UTXO is spent in 2 different transactions, we call that a double spend. When you bump the fee of a transaction you are actually creating an entirely different transaction (it has to even be signed again) and the fact that the two transactions differ only in the output amount doesn't change that.

What RBF does is that it "reserves the right to double spend" the UTXOs in a tx marked by RBF for the signer but with certain restrictions, such as the increased fee has to be proportional to the tx size not any small amount.

[nc50lc]

Technical question from a non-technical guy... Sorry if it comes out as something stupid, but I rather seek an answer to my ideas than putting them in a dark corner.

You can read more about RBF here: bip-0125 - Opt-in Full Replace-by-Fee Signaling
The summary isn't too technical.

"Double-spend" is a badly used term IMO because only one will be included in a block, and Bitcoin can't be double-spent.
but based from it's common usage (able to spend the same input of an unconfirmed txn to a new transaction), then RBF indeed falls to that category.
Because the replacement (higher fee txn) is a new transaction that spent the same input(s) of the "bumped" txn.

No need to explain what a deposit is, but most, if not all casinos require at least X confirmations from the network in order to credit the deposit. Nothing wrong with that, since they cover themselves from a double-spending attack. However, in some situations, transactions get stuck and the player is left to wait (bad luck fella, use a higher fee next time) for a long time. The main reason this feature exists is to prevent double spends, as I have already mentioned, but I'd like to know if there is an alternative to it.

Alternative to?
Anyway, they can use CPFP, either the Casino to consolidate the unconfirmed deposits, but that's expensive if set to higher fee rate;
or the user if the transaction has a change - spend the change in his new txn but set a high fee rate.
Transactions rarely drop from the mempools anyways and they can re-broadcast, the consequence is usually just long waiting time to withdraw from the Casino.

CPFP is a kind of RBF, IIRC

Although both can speed-up transaction confirmation, those are totally different from each other.
"Child-Pays-For-Parent" is utilizing the miner's parent-child total transaction fee tracking (forgot what it's called)
by creating a child txn with high fee in order to prioritize the low-fee parent txn with it.

-snip- so, if transactions that don't have RBF active can not be double spent, could hypothetically a casino run a node that is able to tell if a transaction has this activated, and in the event of it being negative, instantly credit the money with no confirmations required?

It's basically a simple difference in nSequence that marks the transaction "replaceable", Casinos check that to safely implement their "zero-fee deposit" feature.
So if all of the transaction's inputs have FFFFFFFF as nSequence number, it means that it's not opted-in as replaceable.
If it has an unconfirmed parent(s), any of the parent transaction shouldn't be marked as replaceable as well.

[n0nce]

Don't confuse RBF with double-spend! That's totally not the same thing. Double spending is an attack scenario where you spend the same funds twice (like, to 2 different addresses). RBF just allows you to bump the fee to have the transaction be verified quicker.

Actually RBF is like a sub-category of double spend.
Technically speaking when the same UTXO is spent in 2 different transactions, we call that a double spend. When you bump the fee of a transaction you are actually creating an entirely different transaction (it has to even be signed again) and the fact that the two transactions differ only in the output amount doesn't change that.

What RBF does is that it "reserves the right to double spend" the UTXOs in a tx marked by RBF for the signer but with certain restrictions, such as the increased fee has to be proportional to the tx size not any small amount.

Okay, yes, I stand corrected! I wanted to clarify though that there is a difference between let's say 'allowed double-spend through RBF' and 'malicious double-spend'. As long as you wait for your confirmations, you're good, no matter if the sender used RBF or not.

The crux of the question, as I understood, was if a Hal Finney attack is possible if a transaction has RBF toggled off, to which the answer would be yes

By the way, very interesting, if you scroll down a bit there's a so-called vector76 attack, which is possible even though as a recipient you see 1 confirmation. So I would always wait for like 3 confirmations if I'm in a hurry and the amount is not large, but for anything else 6 confirmations.

You don't need to mine 2 blocks in a row.  Mining a single block is sufficient if the network resolves the fork the way you want, and it might be possible to set things up so that this is likely.

Let's say I observe the timing of when nodes are broadcasting transactions and how they are propagating through the network.  By watching for which nodes are earliest to broadcast transactions from my target, I manage to establish a direct connection to my target.

I use a similar method of watching block broadcasts to establish connections to most of the mining pools.

Now I create a transaction making a valid, large deposit into my target.  I do not broadcast this transaction but I add it to a block that I am attempting to mine.  I mine solo, just like normal, except that I have an extra non-broadcasted tx that I am including.

Eventually, I succeed in creating a valid block.  I do not broadcast it immediately, but instead I wait until someone else mines a block, and when that happens, I immediately broadcast my block to my target.  If my target sees my block before the other block, they will accept it, and my transaction will have one confirmation.  The block chain has forked, and my target (and possibly other nodes, if my target relays quickly enough) will believe that my block is the correct one, while other nodes will believe that the other fork is the correct one.

I immediately request a withdrawal, and my target generates a transaction sending the large amount of coins to an address I control.  I also double-spend some of the inputs, sending the coins to myself.  The part of the network that did not receive my block first (which hopefully is most of the miners) will accept this as valid and work to include it in the next block.

If my block eventually "wins" because enough miners saw my block first and added onto it first, then I have just made a deposit and withdrawal, and I lose nothing.

If my block eventually "loses", then the deposit is invalidated.  If the deposit tx was not one of the inputs to the withdrawal transaction, then the withdrawal is still valid.

[o_e_l_e_o]

If it has an unconfirmed parent(s), any of the parent transaction shouldn't be marked as replaceable as well.

You shouldn't really accept zero confirmations for any transaction which has any unconfirmed parents regardless of their RBF status, since transaction malleability would allow a miner to invalidate the child transaction without invalidating/double-spending the parent transaction(s) (unless all the unconfirmed parents only spend bech32 segwit inputs).

By the way, very interesting, if you scroll down a bit there's a so-called vector76 attack, which is possible even though as a recipient you see 1 confirmation. So I would always wait for like 3 confirmations if I'm in a hurry and the amount is not large, but for anything else 6 confirmations.

As noted on the wiki page, for this attack to be successful the attacker's block which contains their initial payment transaction would need to lose to the competing block at the same height, and therefore become stale. So if the attacker is trying to scam you for a value which is less than the block reward plus fees, then it makes no sense for them to perform this attack since they would make more money by just broadcasting their block and claiming the block reward. I'd still be happy to accept 1 confirmation for small values.

[ranochigo]

Using the RBF flag as the only metric to determine if a transaction has the potential to be replaced can be quite misleading. Point is, it is not difficult to include a different transaction from the transaction that you're seeing into a block, even if the transaction is still in the mempool and pays a sufficiently high fee. It is even easier if the miner has a good proportion of the hashrate such that they can still profit from an attack like this (Ghash.io). An RBF flag only determines how well propagated a competing transaction would be, if it were to be propagated before that transaction gets confirmed. It is unsafe for people to be accepting zero-conf transactions, even moreso in a climate with volatile fees.

IIRC, there was an incident for which someone leveraged on different policies between the pools for specific transactions to have a higher chance to be confirmed than others. There is also instances where different transactions were included with different forks, but none of which were malicious AFAIK. There is also selfish mining, which doesn't require quite near half of the network hashrate. The whole point with one-conf transactions is that it isn't worth the effort (or likely) for someone to defraud you as long as the transaction has a single confirmation. Confirmations are merely how difficult or expensive for someone to reverse your transactions.

tl;dr: Transaction finality is only guaranteed with confirmations. Any services that you've seen which accepts zero-conf transactions are likely to have done certain risk-reward analysis beforehand for them to implement it.

[BlackHatCoiner]

I think the term “double spending” is justifiably confusing for a non-technical person.

There are many ways one can construe it. Double spending could be understood as when you spend the same amount of money in two different addresses. Like you spent the same output twice. Another way to define double spending could be when you'd pay for a service and then reversed the transaction like it never happened. That is also considered double spending, because you could have bought it twice and removed one of the transactions which means you luxuriated the services twice, but only paid once; hence you double-spent your money.

In Bitcoin, you can't spend the same output or duplicate the amount of it by consensus. What you can do, though, is reverse a transaction if you succeed on acquiring the majority of the computational power that is offered.

So in Bitcoin it is currently almost infeasible to double spend money if they're at least 6 blocks deep.


The RBF feature doesn't double-spend your money in a bad way; you just want from the nodes to replace your old transaction with the new one when both are unconfirmed. What matters is that you can't cheat the ledger which contains the confirmed transactions. You should only consider received bitcoins the ones that are displayed in this ledger. In the mempool, all bets are off.

[nc50lc]

If it has an unconfirmed parent(s), any of the parent transaction shouldn't be marked as replaceable as well.

You shouldn't really accept zero confirmations for any transaction which has any unconfirmed parents regardless of their RBF status, since transaction malleability would allow a miner to invalidate the child transaction without invalidating/double-spending the parent transaction(s) (unless all the unconfirmed parents only spend bech32 segwit inputs).
-snip-

However there are Casinos that accept zero-confirmation deposits.
Since they are custodial, their primary protection against those who'll "cancel" their transaction is to prevent withdrawals of the funds/winnings until the deposit has enough confirmations.
Rest are the rules and requirements like non-RBF transactions to qualify to that feature, I don't know if they are disqualifying txns with unconfirmed parent(s).

[pooya87]

However there are Casinos that accept zero-confirmation deposits.
Since they are custodial, their primary protection against those who'll "cancel" their transaction is to prevent withdrawals of the funds/winnings until the deposit has enough confirmations.
Rest are the rules and requirements like non-RBF transactions to qualify to that feature, I don't know if they are disqualifying txns with unconfirmed parent(s).

Usually those accepting 0-confirmation transactions do a risk assessment for every transaction. This way they can reduce the risk of being scammed to a minimum. Some of the things to assess are:
- account age
- total successful amount deposited so far
- amount being deposited
- RBF status
- fee rate compared to other transactions in mempool
- state of UTXOs being spent (confirmed or not)
- having a good number of connections to as many nodes as possible and watching their mempool for competing transactions (ie. double spend attack)

[PrimeNumber7]

[...]
I know transactions with RBF can be double spent (or accelerated, call it however you like it most), but is there any other way to actually do this? CPFP is a kind of RBF, IIRC; so, if transactions that don't have RBF active can not be double spent, could hypothetically a casino run a node that is able to tell if a transaction has this activated, and in the event of it being negative, instantly credit the money with no confirmations required?

Oh no, please no Don't confuse RBF with double-spend attacks! That's totally not the same thing.

If I am not mistaken, there is no technical reason why a RBF transaction cannot be double-spent in a way that results in entirely different outputs than the original transaction. Most wallet implementations will not allow for this, so you will have to have some technical know-how in order to create this kind of double-spend transaction. AFAIK, there are ~zero businesses that accept 0-confirmation RBF transactions, so there is really not much incentive for anyone to create these types of malicious double-spends.

If it has an unconfirmed parent(s), any of the parent transaction shouldn't be marked as replaceable as well.

You shouldn't really accept zero confirmations for any transaction which has any unconfirmed parents regardless of their RBF status, since transaction malleability would allow a miner to invalidate the child transaction without invalidating/double-spending the parent transaction(s) (unless all the unconfirmed parents only spend bech32 segwit inputs).

The issue of transaction malleability was solved via BIP66. Further, as you note, SW parent transactions are not maileabile.

CPFP

CPFP is when the output of an unconfirmed transaction is spent in a transaction with a high enough fee such that the total fee in both transactions is high enough (when considering the total size) to get both transactions confirmed based on the current fee market. A casino could potentially offer to create a CPFP transaction for customer deposits as a "service" they charge for in order to get their deposit transactions confirmed more quickly.

Also, if a casino requires their customers to have accounts, they can extend "credit" to their long-standing customers who have a history of having their deposits confirm, and charge a "fee" for taking on the risk the deposit is double spent in a way that the casino does not receive the deposit.

[pooya87]

The issue of transaction malleability was solved via BIP66. Further, as you note, SW parent transactions are not maileabile.

BIP-66 is only one case of malleability fix involving the DER encoding used in ECDSA signatures. There are more cases most of which are outlined in BIP-62. The rest are considered non-standard transactions not invalid in legacy transactions. However they are ineffective in SegWit transactions (signature doesn't affect txid).
Exception may apply, eg. #9 can never be solved regardless of the transaction type.

[o_e_l_e_o]

The casinos which accept zero confirmation deposits have no risk of capital loss, and can only at most lose the deposit the customer placed. If the customer wins, they will not be allowed to withdraw until the deposit confirms. If the customer loses and double spends their deposit, then at most the casino will lose their deposit, and will then ban their account and IP address.

The issue of transaction malleability was solved via BIP66. Further, as you note, SW parent transactions are not maileabile.

It wasn't, as pooya has pointed out above. One of the primary goals behind segwit was to fix transaction malleability to allow the Lightning network to function properly. See here: https://bitcoincore.org/en/2016/01/26/segwit-benefits/. P2PKH and P2SH addresses are still vulnerable to such an attack, however.

[NotATether]

Some crypto businesses do accept zero-confirmation transactions. But they take some precautions to make sure you won't be able to cancel the transaction and even if you do, it shouldn't cause them any financial damage. In case of casinos, for example, they will instantly credit your account only when the transaction is non-RBF.

At least one casino (Sportsbet) lets you deposit RBF zero-confirm transactions (from my experience) so I'm curious to know how many casinos actually have this risk-assessment tech deployed, and whether they make it in-house or use one from a provider (and who?).

[hugeblack]

I don't know how the casinos work but when you make the deposit they update their database, the parties can accept payments that have zero confirmations (in the case of bitcoin) and then delay the withdrawals until they are sure the user made the deposit.

In Bitcoin, coin is either with the sender or the receiver, there are no third parties.

They can also grant this feature for VIP accounts or those that have completed certain conditions. In the end, if you trust the other party, waiting for confirmations is meaningless.


Note that the Bitcoin network is almost the only one that you can trust with one confirmation, some blockchains even need more than 16 confirmations for that.

[PrimeNumber7]

Thats fair enough.

The casinos which accept zero confirmation deposits have no risk of capital loss, and can only at most lose the deposit the customer placed. If the customer wins, they will not be allowed to withdraw until the deposit confirms. If the customer loses and double spends their deposit, then at most the casino will lose their deposit, and will then ban their account and IP address.

I think you know it is trivial to change your IP address. Unless the casino is requiring KYC prior to playing, it is also trivial to create a new account. You can use a mixer to hide blockchain evidence you have played at the casino previously.

If a gambler is allowed to gamble their deposit, and their deposit never confirms, if the gambler had a net losing bet, the house edge will effectively have been lowered, possibly to something below zero. A negative house edge is going to result in the casino losing money over the long run.

A deposit not confirming that was allowed to be gambled, will pretty much always mean the customer took some action to intentionally prevent the deposit from confirming. This will pretty much always be because the customer's balance is less than the deposit amount (they lost money gambling). A customer will generally have no reason to prevent a deposit from confirming if he is a net winner in his wagers.