yanmaani at cock.li [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-17 📝 Original message:Well, it's the right word. ...
📅 Original date posted:2021-10-17
📝 Original message:Well, it's the right word. If you're going to do a hardfork by changing
the timestamp definition, you're already doing a hardfork. At that
point, you've already crossed the Rubicon and might as well put in any
other necessary changes (e.g. to transaction locking), because it will
be as much of a hardfork either way.
The important bit here is "as long as it doesn't change anything now" -
this is indeed a hardfork, but it's a timestamp-activated hardfork that
triggers in 2106. Until that point, it has absolutely no bearing on
consensus rules (as opposed to the other proposals, which are at least a
soft-fork today).
I understand that there's some problems in getting consensus for forks,
but surely we can agree that everyone will update their Bitcoin at least
once in the next 85 years? (If they don't, they're doomed anyway.)
On 2021-10-17 15:46, Kate Salazar wrote:
> Hi yanmaani
>
...
>> 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).
>
...
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:Well, it's the right word. If you're going to do a hardfork by changing
the timestamp definition, you're already doing a hardfork. At that
point, you've already crossed the Rubicon and might as well put in any
other necessary changes (e.g. to transaction locking), because it will
be as much of a hardfork either way.
The important bit here is "as long as it doesn't change anything now" -
this is indeed a hardfork, but it's a timestamp-activated hardfork that
triggers in 2106. Until that point, it has absolutely no bearing on
consensus rules (as opposed to the other proposals, which are at least a
soft-fork today).
I understand that there's some problems in getting consensus for forks,
but surely we can agree that everyone will update their Bitcoin at least
once in the next 85 years? (If they don't, they're doomed anyway.)
On 2021-10-17 15:46, Kate Salazar wrote:
> Hi yanmaani
>
...
>> 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).
>
...
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev