4 ms·

I feel the article does Pieter Wuille a disservice by mentioning the Blockstream/sidechains conflict of interest without mentioning the fact that he is actually

I feel the article does Pieter Wuille a disservice by mentioning the Blockstream/sidechains conflict of interest without mentioning the fact that he is actually in favour of raising the block size limit (albeit gradually, over time) and has authored a proposal to do so: https://gist.github.com/sipa/c65665fc360ca7a176a6 https://gist.github.com/sipa/c65665fc360ca7a176a6 What's ironic about this whole affair is that four of the five core developers support raising the blocksize limit (Gregory Maxwell is the sole dissenter, preferring to wait until a transaction backlog develops before taking action) but they diverge on exactly how and how quickly to raise it.

jnbiche 11y ago
I honestly feel that some of the "pro raising" devs aren't actually in favor of raising it anytime in the foreseeable future, and are just dragging their feet in the hopes of that the whole thing will go away. The whole point of this debate is that we've been litigating this affair for the past three years, each year a several core devs claiming to want to raise it "soon", and then it just gets put down another year. I'm still not sure about the BitcoinXT gaining consensus, but I'm very glad someone is putting real pressure on the situation, because that's the only way the block size will be raised anytime in the next few years.
- jackgavigan 11y ago
  My take on it is that the key difference is that Gavin perceives a greater urgency in raising the limit before we reach the point where blocks start getting filled up, than Jeff/Wladimir/Pieter do. I think he got frustrated that no progress was being made, which sparked his decision to add the relevant code to XT, which is what has brought things to a head. I actually suspect that his preferred outcome is not to fork the blockchain into XT and Core, but to put some pressure on the other core devs to act.
  - kang 11y ago
    That would not be correct entirely. Earlier they had 90% as the consensus limit, which they have now brought down to 75% and have suggested driving consensus in regular milestones if that doesn't succeed. Surely they want the fork.
    - jackgavigan 11y ago
      90% was Jeff Garzik's suggestion. Gavin chose 75% "so that one large mining pool does not have effective veto power over a blocksize increase".
      - Bootvis 11y ago
        Am I missing something or is that a rather weak argument? If the hashers in that large mining pool don't like the veto, they'll vote with their feet and leave the pool. But if the pool actually has 25% or more of the hashing power it is a clear sign of no consensus. It seems to me that the operator of a pool is not really in control of the computing power.
        jnbiche 11y ago
        Combined, the Chinese mining pools have well over 25% of the hashrate using only in-house hashing. I think this was the political way of denying a veto to the Chinese mining operations (who frequently collaborate and will likely vote in block).
        jackgavigan 11y ago
        >..if the pool actually has 25% or more of the hashing power it is a clear sign of no consensus. Gavin clearly agrees. However, I guess he doesn't think that a pool (or a miner like BitFury) that has between 10% and 25% of the hashing power should have the power of veto.
      - kang 11y ago
        This is not a one time vote. This is voting over a significant period of time and powers are not fixed.
  - hollerith 11y ago
    Would Bitcoin XT exist if there were no need to pressure the other core devs? I.e., does it serve some additional or original purpose?
    - jackgavigan 11y ago
      Yes, it's been around for a while and contains various enhancements and patches that aren't in Core. See https://bitcoinxt.software/patches.html https://bitcoinxt.software/patches.html
      - deleted 11y ago
        [deleted]
      - pstrateman 11y ago
        > Yes, it's been around for a while and contains various enhancements and patches that aren't in Core. See https://bitcoinxt.software/patches.html https://bitcoinxt.software/patches.html Only if by enhancements you mean damaging centralization bugs. TOR blacklisting by default for example
        jnbiche 11y ago
        I'm still not sure how I feel about that patch, but to be clear it does not blacklist Tor by default. What it does is that if a particular node detects a DOS attack that originates from the Tor network, each node with then down rate the Tor IPs (since that's where many of the DOSs originate from), giving non-Tor nodes higher precedence. And thus avoiding the DOS attach for non-Tor nodes. Under normal conditions, Tor nodes are fully integrated into the network. Like I said, I'm still ambivalent about this patch (for multiple reasons), but saying blacklisting Tor by default might give people the wrong impression of what it does. In the words of BitcoinXT site [1]: "This patch set introduces code that runs when a node is full and otherwise could not accept new connections. It labels and prioritises connections according to lists of IP ranges: if a high priority IP address connects and the node is full, it will disconnect a lower priority connection to make room. Currently Tor exits are labelled as being lower priority than regular IP addresses, as jamming attacks via Tor have been observed, and most users/merchants don't use it. In normal operation this new code will never run. If someone performs a DoS attack via Tor, then legitimate Tor users will get the existing behaviour of being unable to connect, but mobile and home users will still be able to use the network without disruption." I've looked at the patch, and that's pretty much what it does [2]. 1. https://bitcoinxt.software/patches.html https://bitcoinxt.software/patches.html 2. https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23 https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8...

