Replace by fee cannot solve the double spend issue

[monsterer]

My post was deleted from this thread:

https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189

so I'm repeating it here:

Quote from: jedunnigan on July 06, 2013, 11:39:57 PM
....However we can make zero-confirmation transactions safe without complex trusted identity systems, ironically by making it easier to double-spend. If we implement replace-by-fee nodes will always forward the transaction with the highest overall fee (including parents) even if it would double-spend a previous transaction. At first glance this appears to make double-spending trivial and zero-confirmation transactions useless, but in fact it enables a powerful counter-measure to an attempted double-spend: the merchant who was ripped off creates a subsequent transaction sending 100% of the funds to mining fees. All replace-by-fee miners will mine that transaction, rather than the one sending the funds back to the fraudster, and there is nothing the fraudster can do about it other than hope they get lucky and some one mines their double-spend before they hear about the counter spend. The transaction can also be constructed such that the payee pays slightly more in advance, with the merchant refunding the extra amount once the transaction confirms, to ensure that a double-spend will result in a net loss for the fraudster.

By the time they have been ripped off, it can be too late for that to make any difference:

Consider an instant exchange such as shapeshift.io which processes transactions at 0 confirmations. Once they decide to accept a transaction at 0 confirms (based on some network confidence metric), they send funds in exchange for bitcoin on a different blockchain to the original sender of the transaction.

For them, replace by fee completely destroys their ability to work with 0 confirmation transactions because they cannot ever recover the funds from the other blockchain. If they counter double spent the incoming bitcoin transaction after they originally processed it, it makes no difference to the attacker at all - he still got his coins on the other blockchain.

edit: in fact, I fail to see how this can work, for example at a cafe, or restaurant?

[1715028202]

1715028202

[1715028202]

1715028202

[tl121]

My post was deleted from this thread:

https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189

so I'm repeating it here:

Quote from: jedunnigan on July 06, 2013, 11:39:57 PM
....However we can make zero-confirmation transactions safe without complex trusted identity systems, ironically by making it easier to double-spend. If we implement replace-by-fee nodes will always forward the transaction with the highest overall fee (including parents) even if it would double-spend a previous transaction. At first glance this appears to make double-spending trivial and zero-confirmation transactions useless, but in fact it enables a powerful counter-measure to an attempted double-spend: the merchant who was ripped off creates a subsequent transaction sending 100% of the funds to mining fees. All replace-by-fee miners will mine that transaction, rather than the one sending the funds back to the fraudster, and there is nothing the fraudster can do about it other than hope they get lucky and some one mines their double-spend before they hear about the counter spend. The transaction can also be constructed such that the payee pays slightly more in advance, with the merchant refunding the extra amount once the transaction confirms, to ensure that a double-spend will result in a net loss for the fraudster.

By the time they have been ripped off, it can be too late for that to make any difference:

Consider an instant exchange such as shapeshift.io which processes transactions at 0 confirmations. Once they decide to accept a transaction at 0 confirms (based on some network confidence metric), they send funds in exchange for bitcoin on a different blockchain to the original sender of the transaction.

For them, replace by fee completely destroys their ability to work with 0 confirmation transactions because they cannot ever recover the funds from the other blockchain. If they counter double spent the incoming bitcoin transaction after they originally processed it, it makes no difference to the attacker at all - he still got his coins on the other blockchain.

edit: in fact, I fail to see how this can work, for example at a cafe, or restaurant?

Cafes and restaurants don't enjoy 100% reliability of payments.  For example, a customer can simply walk out of the restaurant without paying in many places.   If a merchant is not technically competent in bitcoin, regardless of protocol features, he can always use a payment processor who for a small fee insures them against double spends.  Or they can just take the risk. Even credit card payments are not guaranteed because of credit card fraud and the possibility of charges being reversed.  These are business decisions.

[monsterer]

