What is Nostr?
Adam Back [ARCHIVE] /
npub1ac8…swfj
2023-06-07 17:46:44
in reply to nevent1q…78mj

Adam Back [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-17 📝 Original message:While it is interesting to ...

📅 Original date posted:2015-12-17
📝 Original message:While it is interesting to contemplate moving to a world with
hard-fork only upgrades (deprecate soft-forks), now is possibly not
the time to consider that. Someone can take that topic and make a
what-if sketch for how it could work and put it on the wishlist wiki
if its not already there.

We want to be pragmatic and constructive to reach consensus and that
takes not mixing in what-ifs or orthogonal long standing problems into
the mix, as needing to be fixed now.

Adam


On 17 December 2015 at 19:52, Jeff Garzik via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Thu, Dec 17, 2015 at 1:46 PM, jl2012 <jl2012 at xbt.hk> wrote:
>>
>> This is not correct.
>>
>> As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx
>> are less secure than others? I don't think so. Since one invalid CLTV tx
>> will make the whole block invalid. Having more nodes to fully validate
>> non-CLTV txs won't make them any safer. The same logic also applies to SW
>> softfork.
>
>
>
> Yes - the logic applies to all soft forks. Each soft fork degrades the
> security of non-upgraded nodes.
>
> The core design of bitcoin is that trustless nodes validate the work of
> miners, not trust them.
>
> Soft forks move in the opposite direction. Each new soft-forked feature
> leans very heavily on miner trust rather than P2P network validation.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Author Public Key
npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj