4 ms·

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

by apeace 9y ago

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-risks-splintering-as-civil-war-enters-critical-month https://www.bloomberg.com/news/articles/2017-07-10/bitcoin-r... [1] https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7 https://medium.com/@octskyward/on-consensus-and-forks-c6a050... [2] https://blog.plan99.net/the-resolution-of-the-bitcoin-experiment-dabb30201f7 https://blog.plan99.net/the-resolution-of-the-bitcoin-experi...

petertodd 9y ago
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 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 9y ago
  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 9y ago
    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 9y ago
      > 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.)

by apeace 9y ago

petertodd 9y ago

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 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 9y ago
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 9y ago
  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 9y ago
    > 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.)