4 ms·

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 th

by ggreer 11y ago

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.

ikeboy 11y ago
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 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.
- 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?

by ggreer 11y ago

ikeboy 11y ago

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 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.

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?