Re: [bitcoin-dev] Yet another blocklimit proposal / compromise
On Sep 11, 2015 1:54 PM, "Marcel Jamin" wrote: > And what they felt "remained fair to all to all miners and node operators worldwide." Increasing network connection requirements might even decrease mining centralization right now. No. People seem to think "Chinese have slow connections? Screw them, free competition." But not being well connected with the other miners is not a problem for the Chinese miners (who are the hashrate majority), it's a problem for the rest of the miners!! It's not about being well connected to the "global internet", it's about being well connected to the hashrate majority. > 2015-09-11 18:47 GMT+02:00 Adam Back : >> >> Bitcoin security depends on the enforcement of consensus rules which >> is done by economically dependent full nodes. This is distinct from >> miners fullnodes, and balances miners interests, otherwise SPV nodes >> and decentralisation of policy would tend degrade, I think. Therefore >> it is important that it be reasonably convenient to run full nodes for >> decentralisation security. >> >> Also you may want to read this summary of Bitcoin decentralisation by Mark: >> >> https://www.reddit.com/r/Bitcoin/comments/3h7eei/greg_luke_adam_if_xt_takes_over_and_wins_the/cu53eq3 >> >> I think you maybe misunderstanding what the Chinese miners said also, >> about 8MB, that was a cap on the maximum they felt they could handle >> with current network infrastructure. >> >> I had proposed 2-4-8MB growing over a 4 year time frame with 2MB once >> the hard-fork is upgraded by everyone in the network. (I dont >> consider miner triggers, as with soft-fork upgrades, to be an >> appropriate roll out mechanism because it is more important that >> economically dependent full nodes upgrade, though it can be useful to >> know that miners also have upgraded to a reasonable extent to avoid a >> temporary hashrate drop off affecting security). >> >> Adam >> >> On 9 September 2015 at 15:00, Marcel Jamin via bitcoin-dev >> wrote: >> > I think the overlap of people who want to run a serious mining operation and >> > people who are unable to afford a slightly above average internet connection >> > is infinitesimally small. >> > >> > 2015-09-09 20:51 GMT+02:00 Jorge Timón : >> >> >> >> >> >> On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" >> >> wrote: >> >> > >> >> > I propose to: >> >> > >> >> > a) assess what blocklimit is currently technically possible without >> >> > driving up costs of running a node up too much. Most systems currently >> >> > running a fullnode probably have some capacity left. >> >> >> >> What about the risk of further increasing mining centralization? >> > >> > >> > >> > ___ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Yet another blocklimit proposal / compromise
> Therefore it is important that it be reasonably convenient to run full nodes for decentralisation security. Yes, and I'm suggesting to define what "reasonably convenient" is in 2016. Most likely node operators have more than a little headroom for larger blocks. If you just use more of the processing power / storage / bandwidth you very likely already paid for then there is no increase in costs. > I think you maybe misunderstanding what the Chinese miners said also, about 8MB, that was a cap on the maximum they felt they could handle with current network infrastructure. And what they felt "remained fair to all to all miners and node operators worldwide." Increasing network connection requirements might even decrease mining centralization right now. 2015-09-11 18:47 GMT+02:00 Adam Back : > Bitcoin security depends on the enforcement of consensus rules which > is done by economically dependent full nodes. This is distinct from > miners fullnodes, and balances miners interests, otherwise SPV nodes > and decentralisation of policy would tend degrade, I think. Therefore > it is important that it be reasonably convenient to run full nodes for > decentralisation security. > > Also you may want to read this summary of Bitcoin decentralisation by Mark: > > > https://www.reddit.com/r/Bitcoin/comments/3h7eei/greg_luke_adam_if_xt_takes_over_and_wins_the/cu53eq3 > > I think you maybe misunderstanding what the Chinese miners said also, > about 8MB, that was a cap on the maximum they felt they could handle > with current network infrastructure. > > I had proposed 2-4-8MB growing over a 4 year time frame with 2MB once > the hard-fork is upgraded by everyone in the network. (I dont > consider miner triggers, as with soft-fork upgrades, to be an > appropriate roll out mechanism because it is more important that > economically dependent full nodes upgrade, though it can be useful to > know that miners also have upgraded to a reasonable extent to avoid a > temporary hashrate drop off affecting security). > > Adam > > On 9 September 2015 at 15:00, Marcel Jamin via bitcoin-dev > wrote: > > I think the overlap of people who want to run a serious mining operation > and > > people who are unable to afford a slightly above average internet > connection > > is infinitesimally small. > > > > 2015-09-09 20:51 GMT+02:00 Jorge Timón : > >> > >> > >> On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" > >> wrote: > >> > > >> > I propose to: > >> > > >> > a) assess what blocklimit is currently technically possible without > >> > driving up costs of running a node up too much. Most systems currently > >> > running a fullnode probably have some capacity left. > >> > >> What about the risk of further increasing mining centralization? > > > > > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Yet another blocklimit proposal / compromise
Bitcoin security depends on the enforcement of consensus rules which is done by economically dependent full nodes. This is distinct from miners fullnodes, and balances miners interests, otherwise SPV nodes and decentralisation of policy would tend degrade, I think. Therefore it is important that it be reasonably convenient to run full nodes for decentralisation security. Also you may want to read this summary of Bitcoin decentralisation by Mark: https://www.reddit.com/r/Bitcoin/comments/3h7eei/greg_luke_adam_if_xt_takes_over_and_wins_the/cu53eq3 I think you maybe misunderstanding what the Chinese miners said also, about 8MB, that was a cap on the maximum they felt they could handle with current network infrastructure. I had proposed 2-4-8MB growing over a 4 year time frame with 2MB once the hard-fork is upgraded by everyone in the network. (I dont consider miner triggers, as with soft-fork upgrades, to be an appropriate roll out mechanism because it is more important that economically dependent full nodes upgrade, though it can be useful to know that miners also have upgraded to a reasonable extent to avoid a temporary hashrate drop off affecting security). Adam On 9 September 2015 at 15:00, Marcel Jamin via bitcoin-dev wrote: > I think the overlap of people who want to run a serious mining operation and > people who are unable to afford a slightly above average internet connection > is infinitesimally small. > > 2015-09-09 20:51 GMT+02:00 Jorge Timón : >> >> >> On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" >> wrote: >> > >> > I propose to: >> > >> > a) assess what blocklimit is currently technically possible without >> > driving up costs of running a node up too much. Most systems currently >> > running a fullnode probably have some capacity left. >> >> What about the risk of further increasing mining centralization? > > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Yet another blocklimit proposal / compromise
Unfortunately the relation between block maximum size and mining centralization is much more complex than that. On Sep 9, 2015 3:00 PM, "Marcel Jamin" wrote: > I think the overlap of people who want to run a serious mining operation > and people who are unable to afford a slightly above average internet > connection is infinitesimally small. > > 2015-09-09 20:51 GMT+02:00 Jorge Timón : > >> >> On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> > >> > I propose to: >> > >> > a) assess what blocklimit is currently technically possible without >> driving up costs of running a node up too much. Most systems currently >> running a fullnode probably have some capacity left. >> >> What about the risk of further increasing mining centralization? >> > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Yet another blocklimit proposal / compromise
I think the overlap of people who want to run a serious mining operation and people who are unable to afford a slightly above average internet connection is infinitesimally small. 2015-09-09 20:51 GMT+02:00 Jorge Timón : > > On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > I propose to: > > > > a) assess what blocklimit is currently technically possible without > driving up costs of running a node up too much. Most systems currently > running a fullnode probably have some capacity left. > > What about the risk of further increasing mining centralization? > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Yet another blocklimit proposal / compromise
On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I propose to: > > a) assess what blocklimit is currently technically possible without driving up costs of running a node up too much. Most systems currently running a fullnode probably have some capacity left. What about the risk of further increasing mining centralization? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Yet another blocklimit proposal / compromise
I propose to: a) assess what blocklimit is currently technically possible without driving up costs of running a node up too much. Most systems currently running a fullnode probably have some capacity left. b) set the determined blocklimit at the next reward halving c) then double the blocksize limit at every halving thereafter up to a hardlimit of 8GB. Reasoning: Doubling every four years will stay within expected technological growth. Cisco's VNI forecast predicts a 2.1-fold increase in global average fixed broadand speed from 2014 to 2019. Nielsen's law, which looks more at the power user (probably more fitting) is even more optimistic with +50% per year. This proposal can be considered a compromise between Pieter's and Gavin's proposals. While the growth rate is more or less what Pieter proposes, it includes an initial increase to kickstart the growth. If we start with 8MB, which seems to be popular among miners, we would reach 8GB in 2056 (as opposed to 2036 in BIP101). The start date (ca. mid 2016) is also a compromise between Pieter's 01/2017 and Gavin's 01/2016. It's simple, predictable and IMHO elegant -- block subsidy halves, blocksize limit doubles. It might make sense to update the limit more often in between, though. Either completely linearly based on a block's timestamp like in BIP101, or for example for each difficulty period. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
