Bitcoin Forum

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

Oh no, please no :D 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 (https://en.bitcoin.it/wiki/Replace_by_fee) explains RBF nicely.
Here about double spending attacks (https://en.bitcoin.it/wiki/Irreversible_Transactions#Finney_attack) :)

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 ;D

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 (https://developer.bitcoin.org/reference/rpc/sendrawtransaction.html) command.

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

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.

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.


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 also allows you to change the inputs and outputs. A requirement is that the replacing transaction has to have at least 1 same input.

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.

You can read more about RBF here: bip-0125 - Opt-in Full Replace-by-Fee Signaling (https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#Summary)
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.

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.

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.

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.

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 (https://en.bitcoin.it/wiki/Irreversible_Transactions#Finney_attack) is possible if a transaction has RBF toggled off, to which the answer would be yes ;D

By the way, very interesting, if you scroll down a bit there's a so-called vector76 attack (https://en.bitcoin.it/wiki/Irreversible_Transactions#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 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).

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.

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.

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.

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)

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.

The issue of transaction malleability was solved via BIP66 (https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki). Further, as you note, SW parent transactions are not maileabile.

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.

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 (https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki). 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.

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.

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.

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?).

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.

Thats fair enough.

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.

And if enough people do this to effectively lower the house edge, then the casino can just stop accepting zero confirmation deposits. The fact that a lot of casinos still accept zero confirmation deposits is evidence that very few people try to scam in this manner.

I fail to see how the house edge get reduced, even if it was not the topic here.

HE is only a %, and no matter what happens only the casino can change it. If a user deposit gets credited with 0 confirmation, lost and then double spent; the casino has at most only lost virtual credit, and some electricity/resources. They will stop earning those $$ from the deposit, but they will not lose money

If the casino allows you to receive the virtual credits before your transaction becomes confirmed, it is possible to cheat the system and end up with more money than you had before.

If they sent you their virtual credits before you officially transacted with them, you could play bunch of games, double them and then withdraw your funds before the first transaction's confirmation. Once their withdrawal transaction had at least 1 confirmation, you could double spend the first one.

It's all about the casino's terms of use. It should not allow you to withdraw anything as long as there are unconfirmed transactions related with you.

Assume that 10 people have deposited bitcoin into a casino. All deposits have been credited before confirmation.
All 10 people start to gamble after their deposit were credited. 5 of them lose and 5 of them win.
The losers double-spend the UTXOs deposited into the casino. The winners wait for their transaction to be confirmed and withdraw all their balance.
This is how the casino lose money.

It will still not lose, since it'd be as if the double spent ones had never happened. They do stop winning, but never lose

The casino will lose money in the long term.
In any casino, some people win and some people lose. The casino get money from losers and give it to winners.
If a significant number of losers cheat the casino with double-spending, the money that casino must pay to winners will be bigger than the money they get from losers and the casino lose money.

Assuming all losers cheat the casino with invalidating their deposits, it would be like that all gamblers win money and there is no loser.

Which casinos accept zero confirmation deposits today? I remember reading about a Russian scammer from several years ago that did a number of things to trick casinos into accepting his unconfirmed transaction, would make a single high probability bet, would see that his deposit transaction confirms if the bet wins, and double spends the deposit transaction if his bet loses. IIRC, at one point he used non-standard transactions that miners would not confirm by default but was able to get miners to confirm by his request, and at another point would use a chain of unconfirmed transactions, whose total fee was too low for miners to confirm under normal circumstances, but was able to get one to confirm his transactions upon his request.

Say, for example, a gambler deposits coin to a casino, places a bet that has a 95% chance of winning. If he wins, he receives 104.21% of his bet, allows his transaction to confirm, and withdraws his entire balance. He repeats this process an additional 18 times while placing the same bet amount each time. He has received a total of 79.99% of his bet amount from the casino, plus his original bet amount. On the 20th time the gambler does this procedure, the casino informs the gambler that he lost his bet, so the gambler double spends his deposit transaction. The casino has paid out ~80% of what the gambler bet on a bet that wins 95% of the time. The casino should have won the 20th bet but did not actually receive the coin from that bet. If the casino were to sum the 20 bets the player made, it expected to receive 20% of the player's bet amount, but instead paid out a total of 80% of the player's bet amount, while the player won the expected number of bets.

To put the above in more technical terms, when a casino sets the HE at, say 1%, it will set the odds and payout so that the EV of each bet a player makes is 1% of the bet amount. In order for each bet to have this EV value, each bet placed must involve value being transferred to the winning party according to the odds and payout multiplier.

Besides waiting for confirmations to assure that the casino's don't get burned by double spends, could actually be argued to be a good thing, because it somewhat protects against users falling prey to their gambling addictions due to grace period created by waiting for those confirmations, since most gamblers will act upon impulse, and end up spending more due to being in the heat of the moment.

At the moment, double spend attacks are somewhat rare due to the fact that most companies or people accepting Bitcoin regularly wait for the confirmations, however if this wasn't the case, and more people were willing to accept Bitcoin without waiting for confirmations, double spend attacks would become more frequent. I don't see a near future where users won't wait for confirmations.

Really? I don't know how Casinos actually work but losing profit is actually a loss, value isn't being created out of thin air.

Replace the Casino example with an exchange.

Bitcoin price = $1000

I deposit 1 BTC, the market crashes, and I sell it for 100 USD right before the market shoots back to $1000, I then go and double-pend that 1 BTC, the exchange will freeze that remaining $100 but that does not solve their problem, the person who bought my 1 BTC will want to withdraw it, in this case, the exchange lost 0.9BTC which they need to pay to whoever the person that bought my "imaginary" 1 BTC which was never actually confirmed in the exchange's wallet.

Also for a Casino, the double-spent amount is a loss they have to bear, the inner working of any casino or any organization for that matter does not matter, when someone double-spends something, someone else loses it, unless that someone lives in a vacuum.

I don't think that example is actually a good one. Exchanges need at least 2 people in order to do trades, whereas this particular case we've been discussing (which now brings up the question of whether this should be continued in gambling discussion) only involves one person.

I may be wrong about this, but I still see making a double spending and not doing a deposit as the exact same thing. Does it affect the overall casino economy? Well, that's for sure; but not the point here...

It only involves one person if one person is playing against himself, in the Casino, as far as I know, you are either playing against other gamblers or the dealer of the Casino, if you are playing against other people and the Casino is only collecting fees, then the Casino is responsible for guaranteeing payment to those who win. So if someone loses and double-spend that money, the Casino will have to cover that loss.

In the event of playing directly against the dealer, the Casino is actually the other person, the dealer is counting on the odds which favor them by a small percentage which depends on the exact game.

If 100 people play an online game on which the Casino has an edge of 1%, each with 1 BTC, on average 50.5 people will lose, 49.5 will win, the Casino will make 1 BTC, if a single person double-spends a losing game the odds shift against the Casino and they are guaranteed a loss, the loss will be in their trial balance, no matter how you look at it, it is a direct loss.



Only if the person did not play any games using that double-spent amount, the moment they do, they have already created an impact on the win/loss ratio of the Casino.

Talking from developing an exchange side, 3 or greater is considered secure, but if the user did deposit previously on few occasions with no issues then that can be dropped to 2 confirmations and later after certain deposits number it can be dropped to 1 network confirmation. But with Casinos not sure what they have specified in their codes. Also adding to that in what am working on I have specified a double spend check as well on the address where the deposit is coming from, there are many checks you can put in code to make sure before crediting the users in DB but definitely at least 1 confirmation is required.

A bad 0 confirmations scenario is this:

Alice deposits 1 BTC into a casino, gets immediately credited for the balance in DB, plays some casino online games at that platform with Bob. Alice loses and bob wins. Platform never receives confirmation on Alice’s tx. The platform is forced now to pay Bob for the win from their own pocket instead of Alice’s funds. So I doubt Casino’s can maintain operation with that kind of strategy, sustainability is at risk here in this business model.

Requiring a certain KYC level would probably be more ideal, if they are an exchange.
Addresses are not linked to identity and each address should ideally only be used once. Implementing a check on the addresses themselves wouldn't really be effective. Double spends are not recorded on the blockchain and many a times, they are a result of poor propagation, for which your nodes may or may not see the double spend at all.

I agree with you but KYC can be bypassed with fake documents.. am trying to base those checks more on the casino scenario. In regards to addresses not linked to identity I think you misunderstood my point, Alice has an account at platform (A). Alice uses another address (B) with balance to deposit into the platform receive address (C) generated specifically for Alice’s account. Address (B) can be checked for double spend risk, some tx explorers provide that.

Here from Blockcypher website:

“ Zero Confirmations and Double Spending
To help you deal with zero confirmation (aka unconfirmed) transactions and the risk of double spending, we provide 2 additional transaction properties:

receive_count: the number of nodes in the bitcoin network we've received that transaction from so far, indicates how many nodes, at the minimum, accepted this transaction.
confidence: the percentage chance (between 0 and 1) that a transaction will make it into a block over time, which accounts for double-spend or transaction loss. Note that it doesn't indicate how fast the confirmation will happen.
preference: level of preference miners will have to include this transaction in their block, a high preference means the transaction is very likely to be confirmed in the next block, a low preference means it's likely to take several blocks (>6).
The confidence is calculated based on elapsed time as well as the receive count and is based on several public research results. As BlockCypher pools resources for many users, we're always connected to a statistically significant number of nodes on the network (and offer connections in return). While maintaining those connections, we can also assess whether a given node has received a particular transaction. By monitoring the propagation of transactions across the network, we can calculate its probability to be the "winning" transaction at any given point in time, if a double-spend was attempted.

In addition, 2 other properties indicate when a double-spend has been detected:

double_spend: a boolean indicating whether this transaction is a double spend.
double_spend_tx: the hash of the other transaction involved in the double spend attempt.”

That is correct, but having any identity is better than relying on addresses that can be generated on the fly with no links to anyone whatsoever. It provides a reasonable deterrence against fraud.
The double spend prediction can determine the ease of double spending, as those are the factors that determines if miners are likely to confirm the transaction or not. It doesn't provide an absolute prevention of double spends, as there are many other possible ways to execute one without triggering the heuristics. They are practically useless if the adversary is well-versed in the subject and have a reasonable amount of resources; for example as blockcypher cannot possibly predict the preference of miners, it doesn't provide an accurate depiction of the types of transactions that miners would prefer.

Another scenario I can imagine would be if the mempool surges suddenly, which has actually happened ever so often, certain transactions can get evicted and it makes double spending them quite trivial. Sure, it is something that we've relied on in the past but it doesn't really apply anymore. Casinos or merchants are less willing to suffer losses due to the occasional double spending, especially with something like LN in play. The problem with this is that, we have to assume that the transaction doesn't have opt-in RBF enabled, which isn't great for the user; their transaction can get stuck during bouts of high fees. I would rather users wait for a confirmation than having them to wait for days to get their transaction confirmed.

This is the risk assessment (https://bitcointalk.org/index.php?topic=5363009.msg58060380#msg58060380) that I talked about, although it is best if businesses run their own node and implement their own assessment system rather than relying on a third party.

I'm very surprised that the gambling sites haven't yet widely implemented Lightning Network. It solves the two problems that are being talked about here.
- The casino doesn't have to worry about double spends anymore
- They can credit user's account right away without having to wait for confirmation, do risk assessment, etc.
- The user doesn't have to wait for confirmation and can gamble faster (better for the casino if they do it fast and lose more money)
- The user also doesn't have to leave their coins with a third party (their account balance) they can only deposit what they want to gamble and withdraw any extra funds right away with very low fee. All with "lightning" speed.

The biggest issue with LN and gambling that I see right now is that the amounts that can be transacted aren't huge. Many channels just don't yet have the capacity to allow for $1,000 deposits or larger, even though payments can and are split up and sent via multiple routes. I already had issues sending funds from one wallet to another that were much smaller.
The casino could solve this though by creating a very well connected node that has big channels towards especially wallet App providers like Breez, BlueWallet and similar, which is what most newcomers usually use.

Maybe that's why. If casinos charge a sufficiently high withdrawal fee, then it incentivizes people not withdraw smaller amounts, but rather to leave them on the platform until they have a larger amount to withdraw. Any coins which are already on a platform are far easier to impulsively gamble with, and therefore generate more profit for the casino. This will be especially true if someone is now aiming for some target number to make their withdrawal amount sufficiently large enough to justify the withdrawal fee.