9 ms·

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 h

by ikeboy 11y ago

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.

ggreer 11y ago
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. 1. https://bitcoin.org/en/alert/2013-03-11-chain-fork https://bitcoin.org/en/alert/2013-03-11-chain-fork
- ikeboy 11y ago
  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%? https://bitcoin.org/en/alert/2015-07-04-spv-mining https://bitcoin.org/en/alert/2015-07-04-spv-mining
  - 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.
- makomk 11y ago
  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.
pash 11y ago
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. 0. https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7#.kxsty3rw9 https://medium.com/@octskyward/on-consensus-and-forks-c6a050... 1. https://bitcointalk.org/index.php?topic=1296628.0 https://bitcointalk.org/index.php?topic=1296628.0 2. https://np.reddit.com/r/bitcoin_uncensored/comments/43w24e/raising_the_21_million_btc_limit_with_a_soft_fork https://np.reddit.com/r/bitcoin_uncensored/comments/43w24e/r... 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.
- ikeboy 11y ago
thescriptkiddie 11y ago
The segwit soft fork is not optional, clients that do not upgrade in time will be broken much like a hard fork.
- ikeboy 11y ago
  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.
  - thescriptkiddie 11y ago
    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.
    - ikeboy 11y ago
      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.

by ikeboy 11y ago

ggreer 11y ago

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. 1. https://bitcoin.org/en/alert/2013-03-11-chain-fork https://bitcoin.org/en/alert/2013-03-11-chain-fork

ikeboy 11y ago
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%? https://bitcoin.org/en/alert/2015-07-04-spv-mining https://bitcoin.org/en/alert/2015-07-04-spv-mining
- 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.
makomk 11y ago
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.

pash 11y ago

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. 0. https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7#.kxsty3rw9 https://medium.com/@octskyward/on-consensus-and-forks-c6a050... 1. https://bitcointalk.org/index.php?topic=1296628.0 https://bitcointalk.org/index.php?topic=1296628.0 2. https://np.reddit.com/r/bitcoin_uncensored/comments/43w24e/raising_the_21_million_btc_limit_with_a_soft_fork https://np.reddit.com/r/bitcoin_uncensored/comments/43w24e/r... 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.

ikeboy 11y ago

thescriptkiddie 11y ago

The segwit soft fork is not optional, clients that do not upgrade in time will be broken much like a hard fork.

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