5 ms·

This is a really complicated discussion, that has been splashed all over reddit and other forums for the last year. The reality is that the network is rapidly a

This is a really complicated discussion, that has been splashed all over reddit and other forums for the last year. The reality is that the network is rapidly approaching if it hasn't already exceeded capacity at 1 MB. This doesn't break the network, but it ends up with load sheddding (people who no longer transact) and worse, people who transact but due to rapidly changing fees have to wait in line indefinitely to get their first confirmation. The mempool will eventually randomly eject transactions, but this can cause issues for wallets and other services. To say that centralization increases dramatically at 2 MB just isn't the case. Once people stop running full nodes because they don't believe in Bitcoin's potential as a transaction network then what? This is all about control, who gets to control the fate of the Bitcoin network, and right now that battle is being waged between large well funded companies each of which has its own vision for what Bitcoin is. Development should under no circumstances be centralized with one entity, but there you have it. The only people who benefit from bitcoin being unable to scale are those who want it to simply be a digital gold / store of value, and those that sell alternative solutions for various markets. This is just going to lead to capital flight from Bitcoin into alternative networks that have a growth potential despite being inferior at the moment.

xkarga00 11y ago
That's exactly the reason why I believe in the potential of Decred. https://www.decred.org/ https://www.decred.org/
- completereset 11y ago
  And how is Decred better exactly at scaling?
  - xkarga00 11y ago
    It doesn't need to be at this stage. It's better at governance by combining PoW and PoS mining ie. everybody has a saying on what the next block will be. It only remains to be seen if it will fulfill its potential.
nadaviv 11y ago
The fact is that transactions still consistently and reliably get mined quickly with reasonable fees of 40-50 satoshis/byte [0] [1], or roughly $0.04-$0.05 for an average 250 bytes tx. For a global payment network that provides non-reversible payments and near-instant (within a block) settlement, this is a dirt cheap. The only real issue we're experiencing is due to broken wallets that don't handle fees well. Fortunately, most modern wallets today do handle fees properly, and users are slowly moving away from unmaintained wallet software that don't (the main culprit being blockchain.info's wallet). The median time for fee paying transactions to get confirmed has been 12 minutes at peak [2] (note that 10 minutes is the average time between blocks, and so the absolute minimum possible average time for the first confirmation), which shows us that the majority of transactions are being conducted using proper wallet software which does not cause delays. In reality, actual bitcoin-using customers that are detached from all the drama in the online bitcoin community don't actually experience any degraded service or delays (again, except for these using broken wallets), and would be very surprised to learn about all the drama going on. > Development should under no circumstances be centralized with one entity, but there you have it. Bitcoin Core is not really an "entity". It is a diverse set of technical experts working on improving Bitcoin using a consensus-driven decision making process. There are hundreds of contributors from various backgrounds, associations, and geographical locations. Communication and discussions are all being done in the open, in mailing lists, GitHub and IRC. There is no hierarchy and no one is in charge, and community members have repeatedly shown their dedication to the consensus-driven approach and opposition to merging controversial changes. This development process has made Bitcoin very resilient to hasty decisions driven by populism, political forces and tyranny of the majority situations. > those who want it to simply be a digital gold / store of value Straw man? I'm not sure who you're referring to exactly. There are people who want bitcoin to scale using on-chain capacity, and others that want bitcoin to scale using a multi-layered system with the blockchain as the settlement layer and payment channels acting as a write cache. I'm not aware of any group of people that don't want it to scale at all. If anything, I would say that these advocating for a multi-layered system are more true to the original vision of bitcoin as an "electronic cash system". Using a write cache would allow for really instant (safe zero-conf), really micro (down to tiny fractions of a cent), really low-fees (approaching zero) and really high-volume (orders of magnitude more than what's possible using blockchain alone) payments -- basically, what bitcoin has always been sold as, but never actually was. [0] https://bitcoinfees.21.co/ https://bitcoinfees.21.co/ [1] https://bitcoinfees.github.io/ https://bitcoinfees.github.io/ [2] https://blockchain.info/charts/avg-confirmation-time?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address= https://blockchain.info/charts/avg-confirmation-time?timespa...
nadaviv 11y ago
> To say that centralization increases dramatically at 2 MB just isn't the case. No one is saying that. Core's SegWit proposal also gives us an effective blocksize of ~2mb, the same as Classic - only without requiring a coordinated network-wide upgrade and without the risk of splitting the payment network and currency in two if everyone doesn't upgrade in time. This is the more responsible way to deploy such an upgrade, especially if you consider the capacity bump to be urgent. (a safe hard-fork would require a grace period of 6-12 months to wait for everyone to upgrade, and so would be much slower to roll out than SegWit) Also, several of the Bitcoin Core members have committed to coding an hard-fork proposal for raising the block size limit within a few months, and to bring it up to the wider development community to gather consensus. I do agree that this isn't about the technical issues, but about control. The bitcoin development community has been very responsive and insightful throughout the scaling debate, and has provided us with great technical solutions to some very difficult problems. The ones opposing the Bitcoin Core development community seem to disregard the technical merit of their proposals in favor of repeating personal attacks, conspiracy theories and toxicity. This is creating an hostile environment that developers will start running away from... which is a shame, because we don't really have any developers to spare - people with intersection of the domain knowledge required to work on Bitcoin (cryptography, distributed networks, game theory, economics, computer science, etc) are VERY rare.
- pmorici 11y ago
  >No one is saying that. Core's SegWit proposal also gives us an effective blocksize of ~2mb, the same as Classic - only without requiring a coordinated network-wide upgrade and without the risk of splitting the payment network and currency in two if everyone doesn't upgrade in time. If that is such a huge concern then why is core proposing a hard-fork to change the way the difficulty is adjusted? [0] If they are for adjusting the difficulty computation why not raise the block size at the same time? [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012489.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016...
  - nadaviv 11y ago
    "Core" is not proposing anything, that difficulty adjustment hard-fork proposal was brought up on the mailing list by a member of the community and is in early discussion stages. There's no consensus that this change is necessary, and there hasn't been an in-depth discussion about how and when it should be incorporated (if accepted) and whether it should be alongside the block-size hard-fork or separately.

xkarga00 11y ago

That's exactly the reason why I believe in the potential of Decred. https://www.decred.org/ https://www.decred.org/

completereset 11y ago
And how is Decred better exactly at scaling?
- xkarga00 11y ago
  It doesn't need to be at this stage. It's better at governance by combining PoW and PoS mining ie. everybody has a saying on what the next block will be. It only remains to be seen if it will fulfill its potential.

nadaviv 11y ago

The fact is that transactions still consistently and reliably get mined quickly with reasonable fees of 40-50 satoshis/byte [0] [1], or roughly $0.04-$0.05 for an average 250 bytes tx. For a global payment network that provides non-reversible payments and near-instant (within a block) settlement, this is a dirt cheap. The only real issue we're experiencing is due to broken wallets that don't handle fees well. Fortunately, most modern wallets today do handle fees properly, and users are slowly moving away from unmaintained wallet software that don't (the main culprit being blockchain.info's wallet). The median time for fee paying transactions to get confirmed has been 12 minutes at peak [2] (note that 10 minutes is the average time between blocks, and so the absolute minimum possible average time for the first confirmation), which shows us that the majority of transactions are being conducted using proper wallet software which does not cause delays. In reality, actual bitcoin-using customers that are detached from all the drama in the online bitcoin community don't actually experience any degraded service or delays (again, except for these using broken wallets), and would be very surprised to learn about all the drama going on. > Development should under no circumstances be centralized with one entity, but there you have it. Bitcoin Core is not really an "entity". It is a diverse set of technical experts working on improving Bitcoin using a consensus-driven decision making process. There are hundreds of contributors from various backgrounds, associations, and geographical locations. Communication and discussions are all being done in the open, in mailing lists, GitHub and IRC. There is no hierarchy and no one is in charge, and community members have repeatedly shown their dedication to the consensus-driven approach and opposition to merging controversial changes. This development process has made Bitcoin very resilient to hasty decisions driven by populism, political forces and tyranny of the majority situations. > those who want it to simply be a digital gold / store of value Straw man? I'm not sure who you're referring to exactly. There are people who want bitcoin to scale using on-chain capacity, and others that want bitcoin to scale using a multi-layered system with the blockchain as the settlement layer and payment channels acting as a write cache. I'm not aware of any group of people that don't want it to scale at all. If anything, I would say that these advocating for a multi-layered system are more true to the original vision of bitcoin as an "electronic cash system". Using a write cache would allow for really instant (safe zero-conf), really micro (down to tiny fractions of a cent), really low-fees (approaching zero) and really high-volume (orders of magnitude more than what's possible using blockchain alone) payments -- basically, what bitcoin has always been sold as, but never actually was. [0] https://bitcoinfees.21.co/ https://bitcoinfees.21.co/ [1] https://bitcoinfees.github.io/ https://bitcoinfees.github.io/ [2] https://blockchain.info/charts/avg-confirmation-time?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address= https://blockchain.info/charts/avg-confirmation-time?timespa...

