>> (p.1)
    Author Topic: Max Locktime  (Read 1091 times)

    • manuelra (OP)
    Newbie
    *
    Offline Offline

    Activity: 6
    Merit: 3


    View Profile
    November 25, 2016, 06:15:59 PM
    Last edit: November 27, 2016, 01:20:02 PM by manuelra
    Merited by ABCbits (2)
     #1
    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

  • YIz
    Hero Member
    *****
    Offline Offline

    Activity: 700
    Merit: 502


    WOLFBET.COM - Exclusive VIP Rewards


    View Profile
    November 25, 2016, 09:34:37 PM
    Last edit: November 25, 2016, 09:45:03 PM by YIz
     #2
    The timestamp of 4417977600 represents January 1st 2110, at 12:00 AM. is this what you're asking?

    .WOLFBET....
    CRYPTO CASINO
    &     SPORTSBOOK
    ████████████████████
    ███████████████████████
    ███████████████████████
    ███████████████████████
    ███████████████████████
    ███████████████████████
    ███████████████████████
    ███████████████████████
    ███████████████████████
    ███████████████████████
    ███████████████████████
    ███████████████████████
    ███████████████████
    		███████
    ███████████
    █████████████
    ██████████████
    ███████████████
    ████████████████
    ████████████████
    ████████████████
    ███████████████
    ███████████████
    ██████████████
    ████████████
    ████████████████    		|
    |    		|
    |    		|
    |


    ███████████████████
    █████████████████████████
    █████████████████████████████
     
    ████████████████████████████
    █████████████████████████
    █████████████████████
    █████████████████
    ███████████████
    ████████████
    ████████████████████████
    		▄▄▄▄▄▄▄▄▄▄▄▄▄▄

    EXCLUSIVE VIP
    REWARDS

    ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

    ....PLAY NOW.

  • manuelra (OP)
    Newbie
    *
    Offline Offline

    Activity: 6
    Merit: 3


    View Profile
    November 25, 2016, 11:22:41 PM
     #3
    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
    Legendary
    *
    Offline Offline

    Activity: 1048
    Merit: 2847


    Bitcoin and C♯ Enthusiast


    View Profile WWW
    November 26, 2016, 05:35:35 PM
    Merited by ABCbits (2)
     #4
    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.
    Projects List+Suggestion box
    Donate: 1Q9s or bc1q
    		|
    |
    |
    FinderOuter(0.20.0)Ann-git
    Denovo(0.8.0)Ann-git
    Bitcoin.Net(0.27.0)Ann-git
    		|
    |
    |
    BitcoinTransactionTool(0.11.0)Ann-git
    WatchOnlyBitcoinWallet(4.0.0)Ann-git
    SharpPusher(0.14.0)Ann-git

  • manuelra (OP)
    Newbie
    *
    Offline Offline

    Activity: 6
    Merit: 3


    View Profile
    November 27, 2016, 01:24:02 PM
     #5
    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 (OP)
    Newbie
    *
    Offline Offline

    Activity: 6
    Merit: 3


    View Profile
    November 30, 2016, 02:36:15 PM
     #6
    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
    Moderator
    Legendary
    *
    expert
    Offline Offline

    Activity: 3766
    Merit: 7233


    Just writing some code


    View Profile WWW
    November 30, 2016, 03:55:08 PM
    Merited by ABCbits (1)
     #7
    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.
    Bitcoin Core contributor | Tip Me! | GitHub | GPG Key Fingerprint 0x17565732E08E5E41

  • gmaxwell
    Moderator
    Legendary
    *
    expert
    Offline Offline

    Activity: 4494
    Merit: 9662



    View Profile WWW
    December 02, 2016, 03:30:49 AM
    Merited by ABCbits (3)
     #8
    Quote from: achow101 on November 30, 2016, 03:55:08 PM
    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...)
    Pages: [1]
      Print  
Page 1
Viewing Page: 1

IRLBTC™ © 2025 IRLBTC.com