* [bitcoin-dev] The increase of max block size should be determined by block height instead of block time @ 2015-12-18 19:17 Chun Wang 2015-12-18 19:52 ` Jorge Timón 2015-12-19 18:20 ` Peter Todd 0 siblings, 2 replies; 10+ messages in thread From: Chun Wang @ 2015-12-18 19:17 UTC (permalink / raw) To: bitcoin-dev In many BIPs we have seen, include the latest BIP202, it is the block time that determine the max block size. From from pool's point of view, it cannot issue a job with a fixed ntime due to the existence of ntime roll. It is hard to issue a job with the max block size unknown. For developers, it is also easier to implement if max block size is a function of block height instead of time. Block height is also much more simple and elegant than time. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time 2015-12-18 19:17 [bitcoin-dev] The increase of max block size should be determined by block height instead of block time Chun Wang @ 2015-12-18 19:52 ` Jorge Timón 2015-12-18 20:02 ` Jeff Garzik 2015-12-18 20:43 ` Peter Todd 2015-12-19 18:20 ` Peter Todd 1 sibling, 2 replies; 10+ messages in thread From: Jorge Timón @ 2015-12-18 19:52 UTC (permalink / raw) To: Chun Wang; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1818 bytes --] I agree that nHeight is the simplest option and is my preference. Another option is to use the median time from the previous block (thus you know whether or not the next block should start the miner confirmation or not). In fact, if we're going to use bip9 for 95% miner upgrade confirmation, it would be nice to always pick a difficulty retarget block (ie block.nHeight % DifficultyAdjustmentInterval == 0). Actually I would always have an initial height in bip9, for softforks too. I would also use the sign bit as the "hardfork bit" that gets activated for the next diff interval after 95% is reached and a hardfork becomes active (that way even SPV nodes will notice when a softfork or hardfork happens and also be able to tell which one is it). I should update bip99 with all this. And if the 2 mb bump is uncontroversial, maybe I can add that to the timewarp fix and th recovery of the other 2 bits in block.nVersion (given that bip102 doesn't seem to follow bip99's recommendations and doesn't want to give 6 full months as the pre activation grace period). On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > In many BIPs we have seen, include the latest BIP202, it is the block > time that determine the max block size. From from pool's point of > view, it cannot issue a job with a fixed ntime due to the existence of > ntime roll. It is hard to issue a job with the max block size unknown. > For developers, it is also easier to implement if max block size is a > function of block height instead of time. Block height is also much > more simple and elegant than time. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 2331 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time 2015-12-18 19:52 ` Jorge Timón @ 2015-12-18 20:02 ` Jeff Garzik 2015-12-18 20:10 ` Jorge Timón 2015-12-18 20:43 ` Peter Todd 1 sibling, 1 reply; 10+ messages in thread From: Jeff Garzik @ 2015-12-18 20:02 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2730 bytes --] From a code standpoint, based off height is easy. My first internal version triggered on block 406,800 (~May 5), and each block increased by 20 bytes thereafter. It was changed to time, because time was the standard used in years past for other changes; MTP flag day is more stable than block height. It is preferred to have a single flag trigger (height or time), rather than the more complex trigger-on-time, increment-on-height, but any combination of those will work. Easy to change code back to height-based... On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón < bitcoin-dev@lists•linuxfoundation.org> wrote: > I agree that nHeight is the simplest option and is my preference. > Another option is to use the median time from the previous block (thus you > know whether or not the next block should start the miner confirmation or > not). In fact, if we're going to use bip9 for 95% miner upgrade > confirmation, it would be nice to always pick a difficulty retarget block > (ie block.nHeight % DifficultyAdjustmentInterval == 0). > Actually I would always have an initial height in bip9, for softforks too. > I would also use the sign bit as the "hardfork bit" that gets activated > for the next diff interval after 95% is reached and a hardfork becomes > active (that way even SPV nodes will notice when a softfork or hardfork > happens and also be able to tell which one is it). > I should update bip99 with all this. And if the 2 mb bump is > uncontroversial, maybe I can add that to the timewarp fix and th recovery > of the other 2 bits in block.nVersion (given that bip102 doesn't seem to > follow bip99's recommendations and doesn't want to give 6 full months as > the pre activation grace period). > On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> In many BIPs we have seen, include the latest BIP202, it is the block >> time that determine the max block size. From from pool's point of >> view, it cannot issue a job with a fixed ntime due to the existence of >> ntime roll. It is hard to issue a job with the max block size unknown. >> For developers, it is also easier to implement if max block size is a >> function of block height instead of time. Block height is also much >> more simple and elegant than time. >> _______________________________________________ >> 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: 3835 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time 2015-12-18 20:02 ` Jeff Garzik @ 2015-12-18 20:10 ` Jorge Timón 2015-12-18 20:15 ` Jeff Garzik 0 siblings, 1 reply; 10+ messages in thread From: Jorge Timón @ 2015-12-18 20:10 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3203 bytes --] Well, if it's not going to be height, I think median time of the previous block is better than the time of the current one, and would also solve Chun Wang's concerns. But as said I prefer to use heights that correspond to diff recalculation (because that's the window that bip9 will use for the later 95% confirmation anyway). On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik@gmail•com> wrote: > From a code standpoint, based off height is easy. > > My first internal version triggered on block 406,800 (~May 5), and each > block increased by 20 bytes thereafter. > > It was changed to time, because time was the standard used in years past > for other changes; MTP flag day is more stable than block height. > > It is preferred to have a single flag trigger (height or time), rather > than the more complex trigger-on-time, increment-on-height, but any > combination of those will work. > > Easy to change code back to height-based... > > > > On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> I agree that nHeight is the simplest option and is my preference. >> Another option is to use the median time from the previous block (thus >> you know whether or not the next block should start the miner confirmation >> or not). In fact, if we're going to use bip9 for 95% miner upgrade >> confirmation, it would be nice to always pick a difficulty retarget block >> (ie block.nHeight % DifficultyAdjustmentInterval == 0). >> Actually I would always have an initial height in bip9, for softforks too. >> I would also use the sign bit as the "hardfork bit" that gets activated >> for the next diff interval after 95% is reached and a hardfork becomes >> active (that way even SPV nodes will notice when a softfork or hardfork >> happens and also be able to tell which one is it). >> I should update bip99 with all this. And if the 2 mb bump is >> uncontroversial, maybe I can add that to the timewarp fix and th recovery >> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to >> follow bip99's recommendations and doesn't want to give 6 full months as >> the pre activation grace period). >> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> >>> In many BIPs we have seen, include the latest BIP202, it is the block >>> time that determine the max block size. From from pool's point of >>> view, it cannot issue a job with a fixed ntime due to the existence of >>> ntime roll. It is hard to issue a job with the max block size unknown. >>> For developers, it is also easier to implement if max block size is a >>> function of block height instead of time. Block height is also much >>> more simple and elegant than time. >>> _______________________________________________ >>> 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: 4478 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time 2015-12-18 20:10 ` Jorge Timón @ 2015-12-18 20:15 ` Jeff Garzik 2015-12-18 20:20 ` Jorge Timón 2015-12-18 20:58 ` gb 0 siblings, 2 replies; 10+ messages in thread From: Jeff Garzik @ 2015-12-18 20:15 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3799 bytes --] My preference is height activation + one step per block (i.e. also height). Height seems KISS. AFAICT most of the attacks would occur around the already-heavily-watched flag day activation event, in a height based environment, a useful attribute. However I would like to hear from others about possible attacks with the various approaches, before diverging from the default community approach of switch-based-on-time. On Fri, Dec 18, 2015 at 3:10 PM, Jorge Timón <jtimon@jtimon•cc> wrote: > Well, if it's not going to be height, I think median time of the previous > block is better than the time of the current one, and would also solve Chun > Wang's concerns. > But as said I prefer to use heights that correspond to diff recalculation > (because that's the window that bip9 will use for the later 95% > confirmation anyway). > On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik@gmail•com> wrote: > >> From a code standpoint, based off height is easy. >> >> My first internal version triggered on block 406,800 (~May 5), and each >> block increased by 20 bytes thereafter. >> >> It was changed to time, because time was the standard used in years past >> for other changes; MTP flag day is more stable than block height. >> >> It is preferred to have a single flag trigger (height or time), rather >> than the more complex trigger-on-time, increment-on-height, but any >> combination of those will work. >> >> Easy to change code back to height-based... >> >> >> >> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> >>> I agree that nHeight is the simplest option and is my preference. >>> Another option is to use the median time from the previous block (thus >>> you know whether or not the next block should start the miner confirmation >>> or not). In fact, if we're going to use bip9 for 95% miner upgrade >>> confirmation, it would be nice to always pick a difficulty retarget block >>> (ie block.nHeight % DifficultyAdjustmentInterval == 0). >>> Actually I would always have an initial height in bip9, for softforks >>> too. >>> I would also use the sign bit as the "hardfork bit" that gets activated >>> for the next diff interval after 95% is reached and a hardfork becomes >>> active (that way even SPV nodes will notice when a softfork or hardfork >>> happens and also be able to tell which one is it). >>> I should update bip99 with all this. And if the 2 mb bump is >>> uncontroversial, maybe I can add that to the timewarp fix and th recovery >>> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to >>> follow bip99's recommendations and doesn't want to give 6 full months as >>> the pre activation grace period). >>> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" < >>> bitcoin-dev@lists•linuxfoundation.org> wrote: >>> >>>> In many BIPs we have seen, include the latest BIP202, it is the block >>>> time that determine the max block size. From from pool's point of >>>> view, it cannot issue a job with a fixed ntime due to the existence of >>>> ntime roll. It is hard to issue a job with the max block size unknown. >>>> For developers, it is also easier to implement if max block size is a >>>> function of block height instead of time. Block height is also much >>>> more simple and elegant than time. >>>> _______________________________________________ >>>> 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: 5463 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time 2015-12-18 20:15 ` Jeff Garzik @ 2015-12-18 20:20 ` Jorge Timón 2015-12-18 20:58 ` gb 1 sibling, 0 replies; 10+ messages in thread From: Jorge Timón @ 2015-12-18 20:20 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4113 bytes --] I believe the attacks are the same for height or median time of the prev block are equal, only the time of the current block has more edge cases. On Dec 18, 2015 9:15 PM, "Jeff Garzik" <jgarzik@gmail•com> wrote: > My preference is height activation + one step per block (i.e. also > height). Height seems KISS. > > AFAICT most of the attacks would occur around the already-heavily-watched > flag day activation event, in a height based environment, a useful > attribute. > > However I would like to hear from others about possible attacks with the > various approaches, before diverging from the default community approach of > switch-based-on-time. > > > > > > > On Fri, Dec 18, 2015 at 3:10 PM, Jorge Timón <jtimon@jtimon•cc> wrote: > >> Well, if it's not going to be height, I think median time of the previous >> block is better than the time of the current one, and would also solve Chun >> Wang's concerns. >> But as said I prefer to use heights that correspond to diff recalculation >> (because that's the window that bip9 will use for the later 95% >> confirmation anyway). >> On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik@gmail•com> wrote: >> >>> From a code standpoint, based off height is easy. >>> >>> My first internal version triggered on block 406,800 (~May 5), and each >>> block increased by 20 bytes thereafter. >>> >>> It was changed to time, because time was the standard used in years past >>> for other changes; MTP flag day is more stable than block height. >>> >>> It is preferred to have a single flag trigger (height or time), rather >>> than the more complex trigger-on-time, increment-on-height, but any >>> combination of those will work. >>> >>> Easy to change code back to height-based... >>> >>> >>> >>> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón < >>> bitcoin-dev@lists•linuxfoundation.org> wrote: >>> >>>> I agree that nHeight is the simplest option and is my preference. >>>> Another option is to use the median time from the previous block (thus >>>> you know whether or not the next block should start the miner confirmation >>>> or not). In fact, if we're going to use bip9 for 95% miner upgrade >>>> confirmation, it would be nice to always pick a difficulty retarget block >>>> (ie block.nHeight % DifficultyAdjustmentInterval == 0). >>>> Actually I would always have an initial height in bip9, for softforks >>>> too. >>>> I would also use the sign bit as the "hardfork bit" that gets activated >>>> for the next diff interval after 95% is reached and a hardfork becomes >>>> active (that way even SPV nodes will notice when a softfork or hardfork >>>> happens and also be able to tell which one is it). >>>> I should update bip99 with all this. And if the 2 mb bump is >>>> uncontroversial, maybe I can add that to the timewarp fix and th recovery >>>> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to >>>> follow bip99's recommendations and doesn't want to give 6 full months as >>>> the pre activation grace period). >>>> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" < >>>> bitcoin-dev@lists•linuxfoundation.org> wrote: >>>> >>>>> In many BIPs we have seen, include the latest BIP202, it is the block >>>>> time that determine the max block size. From from pool's point of >>>>> view, it cannot issue a job with a fixed ntime due to the existence of >>>>> ntime roll. It is hard to issue a job with the max block size unknown. >>>>> For developers, it is also easier to implement if max block size is a >>>>> function of block height instead of time. Block height is also much >>>>> more simple and elegant than time. >>>>> _______________________________________________ >>>>> 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: 5892 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time 2015-12-18 20:15 ` Jeff Garzik 2015-12-18 20:20 ` Jorge Timón @ 2015-12-18 20:58 ` gb 1 sibling, 0 replies; 10+ messages in thread From: gb @ 2015-12-18 20:58 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev On Fri, 2015-12-18 at 15:15 -0500, Jeff Garzik via bitcoin-dev wrote: > My preference is height activation + one step per block (i.e. also > height). Height seems KISS. > > Under this scheme the size of the step-per-block increase could be decreased every 210,000 blocks (at time of reward halvings). So, a linear growth rate that decreases every ~4 years, ultimately grandfathering max_block_size increases on the same block-schedule that reward decreases. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time 2015-12-18 19:52 ` Jorge Timón 2015-12-18 20:02 ` Jeff Garzik @ 2015-12-18 20:43 ` Peter Todd 2015-12-18 22:58 ` Jorge Timón 1 sibling, 1 reply; 10+ messages in thread From: Peter Todd @ 2015-12-18 20:43 UTC (permalink / raw) To: Jorge Timón, Jorge Timón via bitcoin-dev, Chun Wang; +Cc: Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 18 December 2015 11:52:19 GMT-08:00, "Jorge Timón via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation.org> wrote: >I agree that nHeight is the simplest option and is my preference. >Another option is to use the median time from the previous block FWIW all these median time based schemes should be using median time past: the point is to use a time that the block creator has no direct control of, while still tying the rule to wall clock time for planning purposes. -----BEGIN PGP SIGNATURE----- iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWdG/r AAoJEMCF8hzn9Lncz4MH/iYJv6aB9rvfvy1KuSSHAQDQ++6j7Flmk2n8f/S4jt4q 92MZnKDw09HxUJiWvwREi81wHpq4JedgK1Z/+8m3wlK+jaIyWZ7Su+Jm+EqsoOSJ Sx6oisbyFlhVEUAdaG/XOX/K0mqh01NSvGGpoQjHAYzcG3pI03OC4G7Qg4WGeZLx O0yb387DmK/of52JGJcei3TUx0w8Up/GdXDqerLxioH7fhGhtGCj0vyD4LugnNLQ hka5g+hri27YltfaRxncNQ0nZT4rAfgRgRH1Qi3kHnc6ZgRcRjjb36TyrWjZ34eb 9+YDAirFwu8HGmi7lfxh9DDtVjPZCwKal7/rNeRI744= =7f+W -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time 2015-12-18 20:43 ` Peter Todd @ 2015-12-18 22:58 ` Jorge Timón 0 siblings, 0 replies; 10+ messages in thread From: Jorge Timón @ 2015-12-18 22:58 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1325 bytes --] On Dec 18, 2015 9:43 PM, "Peter Todd" <pete@petertodd•org> wrote: > FWIW all these median time based schemes should be using median time past: the point is to use a time that the block creator has no direct control of, while still tying the rule to wall clock time for planning purposes. Well, if after the "planned clock time" you need to wait for the next diff retarget and then wait for 95% (bip9) I think the value of being able to use "human friendly clock time" is very dubious (specially since median time is different from real-world time anyway). But yeah, not giving the creator of the current block direct control over whether its block starts the activation process or not is achieved with median time of the previous block just as well as nHeight does. So even if I disagree with the value that median time brings over the simpler height approach, let's please decide on one and always use that for both hardforks and softforks as part of bip9 (which we would need to modify). An initial time threshold is not necessary for uncontroversial softforks, but it doesn't hurt (you can always set it in the past if you want to not use it) and in fact it simplifies bip9's implementation. Let's please decide once and for all, update bip9 and bip99 and stop doing something different on every hardfork patch we write. [-- Attachment #2: Type: text/html, Size: 1486 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time 2015-12-18 19:17 [bitcoin-dev] The increase of max block size should be determined by block height instead of block time Chun Wang 2015-12-18 19:52 ` Jorge Timón @ 2015-12-19 18:20 ` Peter Todd 1 sibling, 0 replies; 10+ messages in thread From: Peter Todd @ 2015-12-19 18:20 UTC (permalink / raw) To: Chun Wang; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 895 bytes --] On Sat, Dec 19, 2015 at 03:17:03AM +0800, Chun Wang via bitcoin-dev wrote: > In many BIPs we have seen, include the latest BIP202, it is the block > time that determine the max block size. From from pool's point of > view, it cannot issue a job with a fixed ntime due to the existence of > ntime roll. It is hard to issue a job with the max block size unknown. > For developers, it is also easier to implement if max block size is a > function of block height instead of time. Block height is also much > more simple and elegant than time. If size is calculated from the median time past, which is fixed for a given block and has no dependency on the block header's nTime field, does that solve your problem? By "median time past" I mean the median time for the previous block. -- 'peter'[:-1]@petertodd.org 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-12-19 18:20 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-12-18 19:17 [bitcoin-dev] The increase of max block size should be determined by block height instead of block time Chun Wang 2015-12-18 19:52 ` Jorge Timón 2015-12-18 20:02 ` Jeff Garzik 2015-12-18 20:10 ` Jorge Timón 2015-12-18 20:15 ` Jeff Garzik 2015-12-18 20:20 ` Jorge Timón 2015-12-18 20:58 ` gb 2015-12-18 20:43 ` Peter Todd 2015-12-18 22:58 ` Jorge Timón 2015-12-19 18:20 ` Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox