Topic: Bitcoin users or miners - who is behind(initiates) a bitcoin Locktime? (Read 366 times)

I never said that, i just wanted to point out @pooya87 use that PDF as reference rather than "have a crystal ball now and are able to somehow see into the future". And while i agree it may not turn out the be true, they attempt to explain it on B.1 page 70 to 72 and B.2.11 page 84 to page 85. Although on 2024, we can see the explanation isn't very good since Moore Law slows down and it doesn't consider quantum computing.


You're right, although i've stated it's just an example how cryptography usually only deemed secure for some time.

You won't see any blocks, which are further than two hours in the future anyway. They will be mined, they will wait for being broadcasted, but you won't get them in your node. And also, anyone could mine a competing block in the meantime, at the same height. Which means, that if anyone is mining further than two hours in the future, then that miner is taking a huge risk of getting all of that reorged.

If you can forge a timestamp, then you can lower the difficulty as well, and produce more blocks than usual (which means, that you indirectly can fake block height as well).

So we're supposed to just accept their table without them providing any explanation or justifications? Anyone could make up a table like that just saying "let's make the key sizes get bigger every 10 years or so." Unless they can provide some rigorous argument, lets not state these things as facts just rules of thumb projections which may not turn out to be true.



That doesn't have anything to do with the security of SHA256.


we really don't have a way to measure real world time in bitcoin. blocktimes are based on time stamps from miners what would happen if enough miners just set their clocks to 500 years into the future. well then they could mine transactions whose nLocktime was set using the datetime. some people would be pretty surprised to see that their nLocktime had no affect...

you can't forge blockheight but you can forge a timestamp simple as that. it may not be easy but i think it is possible.

What are you talking about? He clearly state the reason and source, which can be found on https://www.secg.org/sec1-v2.pdf. And it's common that cryptography only deemed secure for some time. For example, SHA-1 which created on 1995 stopped being used by most company between 2010-2020.


But should the software assume block time is always at 10 minutes? Few years ago, i did quick calculation which shows average block time is only about 9.4 minutes since hashrate/difficulty almost always growing.

Because they don't have to be. You know, why blocks are timestamped at all? To determine the next difficulty. If not that, then they could be created without any timestamps. And by knowing that, do you think the difficulty is underestimated or overestimated? Because I think it is quite accurate, which means, that block timestamping works fine, as it is.

There are other ways, if you want to use them. If you really want another kind of locktime, then you can try hash-based locktime: https://gwern.net/self-decrypting

Yeah, and then your transaction could be months away from the time, when you want it to confirm. For example: see the exact times of each and every halving, and compare it with scheduled time.
Currently, we have 2024, and the basic block reward already dropped into 3.125 BTC. See?

to segregate two different functionalities.


I should be able to use nlocktime to specify any block height i want to even if it's more than 500 million. that's my stance. i don't see the point in specifying a particular date and time since bitcoin knows nothing about precise times. and blocks are not at exact time intervals so there really is no reason to be using a date and time for a locking mechanism. the software could take your datetime and convert that to an estimated block height internally...

Adding a single "if" in some already working implementation is much easier, than introducing some completely separate field in your data structure, update it in all serialization methods, not forget about constructors and destructors (if any), and so on.

Satoshi did the simplest thing he could. He just called some functions from the standard library or WinAPI, without thinking about "2106 year problem" or "2038 year problem". In the same way, people use "int" as their data type, without thinking if it is "int32", "int64", or maybe "uint32". In that case, Satoshi was aware enough to use unsigned integers, and to specify the size of those fields in most cases, but he was not aware enough, to do the same with time-based data types, like "time_t".

Definitely not. He used Windows, and there are some traces, leading to the conclusion, that he was running Windows on a real hardware, without any virtualization (because in that case, it would affect his mining performance, and some other things). Even if you assume, that he privately used some kind of Linux, then definitely he had at least one physical machine, with Japanese version of Windows XP, without any VirtualBox, and used that for development.

At that time, people didn't think about soft-forks and hard-forks, as we do it now. There were old times, when people thought, that you can upgrade the whole Script by using OP_VER (which is now disabled). In the same way, people thought, that transaction versions and block versions can be used to fully replace everything. But now, we know, that it is not the case.

There are two different things, which should be clearly separated:

1. nLockTime at the end of transaction
2. OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY inside Script

