Is this double spending or not? | Bitcointalksearch.org

malevolent

legendary

Activity: 3472

Merit: 1722

Quote from: o_e_l_e_o on May 30, 2020, 01:06:42 AM

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

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: ranochigo on May 30, 2020, 01:19:25 AM

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.

o_e_l_e_o

legendary

Activity: 2268

Merit: 18711

Quote from: ranochigo on May 30, 2020, 01:19:25 AM

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.

Quote from: ranochigo on May 30, 2020, 01:19:25 AM

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.

Quote from: ranochigo on May 30, 2020, 01:19:25 AM

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.

ranochigo

legendary

Activity: 3038

Merit: 4418

Crypto Swap Exchange

Quote from: o_e_l_e_o on May 30, 2020, 01:06:42 AM

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.

Quote from: o_e_l_e_o on May 30, 2020, 01:06:42 AM

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.

Quote from: o_e_l_e_o on May 30, 2020, 01:06:42 AM

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

legendary

Activity: 2268

Merit: 18711

Quote from: AdolfinWolf on May 29, 2020, 07:06:43 AM

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.

BrewMaster

legendary

Activity: 2128

Merit: 1293

There is trouble abrewing

Quote from: hosseinimr93 on May 29, 2020, 10:25:14 AM

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.

AdolfinWolf

legendary

Activity: 1946

Merit: 1427

Quote from: hosseinimr93 on May 29, 2020, 10:25:14 AM

Quote from: AdolfinWolf on May 29, 2020, 07:06:43 AM

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?

hosseinimr93

legendary

Activity: 2380

Merit: 5213

Quote from: AdolfinWolf on May 29, 2020, 07:06:43 AM

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.

bob123

legendary

Activity: 1624

Merit: 2481

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.

AdolfinWolf

legendary

Activity: 1946

Merit: 1427

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.

Quote from: Zyger on May 29, 2020, 06:58:31 AM

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

Zyger

newbie

Activity: 7

Merit: 5

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?

Topic: Is this double spending or not? (Read 245 times)