5 ms·

Not a great article. Perhaps best to downvote until a better one comes along. Things to consider, which most people can agree on : - SegWit2X [ segwit featur

by jgord 9y ago

Not a great article. Perhaps best to downvote until a better one comes along. Things to consider, which most people can agree on : - SegWit2X [ segwit feature, followed by 2MB block size ] is seen as a compromise worth taking to move things forward past the current impasse, by a range of people who dislike SegWit and think an actual blocksize increase is urgently needed - There is an immediate scaling problem : The mean and median blocksize is converging on the max blocksize of 1MB, and transactions waiting to get into the block blow out on a daily basis to 20MB. This backlog of waiting transactions causes users to pay high fees to get their transaction to the front of the queue, and causes delays in processing/confirmation times. - there is a less urgent longer term scaling problem due to the linear architecture of the blockchain itself My personal viewpoint : - if you are only processing 3 transactions per second, there is substantial room for performance increases - SegWit may help slightly in alleviating transaction pressure, and a 2MB block size will help a bit more. Given the voracity of the debate, SegWit2X is a practical compromise we should adopt to move forward. The USD/BTC market seems to agree with this. - We do need a schedule for block increases over the next couple years so all parties have certainty, and so it doesn't create renewed havoc every few months. - blocksize is just the first of several engineering optimizations that could see transaction throughput on the same linear architecture increase over 1000x. eg. We have a 150GB full blockchain - it would be half the size on disk if compressed. - Even if LN or side chains are the way to scale, and only 0.1% of transactions are 'settled' on the main chain, we will still need a more efficient main blockchain, because the growth of transaction volumes will likely be exponential for the next decade. - some people think the blocksize is a fundamental part of the genius breakthrough in technology that is the blockchain, and so cannot be tinkered with. This is wrong. Proof-of-work, monetary supply, miner reward, chained hash of the blocks, longest block wins, distributed redundancy are fundamental ideas at the core of bitcoin .. but blocksize is merely a technical issue, an artificial limit that was there to make implementation simpler, and always assumed that it would need to be increased well before it became an issue.

rothbardrand 9y ago
Unless things have changed in the last week, your info on the backlog of transactions is out of date. There was a concerted spam campaign from April to June of this year that made the backlog grow and transaction fees go up, but that has ended around the time Segwit2X was getting committed. You also don't seem to understand that Segwit is an increase in the block size, up to about 4MB, and there are very good engineering reasons for keeping blocks smaller-- namely larger blocks increase centralization when the Great Firewall of China is taken into account.
- jgord 9y ago
  Everyone can look at the numbers and decide the most plausible explanation : https://blockchain.info/charts/avg-block-size?timespan=all https://blockchain.info/charts/avg-block-size?timespan=all To my eyes, thats a graph of user growth, not a spam attack. Similarly, this graph tells the story of an artificial barrier being hit up against : https://quantblog.files.wordpress.com/2017/07/median_mean_blocksize.png https://quantblog.files.wordpress.com/2017/07/median_mean_bl... In June mempools did go up to 100 or 120 MB ... I think due to new users, who then backed off as fees went up .. but even if we factor that out, there has been a steady increase over the past several years, and mempools are routinely up to 20MB every day - ie. 20x times the number of transactions are waiting for a block, as can fit in that block .. so they have to wait around to be cleared. This is not due mainly to spam, it is due to users wanting to send money with bitcoin. I disagree that "SegWit is a block size increase" - taking the signature data out of the transaction, means the same 1MB block can squeeze in more transactions, but I think a more honest way of saying this is block "compression" or call it an "effective block size increase". If segwit saves 50-60% of transaction space in the block buffer, then combined with an actual 2x blocksize increase, thats an effective block increase of ~4x .. which is urgently needed. I also disagree that blocks need to be small due to the 'firewall of china centralization issue'. I suspect 8MB blocks would flow rather well across Chinas virtual borders, particularly if there are good economic reasons for those blocks to flow. Keep in mind we're talking a paltry 200MB of transactions per day .. I'm sure that level of bandwidth is dwarfed by general internet traffic. Your explanations are presented as "very good engineering reasons", but I genuinely don't think they are. Speaking plainly - transaction throughput, and thus user growth, is being strangled by a small block size.
  - jgord 9y ago
    mempool size over the past 30 days : https://blockchain.info/charts/mempool-size?timespan=30days https://blockchain.info/charts/mempool-size?timespan=30days Its almost never below 15MB - ie 15x as many transactions waiting to be processed, as can possibly fit in the next block. [ and blocks arrive on average every 10mins, so its a long wait to clear out the daily peak ] To me these stats really do present a "very good engineering reason" to increase blocksize.
knocte 9y ago
> - There is an immediate scaling problem: The mean and median blocksize is converging on the max blocksize of 1MB, and transactions waiting to get into the block blow out on a daily basis to 20MB. This backlog of waiting transactions causes users to pay high fees to get their transaction to the front of the queue, and causes delays in processing/confirmation times. Refuted: https://twitter.com/aantonop/status/885840778630541312 https://twitter.com/aantonop/status/885840778630541312 > Given the voracity of the debate, SegWit2X is a practical compromise we should adopt to move forward Agreed. > because the growth of transaction volumes will likely be exponential for the next decade. Maybe the answer to this is extreme-pruning blockchains, e.g. MimbleWimble. > some people think the blocksize is a fundamental part of the genius breakthrough in technology that is the blockchain, and so cannot be tinkered with. This is wrong I don't think they claim that blocksize is directly fundamental, what they might say is that decentralization is fundamental, and blocksize changes could undermine it.
- knocte 9y ago
  > Refuted: https://twitter.com/aantonop/status/885840778630541312 https://twitter.com/aantonop/status/885840778630541312 Possibly more digestible/readable sources: https://news.bitcoin.com/bitcoin-network-spam-attack-one-users-white-whale/ https://news.bitcoin.com/bitcoin-network-spam-attack-one-use... , https://bravenewcoin.com/news/bitcoin-spam-attack-stressed-network-for-at-least-18-months-claims-software-developer/ https://bravenewcoin.com/news/bitcoin-spam-attack-stressed-n...
h1d 9y ago
> USD/BTC market seems to agree They rallied back because of BIP 91 being locked in leading for SegWit activation later. Nothing to do with 2x increase at the moment. > immediate scaling problem. This was spam tx likely from miners who insist on bigger blocks. The backlogs have been reduced now. https://blockchain.info/charts/mempool-count?timespan=1year https://blockchain.info/charts/mempool-count?timespan=1year > half the size It's not compressable. Why would they not compress if it was possible already? Block size increase is not engineering, it's giving up on thinking as it drags disk space and bandwidth with the increase and not solving a thing for the future.

by jgord 9y ago

rothbardrand 9y ago

Unless things have changed in the last week, your info on the backlog of transactions is out of date. There was a concerted spam campaign from April to June of this year that made the backlog grow and transaction fees go up, but that has ended around the time Segwit2X was getting committed. You also don't seem to understand that Segwit is an increase in the block size, up to about 4MB, and there are very good engineering reasons for keeping blocks smaller-- namely larger blocks increase centralization when the Great Firewall of China is taken into account.

jgord 9y ago
Everyone can look at the numbers and decide the most plausible explanation : https://blockchain.info/charts/avg-block-size?timespan=all https://blockchain.info/charts/avg-block-size?timespan=all To my eyes, thats a graph of user growth, not a spam attack. Similarly, this graph tells the story of an artificial barrier being hit up against : https://quantblog.files.wordpress.com/2017/07/median_mean_blocksize.png https://quantblog.files.wordpress.com/2017/07/median_mean_bl... In June mempools did go up to 100 or 120 MB ... I think due to new users, who then backed off as fees went up .. but even if we factor that out, there has been a steady increase over the past several years, and mempools are routinely up to 20MB every day - ie. 20x times the number of transactions are waiting for a block, as can fit in that block .. so they have to wait around to be cleared. This is not due mainly to spam, it is due to users wanting to send money with bitcoin. I disagree that "SegWit is a block size increase" - taking the signature data out of the transaction, means the same 1MB block can squeeze in more transactions, but I think a more honest way of saying this is block "compression" or call it an "effective block size increase". If segwit saves 50-60% of transaction space in the block buffer, then combined with an actual 2x blocksize increase, thats an effective block increase of ~4x .. which is urgently needed. I also disagree that blocks need to be small due to the 'firewall of china centralization issue'. I suspect 8MB blocks would flow rather well across Chinas virtual borders, particularly if there are good economic reasons for those blocks to flow. Keep in mind we're talking a paltry 200MB of transactions per day .. I'm sure that level of bandwidth is dwarfed by general internet traffic. Your explanations are presented as "very good engineering reasons", but I genuinely don't think they are. Speaking plainly - transaction throughput, and thus user growth, is being strangled by a small block size.
- jgord 9y ago
  mempool size over the past 30 days : https://blockchain.info/charts/mempool-size?timespan=30days https://blockchain.info/charts/mempool-size?timespan=30days Its almost never below 15MB - ie 15x as many transactions waiting to be processed, as can possibly fit in the next block. [ and blocks arrive on average every 10mins, so its a long wait to clear out the daily peak ] To me these stats really do present a "very good engineering reason" to increase blocksize.

knocte 9y ago

> - There is an immediate scaling problem: The mean and median blocksize is converging on the max blocksize of 1MB, and transactions waiting to get into the block blow out on a daily basis to 20MB. This backlog of waiting transactions causes users to pay high fees to get their transaction to the front of the queue, and causes delays in processing/confirmation times. Refuted: https://twitter.com/aantonop/status/885840778630541312 https://twitter.com/aantonop/status/885840778630541312 > Given the voracity of the debate, SegWit2X is a practical compromise we should adopt to move forward Agreed. > because the growth of transaction volumes will likely be exponential for the next decade. Maybe the answer to this is extreme-pruning blockchains, e.g. MimbleWimble. > some people think the blocksize is a fundamental part of the genius breakthrough in technology that is the blockchain, and so cannot be tinkered with. This is wrong I don't think they claim that blocksize is directly fundamental, what they might say is that decentralization is fundamental, and blocksize changes could undermine it.

knocte 9y ago
> Refuted: https://twitter.com/aantonop/status/885840778630541312 https://twitter.com/aantonop/status/885840778630541312 Possibly more digestible/readable sources: https://news.bitcoin.com/bitcoin-network-spam-attack-one-users-white-whale/ https://news.bitcoin.com/bitcoin-network-spam-attack-one-use... , https://bravenewcoin.com/news/bitcoin-spam-attack-stressed-network-for-at-least-18-months-claims-software-developer/ https://bravenewcoin.com/news/bitcoin-spam-attack-stressed-n...

h1d 9y ago

> USD/BTC market seems to agree They rallied back because of BIP 91 being locked in leading for SegWit activation later. Nothing to do with 2x increase at the moment. > immediate scaling problem. This was spam tx likely from miners who insist on bigger blocks. The backlogs have been reduced now. https://blockchain.info/charts/mempool-count?timespan=1year https://blockchain.info/charts/mempool-count?timespan=1year > half the size It's not compressable. Why would they not compress if it was possible already? Block size increase is not engineering, it's giving up on thinking as it drags disk space and bandwidth with the increase and not solving a thing for the future.