Ah, I see you're right—once MTP reaches 2^32 - 1, no valid timestamp can exceed it, making the next block mathematically impossible. I was wrong about the halt. I still maintain my other points about timeline and opportunity costs. Henry *Henry Romp802-458-7299 <8024587299>* *151henry151@gmail.com <151henry151@gmail.com>* On Mon, Dec 15, 2025, 04:59 Garlo Nicon wrote: > > The blockchain won't "halt" at overflow, it will have validation > problems. > > These "validation problems" will be quite serious. For example: it will be > possible to produce a chain with a bigger chainwork, and pass it to the old > nodes. > > Which means, that the chain can go forward for the new nodes, while being > perceived as a constantly reorged, by the old implementation. > > And then, the question is: do we want to design a new soft-fork in a way, > where it would be seen as constantly-reorged chain by the old nodes? > > > The overflow doesn't automatically stop the chain. > > It will, because overflowed timestamps from 1970 will be rejected by all > old nodes. > > > At that point there are no more valid blocks that can be appended to the > chain. > > As long as the chainwork won't overflow, you can always reorg the old > blocks. If that reorg will be deterministic, and accepted by hashrate > majority, then it will be seen only by old nodes. New nodes can see a > stable chain, always going forward, beyond 0xffffffff. > > Anyway, it will be just one-bit increment per 136 years. > > niedz., 14 gru 2025 o 15:09 'Russell O'Connor' via Bitcoin Development > Mailing List napisał(a): > >> On Sat, Dec 13, 2025 at 5:05 AM Henry Romp <151henry151@gmail.com> wrote: >> >>> The blockchain won't "halt" at overflow, it will have validation >>> problems. The overflow doesn't automatically stop the chain. Nodes would >>> continue with wrapped-around timestamps (though this would cause some >>> problems). >>> >> >> Yes the blockchain halts. >> >> The timestamps are required to eventually increase; more specifically >> each new timestamp is required to be strictly greater than the MTP >> timestamp. Assuming these timestamps stay reasonably accurate up to the >> end then at best you can squeeze out a few more blocks by lying about the >> time, but eventually the MTP timestamp will reach its maximum value. At >> that point there are no more valid blocks that can be appended to the chain. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAMZUoKkXQv%2BLO_3iWf1_PnPMR7ocO0ddHZhfZo63Umst%3DpVCPg%40mail.gmail.com >> >> . >> > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPnXYtPdbFwc1mOsP2eHQBwuJhn2XxLCWC-pt6%2BN-bu3BRRbiA%40mail.gmail.com.