š
Original date posted:2021-10-16
š Original message:yes but ... just for the sake of argument ... if a change such as this
wraparound interpretation is made anytime in the next 5 years it'll be over
a *decade after that *before any wrapped-around timestamp is legitimately
mined ... and by then nobody will be running incompatible (decade old) node
software (especially since it would mean that a decade had gone by without
a *single* consensus change ... seems very unlikely).
On Sat, Oct 16, 2021 at 11:57 AM vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the
> appropriate time?
>
> The chain will halt for all old clients, because there is no 32-bit value
> greater than 0xffffffff.
>
> > 1. Is not violated, since "not lower than" means "greater than or equal
> to"
>
> No, because it has to be strictly "greater than" in the Bitcoin Core
> source code, it is rejected when it is "lower or equal to", see:
> https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/validation.cpp#L3089-L3094
>
> > 2. Is not violated, since it would be a past actual real time.
>
> If the current time is 0x0000000100000000, then the lowest 32 bits will
> point to some time around 1970, so for old clients two rules are violated
> at the same time.
>
> > 3. Is not violated since 0xFFFFFFFF < 0x100000000.
>
> This is hard to change, because 32-bit timestamps are included in block
> headers, so using any wider data type here will make it
> hardware-incompatible and will cause a hard-fork. That's why I think new
> timestamps should be placed in the coinbase transaction. But that still
> does not solve chain halting problem.
>
> To test chain halting, all that is needed is starting regtest and
> producing one block with 0xffffffff timestamp, just after the Genesis
> Block. Then, median time is equal to 0xffffffff and adding any new blocks
> is no longer possible. The only soft-fork solution I can see require
> overwriting that block.
>
> Example from https://bitcointalk.org/index.php?topic=5365359.0
>
> submitblock
> 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fffffffffffff7f200100000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
> null
> generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt
> CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestamp
> is too early (code -1)
>
> I don't know any timestamp that can be used in any next block and accepted
> by old nodes.
>
> On 2021-10-16 01:01:54 user ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> > Good morning yanmaani,
>
>
> > It's well-known. Nobody really cares, because it's so far off. Not
> > possible to do by softfork, no.
>
> I think it is possible by softfork if we try hard enough?
>
>
> > 1. The block timestamp may not be lower than the median of the last 11
> > blocks'
> >
> > 2. The block timestamp may not be greater than the current time plus two
> > hours
> >
> > 3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106
> > 06:28:16 +0000)
>
> What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the
> appropriate time?
>
> In that case:
>
> 1. Is not violated, since "not lower than" means "greater than or equal
> to", and after a while the median becomes 0xFFFFFFFF and 0xFFFFFFFF ==
> 0xFFFFFFFF
> 2. Is not violated, since it would be a past actual real time.
> 3. Is not violated since 0xFFFFFFFF < 0x100000000.
>
> In that case, we could then add an additional rule, which is that a 64-bit
> (or 128-bit, or 256-bit) timestamp has to be present in the coinbase
> transaction, with similar rules except translated to 64-bit/128-bit/256-bit.
>
> Possibly a similar scheme could be used for `nLockTime`; we could put a
> 64-bit `nLockTime64` in that additional signed block in Taproot SegWit v1
> if the legacy v`nLockTime` is at the maximum seconds-timelock possible.
>
> Regards,
> ZmnSCPxj
>
>
> _______________________________________________
> 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/20211016/c540960f/attachment.html>;
David Bakin [ARCHIVE] /
npub19sā¦6382x
2023-06-07 23:00:10
in reply to nevent1qā¦zj53
Author Public Key
npub19s2kcnzckc30xlxrcp4rpzhw4nue395g6ztq390p6yhchh5wdqcss6382xSeen on
wss://relay.nostr.bandPublished at
2023-06-07 23:00:10Event JSON
{
"id": "3b7ae5a14ba78b375df640970f798219355162eedc3ef50b95a7d313db0d18eb",
"pubkey": "2c156c4c58b622f37cc3c06a308aeeacf9989688d0960895e1d12f8bde8e6831",
"created_at": 1686178810,
"kind": 1,
"tags": [
[
"e",
"c0e13d397dc71c2d737cbe4277ed0c11fb0c8d97302650a28ed4170c1d01b58d",
"",
"root"
],
[
"e",
"e1e816f59a55b9027292e26cbaba59672926f32de1503ed022598849d72103fb",
"",
"reply"
],
[
"p",
"8d3cf7eba921036409f1fec074cf8cfd8925bc7cb18e35d358b1ccc89752ee32"
]
],
"content": "š
Original date posted:2021-10-16\nš Original message:yes but ... just for the sake of argument ... if a change such as this\nwraparound interpretation is made anytime in the next 5 years it'll be over\na *decade after that *before any wrapped-around timestamp is legitimately\nmined ... and by then nobody will be running incompatible (decade old) node\nsoftware (especially since it would mean that a decade had gone by without\na *single* consensus change ... seems very unlikely).\n\nOn Sat, Oct 16, 2021 at 11:57 AM vjudeu via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e \u003e What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the\n\u003e appropriate time?\n\u003e\n\u003e The chain will halt for all old clients, because there is no 32-bit value\n\u003e greater than 0xffffffff.\n\u003e\n\u003e \u003e 1. Is not violated, since \"not lower than\" means \"greater than or equal\n\u003e to\"\n\u003e\n\u003e No, because it has to be strictly \"greater than\" in the Bitcoin Core\n\u003e source code, it is rejected when it is \"lower or equal to\", see:\n\u003e https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/validation.cpp#L3089-L3094\n\u003e\n\u003e \u003e 2. Is not violated, since it would be a past actual real time.\n\u003e\n\u003e If the current time is 0x0000000100000000, then the lowest 32 bits will\n\u003e point to some time around 1970, so for old clients two rules are violated\n\u003e at the same time.\n\u003e\n\u003e \u003e 3. Is not violated since 0xFFFFFFFF \u003c 0x100000000.\n\u003e\n\u003e This is hard to change, because 32-bit timestamps are included in block\n\u003e headers, so using any wider data type here will make it\n\u003e hardware-incompatible and will cause a hard-fork. That's why I think new\n\u003e timestamps should be placed in the coinbase transaction. But that still\n\u003e does not solve chain halting problem.\n\u003e\n\u003e To test chain halting, all that is needed is starting regtest and\n\u003e producing one block with 0xffffffff timestamp, just after the Genesis\n\u003e Block. Then, median time is equal to 0xffffffff and adding any new blocks\n\u003e is no longer possible. The only soft-fork solution I can see require\n\u003e overwriting that block.\n\u003e\n\u003e Example from https://bitcointalk.org/index.php?topic=5365359.0\n\u003e\n\u003e submitblock\n\u003e 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fffffffffffff7f200100000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000\n\u003e null\n\u003e generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt\n\u003e CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestamp\n\u003e is too early (code -1)\n\u003e\n\u003e I don't know any timestamp that can be used in any next block and accepted\n\u003e by old nodes.\n\u003e\n\u003e On 2021-10-16 01:01:54 user ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e \u003e Good morning yanmaani,\n\u003e\n\u003e\n\u003e \u003e It's well-known. Nobody really cares, because it's so far off. Not\n\u003e \u003e possible to do by softfork, no.\n\u003e\n\u003e I think it is possible by softfork if we try hard enough?\n\u003e\n\u003e\n\u003e \u003e 1. The block timestamp may not be lower than the median of the last 11\n\u003e \u003e blocks'\n\u003e \u003e\n\u003e \u003e 2. The block timestamp may not be greater than the current time plus two\n\u003e \u003e hours\n\u003e \u003e\n\u003e \u003e 3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106\n\u003e \u003e 06:28:16 +0000)\n\u003e\n\u003e What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the\n\u003e appropriate time?\n\u003e\n\u003e In that case:\n\u003e\n\u003e 1. Is not violated, since \"not lower than\" means \"greater than or equal\n\u003e to\", and after a while the median becomes 0xFFFFFFFF and 0xFFFFFFFF ==\n\u003e 0xFFFFFFFF\n\u003e 2. Is not violated, since it would be a past actual real time.\n\u003e 3. Is not violated since 0xFFFFFFFF \u003c 0x100000000.\n\u003e\n\u003e In that case, we could then add an additional rule, which is that a 64-bit\n\u003e (or 128-bit, or 256-bit) timestamp has to be present in the coinbase\n\u003e transaction, with similar rules except translated to 64-bit/128-bit/256-bit.\n\u003e\n\u003e Possibly a similar scheme could be used for `nLockTime`; we could put a\n\u003e 64-bit `nLockTime64` in that additional signed block in Taproot SegWit v1\n\u003e if the legacy v`nLockTime` is at the maximum seconds-timelock possible.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211016/c540960f/attachment.html\u003e",
"sig": "6414495c12f63869b6b3fd65e736e7820943ebb10982b6563816caedac48497ba4a41457262d52e51f544dc6803cc58caffccfcd01f1440983dcf7df39566a0b"
}