Also note, that even if we run out of those, and if all locktime values could be used (so nLockTime will become de-facto transaction nonce), then still, adding new opcodes is possible. Also: reusing existing ones is another option. Which means, that after block 500,000,000, and after year 2106, when every locktime value will be valid, we can implement completely different locktime rules from scratch, without any limits.

Why? What's the benefit of increasing the transaction size by a fixed 4 byte and wasting the block space for something that can be done already using the current method?

Think about that number a little bit. 9500 YEARS. Bitcoin is probably an ancient history after 100 years just like fire that cavemen built thousands of years ago. In 9500 years people may not even remember something called Bitcoin ever existed.
So I ask again what's the benefit of adding an extra 4 bytes that is never going to be used?

There are a lot of things in the protocol that won't work way before 2106 like SHA256 and ECDSA using secp256k1 curve. For example this last part according to SEC 1 v2 the 256 bit curve is only secure until 2040 (B.2.1 page 73, table 3).

oh i already know that. i'm glad you agree.

small and hard to understand and work with and possible unintended consequences if things don't get fixed for that year 2106 bug. is that going to be a bug or what are people going to do? 


satoshi must have been a linux hacker. its a hack. that's all it is and not even a very elegant one. and yet, it requires all these possible fixes you mentioned just so it can keep working past 2106 what a disaster of an opcode.

https://en.bitcoin.it/wiki/NLockTime

1. The time always moves forward in the long term. It has to be strictly greater than MTP, which means, that you cannot start from the Genesis Block in 2009, and get a valid block in 2005.
2. For miners, it is profitable to move the time forward. Especially in testnet, where by moving it 20 minutes to the future, you can work with the minimal difficulty. But also in mainnet, if you have more time between blocks, then the difficulty is decreased.
3. Blocks are accepted up to two hours in the future. However, it can be changed locally in the node settings. And as always: you can work on future blocks, but if you work very far in the future (more than two hours), then there is a huge risk of getting your blocks reorged (because they are rejected by other nodes, until their clock will get there, and your blocks will be in this two hours window).
4. If you have some decentralized clock, then there is no one source of truth. Actually, we have three, which means, that having some "wiggle room" is a good thing. As Satoshi wrote in version 0.1.0:


Edit: It is far from perfect, but it was better to have any format, than to have no format at all. And also, it shows that Satoshi tried to compress things, as much as he could. For that reason, we have VarInt. For the same reason, we have compressed 256-bit target into 32-bit value. If Satoshi would know about compressed public keys, then we could also have them from the start. But because he didn't know about it, he applied SHA-256 and RIPEMD-160, to get 160-bit addresses, because 256-bit and 512-bit ones were too big.

So, is it possible to have two separate locktimes, one for block numbers, and one for timestamps? Yes, of course. But: Satoshi wanted to make it small. And I guess it could be even smaller, like "skip the last four bytes, if there is no locktime", but we cannot have that now, because locktime is signed (even if you use SIGHASH_NONE | SIGHASH_ANYONECANPAY).

1. Do you need bigger timespan than 136 years, with accuracy up to one second?
2. It is possible to re-activate locktime in the future, by treating it like (time64 % 2^32). It is a soft-fork.
3. It is more likely, that the time in the block header will be also expressed as something like (time64 % 2^32) in the future. Because if you switch from 80-byte block headers into for example 84-byte block headers, then it will be ASIC-incompatible.

1. You can separate them in your implementation, and add back-and-forth conversion, without touching any consensus rules. It would be a no-fork, not even a soft-fork, if you want to change it locally.
2. It is not a "poor design". It is just some kind of compression. And also tell me: if block numbers wouldn't be there, then would you really need to put locktime between 1970 and 1985, with accuracy to a single second?

how much wiggle room is there? that doesn't sound like a good thing.

does that seem like an ideal solution or does that seem like shoehorning two totally separate ways of locking a transaction into the same field? think about it. just add an extra 4 bytes and have one set of bytes for block height and the other set for datetime. that way you get alot more use out nlocktime than 9500 years. and it works past the year 2106... 

having those 4 bytes perform separate things with different meanings is just an example of poor design.

