Except they're not being conservative. Core's approach has been to introduce new complexities such as replace-by-fee[1] and segregated witness[2]. These are much bigger changes to Bitcoin than a one-time increase of the max block size.
The first is just putting in code that had been part of Bitcoin since the beginning, temporarily removed due to DoS concerns, and re-added once those concerns had been alleviated by requiring a higher fee.
The second is being implemented as a soft fork, while a block size increase would be a hard fork. Soft forks have been done many times while hard forks have no precedent. Why do you consider that a bigger change? Soft forks are "optional", a backwards compatible change, while hard forks aren't.
The problem with RBF is that (in some cases) it can allow double-spends with older receiving software. If the receiver accepts zero-confirmation transactions, the sender can send one transaction, wait for the receiver to accept it, then send another transaction with a higher fee and a different receiver. In other words: RBF may be opt-in, but it decreases security for wallets that don't support it.
The problem with SegWit is that it isn't ready. A few days ago, SegWit caused testnet to fork. The cause has been identified and fixed, but it will still be months before SegWit is trusted enough for production use.
While Bitcoin has never had an intentional hard fork, it has had an accidental one.[1] It was chaotic, but not world-ending. In contrast, Classic requires 750 out of the last 1000 mined blocks to trigger, and it has a month-long grace period before accepting larger blocks. It would be a well-known and predictable switchover.
Those types of transactions have been non-standard and non mined by default anyway. The opt in flag has been designated for replacing transactions from day one, and plenty of wallets will recognize it and warn.
Individual merchants shouldn't be accepting zero conf anyway without risk assessment (it's been demonstrated how easy it is to double spend well before RBF), and if they use an external company to accept then that company will check for the flag.
Re 75% is enough: remember the fork that happened just last year on a soft fork with 95%?
The cause of the fork you mentioned was not related to the threshold. Miners had software that falsely claimed to supported the new, stricter checks. Even if the threshold had been 100% of the last 1,000 blocks, the fork would have still happened. Unless you think no threshold is ever acceptable (because software can lie about its capabilities), your argument proves too much.
I mentioned RBF as an example of Core adding complexities when they should be focusing on scaling. We can reasonably disagree as to whether RBF's advantages outweigh its disadvantages. I lean toward, "Not worth it." but debating RBF gets away from my main criticism of Core: That they are not being careful or conservative. They're just doing a terrible job of scaling Bitcoin.
I mentioned that fork because you implied that a 75% hard fork would be effectively riskless. There are all kinds of things that can go wrong, and not wanting a hard fork unless there are no other options is prudent.
RBF helped the existing problem of transactions never going through. A fee market will need to develop eventually anyway (as nullc has said, there's an unlimited amount of data people would like to store for free), and allowing fee changes for transactions where zero conf acceptance is not required is a step towards making transactions easier in a fee market.
Claiming that RBF is not careful is something I can't agree with. If wallet designers disregard a feature of Bitcoin that's been there from the beginning, and users accept zero confs without doing basic security checks, protecting them isn't more important than providing features to everyone else. First seen was never advertised as secure, and if you're too lazy to check for that flag I don't really care. Considering that double spends were still very possible previously, and the detection is one line of code, I'm not particularly worried. https://petertodd.org/2016/are-wallets-ready-for-rbf points out that none of the top wallets would detect a regular double-spend even without RBF.
I'm not sure how you got that impression, but I certainly don't want to imply that Classic's method is effectively riskless. I'm saying that it's the best available option to help with Bitcoin's current scaling problem. Compared to SegWit, it's an absolutely trivial change. Adoption of it is predictable (750/1000 most recent blocks, plus a month grace period), giving everyone plenty of time to update their software. And most importantly, it's ready today. Even the most optimistic timelines put SegWit months out.
You keep coming back to RBF, but it seems we only disagree on the magnitude of the disadvantages I highlighted, not their existence. The post you linked to shows that wallets really aren't ready for RBF. The author (who I now notice is a Bitcoin Core developer) is rather disingenuous. He neglects to mention that:
• Without RBF, zero-conf double-spends have a success rate of around 50%. With RBF, this becomes a ≈100% success rate.
• Without RBF, the success rate of a zero-conf double-spend decreases over time. As more nodes see the transaction, fewer will accept any future double-spend. With RBF, the double-spend success rate stays close to 100% until there is a confirmation.
Again, reasonable people can disagree about whether RBF is good or bad. I only brought it up as an example of Core introducing complexity that is, at best, tangentially related to scaling.
I'm a bit too lazy to count lines now, but I believe nullc has said the actual changes in segwit are smaller than those in the hardfork to 2MB.
Could you point me to the metric by which Classic's changes are smaller? Maybe some of those commits shouldn't be counted or something, or they change less lines, I don't know?
> I'm a bit too lazy to count lines now, but I believe nullc has said the actual changes in segwit are smaller than those in the hardfork to 2MB.
Click on "Files changed" for line count stats. You'll see the Core → Classic diff is smaller than the SegWit diff: +1,803/-339 lines vs +2,193/-386. That's despite the fact that Core → Classic includes:
• Replacing every instance of "Core" with "Classic" and updating all links to online docs, chat, etc. (This is why 103 files were changed.)
• Updating copyright notices.
• Adding a description of Bitcoin Classic (and how it differs from Core).
• Adding a Debian package builder, including a default bitcoin.conf, service description, and pre/post install/uninstall handlers.
• Adding the Classic team's package signing keys.
The functional Classic diff is this changeset[1]. It's +865/-75, and the majority of the lines added are test cases.
(Not very familiar with github, didn't realize you could count lines so easily).
Does the code you linked to compile and work alone? If so, I'd have to agree that it's smaller. I found the post I was referencing earlier, btw, at https://np.reddit.com/r/Bitcoin/comments/3vurqp/greg_maxwell... That was before the classic code was released, though.
Code committed less than a month ago can hardly be called "ready today". In what sense is classic readier than segwit?
Yes, that's the functional diff and test cases. It compiles and runs. None of the subsequent commits to Classic fix bugs in that code. It was solid from the get-go.
In the comment you linked to, Greg Maxwell is trying mightily to paint a rosy picture of SegWit while disparaging a block size increase. As the diffs show, his assertions on the complexity of these changes are simply incorrect.
> Code committed less than a month ago can hardly be called "ready today". In what sense is classic readier than segwit?
When it comes to reliability, time since commit doesn't matter nearly as much as testing, code reviews, and the complexity of the change. There are several senses in which Classic is more ready than SegWit. The Classic switchover has been run on testnets without issue. In contrast, SegWit's testnet had forks as recently as a few days ago. Thousands of people are running Classic in production right now, including companies like Coinbase. SegWit won't be production-ready for months.
That's giving too much credit. His predictions were incorrect, and not by a small amount. I'm no Bitcoin developer, but a month ago it was obvious to me that Segregated Witness would require far more code than a block size increase. Maxwell thought SegWit would be smaller, but even its current (incomplete) state is bigger by a factor of four. That's not a small mistake. It indicates a fundamental misunderstanding somewhere along the line. The more I read comments made by Core devs, the more I think they are either mistaken or misleading. I truly wish this wasn't the case.
Lastly, I hope this back-and-forth has given you a better grasp of the subject and caused you to change your mind on some things. I can't shake the idea that you're trying to convince others rather than figure out what's true. And judging from recent comments on HN, you seem to be overconfident in your technical abilities (not knowing how to use GitHub, thinking HTTPS is too resource-intensive for many applications, etc). I urge you to be more self-critical in the future.
The difference wasn't that segwit got bigger, it was that the other patch got smaller. (Or rather, looking at it again, he's referring to BIP101 which was an adjustable size HF).
I don't see why not knowing how to check the line difference in github implies a lack of technical skill. The claim about https I had taken directly from a site which claimed they didn't host it on https because it was too expensive. I haven't dealt directly with testing https on a large scale, but again, that's hardly a core technical skill, except for someone running webservices.
I've changed to a bit more uncertainty on the difference between soft forks and hard forks based on someone else's comments here. I'm not sure if I've changed my mind on anything due to your comments in particular (except that the classic fork is indeed smaller).
I'm not sure what I can do about incorrect information from an unreliable source that I'm not aware is incorrect. Do you have any practical piece of advice on that besides "be more self-critical"? (Because the practical consequence of such self-criticalness would be less posting on subjects I'm semi-confident about, and while I'm occasionally wrong, I think I'm overall contributing in a beneficial way. I wouldn't have >2500 karma here if I wasn't.)
You really shouldn't be accepting zero-confirmation transactions that are marked as replaceable no matter how old your receiving software is. Even though it happens that most pools don't ever actually accept replacements for them, that's merely a policy decision on the part of the pools - the field marking them as replaceable has been there as long as Bitcoin's existed and I think a few pools do honour it.
If the fork is successful, then the longer chain will always be the segwit one. The only problem is if the longer chain is non-segwit, but that means either
1. There isn't a segwit supermajority or
2. It's longer by very few blocks, perhaps only one
In the first, nobody should be using segwit to send money and therefore there's no breakage, and in the second the threat isn't increased that the threat of any orphan block, which happen occasionally. If you're accepting single-conf then you're accepting the risk of orphan blocks, so this isn't worse.
It's not about which chain is longer. With segwit as a soft fork old clients will recognize new blocks as valid but fail to see segwit transactions, effectively failing silently. With segwit as a hard fork old clients will not accept new blocks and fail loudly. In both cases old clients are forced to upgrade in order to keep using the network.
All segwit transactions are valid under the old rules. Old clients can continue sending transactions as they did before, as I mentioned, segwit only repurposes non-standard transactions, so it should have no effect on someone using the network normally.
Your understanding of soft forks is incorrect. Changes to the consensus rules implemented by soft forks are in no way optional, nor are they backwards-compatible [0].
Nor are soft-forking changes meaningfully more limited in scope than hard-forking changes. Soft forks, by introducing new rules referring to data unreferenced by the old rules, can be used to make almost arbitrary changes to the protocol. Bitcoin Core's planned implementation of segregated witness uses this technique, which is how it is able effectively to loosen the constraint on block sizes. The technique can be extended to implement an arbitrary increase in the blocksize as a soft fork [1], or even to change the rule that limits the final supply of bitcoin to 21 million units [2]. Name a change you want to make to the consensus rules: chances are that with enough cleverness (and a willingness to make a big enough mess) you can find a way to implement it as a soft fork.
The most salient consequences of changing consensus rules by soft fork versus by hard fork, to my mind, are that (a) soft-forking changes ordinarily introduce substantial additional complexity compared to effecting the same change with a hard fork, and (b) developers can introduce changes via soft forks without having to secure the same degree of explicit consent from miners and users that hard forks require.
Phenomenon (a) occurs because soft-forking changes must be implemented by roundabout mechanisms that preserve formal (but not semantic) compatibility with the old rules, whereas hard forks provide the freedom to make changes in the simplest or most technically appropriate way. Point (b) perhaps helps to explain the preference of Bitcoin Core's team for soft-forking changes: they are less constrained by the desires of users and miners under a policy of implementing changes to the consensus rules by soft fork than they would be if they were to attempt the same changes with hard forks.
Edit: I encourage interested readers to verify what I have written by referring to the sources I cited or by doing their own research. Downvotes in discussions of Bitcoin here unfortunately tend to reflect the voters' loyalties in the blocksize brouhaha more than their honest assessment of whether a comment is informative and correct.
No, you cannot "change the rule that limits the final supply of bitcoin to 21 million units" through a softfork. You can indeed append an "extension record" with "extension transactions" that generate and transfer whatever number of extension coins you like as https://np.reddit.com/r/bitcoin_uncensored/comments/43w24e/r... lays out, but you can never ever convert those extension coins into ordinary Bitcoins that existing nodes accept as valid. You've basically created a very elaborate altcoin as a sidechain of Bitcoin.
This is not the technique that segregated witness uses. All SegWit transactions are on-chain transactions that are visible to existing clients, which means that the coin cap and all the other Bitcoin rules still apply and the coins from them can subsequently be sent to non-SegWit clients - the only thing that's not available to older nodes is the information about who's allowed to spend SegWit transactions. It's similar to the P2SH fork a few years back in that respect. (That's also why the effective block size gain is limited. Any further increases are planned to be done through a hard fork.)
Now, technically of course 51%+ of miners could refuse to accept standard Bitcoin transactions of any kind and force everyone onto their extension chain. In fact, they could even declare a day zero after which they refused to accept any existing transactions or coins as valid, resetting the whole thing as an extension chain. This is an unavoidable consequence of miners being able to decide which valid transactions they accept - Bitcoin simply relies on the majority of miners not trying to shut the whole thing down.
Yes, you're right, but again only in a formalistic sense. It is the semantics of the rules that matter, not their form. And the semantics can be changed arbitrarily in the way I described. I don't think my point is pedantic. Segregated witness is just this sort of change, one that preserves the form of the old rules while significantly reinterpreting their meaning.
No, segregated witness doesn't change the semantics as drastically as, say, changing the effective cap on the final supply of monetary units. But that's beside the point—which is that it is wrong to think of soft-forking changes as intrinsically less significant or more acceptable than hard-forking changes. You can effectively change anything with either approach. To judge a change to the consensus rules, you must look at its semantics: whether it is implemented as a soft fork or a hard fork tells you essentially nothing.
Yet a large chunk of the Bitcoin community seems to believe that soft forks should be preferred to hard forks as a matter of principle. That is nonsense.
Old nodes continue to work only in a trivial sense: after a soft-fork, they can no longer properly interpret the meaning of data in the blockchain, so their ability to validate new transactions has been destroyed. If Bitcoin Core's soft fork to introduce segregated witness proceeds, for example, nodes that are not upgraded (and so have no understanding of the witness data) will happily interpret all seg-wit transactions as valid, whether they really are or not.
For this reason, some people view soft forks as insidious in a way that hard forks are not: the sole purpose of a Bitcoin node is to interpret data contained in the blockchain and in newly broadcast transactions to determine the validity of those transactions under a particular ruleset, and a soft-fork is a subterfuge specifically designed to make some of those nodes unaware that their ability to perform that function has been destroyed.
If soft forks are "less risky", it is precisely for that reason: soft forks ensure that the nodes of miners and users who do not explicitly consent to a rule change fail even to notice that the rules have changed!
Firstly, not all soft forks introduce extra data. Some are simply about minor policy.
Second, soft forks have been the standard since the beginning, and everyone understands that minors can set their own rules.
Third, non upgraded nodes, if they follow the longest chain, do not break. If they mine themselves they'll get orphaned, but that doesn't break them as long as they wait for a couple of blocks before accepting transactions as valid.
Fourth, soft forks have traditionally repurposed non standard transactions, which shouldn't be issued by anyone expecting consistent behavior. Segwit uses anyone-can-spend which are non standard, and as the bip says "Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion."
Fifth, anyone can "notice" by virtue of the block header changing. A majority of minors can reject transactions, that's not deceitful in any way.
I do want to thank you for pointing out that many changes can be done with a soft fork, which I hadn't seen before. That got an upvote from me.
Some of those changes seem like they'd require users cooperation as well, though. The "meaning" of the extra data would only be useful by those that decide to acknowledge it.
I'm wondering if it might be a better idea in general to do all future changes as soft forks. Is anyone arguing this?
I don't know of a single responsible bitcoin developer that wouldn't prefer using soft-forks to hard-forks. Bitcoin has had hard-forks in the past, but they have been done in response to a specific issue, and were done very quickly. What's most important, everyone agreed that the hard-fork had to be done.
The current attempt by Coinbase to force a contentious hard-fork is dangerous. There are many people that even question its requirement, let alone whether it can be done safely.
I'm not saying it's not going to happen, but it isn't going to be done quickly, and if it is finally going to happen, it'll be managed by the core developers.
I've looked at RBF and my understanding was that it was totally opt-in? Older versions of Bitcoin core still work and can keep on mining. IMO that's less big of a change because it's not breaking anything. I haven't actually looked at segregated witness though.
1. https://github.com/bitcoin/bips/blob/master/bip-0125.mediawi...
2. https://github.com/bitcoin/bips/blob/master/bip-0144.mediawi...