Cafes and restaurants don't enjoy 100% reliability of payments.  For example, a customer can simply walk out of the restaurant without paying in many places.   If a merchant is not technically competent in bitcoin, regardless of protocol features, he can always use a payment processor who for a small fee insures them against double spends.  Or they can just take the risk. Even credit card payments are not guaranteed because of credit card fraud and the possibility of charges being reversed.  These are business decisions.

And the owner of the exchange?

The point is, you cannot solve the double spending problem by using replace by fee against the attacker. It does not work if you take irreversible action at the time you accept the transaction.

[tonych]

Consider an instant exchange such as shapeshift.io which processes transactions at 0 confirmations. Once they decide to accept a transaction at 0 confirms (based on some network confidence metric), they send funds in exchange for bitcoin on a different blockchain to the original sender of the transaction.

For them, replace by fee completely destroys their ability to work with 0 confirmation transactions because they cannot ever recover the funds from the other blockchain. If they counter double spent the incoming bitcoin transaction after they originally processed it, it makes no difference to the attacker at all - he still got his coins on the other blockchain.

Well, they can try to recover the funds by double spending on the other blockchain. This will be a doublespend war.

There is another point why replace by fee is dangerous:

Quote from: jedunnigan on July 06, 2013, 11:39:57 PM
....However we can make zero-confirmation transactions safe without complex trusted identity systems, ironically by making it easier to double-spend. If we implement replace-by-fee nodes will always forward the transaction with the highest overall fee (including parents) even if it would double-spend a previous transaction. At first glance this appears to make double-spending trivial and zero-confirmation transactions useless, but in fact it enables a powerful counter-measure to an attempted double-spend: the merchant who was ripped off creates a subsequent transaction sending 100% of the funds to mining fees. All replace-by-fee miners will mine that transaction, rather than the one sending the funds back to the fraudster, and there is nothing the fraudster can do about it other than hope they get lucky and some one mines their double-spend before they hear about the counter spend. The transaction can also be constructed such that the payee pays slightly more in advance, with the merchant refunding the extra amount once the transaction confirms, to ensure that a double-spend will result in a net loss for the fraudster.

Miners will love this idea. This is a huge difference to what they receive today as mining fees. Perhaps miners would secretly initiate such double spends to provoke users to send the entire transaction amount to them.

[DumbFruit]

The point is, you cannot solve the double spending problem by using replace by fee against the attacker. It does not work if you take irreversible action at the time you accept the transaction.

If it solves the "double spending problem", then Proof of Work in general could be discarded, because the genius of Bitcoin was creating a decentralized payment system that solves the double spending problem.

We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power.

Also, Replace by Fee wasn't introduced in order to solve double spending problems. Replace by Fee is a way to swap out transactions in the mempool with higher fees in order to avoid transactions getting stuck in there, but when you permit that then it's trivial for a user to change the output of an unconfirmed transaction, making double spends extremely easy.²

What you're referring to is a method to mitigate double spending problems of zero confirmation transaction, while permitting Replace by Fee. What was proposed was having the merchant dump the entire transaction into fees if a double spend is detected. Miners would of course accept this transaction over the double spend because the reward is far greater.³ This doesn't guarantee that all zero confirmation transactions are completely reliable, it just heavily mitigates their chances of success. Meaning the primary concern about Replace by Fee is unwarranted.

While you're correct that immediate transactions with a merchant using zero confirmations is not risk free while Replace by Fee is implemented, that wasn't the point.

Quote from: jedunnigan on July 06, 2013, 11:39:57 PM
....However we can make zero-confirmation transactions safe without complex trusted identity systems, ironically by making it easier to double-spend. If we implement replace-by-fee nodes will always forward the transaction with the highest overall fee (including parents) even if it would double-spend a previous transaction. At first glance this appears to make double-spending trivial and zero-confirmation transactions useless, but in fact it enables a powerful counter-measure to an attempted double-spend: the merchant who was ripped off creates a subsequent transaction sending 100% of the funds to mining fees. All replace-by-fee miners will mine that transaction, rather than the one sending the funds back to the fraudster, and there is nothing the fraudster can do about it other than hope they get lucky and some one mines their double-spend before they hear about the counter spend. The transaction can also be constructed such that the payee pays slightly more in advance, with the merchant refunding the extra amount once the transaction confirms, to ensure that a double-spend will result in a net loss for the fraudster.

