* [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M @ 2015-11-12 23:47 John Sacco 2015-11-13 2:56 ` Chun Wang 0 siblings, 1 reply; 15+ messages in thread From: John Sacco @ 2015-11-12 23:47 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2350 bytes --] Hi Devs, Please consider the draft proposal below for peer review. Thanks, John BIP BIP: ? Title: Block size doubles at each reward halving with max block size of 32M Author: John Sacco <johnsock@gmail•com> Status: Draft Type: Standards Track Created: 2015-11-11 Abstract Change max block size to 2MB at next block subsidy halving, and double the block size at each subsidy halving until reaching 32MB. Copyright This proposal belongs in the public domain. Anyone can use this text for any purpose with proper attribution to the author. Motivation 1. Gradually restores block size to the default 32 MB setting originally implemented by Satoshi. 2. Initial increase to 2MB at block halving in July 2016 would have minimal impact to existing nodes running on most hardware and networks. 3. Long term solution that does not make enthusiastic assumptions regarding future bandwidth and storage availability estimates. 4. Maximum block size of 32MB allows peak usage of ~100 tx/sec by year 2031. 5. Exercise network upgrade procedure during subsidy reward halving, a milestone event with the goal of increasing awareness among miners and node operators. Specification 1. Increase the maximum block size to 2MB when block 630,000 is reached and 75% of the last 1,000 blocks have signaled support. 2. Increase maximum block size to 4MB at block 840,000. 3. Increase maximum block size to 8MB at block 1,050,000. 4. Increase maximum block size to 16MB at block 1,260,000. 5. Increase maximum block size to 32MB at block 1,470,000. Backward compatibility All older clients are not compatible with this change. The first block larger than 1M will create a network partition excluding not-upgraded network nodes and miners. Rationale While more comprehensive solutions are developed, an increase to the block size is needed to continue network growth. A longer term solution is needed to prevent complications associated with additional hard forks. It should also increase at a gradual rate that retains and allows a large distribution of full nodes. Scheduling this hard fork to occur no earlier than the subsidy halving in 2016 has the goal of simplifying the communication outreach needed to achieve consensus, while also providing a buffer of time to make necessary preparations. [-- Attachment #2: Type: text/html, Size: 12147 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 2015-11-12 23:47 [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M John Sacco @ 2015-11-13 2:56 ` Chun Wang 2015-11-13 3:37 ` John Sacco 2015-11-13 6:39 ` Luke Dashjr 0 siblings, 2 replies; 15+ messages in thread From: Chun Wang @ 2015-11-13 2:56 UTC (permalink / raw) To: John Sacco; +Cc: bitcoin-dev How about these specs: * 1 MB, height < 210000; * 2 MB, 210000 <= height < 420000; * 4 MB, 420000 <= height < 630000; * 8 MB, 630000 <= height < 840000; * 16 MB, 840000 <= height < 1050000; * 32 MB, height >= 1050000. On Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Hi Devs, > > > Please consider the draft proposal below for peer review. > > > Thanks, > > > John > > > BIP > > BIP: ? > > Title: Block size doubles at each reward halving with max block size of > 32M > > Author: John Sacco <johnsock@gmail•com> > > Status: Draft > > Type: Standards Track > > Created: 2015-11-11 > > Abstract > > Change max block size to 2MB at next block subsidy halving, and double the > block size at each subsidy halving until reaching 32MB. > > Copyright > > This proposal belongs in the public domain. Anyone can use this text for any > purpose with proper attribution to the author. > > Motivation > > 1. Gradually restores block size to the default 32 MB setting originally > implemented by Satoshi. > > 2. Initial increase to 2MB at block halving in July 2016 would have > minimal impact to existing nodes running on most hardware and networks. > > 3. Long term solution that does not make enthusiastic assumptions > regarding future bandwidth and storage availability estimates. > > 4. Maximum block size of 32MB allows peak usage of ~100 tx/sec by year > 2031. > > 5. Exercise network upgrade procedure during subsidy reward halving, a > milestone event with the goal of increasing awareness among miners and node > operators. > > Specification > > 1. Increase the maximum block size to 2MB when block 630,000 is reached > and 75% of the last 1,000 blocks have signaled support. > > 2. Increase maximum block size to 4MB at block 840,000. > > 3. Increase maximum block size to 8MB at block 1,050,000. > > 4. Increase maximum block size to 16MB at block 1,260,000. > > 5. Increase maximum block size to 32MB at block 1,470,000. > > Backward compatibility > > All older clients are not compatible with this change. The first block > larger than 1M will create a network partition excluding not-upgraded > network nodes and miners. > > Rationale > > While more comprehensive solutions are developed, an increase to the block > size is needed to continue network growth. A longer term solution is needed > to prevent complications associated with additional hard forks. It should > also increase at a gradual rate that retains and allows a large distribution > of full nodes. Scheduling this hard fork to occur no earlier than the > subsidy halving in 2016 has the goal of simplifying the communication > outreach needed to achieve consensus, while also providing a buffer of time > to make necessary preparations. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 2015-11-13 2:56 ` Chun Wang @ 2015-11-13 3:37 ` John Sacco 2015-11-13 7:49 ` Btc Drak 2015-11-13 6:39 ` Luke Dashjr 1 sibling, 1 reply; 15+ messages in thread From: John Sacco @ 2015-11-13 3:37 UTC (permalink / raw) To: Chun Wang; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3796 bytes --] I like your suggestion for the continuity and it gets us up to 2 MB in the shorter term. Also I just noticed the math error. Here is a revised spec (incorporating suggestions from Chun Wang): Specification * 1 MB, height < 210,000; * 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks signal support) * 4 MB, height 420,000 < 630,000; (year 2016) * 8 MB, height 630,000 < 840,000; (year ~2020) * 16 MB, height 840,000 < 1,050,000; (year ~2024) * 32 MB, height >= 1,050,000. (year ~2028) On Thu, Nov 12, 2015 at 9:56 PM, Chun Wang <1240902@gmail•com> wrote: > How about these specs: > * 1 MB, height < 210000; > * 2 MB, 210000 <= height < 420000; > * 4 MB, 420000 <= height < 630000; > * 8 MB, 630000 <= height < 840000; > * 16 MB, 840000 <= height < 1050000; > * 32 MB, height >= 1050000. > > > On Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Hi Devs, > > > > > > Please consider the draft proposal below for peer review. > > > > > > Thanks, > > > > > > John > > > > > > BIP > > > > BIP: ? > > > > Title: Block size doubles at each reward halving with max block size of > > 32M > > > > Author: John Sacco <johnsock@gmail•com> > > > > Status: Draft > > > > Type: Standards Track > > > > Created: 2015-11-11 > > > > Abstract > > > > Change max block size to 2MB at next block subsidy halving, and double > the > > block size at each subsidy halving until reaching 32MB. > > > > Copyright > > > > This proposal belongs in the public domain. Anyone can use this text for > any > > purpose with proper attribution to the author. > > > > Motivation > > > > 1. Gradually restores block size to the default 32 MB setting > originally > > implemented by Satoshi. > > > > 2. Initial increase to 2MB at block halving in July 2016 would have > > minimal impact to existing nodes running on most hardware and networks. > > > > 3. Long term solution that does not make enthusiastic assumptions > > regarding future bandwidth and storage availability estimates. > > > > 4. Maximum block size of 32MB allows peak usage of ~100 tx/sec by year > > 2031. > > > > 5. Exercise network upgrade procedure during subsidy reward halving, a > > milestone event with the goal of increasing awareness among miners and > node > > operators. > > > > Specification > > > > 1. Increase the maximum block size to 2MB when block 630,000 is > reached > > and 75% of the last 1,000 blocks have signaled support. > > > > 2. Increase maximum block size to 4MB at block 840,000. > > > > 3. Increase maximum block size to 8MB at block 1,050,000. > > > > 4. Increase maximum block size to 16MB at block 1,260,000. > > > > 5. Increase maximum block size to 32MB at block 1,470,000. > > > > Backward compatibility > > > > All older clients are not compatible with this change. The first block > > larger than 1M will create a network partition excluding not-upgraded > > network nodes and miners. > > > > Rationale > > > > While more comprehensive solutions are developed, an increase to the > block > > size is needed to continue network growth. A longer term solution is > needed > > to prevent complications associated with additional hard forks. It should > > also increase at a gradual rate that retains and allows a large > distribution > > of full nodes. Scheduling this hard fork to occur no earlier than the > > subsidy halving in 2016 has the goal of simplifying the communication > > outreach needed to achieve consensus, while also providing a buffer of > time > > to make necessary preparations. > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > [-- Attachment #2: Type: text/html, Size: 6113 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 2015-11-13 3:37 ` John Sacco @ 2015-11-13 7:49 ` Btc Drak 2015-11-13 9:50 ` John Sacco 0 siblings, 1 reply; 15+ messages in thread From: Btc Drak @ 2015-11-13 7:49 UTC (permalink / raw) To: John Sacco; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4615 bytes --] > * 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks signal support) This doesnt give anyone a chance to upgrade and would cause a hard fork the moment a miner created a >1MB block. Flag day (hard fork) upgrades must start the change at a sufficient time in the future (greater than the current block height) to give all nodes the chance to upgrade. On Fri, Nov 13, 2015 at 3:37 AM, John Sacco via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > I like your suggestion for the continuity and it gets us up to 2 MB in the > shorter term. Also I just noticed the math error. > > Here is a revised spec (incorporating suggestions from Chun Wang): > > Specification > > * 1 MB, height < 210,000; > * 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks signal > support) > * 4 MB, height 420,000 < 630,000; (year 2016) > * 8 MB, height 630,000 < 840,000; (year ~2020) > * 16 MB, height 840,000 < 1,050,000; (year ~2024) > * 32 MB, height >= 1,050,000. (year ~2028) > > > On Thu, Nov 12, 2015 at 9:56 PM, Chun Wang <1240902@gmail•com> wrote: > >> How about these specs: >> * 1 MB, height < 210000; >> * 2 MB, 210000 <= height < 420000; >> * 4 MB, 420000 <= height < 630000; >> * 8 MB, 630000 <= height < 840000; >> * 16 MB, 840000 <= height < 1050000; >> * 32 MB, height >= 1050000. >> >> >> On Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation.org> wrote: >> > Hi Devs, >> > >> > >> > Please consider the draft proposal below for peer review. >> > >> > >> > Thanks, >> > >> > >> > John >> > >> > >> > BIP >> > >> > BIP: ? >> > >> > Title: Block size doubles at each reward halving with max block size >> of >> > 32M >> > >> > Author: John Sacco <johnsock@gmail•com> >> > >> > Status: Draft >> > >> > Type: Standards Track >> > >> > Created: 2015-11-11 >> > >> > Abstract >> > >> > Change max block size to 2MB at next block subsidy halving, and double >> the >> > block size at each subsidy halving until reaching 32MB. >> > >> > Copyright >> > >> > This proposal belongs in the public domain. Anyone can use this text >> for any >> > purpose with proper attribution to the author. >> > >> > Motivation >> > >> > 1. Gradually restores block size to the default 32 MB setting >> originally >> > implemented by Satoshi. >> > >> > 2. Initial increase to 2MB at block halving in July 2016 would have >> > minimal impact to existing nodes running on most hardware and networks. >> > >> > 3. Long term solution that does not make enthusiastic assumptions >> > regarding future bandwidth and storage availability estimates. >> > >> > 4. Maximum block size of 32MB allows peak usage of ~100 tx/sec by >> year >> > 2031. >> > >> > 5. Exercise network upgrade procedure during subsidy reward halving, >> a >> > milestone event with the goal of increasing awareness among miners and >> node >> > operators. >> > >> > Specification >> > >> > 1. Increase the maximum block size to 2MB when block 630,000 is >> reached >> > and 75% of the last 1,000 blocks have signaled support. >> > >> > 2. Increase maximum block size to 4MB at block 840,000. >> > >> > 3. Increase maximum block size to 8MB at block 1,050,000. >> > >> > 4. Increase maximum block size to 16MB at block 1,260,000. >> > >> > 5. Increase maximum block size to 32MB at block 1,470,000. >> > >> > Backward compatibility >> > >> > All older clients are not compatible with this change. The first block >> > larger than 1M will create a network partition excluding not-upgraded >> > network nodes and miners. >> > >> > Rationale >> > >> > While more comprehensive solutions are developed, an increase to the >> block >> > size is needed to continue network growth. A longer term solution is >> needed >> > to prevent complications associated with additional hard forks. It >> should >> > also increase at a gradual rate that retains and allows a large >> distribution >> > of full nodes. Scheduling this hard fork to occur no earlier than the >> > subsidy halving in 2016 has the goal of simplifying the communication >> > outreach needed to achieve consensus, while also providing a buffer of >> time >> > to make necessary preparations. >> > >> > >> > _______________________________________________ >> > 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 > > [-- Attachment #2: Type: text/html, Size: 7510 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 2015-11-13 7:49 ` Btc Drak @ 2015-11-13 9:50 ` John Sacco 2015-11-13 10:52 ` Luke Dashjr 0 siblings, 1 reply; 15+ messages in thread From: John Sacco @ 2015-11-13 9:50 UTC (permalink / raw) To: Btc Drak, Luke Dashjr; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5410 bytes --] Revised spec below to put us back at 2 MB at next halving in 2016 (addressing Luke & Drak's points). This is more in line with intent of the original proposal and provides sufficient time to gain consensus. Specification > > > * 2 MB, height 420,000 < 630,000; (fork active when 75% of last 1,000 blocks signal support and block 420,000 reached, ~July 2016) * 4 MB, height 630,000 < 840,000; (year ~2020) * 8 MB, height 840,000 < 1,050,000; (year ~2024) * 16 MB, height 1,050,000 < 1,260,000; (year ~2028) * 32 MB, height >= 1,260,000. (year ~2032) On Fri, Nov 13, 2015 at 2:49 AM, Btc Drak <btcdrak@gmail•com> wrote: > > * 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks signal > support) > > This doesnt give anyone a chance to upgrade and would cause a hard fork > the moment a miner created a >1MB block. Flag day (hard fork) upgrades must > start the change at a sufficient time in the future (greater than the > current block height) to give all nodes the chance to upgrade. > > On Fri, Nov 13, 2015 at 3:37 AM, John Sacco via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> I like your suggestion for the continuity and it gets us up to 2 MB in >> the shorter term. Also I just noticed the math error. >> >> Here is a revised spec (incorporating suggestions from Chun Wang): >> >> Specification >> >> * 1 MB, height < 210,000; >> * 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks signal >> support) >> * 4 MB, height 420,000 < 630,000; (year 2016) >> * 8 MB, height 630,000 < 840,000; (year ~2020) >> * 16 MB, height 840,000 < 1,050,000; (year ~2024) >> * 32 MB, height >= 1,050,000. (year ~2028) >> >> >> On Thu, Nov 12, 2015 at 9:56 PM, Chun Wang <1240902@gmail•com> wrote: >> >>> How about these specs: >>> * 1 MB, height < 210000; >>> * 2 MB, 210000 <= height < 420000; >>> * 4 MB, 420000 <= height < 630000; >>> * 8 MB, 630000 <= height < 840000; >>> * 16 MB, 840000 <= height < 1050000; >>> * 32 MB, height >= 1050000. >>> >>> >>> On Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev >>> <bitcoin-dev@lists•linuxfoundation.org> wrote: >>> > Hi Devs, >>> > >>> > >>> > Please consider the draft proposal below for peer review. >>> > >>> > >>> > Thanks, >>> > >>> > >>> > John >>> > >>> > >>> > BIP >>> > >>> > BIP: ? >>> > >>> > Title: Block size doubles at each reward halving with max block size >>> of >>> > 32M >>> > >>> > Author: John Sacco <johnsock@gmail•com> >>> > >>> > Status: Draft >>> > >>> > Type: Standards Track >>> > >>> > Created: 2015-11-11 >>> > >>> > Abstract >>> > >>> > Change max block size to 2MB at next block subsidy halving, and double >>> the >>> > block size at each subsidy halving until reaching 32MB. >>> > >>> > Copyright >>> > >>> > This proposal belongs in the public domain. Anyone can use this text >>> for any >>> > purpose with proper attribution to the author. >>> > >>> > Motivation >>> > >>> > 1. Gradually restores block size to the default 32 MB setting >>> originally >>> > implemented by Satoshi. >>> > >>> > 2. Initial increase to 2MB at block halving in July 2016 would have >>> > minimal impact to existing nodes running on most hardware and networks. >>> > >>> > 3. Long term solution that does not make enthusiastic assumptions >>> > regarding future bandwidth and storage availability estimates. >>> > >>> > 4. Maximum block size of 32MB allows peak usage of ~100 tx/sec by >>> year >>> > 2031. >>> > >>> > 5. Exercise network upgrade procedure during subsidy reward >>> halving, a >>> > milestone event with the goal of increasing awareness among miners and >>> node >>> > operators. >>> > >>> > Specification >>> > >>> > 1. Increase the maximum block size to 2MB when block 630,000 is >>> reached >>> > and 75% of the last 1,000 blocks have signaled support. >>> > >>> > 2. Increase maximum block size to 4MB at block 840,000. >>> > >>> > 3. Increase maximum block size to 8MB at block 1,050,000. >>> > >>> > 4. Increase maximum block size to 16MB at block 1,260,000. >>> > >>> > 5. Increase maximum block size to 32MB at block 1,470,000. >>> > >>> > Backward compatibility >>> > >>> > All older clients are not compatible with this change. The first block >>> > larger than 1M will create a network partition excluding not-upgraded >>> > network nodes and miners. >>> > >>> > Rationale >>> > >>> > While more comprehensive solutions are developed, an increase to the >>> block >>> > size is needed to continue network growth. A longer term solution is >>> needed >>> > to prevent complications associated with additional hard forks. It >>> should >>> > also increase at a gradual rate that retains and allows a large >>> distribution >>> > of full nodes. Scheduling this hard fork to occur no earlier than the >>> > subsidy halving in 2016 has the goal of simplifying the communication >>> > outreach needed to achieve consensus, while also providing a buffer of >>> time >>> > to make necessary preparations. >>> > >>> > >>> > _______________________________________________ >>> > 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 >> >> > [-- Attachment #2: Type: text/html, Size: 11019 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 2015-11-13 9:50 ` John Sacco @ 2015-11-13 10:52 ` Luke Dashjr [not found] ` <1447430469019.e0ee1956@Nodemailer> 0 siblings, 1 reply; 15+ messages in thread From: Luke Dashjr @ 2015-11-13 10:52 UTC (permalink / raw) To: John Sacco; +Cc: Bitcoin Dev On Friday, November 13, 2015 9:50:47 AM John Sacco wrote: > * 2 MB, height 420,000 < 630,000; (fork active when 75% of last 1,000 blocks > signal support and block 420,000 reached, ~July 2016) I'd leave out the block signalling. It isn't really useful, complicates the whole BIP, and mistakenly gives people the idea that miners have a choice in hardforks. Luke ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <1447430469019.e0ee1956@Nodemailer>]
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M [not found] ` <1447430469019.e0ee1956@Nodemailer> @ 2015-11-13 22:28 ` Luke Dashjr 2015-11-14 0:02 ` digitsu 0 siblings, 1 reply; 15+ messages in thread From: Luke Dashjr @ 2015-11-13 22:28 UTC (permalink / raw) To: digitsu; +Cc: Bitcoin Dev, John Sacco On Friday, November 13, 2015 4:01:09 PM digitsu@gmail•com wrote: > Forgive the frankness but I don't see why signaling your intent to support > an upgrade to one side of a hard fork can be seen as a bad thing. If for > nothing else doesn't this make for a smoother flag day? (Because once you > signal your intention, it makes it hard to back out on the commitment.) It isn't a commitment in any sense, nor does it make it smoother, because for a hardfork to be successful, it is the *economy* that must switch entirely. The miners are unimportant. > If miners don't have any choice in hard forks, who does? Just the core > devs? Devs have even less of a choice in the matter. What is relevant is the economy: who do people want to spend their bitcoins with? There is no programmatic way to determine this, especially not in advance, so the best we can do is a flag day that gets called off if there isn't clear consensus. Luke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 2015-11-13 22:28 ` Luke Dashjr @ 2015-11-14 0:02 ` digitsu 2015-11-14 9:31 ` Adam Back 0 siblings, 1 reply; 15+ messages in thread From: digitsu @ 2015-11-14 0:02 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev, John Sacco [-- Attachment #1: Type: text/plain, Size: 2653 bytes --] Well I'd like to think that with an economy all parts of it interact with each other in ways more complex than simplistic imperative logic. I agree that the economic majority is essentially what matters in a hard fork but everyone (miners,devs,public thought leaders,businesses) is part of that economy. Additionally what miners signal as their intention affects the decision of that economic majority (and vice versa). You can see the effects of this in traditional political processes in how preliminary vote polling results affect (reinforce) the final vote. We also can see the results of this in (dare I mention) the whole XT affair which had the signed intent of many of the economy (payment processors and wallets and one miner pool) and the rest of the miners did not go along with it. This experiment either means that the rest of the miners couldn't be bothered to signal at all (because they didn't know how) or they were affected by the influence of core devs or the opinions of others on the matter and rejected the economic majority. (Which would imply core devs have some power by way of indirect influence) I would be inclined to believe the latter was more likely. The conclusion which this would seem to imply is that at the very least, miners matter (to what exact extent is debatable). And although there is no direct control of any party over the other in the strict sense, the public vocal opinions of any part of the Bitcoin economy does have an effect in its ability to sway the opinions of the other parts. Digitsu — Regards, On Sat, Nov 14, 2015 at 7:29 AM, Luke Dashjr <luke@dashjr•org> wrote: > On Friday, November 13, 2015 4:01:09 PM digitsu@gmail•com wrote: >> Forgive the frankness but I don't see why signaling your intent to support >> an upgrade to one side of a hard fork can be seen as a bad thing. If for >> nothing else doesn't this make for a smoother flag day? (Because once you >> signal your intention, it makes it hard to back out on the commitment.) > It isn't a commitment in any sense, nor does it make it smoother, because for > a hardfork to be successful, it is the *economy* that must switch entirely. > The miners are unimportant. >> If miners don't have any choice in hard forks, who does? Just the core >> devs? > Devs have even less of a choice in the matter. What is relevant is the > economy: who do people want to spend their bitcoins with? There is no > programmatic way to determine this, especially not in advance, so the best we > can do is a flag day that gets called off if there isn't clear consensus. > Luke [-- Attachment #2: Type: text/html, Size: 3098 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 2015-11-14 0:02 ` digitsu @ 2015-11-14 9:31 ` Adam Back 2015-11-14 10:52 ` Jorge Timón 0 siblings, 1 reply; 15+ messages in thread From: Adam Back @ 2015-11-14 9:31 UTC (permalink / raw) To: digitsu; +Cc: Bitcoin Dev, John Sacco There is a difference between miners signalling intent (as they have been for various BIPs, which is mostly informational only - they are mostly not running the code, and in some cases it is not implemented, so they cant be) there is a difference between that and a 95% miner majority consensus rule. Former can be useful information as you said, latter implies as Luke described something that is not really accurate, it is not strictly only a miner upgrade needed for basic safety as with soft-forks. If you look at BIP 103 for example it is flag day based, and I think this is a more accurate approach. Also with miner votes they can be misleading - vote for one thing, but run something else; what they are running is not generally detectable/enforceable - see for example what happened with the BIP66 accidental fork due to "SPV mining" (ie validationless mining). A hard-fork is for everyone to upgrade and talk with each other to see that the vast majority is on the same plan which includes users, ecosystem companies & miners. Adam On 14 November 2015 at 01:02, digitsu412 via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Well I'd like to think that with an economy all parts of it interact with > each other in ways more complex than simplistic imperative logic. > > I agree that the economic majority is essentially what matters in a hard > fork but everyone (miners,devs,public thought leaders,businesses) is part of > that economy. Additionally what miners signal as their intention affects the > decision of that economic majority (and vice versa). You can see the > effects of this in traditional political processes in how preliminary vote > polling results affect (reinforce) the final vote. > We also can see the results of this in (dare I mention) the whole XT affair > which had the signed intent of many of the economy (payment processors and > wallets and one miner pool) and the rest of the miners did not go along with > it. This experiment either means that the rest of the miners couldn't be > bothered to signal at all (because they didn't know how) or they were > affected by the influence of core devs or the opinions of others on the > matter and rejected the economic majority. (Which would imply core devs > have some power by way of indirect influence) I would be inclined to believe > the latter was more likely. > > The conclusion which this would seem to imply is that at the very least, > miners matter (to what exact extent is debatable). And although there is no > direct control of any party over the other in the strict sense, the public > vocal opinions of any part of the Bitcoin economy does have an effect in its > ability to sway the opinions of the other parts. > > Digitsu > > — Regards, > > > On Sat, Nov 14, 2015 at 7:29 AM, Luke Dashjr <luke@dashjr•org> wrote: >> >> On Friday, November 13, 2015 4:01:09 PM digitsu@gmail•com wrote: >> > Forgive the frankness but I don't see why signaling your intent to >> > support >> > an upgrade to one side of a hard fork can be seen as a bad thing. If for >> > nothing else doesn't this make for a smoother flag day? (Because once >> > you >> > signal your intention, it makes it hard to back out on the commitment.) >> >> It isn't a commitment in any sense, nor does it make it smoother, because >> for >> a hardfork to be successful, it is the *economy* that must switch >> entirely. >> The miners are unimportant. >> >> > If miners don't have any choice in hard forks, who does? Just the core >> > devs? >> >> Devs have even less of a choice in the matter. What is relevant is the >> economy: who do people want to spend their bitcoins with? There is no >> programmatic way to determine this, especially not in advance, so the best >> we >> can do is a flag day that gets called off if there isn't clear consensus. >> >> Luke > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 2015-11-14 9:31 ` Adam Back @ 2015-11-14 10:52 ` Jorge Timón 2015-11-14 21:11 ` Luke Dashjr 0 siblings, 1 reply; 15+ messages in thread From: Jorge Timón @ 2015-11-14 10:52 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev, John Sacco [-- Attachment #1: Type: text/plain, Size: 5672 bytes --] Currently bip99 recommends 95% miner upgrade confirmation with version bits (bip9) for uncontroversial hardforks just like it does for uncontroversial softforks. It is true that in the case of hardforks miners don't decide and it's the whole economy who has to upgrade before activation, but "the whole economy" and "all users" includes miners, so why not use the only upgrade confirmation mechanism that we have available? The way I see it, uncontroversial softforks are also expected to be upgraded to by everyone eventually. The advantage of softforks is that non-miners don't need to do it before activation like with hardforks. That's the only important difference I see between uncontroversial softforks and hardforks (unilateral softforks and schism hardforks are another thing though). Please let's discuss this generally within the context of bip99 instead of discussing different deployment details with every proposal. There's a couple of threads in the ml, a couple of now merged bip99 prs in bitcoin/bips... On Nov 14, 2015 10:31 AM, "Adam Back via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > There is a difference between miners signalling intent (as they have > been for various BIPs, which is mostly informational only - they are > mostly not running the code, and in some cases it is not implemented, > so they cant be) there is a difference between that and a 95% miner > majority consensus rule. Former can be useful information as you > said, latter implies as Luke described something that is not really > accurate, it is not strictly only a miner upgrade needed for basic > safety as with soft-forks. If you look at BIP 103 for example it is > flag day based, and I think this is a more accurate approach. Also > with miner votes they can be misleading - vote for one thing, but run > something else; what they are running is not generally > detectable/enforceable - see for example what happened with the BIP66 > accidental fork due to "SPV mining" (ie validationless mining). > > A hard-fork is for everyone to upgrade and talk with each other to see > that the vast majority is on the same plan which includes users, > ecosystem companies & miners. > > Adam > > On 14 November 2015 at 01:02, digitsu412 via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Well I'd like to think that with an economy all parts of it interact with > > each other in ways more complex than simplistic imperative logic. > > > > I agree that the economic majority is essentially what matters in a hard > > fork but everyone (miners,devs,public thought leaders,businesses) is > part of > > that economy. Additionally what miners signal as their intention affects > the > > decision of that economic majority (and vice versa). You can see the > > effects of this in traditional political processes in how preliminary > vote > > polling results affect (reinforce) the final vote. > > We also can see the results of this in (dare I mention) the whole XT > affair > > which had the signed intent of many of the economy (payment processors > and > > wallets and one miner pool) and the rest of the miners did not go along > with > > it. This experiment either means that the rest of the miners couldn't be > > bothered to signal at all (because they didn't know how) or they were > > affected by the influence of core devs or the opinions of others on the > > matter and rejected the economic majority. (Which would imply core devs > > have some power by way of indirect influence) I would be inclined to > believe > > the latter was more likely. > > > > The conclusion which this would seem to imply is that at the very least, > > miners matter (to what exact extent is debatable). And although there > is no > > direct control of any party over the other in the strict sense, the > public > > vocal opinions of any part of the Bitcoin economy does have an effect in > its > > ability to sway the opinions of the other parts. > > > > Digitsu > > > > — Regards, > > > > > > On Sat, Nov 14, 2015 at 7:29 AM, Luke Dashjr <luke@dashjr•org> wrote: > >> > >> On Friday, November 13, 2015 4:01:09 PM digitsu@gmail•com wrote: > >> > Forgive the frankness but I don't see why signaling your intent to > >> > support > >> > an upgrade to one side of a hard fork can be seen as a bad thing. If > for > >> > nothing else doesn't this make for a smoother flag day? (Because once > >> > you > >> > signal your intention, it makes it hard to back out on the > commitment.) > >> > >> It isn't a commitment in any sense, nor does it make it smoother, > because > >> for > >> a hardfork to be successful, it is the *economy* that must switch > >> entirely. > >> The miners are unimportant. > >> > >> > If miners don't have any choice in hard forks, who does? Just the core > >> > devs? > >> > >> Devs have even less of a choice in the matter. What is relevant is the > >> economy: who do people want to spend their bitcoins with? There is no > >> programmatic way to determine this, especially not in advance, so the > best > >> we > >> can do is a flag day that gets called off if there isn't clear > consensus. > >> > >> Luke > > > > > > > > _______________________________________________ > > 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 > [-- Attachment #2: Type: text/html, Size: 6958 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 2015-11-14 10:52 ` Jorge Timón @ 2015-11-14 21:11 ` Luke Dashjr [not found] ` <CADZB0_Z3Kf4GW0VATjb10kJF0aFgyFOcqX_=y+LFoUpsi+TRUA@mail.gmail.com> 0 siblings, 1 reply; 15+ messages in thread From: Luke Dashjr @ 2015-11-14 21:11 UTC (permalink / raw) To: bitcoin-dev, Jorge Timón; +Cc: John Sacco On Saturday, November 14, 2015 10:52:12 AM Jorge Timón via bitcoin-dev wrote: > Currently bip99 recommends 95% miner upgrade confirmation with version bits > (bip9) for uncontroversial hardforks just like it does for uncontroversial > softforks. It is true that in the case of hardforks miners don't decide and > it's the whole economy who has to upgrade before activation, but "the whole > economy" and "all users" includes miners, so why not use the only upgrade > confirmation mechanism that we have available? Actually, the economy does not necessarily include miners, and in fact the present miner community for the most part does not overlap significantly with economic activity. And at the same time, miners also have a tendency to upgrade at a different rate than the economy. It might make sense to incorporate a miner-trigger, but *only if* the flag is enabled in nodes by an option disabled by default, and the BIP clearly specifies that miners must not enable it until they perceive complete economic adoption of the change. Luke ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <CADZB0_Z3Kf4GW0VATjb10kJF0aFgyFOcqX_=y+LFoUpsi+TRUA@mail.gmail.com>]
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M [not found] ` <CADZB0_Z3Kf4GW0VATjb10kJF0aFgyFOcqX_=y+LFoUpsi+TRUA@mail.gmail.com> @ 2015-11-14 21:27 ` Luke Dashjr 2015-11-15 12:16 ` Jorge Timón 0 siblings, 1 reply; 15+ messages in thread From: Luke Dashjr @ 2015-11-14 21:27 UTC (permalink / raw) To: Angel Leon; +Cc: Bitcoin Dev, John Sacco On Saturday, November 14, 2015 9:15:07 PM Angel Leon wrote: > "the economy does not necessarily include miners" > so the money supply isn't part of the economy? Not in the context of economic majority deciding hardforks. After all, the outcome of the hardfork *determines* the money supply. So the former money supply not supporting the change would just mean they cease to be involved in that capacity. But even aside from that, the more relevant factor in terms of economic involvement is /acceptance/ of bitcoins as payment for real goods. Luke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 2015-11-14 21:27 ` Luke Dashjr @ 2015-11-15 12:16 ` Jorge Timón [not found] ` <CABEog-XUNt9kDS7Mc0XYFjm5ePUT0m1YaAoG9VypTCiGLBongQ@mail.gmail.com> 0 siblings, 1 reply; 15+ messages in thread From: Jorge Timón @ 2015-11-15 12:16 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev, John Sacco On Sat, Nov 14, 2015 at 10:11 PM, Luke Dashjr <luke@dashjr•org> wrote: > On Saturday, November 14, 2015 10:52:12 AM Jorge Timón via bitcoin-dev wrote: >> Currently bip99 recommends 95% miner upgrade confirmation with version bits >> (bip9) for uncontroversial hardforks just like it does for uncontroversial >> softforks. It is true that in the case of hardforks miners don't decide and >> it's the whole economy who has to upgrade before activation, but "the whole >> economy" and "all users" includes miners, so why not use the only upgrade >> confirmation mechanism that we have available? > > Actually, the economy does not necessarily include miners, and in fact the > present miner community for the most part does not overlap significantly with > economic activity. Maybe we should define "the bitcoin economy" is first. In my definition, miners are definitely part of the economy (and also users of the system). On Sat, Nov 14, 2015 at 10:27 PM, Luke Dashjr <luke@dashjr•org> wrote: > On Saturday, November 14, 2015 9:15:07 PM Angel Leon wrote: >> "the economy does not necessarily include miners" >> so the money supply isn't part of the economy? > > Not in the context of economic majority deciding hardforks. After all, the > outcome of the hardfork *determines* the money supply. So the former money > supply not supporting the change would just mean they cease to be involved in > that capacity. But even aside from that, the more relevant factor in terms of > economic involvement is /acceptance/ of bitcoins as payment for real goods. Miners accept bitcoins as payment for a real service (with real costs like electricity) to the network: extending the longest valid chain with their proof of work. In the context of BIP99, there's no concept of "an economic majority" deciding hardforks. Hardforks are either uncontroversial, in which case BIP99 recommends 95% miner upgrade confirmation in addition to a time threshold, or are schism hardforks (for example, an anti-miner hardfork), in which case BIP99 recommends using a time threshold alone. But no majority can force the dissenting users to use one validation rule set or the other: users will always be free to run whatever free software they like. > And at the same time, miners also have a tendency to > upgrade at a different rate than the economy. That alone seems like a very good reason in favor to confirm that miners have upgraded in addition to a minimal activation block median time, not a reason against it > It might make sense to > incorporate a miner-trigger, but *only if* the flag is enabled in nodes by an > option disabled by default, and the BIP clearly specifies that miners must not > enable it until they perceive complete economic adoption of the change. I'm not sure I understand this. The trigger mechanism must be uniform for each rule change, it cannot be optionally different or consensus can fail. How are miners supposed to "perceive" adoption? The time threshold must be set enough in the future to give users time to upgrade. But we can perceive miners' adoption, so if the system knows they haven't upgraded, it should wait for them to upgrade (it would be nice to have an equivalent mechanism to wait for the rest of the users, but unfortunately there's none). Please, remember that this is in the context of uncontroversial hardforks for which all users (including all miners) are expected to upgrade to. To reiterate, schism hardforks are treated differently and the miner upgrade confirmation becomes completely irrelevant. ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <CABEog-XUNt9kDS7Mc0XYFjm5ePUT0m1YaAoG9VypTCiGLBongQ@mail.gmail.com>]
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M [not found] ` <CABEog-XUNt9kDS7Mc0XYFjm5ePUT0m1YaAoG9VypTCiGLBongQ@mail.gmail.com> @ 2015-11-18 10:15 ` Jorge Timón 0 siblings, 0 replies; 15+ messages in thread From: Jorge Timón @ 2015-11-18 10:15 UTC (permalink / raw) To: Shuning Hong, Bitcoin Dev On Wed, Nov 18, 2015 at 10:13 AM, Shuning Hong <hongshuning@gmail•com> wrote: > 2015-11-15 20:16 GMT+08:00 Jorge Timón <bitcoin-dev@lists•linuxfoundation.org>: >> The time threshold must be set enough in the future to give users time to upgrade. But we can perceive miners' adoption, so if the system knows they haven't upgraded, it should wait for them to upgrade (it would be nice to have an equivalent mechanism to wait for the rest of the users, but unfortunately there's none). > > If the majority of the miners never upgrade, how could we treat that > BIP? Wait forever? Assuming it was deployed as an uncontroversial hardfork as recommended in BIP99, the deployment would use versionbits (BIP9) and the hardfork would timeout. But this timeout would clearly signal that either the minimum activation threshold wasn't giving enough time for all users to upgrade (apparently miners didn't had time) or the hardfork is not really an uncontroversial hardfork but rather a schism one. Then, assuming some people still want to deploy it as a schism hardfork, bip99 recommends using only a mediantime threshold without versionbits nor miner upgrade confirmation. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 2015-11-13 2:56 ` Chun Wang 2015-11-13 3:37 ` John Sacco @ 2015-11-13 6:39 ` Luke Dashjr 1 sibling, 0 replies; 15+ messages in thread From: Luke Dashjr @ 2015-11-13 6:39 UTC (permalink / raw) To: bitcoin-dev, Chun Wang; +Cc: John Sacco On Friday, November 13, 2015 2:56:55 AM Chun Wang via bitcoin-dev wrote: > * 2 MB, 210000 <= height < 420000; It's impossible to have the entire network upgraded in the past. Furthermore, 1 MB is already too large a block size today. While blocks don't need to be as big as the limit, it's better to have the limit approximate what is reasonably possible without straining the network. So while your proposed schedule change might be workable (if miners can be trusted to keep actual block size under 50% pending future improvements), I prefer the proposal beginning at the next subsidy halving (which we're well on the way to). Luke ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-11-18 10:15 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-12 23:47 [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M John Sacco
2015-11-13 2:56 ` Chun Wang
2015-11-13 3:37 ` John Sacco
2015-11-13 7:49 ` Btc Drak
2015-11-13 9:50 ` John Sacco
2015-11-13 10:52 ` Luke Dashjr
[not found] ` <1447430469019.e0ee1956@Nodemailer>
2015-11-13 22:28 ` Luke Dashjr
2015-11-14 0:02 ` digitsu
2015-11-14 9:31 ` Adam Back
2015-11-14 10:52 ` Jorge Timón
2015-11-14 21:11 ` Luke Dashjr
[not found] ` <CADZB0_Z3Kf4GW0VATjb10kJF0aFgyFOcqX_=y+LFoUpsi+TRUA@mail.gmail.com>
2015-11-14 21:27 ` Luke Dashjr
2015-11-15 12:16 ` Jorge Timón
[not found] ` <CABEog-XUNt9kDS7Mc0XYFjm5ePUT0m1YaAoG9VypTCiGLBongQ@mail.gmail.com>
2015-11-18 10:15 ` Jorge Timón
2015-11-13 6:39 ` Luke Dashjr
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox