3 ms·

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 avail

by ggreer 11y ago

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.

ikeboy 11y ago
https://github.com/bitcoin/bitcoin/compare/0.12...bitcoinclassic:0.12 https://github.com/bitcoin/bitcoin/compare/0.12...bitcoincla... Commits 48, files changed 103 https://github.com/bitcoin/bitcoin/compare/0.12...sipa:segwit https://github.com/bitcoin/bitcoin/compare/0.12...sipa:segwi... Commits 27, files changed 71 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?
- 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.

by ggreer 11y ago

ikeboy 11y ago

https://github.com/bitcoin/bitcoin/compare/0.12...bitcoinclassic:0.12 https://github.com/bitcoin/bitcoin/compare/0.12...bitcoincla... Commits 48, files changed 103 https://github.com/bitcoin/bitcoin/compare/0.12...sipa:segwit https://github.com/bitcoin/bitcoin/compare/0.12...sipa:segwi... Commits 27, files changed 71 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?

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.