6 ms·

This may be a little unpopular here, but I really appreciate the conservative approach by the Bitcoin core team. There's a lot of cryptocurrencies out there and

This may be a little unpopular here, but I really appreciate the conservative approach by the Bitcoin core team. There's a lot of cryptocurrencies out there and Bitcoin's dominance is from its long history and staying power. Bitcoin needs to have a near majority of agreement for any breaking change or else its risking its own dominance. Hopefully, transaction fees become less over time, but regardless they're necessary to prevent spam. No matter how big of blocks you have, you're always going to have a spam problem and the Bitcoin forks have yet to show how bigger blocks will mean faster transactions.

ggreer 11y ago
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. 1. https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0125.mediawi... 2. https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0144.mediawi...
- 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.
  - 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.
- matthewbauer 11y ago
  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.
  - DCPOS_Anthony 11y ago
    Both of them are opt-in.
- csomar 11y ago
  RBF was introduced by Satoshi and not core. Seg. Wit. is complex but not optional. It means you can simply ignore it.
the_rosentotter 11y ago
It's just that the core developers seem to be selective about what they are conservative about. Replace-by-fee, which is a very controversial change which there's never been a lot of discussion about, gets fast-tracked, while a comparatively trivial change in block size gets iced because it is not part of 'the vision'.
- ikeboy 11y ago
  There's been plenty of discussion (I remember reading articles about it a year before it was actually committed). It's also not even a soft fork, just a policy change for minors. It was in the original release of Bitcoin and removed for DoS reasons that no longer applied. Some minors had been running it previously. It's also opt in. I fail to see any reasonable way in which a blocksize increase is "comparatively trivial".
- wtogami 11y ago
  https://bitcoincore.org/en/faq/optin_rbf/ https://bitcoincore.org/en/faq/optin_rbf/ It may be worthwhile to read the detailed RBF FAQ.
- deleted 11y ago
  [deleted]

ggreer 11y ago

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. 1. https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0125.mediawi... 2. https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0144.mediawi...

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.
- 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.
matthewbauer 11y ago
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.
- DCPOS_Anthony 11y ago
  Both of them are opt-in.
csomar 11y ago
RBF was introduced by Satoshi and not core. Seg. Wit. is complex but not optional. It means you can simply ignore it.

the_rosentotter 11y ago

It's just that the core developers seem to be selective about what they are conservative about. Replace-by-fee, which is a very controversial change which there's never been a lot of discussion about, gets fast-tracked, while a comparatively trivial change in block size gets iced because it is not part of 'the vision'.

ikeboy 11y ago
There's been plenty of discussion (I remember reading articles about it a year before it was actually committed). It's also not even a soft fork, just a policy change for minors. It was in the original release of Bitcoin and removed for DoS reasons that no longer applied. Some minors had been running it previously. It's also opt in. I fail to see any reasonable way in which a blocksize increase is "comparatively trivial".
wtogami 11y ago
https://bitcoincore.org/en/faq/optin_rbf/ https://bitcoincore.org/en/faq/optin_rbf/ It may be worthwhile to read the detailed RBF FAQ.
deleted 11y ago
[deleted]