Miners will love this idea. This is a huge difference to what they receive today as mining fees. Perhaps miners would secretly initiate such double spends to provoke users to send the entire transaction amount to them.

While there is a moral hazard there, it seems rather insignificant to me. A cabal of miners getting together to secretly rip off vending machines and waitresses seems both unlikely and unsubstantial.
Bitcoin Core can't scale to that number of transactions anyway with today's technology.

I don't think 1MB is magic; it always exists relative to widely-deployed technology, sociology, and economics. But these factors aren't a simple function; the procedure I'd prefer would be something like this: if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero ...  Unfortunately, every indicator I can think of except fee totals has been going in the wrong direction almost monotonically along with the blockchain size increase since 2012 when we started hitting full blocks and responded by increasing the default soft target.  This is frustrating; from a clean slate analysis of network health I think my conclusion would be to _decrease_ the limit below the current 300k/txn/day level.

¹https://bitcoin.org/bitcoin.pdf
²https://bitcointalk.org/index.php?topic=179612.0
³https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189
⁴http://sourceforge.net/p/bitcoin/mailman/message/34090559/

[monsterer]

What you're referring to is a method to mitigate double spending problems of zero confirmation transaction, while permitting Replace by Fee. What was proposed was having the merchant dump the entire transaction into fees if a double spend is detected. Miners would of course accept this transaction over the double spend because the reward is far greater.³ This doesn't guarantee that all zero confirmation transactions are completely reliable, it just heavily mitigates their chances of success. Meaning the primary concern about Replace by Fee is unwarranted.

It doesn't work, though - If the merchant dumps the transaction into fees, everyone loses, including the merchant. The whole point of payment in any system is that it is taken in exchange for something. Once that exchange has taken place, the merchant has no recourse.

There is no acceptable length of time a merchant can wait to see if a double spend occurs in order to implement this counter measure - the only acceptable length of time is the time it takes a transaction to be included in a block.

[DumbFruit]

There is no acceptable length of time a merchant can wait to see if a double spend occurs in order to implement this counter measure - the only acceptable length of time is the time it takes a transaction to be included in a block.

You're sneaking in a definition here. "Acceptable" is a subjective term. The chance of a double spend succeeding is less likely the later you wait to broadcast the second transaction. I'm not completely sure what the odds are the longer one waits, but even if the attacker waits just 20 seconds (To try to sneak his double-spend in after the physical transaction takes place.) the original transaction would have propagated to more than 95% of the network, so I'm pretty sure that would mean their chance of success would be a corresponding sub 5%.¹ (Assuming transaction propagation is at least as fast as block propagation, and that the outliers have less than or equal to a proportional amount of hashpower.)
Then even if he waits, he doesn't have any guarantee that the merchant won't see the double spend before it  gets accepted into a block and dumping his sweet vending machine loot into transaction fees.
jdillon does claim that Replace by Fee can make double spends "safe", which is again undefined. So maybe he was being overly optimistic, I don't know.

¹http://bitcoin.stackexchange.com/questions/10821/how-long-does-it-take-to-propagate-a-newly-created-block-to-the-entire-bitcoin-n

[monsterer]

You're sneaking in a definition here. "Acceptable" is a subjective term. The chance of a double spend succeeding is less likely the later you wait to broadcast the second transaction.

As it stands, I agree. However, replace by fee will allow miners to include higher value, double spent transactions which totally breaks this assumption, since a miner could act out of greed and simply always chose the higher value transaction regardless of what the rest of the network thinks. The only thing standing in their way is propagation.