Bitcoin users or miners - who is behind(initiates) a bitcoin Locktime?

[pooya87]

just add an extra 4 bytes

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?

that way you get alot more use out nlocktime than 9500 years.

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?

and it works past the year 2106...

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).

[vjudeu]

small and hard to understand

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.

is that going to be a bug or what are people going to do?

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".

satoshi must have been a linux hacker

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.

it requires all these possible fixes you mentioned

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.

what a disaster of an opcode

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.

[larry_vw_1955]

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?

to segregate two different functionalities.

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.

if that's the case then why are you here? shouldn't you be spending your time on something that is going to last?

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).

I see you have a crystal ball now and are able to somehow see into the future. Interesting...

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.

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...

[vjudeu]

i don't see the point in specifying a particular date and time since bitcoin knows nothing about precise times.

It is as precise, as it can be. The network is decentralized. Which means, that there is no one central clock. And how do you want to agree on the current time, when one node can say "it is 12:08:34", and another node can say "it is 12:08:35". How do you want to determine, who is telling the truth, in a decentralized way?

Also, specifying the date and time works quite well in practice. For example, once I locked a transaction into 17,0000,0000. It means "Tue Nov 14 22:13:20 2023 UTC". I broadcasted it at "October 02, 2023, 05:45:54 AM" (forum time), and it was confirmed on "2023-11-15 01:13:58". See? The time of the block was 17,0000,7238, so this transaction was confirmed just two hours after becoming valid.

blocks are not at exact time intervals

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.

so there really is no reason to be using a date and time for a locking mechanism

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

the software could take your datetime and convert that to an estimated block height internally

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.

Code:

2009   50.00000000
2013   25.00000000
2017   12.50000000
2021    6.25000000
2025    3.12500000

Currently, we have 2024, and the basic block reward already dropped into 3.125 BTC. See?

[ABCbits]

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).

I see you have a crystal ball now and are able to somehow see into the future. Interesting...

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.

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.

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...

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.

[larry_vw_1955]

What are you talking about? He clearly state the reason and source, which can be found on https://www.secg.org/sec1-v2.pdf.

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.

Code:

Security level Symmetric ECC DSA/RSA Protects to year
80 80 160 1024 2010
112 112 224 2048 2030
128 128 256 3072 2040
192 192 384 7680 2080
256 256 512 15360 2120

For example, SHA-1 which created on 1995 stopped being used by most company between 2010-2020.

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

But should the software assume block time is always at 10 minutes?

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.

[vjudeu]

what would happen if enough miners just set their clocks to 500 years into the future

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.

you can't forge blockheight but you can forge a timestamp simple as that

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).

[ABCbits]

What are you talking about? He clearly state the reason and source, which can be found on https://www.secg.org/sec1-v2.pdf.

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.

Code:

Security level Symmetric ECC DSA/RSA Protects to year
80 80 160 1024 2010
112 112 224 2048 2030
128 128 256 3072 2040
192 192 384 7680 2080
256 256 512 15360 2120

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.

For example, SHA-1 which created on 1995 stopped being used by most company between 2010-2020.

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

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

[larry_vw_1955]

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

They estimated that for about $10 million a machine with 325,000 processors could be built that would solve the ECDLP for an elliptic curve E with n ≈ 2^120 in about 35 days. Hardware attacks on larger values of n, such as n ≈ 2^160, appear impractical at this time. Pelzl [Pel06] estimated in 2006 that the cost of special purpose hardware to solve the ECDLP for n ≈ 2^160 over a prime field is about $6 × 10^11.

it's funny how they later say that computer power is going up by a factor of 2^16 per decade. so it's been almost 2 decades since they made these estimates. that means computing power went up by 2^32.  so that $10 million machine that could solve n=2^120 in 35 days should now be able to handle 2^152 in 35 days. multiply that by 2^8 and it can do 2^160 in less than 10 years. which contradicts their table that says that 128 bit ECC should be secure until 2040.

i think the problem is in their later assumption that computer power increases by a factor of 65536 every 10 years. i don't think that's true. not even close. i think on average it might increase by a factor of 10. but not a factor of 65536.

[hosseinimr93]

A locktime only prevents a transaction from being mined before a certain time (or height). You can still replace it with RBF as long as the nsequence values of the inputs you want to change are 0xfffffffd or below. But I guess that is no longer relevant with the emergence of mempoolrullrbf.

There is no need to RBF.

Nodes reject any transaction with locktime set in the future.
Therefore, if you have broadcasted a transaction with locktime set in the future, nodes don't have that in their mempools and you can easily broadcast a new transaction using same inputs even with lower fee.