{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-11-16\n📝 Original message:On Wed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Are checkpoints good now? Are hard forks okay now?\n\u003e\n\nI think that at least one checkpoint should be included.  The assumption is\nthat no 50k re-orgs will happen, and that assumption should be directly\nchecked.\n\nCheckpointing only needs to happen during the headers-first part of the\ndownload.\n\nIf the block at the BIP-65 height is checkpointed, then the comparisons for\nthe other ones are automatically correct.  They are unnecessary, since the\ncheckpoint protects all earlier block, but many people would like to be\nable to verify the legacy chain.\n\nThis makes the change a soft-fork rather than a hard fork.  Chains that\ndon't go through the checkpoint are rejected but no new chains are allowed.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161116/da3702fc/attachment.html\u003e"}