There are some corner cases, where you may want to keep some transaction, even if some locktime is still active. For example: if you have a timelock, set to some block 1,234,567. Then, the block 1,234,567 is reorged, and miners are working on that block again. And then, some transaction had one confirmation, but now has zero. However, we are no longer on that height, to get this transaction included in the next block, but maybe after two or three blocks, it should be added. Then, if you throw it away, then there is a risk, that it will be simply dropped and ignored, if enough nodes will behave in the same way.

To sum up: if you can see a lot of timelocked transactions, and there is some chain reorganization ongoing, then there is a room to simply drop some transactions as "non-final".

Great, then some of Blockcypher's nodes don't belong to those nodes "that enforce that rule".

I generalized the first part because it's pretty much mandatory to protect the owner's node due to it being a DDOS attack vector.
Plus, I'm not aware of any implementation that accept such transaction to their mempool, some niche or personal Bitcoin client maybe.

This is almost true. Almost, because it is the case for those, who use Bitcoin Core. But there are sites, which can accept timelocked transactions for some reason, hold them for a few hours, and then drop, when it will stay unconfirmed (and yes, for those few hours, they may even show, that there is 35% chance for transaction inclusion, even if the real chance is 0%, because of the locktime).

Some example of such website: https://live.blockcypher.com/btc-testnet/pushtx/

Let me add a clarification regarding this for OP.

Transactions with nLocktime field set to future dates/block will be rejected by nodes as "non-final", so it wont make it in any node's mempool that enforce that rule.
so it'll either stay in the wallet locally (not broadcasted); or in text, digital or paper.
Ref: github.com/bitcoin/bitcoin/blob/538363738e9e30813cf3e76ca4f71c1aaff349e7/src/validation.cpp#L797-L802

NotATether must be referring to scripts with CheckLocktimeVerify (OP_CLTV) that prohibits the UTXO to be spent until the set expiration date/block in the script.
In this case, locked UTXO can be included to mempools then the blockchain once "mined" but can't be spent until the right condition is fulfilled.
OP_CLTV (BIP-65): github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
Example use-case: coinb.in/#newTimeLocked

There is a mechanism. It is through the timestamp inside block headers. The result has some "wiggle room", since it is not an accurate time.

In each tx we only have 4 bytes to work with as locktime, so we evaluate those 4 bytes like what I explained above. The space is large enough to cover everything.
Think about those values:

• Any value from 0 to 500,000,000 is interpreted as a block height. We don't really need any more since after 15 years we are still at 850k blocks and it would take ~9500 years to get to 500 mil blocks so it covers everything we need.
• Any value from 500,000,000 to 4,294,967,295 (0xffffffff) is interpreted as datetime. As epoch, that value is between 1985 and 2106 which covers all datetime values we need.

i can understand how everyone could agree on a block height but how does the network come to consensus about a datetime? that doesn't make any sense. there is no consensus mechanism for everyone agreeing on the time. not on bitcoin. so i think this nLocktime feature is suspect.  

there should be 2 separate locktimes. one for datetime and one for block height but mixing the two and having a threshhold where one stops and the other kicks in, it's like you're saying after that point you can't use blockheight for specifying a locktime. ridiculous.

There is only one nLocktime and that single value can only represent one thing, either a datetime value (if bigger than the threshold) or a block height (if smaller than the threshold). That threshold is 500,000,000.

So does this mean that only one of them (time-based lock time or height-based lock time) can be done for a single transaction at a time.

Imagine that the basic block reward is very low, and the coinbase transaction is made out of transaction fees, and not much more than that. Then, Alice creates a transaction in block 1,234,567, with some huge fee, which is confirmed in this block. Imagine that the block 1,234,566 could be reorged, and include Alice's transaction. If that would be the case, then miners could just take the most profitable transactions, from a range of some blocks (for example from the last five blocks), and it could be profitable, to reorg all of those blocks, and to mine for example a block 1,234,563, with the highest possible transaction fees.

So, locking the transaction to the current height simply means, that if Alice's transaction has to appear in block 1,234,567, and cannot be included earlier, then it is no longer possible, to take the most expensive transactions, and just mine some block at the same height, by replacing it over and over again, with some tasty fees, and throwing away other transactions (which will also raise fees, if mempools will start filling up).

Some extreme example: all transactions have locktime zero, and miners could simply mine the same block over and over again, without moving the chain forward. And then, they can wait ad infinitum for bigger and bigger fees. But if you have locktime, then you may say "you will get those fees, but only if you work on some next block, and push the chain forward".