📅 Original date posted:2015-12-18
📝 Original message:>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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/770de789/attachment.html>;
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 17:46:49
in reply to nevent1q…vt25
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 17:46:49Event JSON
{
"id": "38c005274569ad35f3304dcbbf937f19c53ee27ef189922eae022a89209a12be",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686160009,
"kind": 1,
"tags": [
[
"e",
"497fedabcda199dc32dac4427887a8c606ccdbd018602c9bcf98aaa69f427b8a",
"",
"root"
],
[
"e",
"86b8542ed4552b879886f1b4f617adff68cb30dae8073a954156672f65a711e7",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-12-18\n📝 Original message:\u003eFrom a code standpoint, based off height is easy.\n\nMy first internal version triggered on block 406,800 (~May 5), and each\nblock increased by 20 bytes thereafter.\n\nIt was changed to time, because time was the standard used in years past\nfor other changes; MTP flag day is more stable than block height.\n\nIt is preferred to have a single flag trigger (height or time), rather than\nthe more complex trigger-on-time, increment-on-height, but any combination\nof those will work.\n\nEasy to change code back to height-based...\n\n\n\nOn Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I agree that nHeight is the simplest option and is my preference.\n\u003e Another option is to use the median time from the previous block (thus you\n\u003e know whether or not the next block should start the miner confirmation or\n\u003e not). In fact, if we're going to use bip9 for 95% miner upgrade\n\u003e confirmation, it would be nice to always pick a difficulty retarget block\n\u003e (ie block.nHeight % DifficultyAdjustmentInterval == 0).\n\u003e Actually I would always have an initial height in bip9, for softforks too.\n\u003e I would also use the sign bit as the \"hardfork bit\" that gets activated\n\u003e for the next diff interval after 95% is reached and a hardfork becomes\n\u003e active (that way even SPV nodes will notice when a softfork or hardfork\n\u003e happens and also be able to tell which one is it).\n\u003e I should update bip99 with all this. And if the 2 mb bump is\n\u003e uncontroversial, maybe I can add that to the timewarp fix and th recovery\n\u003e of the other 2 bits in block.nVersion (given that bip102 doesn't seem to\n\u003e follow bip99's recommendations and doesn't want to give 6 full months as\n\u003e the pre activation grace period).\n\u003e On Dec 18, 2015 8:17 PM, \"Chun Wang via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e In many BIPs we have seen, include the latest BIP202, it is the block\n\u003e\u003e time that determine the max block size. From from pool's point of\n\u003e\u003e view, it cannot issue a job with a fixed ntime due to the existence of\n\u003e\u003e ntime roll. It is hard to issue a job with the max block size unknown.\n\u003e\u003e For developers, it is also easier to implement if max block size is a\n\u003e\u003e function of block height instead of time. Block height is also much\n\u003e\u003e more simple and elegant than time.\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/770de789/attachment.html\u003e",
"sig": "da5cec896aee769cd165ee34010edbcab18b0e5e88c0fa8366e41ed288252e120de417fc1d70e39684a9ebd2b3afc461f0675dad0b4e08a16e3a752f47a1245e"
}