What, no. The `k` value is calculated implicitly, because there's only
one value of it that could ever be valid - if `k` is 1 too small, we're
70 years too far back, and then the block will violate median of last
11. If `k` is 1 too large, we're 70 years too far in the future, then
the block will violate 2 hour rule. Nothing is added to coinbase or
anywhere else.
It's possible that you'd need some extra logic for locktime, yes, but it
would only be a problem in very special cases. Worst-case, you'll have
to use block time locking in the years around the switch, or softfork in
64-bit locking.
But unless I'm missing something, 32-bit would be enough, you just
wouldn't be able to locktime something past the timestamp for the
switch. After the switchover, everything would be back to normal.
This is a hardfork, yes, but it's a hardfork that kicks in way into the
future. And because it's a hardfork, you might as well do anything, as
long as it doesn't change anything now.
On 2021-10-15 22:22, vju...@gazeta.pl wrote:
Your solution seems to solve the problem of chain halting, but there
are more issues. For example: if you have some time modulo 2^32, then
you no longer know if timestamp zero is related to 1970 or 2106 or
some higher year. Your "k" value representing in fact the most
significant 32 bits of 64-bit timestamp has to be stored in all cases
where time is used. If there is no "k", then zero should be used for
backward compatibility. Skipping "k" could cause problems related to
OP_CHECKLOCKTIMEVERIFY or nLockTime, because if some transaction was
timestamped to 0xbadc0ded, then that transaction will be valid in
0x00000000badc0ded, invalid in 0x0000000100000000, and valid again in
0x00000001badc0ded, the same for timelocked outputs.
So, I think your "k" value should be added to the coinbase
transaction, then you can combine two 32-bit values, the lower bits
from the block header and the higher bits from the coinbase
transaction. Also, adding your "k" value transaction nLockTime field
is needed (maybe in a similar way as transaction witness was added in
Segwit), because in other case after reaching 0x0000000100000000 all
off-chain transactions with timelocks around 0x00000000ffffffff will
be additionally timelocked for the next N years. The same is needed
for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before the
currently used value will solve that (and assuming zero if there is
only some 32-bit value).
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
