No discussion of Peter Todd's RBF? (Replace by Fee)

[rogerver]

I didn't see a thread discussing this, so I thought I should start one.
It seems like a VERY big change to the way zero confirmation transactions are handled.

[coinableS]

I'm seeing a lot of personal attacks and not enough technical responses.

This code has been reviewed and approved by many.

https://github.com/bitcoin/bitcoin/pull/6871

Anyone relying on first-seen mempool behavior should be checking all unconfirmed ancestors anyway; doing otherwise is hopelessly insecure.

[arnoudk]

I have not examined this proposal in enough detail. So I cannot really make an informed comment on this.

It does sound dangerous and my gut feeling is that this increases the risk of fraud.

I don't think the scorched earth theory that is supposed to prevent double spending is going to work. The merchant would lose out and will simply not accept bitcoin again. Only bitcoin loses here.

Normal transactions would have to be replaced by micropayment channels on top of bitcoin.

Or merchants would collaborate with miners to process transactions like the BTCC priority service.

That would force merchants to use payment processors.

So I will not be voting for this change with my (admittedly limited) mining power until I am convinced it is a step in the right direction.

[DOGed]

My biggest concern about this is that it will make double spending much easier then it is now. As it stands now, if you attempt to broadcast a conflicting transaction that has already been propagated throughout the network then the conflicting transaction will be rejected by the nodes and the miners will never see this double spend attempt transaction.

To protect against double spends on 0/unconfirmed transactions, merchants can invest in a number of nodes that are geographically diverse that monitor for double spend attempts, and if one is discovered, then the merchant can wait for one confirmation before accepting the transaction.

Additionally, most merchants that are accepting 0/unconfirmed transactions are in a situation so that once they give whatever they are selling to their customer, they cannot take back.

With RBF, the risk to merchants is that they receive a 0/unconfirmed transaction, they listen to the network for double spend attempts, they find none, they irreversibly give the product to the customer, then the customer broadcasts a conflicting transaction with a higher tx fee. This would most likely mean the end of merchants accepting 0/unconfirmed transactions, and potentially will prevent any kind of brick and mortar stores from accepting bitcoin because accepting a 0/unconfirmed transaction is too risky and it would take too long to wait for one confirmation.

A much better solution would be "Child Pays For Parent" (CPFP), in which a merchant can broadcast a transaction that is dependent on a 0/unconfirmed transaction and this 2nd transaction has a high transaction fee. This would essentially allow for merchants to cover transaction fees to get paid, as is the status quo now with credit card transaction fees.

[Windowly]

I thought this was a very good article by Erik Voorhees on the subject.

Note from CEO Erik Voorhees: An Appeal for Zero-Conf

[arnoudk]

I think Erik Voorhees hits the nail on the head with his plea to ensure that zero conf transactions are not disabled by default. Nobody should destroy business models because they don't like the risk other businesses voluntarily take.

Because the RBF is opt in (I am assuming that this flag is not an unused byte that any wallet implementation currently has set to 1) I am open to the argument that RBF and non RBF transactions would coexist on the network. It seems to me that non RBF should be the default.

Yes double spending can be done now even without nodes relaying transactions. You could build or modify a wallet that broadcasts a competing TX with higher fees to the major miners themselves. The question is how a miner chooses between those two today, regardless of what the default policy is.

In a trustless system, you cannot depend on rules that are not punished by design if broken. But you can accept this risk as a business and it is your right to do so.

I do wonder though if we can explain to the average end user what the difference is. How many TX types will there be in the future? Assuming someone invents ABC type transactions the user will have to choose between RBF with ABC, RBF without ABC, non RBF with ABC and non RBF without ABC.

Now add DEF and GHI and JKL type transactions. You get the point. Users, especially non technical users, will have a hard time understanding this.

[btc]

accepting 0conf txs has always been risky for double spends. what's all the hubbub about

[arnoudk]

accepting 0conf txs has always been risky for double spends. what's all the hubbub about

The way I understand the commotion is about the right of a business to accept the risky zero conf. It does enable real world business cases. As long as transactions can be marked as non RBF and miners respect this setting I see no real problem. Let the free market decide which transactions to use and when. I don't know what business cases RBF enables but I would be happy for these businesses to be launched.

I guess they should not have called it REPLACE by fee, if the goal is for both to coexist. I guess this gives the wrong impression.

However if it IS intended to replace standard transactions, then I do have an issue with that. It is not their right to destroy other people's business models.

[DOGed]

accepting 0conf txs has always been risky for double spends. what's all the hubbub about

Accepting a 0/unconfirmed tx has always had risks, yes, however there have also been ways to mitigate these risks, and businesses could choose to wait for a single transaction until accepting the transaction.

As it stands now, a business who accepts a 0/unconfirmed transaction only after waiting a short amount of time after rebroadcasting a transaction they receive with a well-connected node, and listening for double spend attempts has a fairly low risk of a double spend attack, even from a technologically advanced attacker.

With RBF, it is almost guaranteed that someone will be able to successfully double spend a transaction once they receive goods/services prior to a transaction confirming.

I also do not see any "pros" to RBF, especially any that could not be accomplished by CPFP