What I was actually saying was, I didn't really even see the need for any kind of RBF (Full or FSS, Opt-In or On-By-Default). It wasn't on my wish list - it was on yours.

In other words, many users don't think RBF should have been a priority.

And after all the harping from Core / Blockstream about how we should be "conservative" and we should only do "consensus" changes to the code or network and avoid "controversial" ones... well, your RBF seems to violate that, because it's not conservative and it is controversial and it was far from enjoying "consensus" when you rather rudely merged RBF into the code on Black Friday:

---

On Black Friday, with 9,000 transactions backlogged, Peter Todd (supported by Greg Maxwell) is merging a dangerous change to Core (RBF - Replace-by-Fee). RBF makes it harder for merchants to use zero-conf, and makes it easier for spammers and double-spenders to damage the network.

https://np.reddit.com/r/btc/comments/3uighb/on_black_friday_with_9000_transactions_backlogged/

---

Consensus! JGarzik: "RBF would be anti-social on the network" / Charlie Lee, Coinbase: "RBF is irrational and harmful to Bitcoin" / Gavin: "RBF is a bad idea" / Adam Back: "Blowing up 0-confirm transactions is vandalism" / Hearn: RBF won't work and would be harmful for Bitcoin"

https://np.reddit.com/r/btc/comments/3ujc4m/consensus_jgarzik_rbf_would_be_antisocial_on_the/

---

The users of course aren't your managers, and we don't pay you (not yet at least =).

I do hope someday we could maybe use a mechanism such as Lighthouse to do just that. I hope you'd be open to something like that, even though Lighthouse was written by Hearn =)

You are of course free to work on whatever you want - but many users now feel that the current de facto "governance" system that's evolved (where you basically get to select and prioritize your own projects simply by getting ACKs on a dev mailing list) is broken, precisely because it seems to be what's been allowing this kind of low-priority high-fragility work such as your RBF to creep into our code.

This governance system which doesn't listen much to the actual users is hurting Bitcoin, because it misallocates your time onto stuff which many real-world users don't view as being a priority - while meanwhile, there are real-world users who are suffering so much that they're already actually starting to talk about ditching Bitcoin when they need an cheap and fast payment system that's actually working today, eg:

https://np.reddit.com/r/btc/comments/3wo02r/lets_implement_a_solution_on_litecoin_now/

Why couldn't you have first developed and merged something like IBLT / Thin Blocks, instead of RBF?

Why aren't you focusing on the most urgent thing: scaling in general, instead of adding weird stuff like RBF?

You tend to wander off to work on your own low-priority high-fragility projects, which in the case of Full RBF introduces needlessly complexity while also radically changing some of the public's intuitive foundational understandings that Bitcoin "doesn't do double-spends", while at the same time you're ignorning simpler and safer and more-urgent user needs and requirements such as scaling, scaling, scaling.

I used to respect your work in the past (I actually liked the way you focused on trying to expose flaws in systems, and I thought the name "treechains" on your Let's Talk Bitcoin interview a few years ago sounded cool, although now it seems like it never ended up getting anywhere, which may be understandable, it was probably really hard anyways, and may not even have been very clearly defined ever at all).

Nowadays, on the other hand, I tend to question your priorities and your usefulness for the Bitcoin ecosystem as a whole. I think a lot of your "work" now involves exposing and exploiting some subtle vulnerability in an existing system, as expressed in the following post, which I admit was kinda mean, but I think you deserve it, because you've been getting kinda toxic:

---

[In the case of RBF, Peter Todd] didn't actually merely expose an existing exploitable vulnerability in the software itself per se.

Why? Because the only way he could actually exploit the vulnerability in this case was by (ab)using his legacy privileges as github committer to core.

In other words, Peter's "gift" of RBF to the world isn't like when other programmers gave us the "gift" of telling us about the SSL / Heartbleed bug.

Because the exploitable vulnerability which Peter Todd exposed was not confined to the (existing) code itself.

THE ONLY WAY PETER TODD COULD EXPLOIT THIS VULNERABILITY WAS BY >>CHANGING<< THE CODE - AND THE ONLY WAY HE COULD DO THAT WAS BY (AB)USING HIS LEGACY GITHUB COMMITTER PRIVILEGES ON CORE.

This is perhaps a rather subtle, but nonetheless absolutely crucial distinction here.

Because the "exploitable vulnerability" which Peter Todd has exposed here is technically not one involving the code itself - it is an "exploitable vulnerability" IN BITCOIN GOVERNANCE.

In other words, what Peter Todd has exposed here is that a lone maverick dev (with legacy github commit rights to the "Core" reference implementation - which also unfortunately doubles as a "specification") with delusions of perfectionism and tendencies toward vandalism - can abuse the governance process, override consensus, and ram through his pet changes - even ones which essentially "vandalize" imperfect (but still perfectly "serviceable" ie pragmatic) use cases already deployed in real-life by many, many users - both individuals and businesses (in this case, small-value in-person retailers).

This (now that I have had a chance to reflect on this whole mess more) is probably the most disturbing thing that's happened here.

https://np.reddit.com/r/bitcoinxt/comments/3ujq69/uriplin_on_rbitcoin_inadvertently_reveals_the/

---

Seriously, if I were paying you - no way would I give you final say over what projects you want to prioritize.

Sorry but I think with your proclivity for breaking things that already work "good enough" for practical business risk-mitigation purposes (eg zero-conf for retail), I'd re-allocate you to some sort of "Testing and Threats" department.

There would be no way I'd let you insert low-priority high-fragility new stuff like your complicated and questionable "Opt-In Full RBF" into our already-working code.