2 ms·

> 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 "Fil

by ggreer 11y ago

> 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. 1. https://github.com/bitcoinclassic/bitcoinclassic/compare/04503f78c750e7d5fc11deb247259f3d5074e09b...3aadc515e06021d75d360ca83191ef89081ab914 https://github.com/bitcoinclassic/bitcoinclassic/compare/045...

ikeboy 11y ago
(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_capacity_increases_for_the_bitcoin/cxqzhx0 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?
- ggreer 11y ago
  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.
  - ikeboy 11y ago
    >As the diffs show, his assertions on the complexity of these changes are simply incorrect. The comment was before those commits were made, so it may have been correct at the time of posting.
    - ggreer 11y ago
      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.
      - ikeboy 11y ago
        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.)

by ggreer 11y ago

ikeboy 11y ago

(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_capacity_increases_for_the_bitcoin/cxqzhx0 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?

ggreer 11y ago
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.
- ikeboy 11y ago
  >As the diffs show, his assertions on the complexity of these changes are simply incorrect. The comment was before those commits were made, so it may have been correct at the time of posting.
  - ggreer 11y ago
    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.
    - ikeboy 11y ago
      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.)