📅 Original date posted:2021-10-17
📝 Original message:Hi yanmaani
On Sun, Oct 17, 2021 at 5:28 PM yanmaani--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
>
"Anything" is quite a word.
Ideally, hard fork requires upgrading every node that can be upgraded,
or at least have the node operator's consent to lose the node (for every
node that can't be upgraded).
>
> On 2021-10-15 22:22, vjudeu at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211017/a7bd292d/attachment.html>;
Kate Salazar [ARCHIVE] /
npub10h…ykleg
2023-06-07 23:00:09
in reply to nevent1q…4erz
Author Public Key
npub10hssethcgvfcuuv0z24encsds34cu4knlk8lqr2qgtll9szaa5ts5yklegPublished at
2023-06-07 23:00:09Event JSON
{
"id": "597f9cc0ace95306dc73ef2ae014a6fd843aa074a2c4262151f81b1a1f2e2bc7",
"pubkey": "7de10caef843138e718f12ab99e20d846b8e56d3fd8ff00d4042fff2c05ded17",
"created_at": 1686178809,
"kind": 1,
"tags": [
[
"e",
"c0e13d397dc71c2d737cbe4277ed0c11fb0c8d97302650a28ed4170c1d01b58d",
"",
"root"
],
[
"e",
"7439ffc353af2d87d9ebcb7990ffd8ae3cba4b167773e66afe0c3988082657fb",
"",
"reply"
],
[
"p",
"8f5bcf9ba2de88dd877a672f629a5c6a7bebbeda3fa51324521e03863d8fe094"
]
],
"content": "📅 Original date posted:2021-10-17\n📝 Original message:Hi yanmaani\n\nOn Sun, Oct 17, 2021 at 5:28 PM yanmaani--- via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e What, no. The `k` value is calculated implicitly, because there's only\n\u003e one value of it that could ever be valid - if `k` is 1 too small, we're\n\u003e 70 years too far back, and then the block will violate median of last\n\u003e 11. If `k` is 1 too large, we're 70 years too far in the future, then\n\u003e the block will violate 2 hour rule. Nothing is added to coinbase or\n\u003e anywhere else.\n\u003e\n\u003e It's possible that you'd need some extra logic for locktime, yes, but it\n\u003e would only be a problem in very special cases. Worst-case, you'll have\n\u003e to use block time locking in the years around the switch, or softfork in\n\u003e 64-bit locking.\n\u003e\n\u003e But unless I'm missing something, 32-bit would be enough, you just\n\u003e wouldn't be able to locktime something past the timestamp for the\n\u003e switch. After the switchover, everything would be back to normal.\n\u003e\n\u003e This is a hardfork, yes, but it's a hardfork that kicks in way into the\n\u003e future. And because it's a hardfork, you might as well do anything, as\n\u003e long as it doesn't change anything now.\n\u003e\n\n\"Anything\" is quite a word.\nIdeally, hard fork requires upgrading every node that can be upgraded,\nor at least have the node operator's consent to lose the node (for every\nnode that can't be upgraded).\n\n\n\u003e\n\u003e On 2021-10-15 22:22, vjudeu at gazeta.pl wrote:\n\u003e \u003e Your solution seems to solve the problem of chain halting, but there\n\u003e \u003e are more issues. For example: if you have some time modulo 2^32, then\n\u003e \u003e you no longer know if timestamp zero is related to 1970 or 2106 or\n\u003e \u003e some higher year. Your \"k\" value representing in fact the most\n\u003e \u003e significant 32 bits of 64-bit timestamp has to be stored in all cases\n\u003e \u003e where time is used. If there is no \"k\", then zero should be used for\n\u003e \u003e backward compatibility. Skipping \"k\" could cause problems related to\n\u003e \u003e OP_CHECKLOCKTIMEVERIFY or nLockTime, because if some transaction was\n\u003e \u003e timestamped to 0xbadc0ded, then that transaction will be valid in\n\u003e \u003e 0x00000000badc0ded, invalid in 0x0000000100000000, and valid again in\n\u003e \u003e 0x00000001badc0ded, the same for timelocked outputs.\n\u003e \u003e\n\u003e \u003e So, I think your \"k\" value should be added to the coinbase\n\u003e \u003e transaction, then you can combine two 32-bit values, the lower bits\n\u003e \u003e from the block header and the higher bits from the coinbase\n\u003e \u003e transaction. Also, adding your \"k\" value transaction nLockTime field\n\u003e \u003e is needed (maybe in a similar way as transaction witness was added in\n\u003e \u003e Segwit), because in other case after reaching 0x0000000100000000 all\n\u003e \u003e off-chain transactions with timelocks around 0x00000000ffffffff will\n\u003e \u003e be additionally timelocked for the next N years. The same is needed\n\u003e \u003e for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before the\n\u003e \u003e currently used value will solve that (and assuming zero if there is\n\u003e \u003e only some 32-bit value).\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211017/a7bd292d/attachment.html\u003e",
"sig": "9f44fd4cdd831e71d8ee6eb52aa206dc37dde5c9d4f8203acfb51ddc69ed499fda359dd0fc81737b2c53a0a7fd3fb316ded918ba87e3e073ee5d1ad493e8265d"
}