Post
Topic
Board Development & Technical Discussion
Re: Doubt about double spending
by
nc50lc
on 29/09/2021, 04:02:40 UTC
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 because only one will be included in a block
but based from it's common usage (able to spend the same input 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, the consequence is usually just long waiting time to withdraw from the Casino.

Quote from: Csmiami
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 by creating a child txn with high fee rate 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 the transaction has at least one FFFFFFFF as nSequence number after each input, 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.