Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
Hi, BIP 42 is a code base consensus soft fork that at the time of activation does not really manifest as a fork because nobody is running any code not already applying it. Can a similar thing be done in 17 years? (I haven't really made sense of this year 2038 problem, I don't know or understand what is required if there's something to be done). Cheers! On Sat, Oct 16, 2021 at 11:00 PM David Bakin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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@lists.linuxfoundation.org> wrote: > >> > What happens if a series of blocks has a timestamp of 0x at the >> appropriate time? >> >> The chain will halt for all old clients, because there is no 32-bit value >> greater than 0x. >> >> > 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 0x0001, 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 0x < 0x1. >> >> 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 0x timestamp, just after the Genesis >> Block. Then, median time is equal to 0x 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 >> 010006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0f7f20010001020101035101010200f2052a01001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120 >> 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 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 +) >> >> What happens if a series of blocks has a timestamp of 0x 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 0x and 0x == >> 0x >> 2. Is not violated, since it would be a past actual real time. >> 3. Is not violated since 0x < 0x1. >> >> 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@lists.linuxfoundation.org >>
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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@lists.linuxfoundation.org> wrote: > > What happens if a series of blocks has a timestamp of 0x at the > appropriate time? > > The chain will halt for all old clients, because there is no 32-bit value > greater than 0x. > > > 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 0x0001, 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 0x < 0x1. > > 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 0x timestamp, just after the Genesis > Block. Then, median time is equal to 0x 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 > 010006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0f7f20010001020101035101010200f2052a01001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120 > 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 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 +) > > What happens if a series of blocks has a timestamp of 0x 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 0x and 0x == > 0x > 2. Is not violated, since it would be a past actual real time. > 3. Is not violated since 0x < 0x1. > > 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@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
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
> What happens if a series of blocks has a timestamp of 0x at the > appropriate time? The chain will halt for all old clients, because there is no 32-bit value greater than 0x. > 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 0x0001, 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 0x < 0x1. 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 0x timestamp, just after the Genesis Block. Then, median time is equal to 0x 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 010006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0f7f20010001020101035101010200f2052a01001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120 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 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 +) What happens if a series of blocks has a timestamp of 0x 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 0x and 0x == 0x 2. Is not violated, since it would be a past actual real time. 3. Is not violated since 0x < 0x1. 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On the regularity of soft forks
> Interesting discussion.Correct me if I'm wrong: but putting too many features > together in one shot just can't make things harder to debug in production if > something very unexpected happens.It's a basic principle of software > engineering. Soft fork features can (and should) obviously be tested thoroughly on testnet, signet, custom signets, sidechains etc on a standalone basis and a bundled basis. But whether or not it is a basic principle of general software engineering kind of misses the point. Security critical software clearly isn't engineered in the same way as a new social media app. Bugs are easily reverted in a new social media app. A consensus change is extremely hard to revert and probably requires a hard fork, a level of central coordination we generally attempt to avoid and a speed of deployment that we also attempt to avoid. On top of that we aren't just dealing with security critical software. One of the most important objectives is to keep all the nodes on the network in consensus. Introducing a consensus change before we are comfortable there is community consensus for it is a massive effective bug in itself. The network can split in multiple ways e.g. part of the network disagrees on whether to activate the consensus change, part of the network disagrees on how to resist that consensus change, part of the network disagrees on how to activate that consensus change etc In addition, a social media app can experiment in production whether Feature A works, whether Feature B works or whether Feature A and B work best together. In Bitcoin if we activate consensus Feature A, later decide we want consensus Feature B but find out that by previously activating Feature A we can't have Feature B (it is now unsafe to activate it) or its design now has to be suboptimal because we have to ensure it can safely work in the presence of Feature A we have made a mistake by activating Feature A in the first place. Decentralized security critical consensus changes are an emerging field in itself and really can't be treated like any other software project. This will become universally understood I'm sure over time. -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ‐‐‐ Original Message ‐‐‐ On Friday, October 15th, 2021 at 1:43 AM, Felipe Micaroni Lalli via bitcoin-dev wrote: > Interesting discussion.Correct me if I'm wrong: but putting too many features > together in one shot just can't make things harder to debug in production if > something very unexpected happens. It's a basic principle of software > engineering. > > Change. Deploy. Nothing bad happened? Change it a little more. Deployment. > > Or:Change, change, change. Deploy. Did something bad happen? What change > caused the problem? > > On Thu, Oct 14, 2021 at 8:53 PM Anthony Towns via bitcoin-dev > wrote: > >> On Mon, Oct 11, 2021 at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote: >>> > ... in this post I will argue against frequent soft forks with a single or >>> minimal >>> > set of features and instead argue for infrequent soft forks with batches >>> > of features. >>> I think this type of development has been discussed in the past and has been >>> rejected. >> >>> AJ: - improvements: changes might not make everyone better off, but we >>> don't want changes to screw anyone over either -- pareto >>> improvements in economics, "first, do no harm", etc. (if we get this >>> right, there's no need to make compromises and bundle multiple >>> flawed proposals so that everyone's an equal mix of happy and >>> miserable) >> >> I don't think your conclusion above matches my opinion, for what it's >> worth. >> >> If you've got two features, A and B, where the game theory is: >> >> If A happens, I'm +100, You're -50 >> If B happens, I'm -50, You're +100 >> >> then even though A+B is +50, +50, then I do think the answer should >> generally be "think harder and come up with better proposals" rather than >> "implement A+B as a bundle that makes us both +50". >> >> _But_ if the two features are more like: >> >> If C happens, I'm +100, You're +/- 0 >> If D happens, I'm +/- 0, You're +100 >> >> then I don't have a problem with bundling them together as a single >> simultaneous activation of both C and D. >> >> Also, you can have situations where things are better together, >> that is: >> >> If E happens, we're both at +100 >> If F happens, we're both at +50 >> If E+F both happen, we're both at +9000 >> >> In general, I think combining proposals when the combination is better >> than the individual proposals were is obviously good; and combining >> related proposals into a single activation can be good if it is easier >> to think about the ideas as a set. >> >> It's only when you'd be rejecting the proposal on its own merits that >> I think combining it with others is a bad idea in principle. >> >> For specific examples, we bundled
