Max Locktime

[manuelra]

Suppose Doc Brown wants to send x bitcoins to himself when he reaches 2110 so that he can dispose the Quantum Mind Jar (https://en.wikipedia.org/wiki/Doc_Brown_Saves_the_World - although Doc only needed to jump to 2075, for this problem assume that in fact he needs to jump to 2110). For that purpose he wants to setup a delayed bitcoin transaction, to 2110-01-01 0:00

What value should he use to set locktime on his bitcoin transaction?

Thank you.

Notes:
- locktime is an unsigned 32 bit, which, if above 500.000.000, represents the number of seconds since 1970-1-1 0:00:
- assume that Doc knows that bitcoin will last at least until then
- bitcoin is able to issue new coins until 2140

[1714903973]

1714903973

[1714903973]

1714903973

[1714903973]

1714903973

[YIz]

The timestamp of 4417977600 represents January 1st 2110, at 12:00 AM. is this what you're asking?

[manuelra]

Yiz,

Kind of...

The thing is that that value is above 2^32. So it cannot be represented within the locktime field. From what I understand the max value for locktime is somewhere around 2106.

Please note that BIP65 (whether already supported or not) relies on that field as well.

The good news is that we have ~80yrs to review it (less any reasonable advance we a user may want to use to make a payment), and that review will only become necessary if bitcoin presents that longevity.

But I think it would be prudent to create a BIP for this issue. A possible solution would be to upgrade this to 64 bit, but that may break compatibility. Another would be to allow the user to specify the locktime within the script, but that may create aditional work for miners (to retrieve that info from the script => parsing, etc).

For values below 500.000.000, which represent the block number, this should not be a problem in the near time.

[Coding Enthusiast]

The max value is 4294967295 = 2106-02-07T06:28:15+00:00 (in ISO 8601)

(my personal opinion) And the solution can be turning it into a Compact size UInt like the rest of the numbers in a transaction. That way it can be as big as 0xffffffffffffffff (8 Bytes with 9 Bytes used) and maybe don't break much of the code.

[manuelra]

Whatever the fix, it probably can leverage and/or follow, options taken for similar problems (OSes, languages, etc). Apparently at the OS level the trend is towards using 64 bit to represent time.

The links below provide some info on similar problems.

https://en.wikipedia.org/wiki/Year_2038_problem
https://en.wikipedia.org/wiki/System_time

[manuelra]

As an additional note, the same problem applies to the blockheader timestamp. So with the current data structures blocks cannot exist beyond 2106.

https://github.com/bitcoin/bitcoin/blob/master/src/primitives/block.h

class CBlockHeader
{
public:
    // header
    int32_t nVersion;
    uint256 hashPrevBlock;
    uint256 hashMerkleRoot;
    uint32_t nTime;
[...]


Interestingly the method that returns nTime already casts this value to 64 bits, so in this case the problem might be solved by "only" reviewing block header serialization code.

    int64_t GetBlockTime() const
    {
        return (int64_t)nTime;
    }

But because nodes upgrade incrementally, this code will have to have a way to distinguish formats, and thus a new block header version might be needed so that the serialization code can determine how to un/serialize. And, at least for a while, the upgraded code will have to support serialization to/from both formats.

[achow101]

Any change to the timestamps for nLocktime and the block header will require a hard fork. Given that this is a long term problem, it is not particularly urgent right now to fix this.

[gmaxwell]

Any change to the timestamps for nLocktime and the block header will require a hard fork. Given that this is a long term problem, it is not particularly urgent right now to fix this.

And hardforks tend to break nlocktimed transactoins, potentially forever destroying their funds...

It's really inadvisable to use locktimes set in the far future.  Though everyone working on the Bitcoin project works hard to not invalidate existing transactions, we don't know what new challenges the future may bring-- and the Bitcoin of 2110 might well not accept a signed transaction drafted today.

For your example it's far better to just store the private key needed to spend the funds.. you'll need that anyways in any case... (unless he intends to just give his funds to miners in the far future...)