[apeace]

For the past two years, the Bitcoin community has been embroiled in a debate about how to scale the network to handle more transactions. The debate has at times become less technical, rhetoric about "centralization" and the values of the community has become introduced, etc. Recently the debates have come to a head, and some have referred to it as a "Civil War"[0].

For technical background, I recommend these two posts by Mike Hearn, who has since left the Bitcoin community [1] [2]

Now, what the original article is talking about is the "Core" development team--the people who have commit access on the Bitcoin Github repo. The whole debate has essentially become Core vs. some other factions, mainly miners. You'll see the arguments in [1] and [2].

(Keep in mind, Mike Hearn is strongly on the anti-Core side of the argument. But those articles should give you an idea of what to search for, if you want to hear arguments on the other side.)

[0] https://www.bloomberg.com/news/articles/2017-07-10/bitcoin-r...

[1] https://medium.com/@octskyward/on-consensus-and-forks-c6a050...

[2] https://blog.plan99.net/the-resolution-of-the-bitcoin-experi...

[petertodd]

Both of Hearn's articles contain a number of factually incorrect points. For example, his article on forks states that:

> In a soft fork, a protocol change is carefully constructed to essentially trick old nodes into believing that something is valid when it actually might not be.

The soft-fork protocols used for upgrades are specifically designed to ensure nodes are not tricked into believing something is valid when it might actually not be, as there is a well-defined mechanism - the block header nVersion field - that both co-ordinates soft forks and ensures that nodes that are unaware of the specifics of a given soft-fork know that there are new rules in effect. This is why at present, Bitcoin Core nodes/wallets loudly warn you that unknown rules may be in effect that your node does not understand, because the BIP91 soft-fork just activated that Bitcoin Core does not recognize. (BIP91 is a temporary hack to activate segwit at 80% rather than 95% threshold; in a few weeks it'll no longer be relevant to consensus)

Hearn is misleadingly confusing the adversarial case where a majority of miners may try to change the rules without consent of the community in an undetectable fashion, but that's simply a 51% attack. At present, preventing such attacks is an open research question; conflating the 51% attacks and soft-fork upgrades is very misleading.

In Hearns "resolution of the bitcoin experiment" Hearn states that:

> Bitcoin Core has a brilliant solution to this problem — allow people to mark their payments as changeable after they’ve been sent, up until they appear in the block chain.

and

> How many people would think bitcoins are worth hundreds of dollars each when you soon won’t be able to use them in actual shops?

Here he's referring to zero-confirmation payments and BIP125, Opt-In Replace-By-Fee. First of all, opt-in replace-by-fee is actually derived from Hearns own proposal to re-enable transaction replacement by nSequence. Specifically, Hearn proposed to re-enable an old feature in Bitcoin Core - originally written by Satoshi - that allowed transactions to be replaced if they signalled a higher sequence number. This creates a DoS attack, which I proposed we fix by ensuring that replacements paid a higher fee than the replaced transaction.

Opt-in replace-by-fee is a combination of Hearn's proposal and my own: transactions can signal that they are replacable, and if they signal replacability, can be replaced by transactions paying a higher fee. The combination implements Hearn's desired transaction replacability behavior, while fixing the DoS attack.

The bigger issue is that zero-confirmation transactions are simply not secure: even without the opt-in replace-by-fee that Hearn criticises Bitcoin Core for implementing, it is very easy to double-spend unconfirmed transactions. Soon after Hearn published that post, I did a study which found that every half the wallets tested could be double-spent trivially with nearly 100% success rates, and the other half with about 25% success rates: https://petertodd.org/2016/are-wallets-ready-for-rbf

Unfortunately, Hearn is simply being dishonest on both counts here, something that got him wide condemnation in the technical community.

[hendzen]

Peter,

You just cherry picked one (minor) point from each article, and then used an argument against those points to claim that both articles are incorrect in full. I think that is a dishonest form of argument.

Furthermore, it's worth disclosing your own personal dislike of Mike Hearn - you guys have spent a huge amount of time attacking one another... so I'm inclined to discount any of your statements on him.

[petertodd]

We seem to have a fundamentally different outlook on this. First of all, I'm busy - I'm not going to do a point-by-point takedown of the article if I can avoid it. Secondly, if you can show an author clearly lied about anything - and I think I have clearly shown that - it immediately calls into question the value of the rest of the work. That saves time and effort for the reader, in much the same way that showing a single step in a math proof is wrong is an efficient way of rebutting an entire work.

Secondly, in claiming I have a personal dislike of Hearn, you're actually making a clear ad-hominem attack. My personal feelings are irrelevant to whether or not Hearn's arguments are correct.

In any case, Hearn is quite a nice guy in person, and fun to hang out with; I used to often chat with him on IRC. It quite frankly saddens me that I'm in a field where I'm not able to do what I'd much rather do - be friends with him - because of professional ethics. This is far from the only time when this has happened - repeatedly I've had to end friendships in the Bitcoin space because friends of mine got involved in scams and other dishonest behavior; in another context where the public wasn't being harmed I could be much more forgiving, but here I can't be.

[SomeStupidPoint]

> That saves time and effort for the reader, in much the same way that showing a single step in a math proof is wrong is an efficient way of rebutting an entire work.

This isn't actually how mathematics functions as a profession: small technical faults are routinely pointed out without discrediting the bulk of the work and at times, major works are submitted without all the technical details actually being accounted for.

Mathematicians are capable of understanding the main thrust of a work without getting bogged down in technicalities, and usually try to "ironman" the work -- seeing the main thrust in the best light possible, rather than the worst. (In contrast to "strawman".)

> Secondly, in claiming I have a personal dislike of Hearn, you're actually making a clear ad-hominem attack. My personal feelings are irrelevant to whether or not Hearn's arguments are correct.

It actually is relevant, considering that you "refuted" Hearn's arguments through the flimsiest of means -- pointing out a small flaw and saying he's not technically correct -- without every addressing the core part.

The heuristic of personal bias is a fine way to assess the genuineness with which you presented a heuristic argument (since you didn't address the core points), and assess if we want to take your heuristic point at face value. It's anything but an ad hominem to provide a reason you might be trying to present a faulty heuristic in response to you presenting a heuristic argument.

So... since you were wrong on both points here, we should discount the entirety of your posts on this topic -- at least, by your (poor) logic.

(I don't actually have any opinion on the topic, but your reasoning here is bad.)

[zawy]

Relying on errors or lies on some points to "disprove" the other parts is itself an ad-hominem. Also, if you have a problem with his ethics, then I have an ethical problem with you if you still want to be friends with him. More to the point, in one post you've given me two causes of concern in regards to your ability to be honest with yourself and therefore to others.

[apeace]

Thanks for your reply. I'm a fan of your work and consider myself to be a neutral observer in these debates.

Regarding your first contestation, I think as another commenter said, you are cherry-picking. He explains soft forks well and isn't attempting to mislead. That's why I refer folks to the article.

> This is why at present, Bitcoin Core nodes/wallets loudly warn you that unknown rules may be in effect...

Hearn mentions this mechanism three times in the article. He even discusses the tradeoffs of ignoring this versus rejecting the block. Hardly misleading.

> The soft-fork protocols used for upgrades are specifically designed to ensure nodes are not tricked into believing something is valid when it might actually not be...

He said "essentially tricked", and I think his explanation is clear.

Using segwit as an example, if my understanding is correct, there is an edge case where non-upgraded nodes may try to mine an invalid block, which will consequently be rejected by the majority of the network (assuming the majority is using segwit).

Since segwit transactions look like an "anyone can spend" output, a non-segwit miner could be sent a transaction that spends the output to somewhere it's not supposed to go, and that would be considered invalid by segwit-supporting nodes. Therefore I think it's fair to say non-upgraded nodes are "essentially tricked", and it's a good way to explain the distinction between hard and soft forks.

I don't know as much about replace-by-fee so won't attempt to counter you.

But I will just add that this type of cherry-picking behavior has consistently been coming out of the "Core side", and I have rarely seen strong, clear counter-arguments from that side. Combine that with the very silly censorship stuff on Reddit, and one can understand why Hearn and others have become so frustrated.

Again, I am a fan and a neutral observer. But unless I am looking in the wrong places, the only side being "widely condemned" is the Core side. Perhaps you could point me to the strong, clear counter-arguments from Core? I'll start with the link you posted and check out the rest of your site!

---

EDIT: Corrected "reply-by-fee" to "replace-by-fee"

[petertodd]

> Hearn mentions this mechanism three times in the article. He even discusses the tradeoffs of ignoring this versus rejecting the block. Hardly misleading.

Hearn mentions the nVersion mechanism? Specifically in https://medium.com/@octskyward/on-consensus-and-forks-c6a050... ?

Maybe I'm missing something, but I don't see any mention of the word "version"

> He said "essentially tricked", and I think his explanation is clear.

I think you're misunderstanding my point: everything you raised above is negated by the fact that the soft-fork mechanisms we use are designed to give warnings to users and miners who are not running the new(1) protocol. For example, in addition to the nVersion mechanism I mentioned, segwit transactions are intentionally designed to be not standard transactions, and thus non-segwit miners will reject them. This is an important feature to ensure that those miners don't unintentionally create invalid blocks.

1) I say "new" rather than "upgraded" to avoid making the claim that soft-forks are necessarily an upgrade.

[apeace]

Hey, thanks again! Educational to hear your perspective.

After re-reading it, I was absolutely mistaken. Hearn did mention a functionality to alert you when your node detects an invalid block. But he was trying to make the point that this was only possible with hard forks. It looks like the nVersion mechanism you mentioned negates his point.

Glad you mentioned that, you made it very clear to me that he was indeed being misleading there! I will edit my parent comments to indicate that.

For reference, here are the quotes I was referring to (again, his claim is that this is only possible with a hard fork):

> ...you will be alerted in some way, like via SMS or email if you configured that, and you get to decide what to do.

> ...if a user complains that their payment didn’t go through that’s a signal that you’re out of date, even if you forgot to configure your full node to email/SMS/phone you. But if you prefer to take the chance you can always configure your full node to act as if there was a soft fork whilst simultaneously trying to get your attention as best it can.

> ...a hard fork is still better. Firstly, it’s detectable, so a properly configured node can email/SMS/phone you to let you know it’s out of date.

Regarding your second point, you have not convinced me that I misunderstand. However you've been gracious enough to discuss it on HN thus far, so I won't press :) Perhaps point me to a link or start a convo with me through my contact info in my profile?

Thanks again!

EDIT

---

Did not realize I could no longer edit my parent comments. Hope everyone who is interested reads all the way down.