jnbiche 11y ago

I honestly feel that some of the "pro raising" devs aren't actually in favor of raising it anytime in the foreseeable future, and are just dragging their feet in the hopes of that the whole thing will go away. The whole point of this debate is that we've been litigating this affair for the past three years, each year a several core devs claiming to want to raise it "soon", and then it just gets put down another year. I'm still not sure about the BitcoinXT gaining consensus, but I'm very glad someone is putting real pressure on the situation, because that's the only way the block size will be raised anytime in the next few years.

jackgavigan 11y ago
My take on it is that the key difference is that Gavin perceives a greater urgency in raising the limit before we reach the point where blocks start getting filled up, than Jeff/Wladimir/Pieter do. I think he got frustrated that no progress was being made, which sparked his decision to add the relevant code to XT, which is what has brought things to a head. I actually suspect that his preferred outcome is not to fork the blockchain into XT and Core, but to put some pressure on the other core devs to act.
- kang 11y ago
  That would not be correct entirely. Earlier they had 90% as the consensus limit, which they have now brought down to 75% and have suggested driving consensus in regular milestones if that doesn't succeed. Surely they want the fork.
  - jackgavigan 11y ago
    90% was Jeff Garzik's suggestion. Gavin chose 75% "so that one large mining pool does not have effective veto power over a blocksize increase".
    - Bootvis 11y ago
      Am I missing something or is that a rather weak argument? If the hashers in that large mining pool don't like the veto, they'll vote with their feet and leave the pool. But if the pool actually has 25% or more of the hashing power it is a clear sign of no consensus. It seems to me that the operator of a pool is not really in control of the computing power.
      - jnbiche 11y ago
        Combined, the Chinese mining pools have well over 25% of the hashrate using only in-house hashing. I think this was the political way of denying a veto to the Chinese mining operations (who frequently collaborate and will likely vote in block).
      - jackgavigan 11y ago
        >..if the pool actually has 25% or more of the hashing power it is a clear sign of no consensus. Gavin clearly agrees. However, I guess he doesn't think that a pool (or a miner like BitFury) that has between 10% and 25% of the hashing power should have the power of veto.
    - kang 11y ago
      This is not a one time vote. This is voting over a significant period of time and powers are not fixed.
- hollerith 11y ago
  Would Bitcoin XT exist if there were no need to pressure the other core devs? I.e., does it serve some additional or original purpose?
  - jackgavigan 11y ago
    Yes, it's been around for a while and contains various enhancements and patches that aren't in Core. See https://bitcoinxt.software/patches.html https://bitcoinxt.software/patches.html
    - deleted 11y ago
      [deleted]
    - pstrateman 11y ago
      > Yes, it's been around for a while and contains various enhancements and patches that aren't in Core. See https://bitcoinxt.software/patches.html https://bitcoinxt.software/patches.html Only if by enhancements you mean damaging centralization bugs. TOR blacklisting by default for example
      - jnbiche 11y ago
        I'm still not sure how I feel about that patch, but to be clear it does not blacklist Tor by default. What it does is that if a particular node detects a DOS attack that originates from the Tor network, each node with then down rate the Tor IPs (since that's where many of the DOSs originate from), giving non-Tor nodes higher precedence. And thus avoiding the DOS attach for non-Tor nodes. Under normal conditions, Tor nodes are fully integrated into the network. Like I said, I'm still ambivalent about this patch (for multiple reasons), but saying blacklisting Tor by default might give people the wrong impression of what it does. In the words of BitcoinXT site [1]: "This patch set introduces code that runs when a node is full and otherwise could not accept new connections. It labels and prioritises connections according to lists of IP ranges: if a high priority IP address connects and the node is full, it will disconnect a lower priority connection to make room. Currently Tor exits are labelled as being lower priority than regular IP addresses, as jamming attacks via Tor have been observed, and most users/merchants don't use it. In normal operation this new code will never run. If someone performs a DoS attack via Tor, then legitimate Tor users will get the existing behaviour of being unable to connect, but mobile and home users will still be able to use the network without disruption." I've looked at the patch, and that's pretty much what it does [2]. 1. https://bitcoinxt.software/patches.html https://bitcoinxt.software/patches.html 2. https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23 https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8...