📅 Original date posted:2016-11-16 📝 Original message:Here is my thinking. The ...

Tom Zander [ARCHIVE] /

npub1mju…xnq7

2023-06-07 17:54:24

in reply to nevent1q…5qux

📅 Original date posted:2016-11-16
📝 Original message:Here is my thinking.

The BIP process is about changes to a living project which is the bitcoin
prptocol.
This specific BIP got accepted and we know in the blockchain that
this event (the acceptance) is recorded.
Before a certain block the rules were one way, after they were changed.

I have no problem with changing the *code* to be less complex because it
already knows the past. A checkpoint is the same, it is the registeration of
a past event.
This makes software less complex and still capable of checking the entire
blockchain from genesis.

I don’t see any harm in this change. I see prudent software engineering
practices.

On Monday, 14 November 2016 10:47:35 CET Eric Voskuil via bitcoin-dev wrote:
> NACK
>
> Horrible precedent (hardcoding rule changes based on the assumption that
> large forks indicate a catastrophic failure), extremely poor process
> (already shipped, now the discussion), and not even a material
> performance optimization (the checks are avoidable once activated until a
> sufficiently deep reorg deactivates them).

--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Author Public Key

npub1mju50kqcm07heu967fkq6h4kq666xgekc4yrldf7q52xx9vr8jnsrdxnq7

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-06-07 17:54:24

Kind type

1 Short Text Note

Event JSON

{ "id": "8389337894daecc660790ac0e0656baa251c9c82dadb029945d448f8151b220d", "pubkey": "dcb947d818dbfd7cf0baf26c0d5eb606b5a32336c5483fb53e05146315833ca7", "created_at": 1686160464, "kind": 1, "tags": [ [ "e", "50cde70d11f9c69cc787e52010ba0256918f920ad1f9811ad6566a1543ec1282", "", "root" ], [ "e", "a83d83ad26efa5ff122fb2c11882c4c0f3c477801da4c865625149acbc6b1b14", "", "reply" ], [ "p", "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e" ] ], "content": "📅 Original date posted:2016-11-16\n📝 Original message:Here is my thinking.\n\nThe BIP process is about changes to a living project which is the bitcoin \nprptocol.\nThis specific BIP got accepted and we know in the blockchain that\nthis event (the acceptance) is recorded.\nBefore a certain block the rules were one way, after they were changed.\n\nI have no problem with changing the *code* to be less complex because it \nalready knows the past. A checkpoint is the same, it is the registeration of \na past event.\nThis makes software less complex and still capable of checking the entire \nblockchain from genesis.\n\nI don’t see any harm in this change. I see prudent software engineering \npractices.\n\n\nOn Monday, 14 November 2016 10:47:35 CET Eric Voskuil via bitcoin-dev wrote:\n\u003e NACK\n\u003e \n\u003e Horrible precedent (hardcoding rule changes based on the assumption that\n\u003e large forks indicate a catastrophic failure), extremely poor process\n\u003e (already shipped, now the discussion), and not even a material\n\u003e performance optimization (the checks are avoidable once activated until a\n\u003e sufficiently deep reorg deactivates them).\n\n\n-- \nTom Zander\nBlog: https://zander.github.io\nVlog: https://vimeo.com/channels/tomscryptochannel", "sig": "0ef124b0e8ed9e94d59e802b46ddbfd14356255eea106867cf0dcac1cb5026339564a573e6961c6c115954100e60c5b475a16a8107328dafc70ea0d5f4764f8d" }