Is this double spending or not?

[Zyger]

The blog linked below claims that what they're doing is called double spending, but I always thought that it was done a different way.

https://blog.blockonomics.co/how-to-double-spend-bitcoin-using-electrum-no-technical-sorcery-required-78799b07cad7

Does anyone know if that is actually known as double spending?

[1713896284]

1713896284

[1713896284]

1713896284

[AdolfinWolf]

I think he's doing a CPFP-like transaction where he increases the fee from the original parent, which drops the child upon confirmation?

So parent -> unconfirmed child -> merchant
then
(same) parent -> different unconfirmed child with higher fees ("normal" rbf) -> confirms

and then the first unconfirmed tx along with the child tx to the merchant will disappear. I guess this is a bit of a workaround because electrum doesn't really allow you to change the input addresses of an RBF (using their GUI at least)

Either way, i guess this can be classified as a doublespend, but it's not something that will work because A. merchants generally need 1 confirmations and B. merchants who accept 0-conf usually don't allow RBF transactions and the likes.

The blog linked below claims that what they're doing is called double spending, but I always thought that it was done a different way.

I think you're referring to spending already confirmed funds using a lot of hash power? That's also usually called a double spend attack or (51% attack)

What the above scenario describes is a race attack doublespend - https://en.bitcoin.it/wiki/Irreversible_Transactions#Race_attack

[bob123]

It depends on the definition on double spending.

Theoretically, it is. Because you are using the same input twice.

However, a double spending attack implies that the same input is sent to another address to deceive the recipient of the first transaction.
There are multiple ways to achieve that (e.g. race attack, sybil attack, ... ). Some of them require multiple nodes spread, others require to give up on a block reward, etc.. )

In reality, double spending attacks are not feasible since merchants wait for at least one confirmation. 0-conf transactions are not to be trusted.

[hosseinimr93]

So parent -> unconfirmed child -> merchant
then
(same) parent -> different unconfirmed child with higher fees ("normal" rbf) -> confirms

For removing the transaction from the child to the merchant (second transaction), there is no need to send from the parent to the different child.
If you only bump the fee of the first transaction (from parent to child), the hash of the first transaction will change and the second transaction will disappear.  

[AdolfinWolf]

So parent -> unconfirmed child -> merchant
then
(same) parent -> different unconfirmed child with higher fees ("normal" rbf) -> confirms

For removing the transaction from the child to the merchant (second transaction), there is no need to send from the parent to the different child.
If you only bump the fee of the first transaction (from parent to child), the hash of the first transaction will change and the second transaction will disappear.  

That was exactly my point since Electrum doesn't allow you to change the address using RBF (or for any flag). (from their GUI at least, AFAIAA.), and probably the author's point as well?

[BrewMaster]

If you only bump the fee of the first transaction (from parent to child), the hash of the first transaction will change and the second transaction will disappear. 

that is the definition of a "different transaction" and RBF is categorized under the same name, you can even technically call it double spend. it doesn't matter if the input(s) and output(s) of the transaction is the same. as long as the transaction hash is different (even if values are the same and signature changes like using a different k) it still is going to be a different transaction.

the only difference between RBF double spend and other forms is that nodes are more accepting of this type.

[o_e_l_e_o]

and B. merchants who accept 0-conf usually don't allow RBF transactions and the likes.

Would the arrangement described in OP's link be flagged up to the merchant as RBF, though? Only the first transaction, from wallet 1 to wallet 2, needs to have RBF enabled. The second transaction, form wallet 2 to merchant, does not need to be RBF since it will disappear altogether after the original transaction is replaced.

Which services even still accept zero confirmation transactions? Is their software "smart" enough to look back and see an RBF enabled transaction somewhere in a chain of unconfirmed transactions? To be fair, even if all the transactions in the chain are not RBF enabled, it is still unsafe to accept them due to transaction malleability - the hash of a parent transaction could be changed after being broadcast but before being mined, rendering all subsequent transactions invalid.

[ranochigo]

Which services even still accept zero confirmation transactions?

I know Bitpay used to have a zero confirmation transaction system. They do a risk analysis of your transaction and would require the user to wait if it's too high for the merchant. IIRC, some POS system does this also.

Is their software "smart" enough to look back and see an RBF enabled transaction somewhere in a chain of unconfirmed transactions?

Actually, I find that most of them do not accept transactions with an unconfirmed parent; the risk is too high, RBF enabled or not.

To be fair, even if all the transactions in the chain are not RBF enabled, it is still unsafe to accept them due to transaction malleability - the hash of a parent transaction could be changed after being broadcast but before being mined, rendering all subsequent transactions invalid.

As long as the propagation of a non-RBF transaction is good, then I don't see a huge risk of it encountering this scenario. If it's well propagated, most of the nodes won't accept it anyways, rendering the attack useless. BIP66 helped to fixed this issue largely but I'm not sure how easy is it to execute such an attack right now.

Segwit does help with this attack significantly and that is a point to consider.

[o_e_l_e_o]

Actually, I find that most of them do not accept transactions with an unconfirmed parent; the risk is too high, RBF enabled or not.

Yeah, figures.

As long as the propagation of a non-RBF transaction is good, then I don't see a huge risk of it encountering this scenario. If it's well propagated, most of the nodes won't accept it anyways, rendering the attack useless.

Using transaction malleability to change a transaction hash isn't a case of broadcasting and propagating a new transaction (as is the case of using RBF or performing a "classical" double spend). It's a case of the miner who is mining the block the transaction is contained in altering the transaction hash between the transaction being propagated to the network and the transaction being included in the block. Other nodes don't need to accept the altered transaction in their mempool, because by the time they see it has been altered, it is already included in a block. The attack is obviously unlikely, as it depends on the attacker being able to mine the transaction in question.

Segwit does help with this attack significantly and that is a point to consider.

Yes, but only for SegWit transactions. SegWit does nothing to fix transaction malleability for Legacy inputs.

[LoyceV]

I know Bitpay used to have a zero confirmation transaction system. They do a risk analysis of your transaction and would require the user to wait if it's too high for the merchant.

For my last 2 payments, Bitpay gave me the standard message about the fee being too low ("this is a problem of your wallet"), even though I used the maximum recommended fee from my wallet and both transactions confirmed in the next block. So it looks like they don't accept it anymore, which is unfortunate on time-sensitive orders.

As for OP's scenario: accepting a zero-confirmation transaction is a risk, accepting a transaction with unconfirmed parents is just bad practice. Unless you trust the sender, in that case I wouldn't mind receiving a transaction with low-fee unconfirmed parents.

[malevolent]

Which services even still accept zero confirmation transactions? Is their software "smart" enough to look back and see an RBF enabled transaction somewhere in a chain of unconfirmed transactions? To be fair, even if all the transactions in the chain are not RBF enabled, it is still unsafe to accept them due to transaction malleability - the hash of a parent transaction could be changed after being broadcast but before being mined, rendering all subsequent transactions invalid.

Bustabit and bustadice are probably the most known services still accepting 0-confirmation transactions (for a 1% fee), but from what I've seen it's essentially non-gameable unless someone is a large enough miner, but in that case disallowing of the pre-crediting of 0-confirmation transactions above a certain threshold should suffice.

I also know of two local places selling phone top-up codes which accept 0-conf transactions (they're even selling at a discount).