Topic: Strange Timestamp Argument (Read 263 times)

Do miners check that confirmed transactions from other miners have waited a sufficient nlocktime for a transaction? They must do...

If not, then I still don't fully understand what prevents a miner from processing delayed transactions early, since the signed transaction has all information viewable at any stage and a delayed locktime isn't relayed downstream, as far as I understand. It's mostly related to the honesty of the miners, isn't it? It's not really a concern, since the number of people desiring such a method would be minimal.

I read it. Okay, so the point for this accuracy improvement is to prevent any miner from claiming more transaction fees by lying their block timestamp.

But, why did you say block height 499,999,999 if the 32-bit limit will be reached far earlier than that?

These are Epoch Unix timestamps and when you convert the maximum possible value for a locktime to datetime you get the exact time I posted above. The locktime variable is a 32-bit unsigned integer so it can be as big as 0xffffffff which is equal to 4294967295. An example online tool for conversion: https://www.unixtimestamp.com/

When a unix time is specified, we used to determine it by comparing directly to the block timestamp, which really isn't as accurate as the one that we've implemented now.

I read in our wiki that the median time past is based on the last eleven blocks. Is there any specific reason the developers chose this or is it arbitrary?

Are you sure about that date? Did you possibly mean something like the year 6836 instead?

If nLocktime is time based it is not based on the current time, it is based on the blockchain's median time past.

Block height 499,999,999 or if time is used a time equal to Sun Feb 07 2106 06:28:15.

Is there a theoretical most distant future locktime that a transaction can have?

I imagine the fee would have to be quite large for miners to want to keep it in the mempool for that amount of time, and then it might become a race to see who could publish it the soonest after the benchmarked time.

If you change the transaction, then the signature on the transaction will no longer be valid.  This prevents anyone from changing anything about the transaction (including the amount being paid, the address it's being paid to, and/or the locktime.

Is there anything that prevents a future nLocktime transaction from being used early?

For example, if nLocktime were to be set for 6 months in the future, but a miner wanted to process the transaction now --
then could they republish the transaction with an nLocktime of now or the past?

Transactions don't have any timestamp at all.  They may, however, have an nLocktime.

nLocktime can be time based or height based.

If nLocktime is time based it is not based on the current time, it is based on the blockchain's median time past.

A transaction with a time based lock won't be relayed until it can be included in the next block coming up.

My question is:  Should the second transaction be considered valid if everyone can confirm that one of those transactions contains a false timestamp?

You probably didn't understand my query, but that's okay, I'll just make it clearer.
..
My question is:  Should the second transaction be considered valid if everyone can confirm that one of those transactions contains a false timestamp?

...

I didn't said that it has. You can obviously sign whatever you want from scratch. I was just wondering why the second transaction should be considered valid after every node observed that the user is cheating the system.

Could the user also enter an arbitrary time like 01-01-1970? He should, if the timestamp isn't somehow verified.

Array
(
    [txid] => e3a865d391af57193e4faad75080f3c8178cb696910cc19ea75877f06b9a3598
    [hash] => e3a865d391af57193e4faad75080f3c8178cb696910cc19ea75877f06b9a3598
    [version] => 2
    [size] => 85
    [vsize] => 85
    [weight] => 340
    [locktime] => 0
    [vin] => Array
        (
            

• => Array

               (
                    [txid] => 24e4ccbe8faedc59fa16465e787a0943d5b1b780ab58d00a15a7d7e2390c0edc
                    [vout] => 1
                    [scriptSig] => Array
                        (
                            [asm] =>
                            [hex] =>
                        )

                    [sequence] => 4294967295
                )

        )

    [vout] => Array
        (
            

• => Array

               (
                    [value] => 0.045
                    [n] => 0
                    [scriptPubKey] => Array
                        (
                            [asm] => OP_DUP OP_HASH160 043ea5736aa3a48ebdd5034309b590505d8bdd90 OP_EQUALVERIFY OP_CHECKSIG
                            [hex] => 76a914043ea5736aa3a48ebdd5034309b590505d8bdd9088ac
                            [reqSigs] => 1
                            [type] => pubkeyhash
                            [addresses] => Array
                                (
                                    

• => 1PSkWTzac8K8QGCq17ff27gPw1eHw3gTC

                               )

                        )

                )

        )

)

Broadcasting a transaction has zero dependency on your computer's system time.

What happens if you broadcast a signed a transaction at 19:00 using your system's clock, then once is confirmed, broadcast a signed transaction that spends an output from the previous once, but at 18:00. In other words, if you tease your system's clock and any node can confirm that you have, does that make the second transaction invalid?

If you get a block more than 2 hours in the future you won't accept it until its within 2 hours.  Any timestamp that passes these criteria is valid, anything else will be ignored.

If I understood Maxwell's comment correctly, let's give the hypothetical that there were only two miners on the network, and that they published blocks two years into the future:

Nodes would then wait two years before updating their own records, after their own clocks matched the published blocks, and only if there weren't conflicting blocks published before then. So, there is incentive for miners to be reasonably accurate.

Would that be correct? I've not looked into the code enough yet to know myself.