3 ms·

1) The 1.7 figure is outdated, the latest one from a research by BitFury in November 2016 is 2.1MB [0]. It's probably somewhat higher now. Yes, it does require

1) The 1.7 figure is outdated, the latest one from a research by BitFury in November 2016 is 2.1MB [0]. It's probably somewhat higher now. Yes, it does require wallets to upgrade - but most of them (and all of the major ones) already have segwit implemented [1]. In addition, once a few of the major players that produce lots and lots of transactions upgrade, the fee pressure will level down for everyone, even these who did not upgrade for SegWit. Yes, it is a one-time increase, but one that is sufficient for now. Let's start by doubling the block size first, collect more data, then decide how to further increase the blocksize as the need arises. 2) I'm not seeing that they're going against the community. The technical, business and wide bitcoin community are all looking forward eagerly for segwit's activation. Edit: also, in the case of a hard-fork, users who don't upgrade gets cut off the network entirely. is it not preferable to keep them a part of the network, with somewhat higher fees but a functional wallet otherwise? [0] https://www.weusecoins.com/eli-segwit/ https://www.weusecoins.com/eli-segwit/ [1] https://bitcoincore.org/en/segwit_adoption/ https://bitcoincore.org/en/segwit_adoption/

out_of_protocol 9y ago
1) Still, a lot lower than required. Blocks became full like a year ago (see http://i.imgur.com/d7fwVnd.jpg http://i.imgur.com/d7fwVnd.jpg ) and after that moment fitting transactions within 1MB limit means someone's stopped using bitcoin (me included :( ). +500kB is not gonna change that anyhow ( +1.1MB x 50% adoption). even +1.1MB not nearly enough. > but one that is sufficient for now not really - see above. 2) > The technical, business and wide bitcoin community are all looking forward eagerly Do they understand segwit activation provides zero benefits at moment of said activation? 3) Overall, we're in the stage of planned bitcoin deconstruction. Gladly, there are no way to kill cryptocurrencies - even if bitcoin going to die, someone else will take it's place (related: see "bitcoin market share" chart) P.S. We're talking about wrong problem. "How exactly 2MB blocks should be implemented" is surely wrong direction of talks. Yet we're here for like two years and counting. Whole ecosystem could be progressed by a lot during this time
kobeya 9y ago
> In addition, once a few of the major players that produce lots and lots of transactions upgrade, the fee pressure will level down for everyone Also anyone who upgrades immediately gets the benefit of lower fees. Their transactions are halved in size, from the fee calculation perspective.

out_of_protocol 9y ago

1) Still, a lot lower than required. Blocks became full like a year ago (see http://i.imgur.com/d7fwVnd.jpg http://i.imgur.com/d7fwVnd.jpg ) and after that moment fitting transactions within 1MB limit means someone's stopped using bitcoin (me included :( ). +500kB is not gonna change that anyhow ( +1.1MB x 50% adoption). even +1.1MB not nearly enough. > but one that is sufficient for now not really - see above. 2) > The technical, business and wide bitcoin community are all looking forward eagerly Do they understand segwit activation provides zero benefits at moment of said activation? 3) Overall, we're in the stage of planned bitcoin deconstruction. Gladly, there are no way to kill cryptocurrencies - even if bitcoin going to die, someone else will take it's place (related: see "bitcoin market share" chart) P.S. We're talking about wrong problem. "How exactly 2MB blocks should be implemented" is surely wrong direction of talks. Yet we're here for like two years and counting. Whole ecosystem could be progressed by a lot during this time

kobeya 9y ago

> In addition, once a few of the major players that produce lots and lots of transactions upgrade, the fee pressure will level down for everyone Also anyone who upgrades immediately gets the benefit of lower fees. Their transactions are halved in size, from the fee calculation perspective.