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 SignalingThe 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.
-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.