š
Original date posted:2015-06-22
š Original message:If you truly have a consensus then the rational behavior is to
permanently change the nodes behavior after the trigger.
On 06/22/2015 02:21 PM, Gavin Andresen wrote:
> On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd <pete at petertodd.org
> <mailto:pete at petertodd.org>> wrote:
>
> > Since it's possible that block timestamps aren't chronological
> in order, what would happen if a block following a size increase
> trigger is back in the past before the size increase? Would that
> block have a lower size restriction again? Would using block
> height not be a more stable number to work with?
>
> In the nVersion bits proposal that I co-authored we solved that
> issue by
> comparing the timestamp against the median time, which is
> guaranteed by
> the protocol rules to monotonically advance.
>
>
> That complicates the implementation quite a bit.
>
> I mostly implemented a variant that replaced the MAX_BLOCK_SIZE
> constant with a function that took both a timestamp and a block
> height, and there are several places in the current reference
> implementation where digging out the block height (or, worse,
> calculating the median timestamp for the block) would involve changing
> quite a few functions in the call-chain or acquiring the cs_main lock
> to consult the current best chain.
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> 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/20150622/7494ff4d/attachment-0001.html>;
Patrick Strateman [ARCHIVE] /
npub1l3ā¦69pvv
2023-06-07 15:39:55
in reply to nevent1qā¦8w9g
Author Public Key
npub1l3uf9m4yw2y7x8wyjeswhelsqyy8ql4jaca4nyy6en0s474yadssg69pvvPublished at
2023-06-07 15:39:55Event JSON
{
"id": "2ecc91e9038bd655a40c1d248623603cd01f5786feef65f3572f32ac39fa2c60",
"pubkey": "fc7892eea47289e31dc49660ebe7f00108707eb2ee3b59909accdf0afaa4eb61",
"created_at": 1686152395,
"kind": 1,
"tags": [
[
"e",
"1936c15d372dc9e8a0eaf645dcff207375e90675dbebfadcf82370abc654737d",
"",
"root"
],
[
"e",
"07907a987783ba855bc0a2441ecc78cdd12d37e61dd89fb169a04f52913dbd48",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "š
Original date posted:2015-06-22\nš Original message:If you truly have a consensus then the rational behavior is to\npermanently change the nodes behavior after the trigger.\n\nOn 06/22/2015 02:21 PM, Gavin Andresen wrote:\n\u003e On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd \u003cpete at petertodd.org\n\u003e \u003cmailto:pete at petertodd.org\u003e\u003e wrote:\n\u003e\n\u003e \u003e Since it's possible that block timestamps aren't chronological\n\u003e in order, what would happen if a block following a size increase\n\u003e trigger is back in the past before the size increase? Would that\n\u003e block have a lower size restriction again? Would using block\n\u003e height not be a more stable number to work with?\n\u003e\n\u003e In the nVersion bits proposal that I co-authored we solved that\n\u003e issue by\n\u003e comparing the timestamp against the median time, which is\n\u003e guaranteed by\n\u003e the protocol rules to monotonically advance.\n\u003e\n\u003e\n\u003e That complicates the implementation quite a bit.\n\u003e\n\u003e I mostly implemented a variant that replaced the MAX_BLOCK_SIZE\n\u003e constant with a function that took both a timestamp and a block\n\u003e height, and there are several places in the current reference\n\u003e implementation where digging out the block height (or, worse,\n\u003e calculating the median timestamp for the block) would involve changing\n\u003e quite a few functions in the call-chain or acquiring the cs_main lock\n\u003e to consult the current best chain.\n\u003e\n\u003e -- \n\u003e --\n\u003e Gavin Andresen\n\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/7494ff4d/attachment-0001.html\u003e",
"sig": "48643e3696bc84db2b96e19e1f97774ad588b79a2cfbf7da34156098a9c54e5a89333288dd3311427b49fb17047dd49d5ebdcffcd52c3d5cd5f12d722ab607af"
}