nadaviv 11y ago

> To say that centralization increases dramatically at 2 MB just isn't the case. No one is saying that. Core's SegWit proposal also gives us an effective blocksize of ~2mb, the same as Classic - only without requiring a coordinated network-wide upgrade and without the risk of splitting the payment network and currency in two if everyone doesn't upgrade in time. This is the more responsible way to deploy such an upgrade, especially if you consider the capacity bump to be urgent. (a safe hard-fork would require a grace period of 6-12 months to wait for everyone to upgrade, and so would be much slower to roll out than SegWit) Also, several of the Bitcoin Core members have committed to coding an hard-fork proposal for raising the block size limit within a few months, and to bring it up to the wider development community to gather consensus. I do agree that this isn't about the technical issues, but about control. The bitcoin development community has been very responsive and insightful throughout the scaling debate, and has provided us with great technical solutions to some very difficult problems. The ones opposing the Bitcoin Core development community seem to disregard the technical merit of their proposals in favor of repeating personal attacks, conspiracy theories and toxicity. This is creating an hostile environment that developers will start running away from... which is a shame, because we don't really have any developers to spare - people with intersection of the domain knowledge required to work on Bitcoin (cryptography, distributed networks, game theory, economics, computer science, etc) are VERY rare.

pmorici 11y ago
>No one is saying that. Core's SegWit proposal also gives us an effective blocksize of ~2mb, the same as Classic - only without requiring a coordinated network-wide upgrade and without the risk of splitting the payment network and currency in two if everyone doesn't upgrade in time. If that is such a huge concern then why is core proposing a hard-fork to change the way the difficulty is adjusted? [0] If they are for adjusting the difficulty computation why not raise the block size at the same time? [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012489.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016...
- nadaviv 11y ago
  "Core" is not proposing anything, that difficulty adjustment hard-fork proposal was brought up on the mailing list by a member of the community and is in early discussion stages. There's no consensus that this change is necessary, and there hasn't been an in-depth discussion about how and when it should be incorporated (if accepted) and whether it should be alongside the block-size hard-fork or separately.