š
Original date posted:2015-06-22
š Original message:On Mon, Jun 22, 2015 at 07:32:22PM +0000, Jean-Paul Kogelman wrote:
>
>
> On Jun 22, 2015, at 11:18 AM, Gavin Andresen <gavinandresen at gmail.com> wrote:
>
> The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
> Ā
> 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.
--
'peter'[:-1]@petertodd.org
0000000000000000138b2613c026e0ed1dbf6f8f193f1c3115bdf540dc22fbf6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/0f5603a7/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 15:39:54
in reply to nevent1qā¦fw63
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Seen on
wss://relay.noswhere.comPublished at
2023-06-07 15:39:54Event JSON
{
"id": "3cb54b40fba474e03aafd2398c0e7eff1c10e2fb7873800025ab8349c80a8543",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686152394,
"kind": 1,
"tags": [
[
"e",
"1936c15d372dc9e8a0eaf645dcff207375e90675dbebfadcf82370abc654737d",
"",
"root"
],
[
"e",
"3f62514e66f990e981df511d115c40e239e1b8c018ac166b2276cd26b6764709",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "š
Original date posted:2015-06-22\nš Original message:On Mon, Jun 22, 2015 at 07:32:22PM +0000, Jean-Paul Kogelman wrote:\n\u003e \n\u003e \n\u003e On Jun 22, 2015, at 11:18 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e wrote:\n\u003e \n\u003e The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.\n\u003e Ā \n\u003e 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?\n\nIn the nVersion bits proposal that I co-authored we solved that issue by\ncomparing the timestamp against the median time, which is guaranteed by\nthe protocol rules to monotonically advance.\n\n-- \n'peter'[:-1]@petertodd.org\n0000000000000000138b2613c026e0ed1dbf6f8f193f1c3115bdf540dc22fbf6\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/0f5603a7/attachment.sig\u003e",
"sig": "157c028ba0d93cb7302212b29f410339deec329bc348960aa2ee7cfa4aa63d665db2243a3044f49ea89a13e22bc6d832e6ef01e94c4e9918fe987c2549762a46"
}