Leave opt-in RBF code in, but disabled by default about bitcoinclassic

This is now disabled by default in #4.

[ripper234]

ACK, RBF should definitely be accessible to whichever miners who want it (only opt in).

RBF should be pulled. Fee Market not a concern when approaching from a "bitcoin grows parallel with tech" thought process.

If Peter Todd wants to show proven use cases that is a different story.

[ripper234]

The code is implemented and tested, no need to throw it away.
There is zero harm in having it in the codebase, opt in.

Let miners experiment with it if they want.

Another benefit: the less diffs we have from the Core codebase, the easier it gets to merge patches cross repos.

RBF is a major contention, if it stays Classic doesnt stand a chance. Opt in, in this instance doesnt hold weight as it is the receiver that is affected most.

[ripper234]

If we leave it in, we increase the number of miners who are comfortable running Classic instead of Core.

Give the user more options, don't try to dictate policy for them.

I submit that is not the correct framing. Miners benefit from higher fees in that scenario, but it is based on a fee market which overall harms bitcoin more than helps.

They would earn far more with raising the number of tx's and having a healthier bitcoin. Not all miners think short term, and those that do arent really in it to see bitcoin grow. That is the "quick buck, get out early" mindset.

"The code is implemented and tested, no need to throw it away."

Is the equivalent of asking:

"I already rolled this blunt, why throw it out?" while in the process of getting pulled over by a state trooper who has a K9 in the back of his vehicle.

RBF is a contention, and not a small one at that. It has no real world testing nor proven data to back it up. Classic doesnt move forward with this.

[ripper234]

Completely removing RBF from the codebase distances us from Core.

The more distant we are, the more words are wasted on internet forums debating "Core vs Classic".

[m-schmoock]

Changing it to real "Opt-In" (as they claim) by disabling it per default seems the right decision to me.

"Changing it to real "Opt-In" (as they claim) by disabling it per default seems the right decision to me."

I agree, however changing it to "real opt-in" is the same as removing it or nullifying it as a whole. Disabling it entirely would most likely be sufficient, I would remove it though personally.

Nothing further to add.

[m-schmoock]

@Soupernerd : Theres a difference in disabling or just changing the default. The latter means that the node will still be able to process it if the initiator opt'ed-in for RBF.
If we disable/remove it, the node cannot process RBF at all, correct?

After all it should be the users decision to have RBF or not.

[dgenr8]

Replaceability has use cases, and opt-in RBF actually helps 0-conf by tagging a class of tx that can easily be shunted to "don't trust without confirm". This class exists, even without RBF -- for example, non-standard or low-fee transactions.

However, an "always allow RBF" option (a la #4) has no more place in an official distribution than do tools for creating double-spends intended to defraud receivers.

[andyrowe]

ACK

[ripper234]

https://bitcoinclassic.consider.it/leave-rbf-in-but-disabled-by-default

@ahmedbodi can you add a link to consider.it to the OP?

[jtoomim]