📅 Original date posted:2016-11-16
📝 Original message:BIP30 actually was given similar treatment after a reasonable amount of
time had passed.
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392
You are also missing BIP50: 'March 2013 Chain For Post-Mortem', which
neither benefited nor improved bitcoin, but did document an event for
posterity.
This is not a hard fork. Removing ISM just means we've committed to
those soft-forks only locking into the chain we use now.
On 11/16/2016 01:58 PM, Eric Voskuil via bitcoin-dev wrote:
> This sort of statement represents one consequence of the
> aforementioned bad precedent.
>
> Are checkpoints good now? Are hard forks okay now?
>
> What is the maximum depth of a reorg allowed by this non-machine
> consensus?
>
> Shouldn't we just define a max depth so that all cruft deeper than
> that can just be discarded on a regular basis?
>
> Why are there activation heights defined by this hard fork if it's not
> possible to reorg back to them?
>
> The "BIP" is neither a Proposal (it's been decided, just documenting
> for posterity), nor an Improvement (there is no actual benefit, just
> some tidying up in the notoriously obtuse satoshi code base), nor
> Bitcoin (a hard fork defines an alt coin, so from Aug 4 forward it has
> been CoreCoin).
>
> e
>
> On Nov 16, 2016, at 5:29 AM, Jameson Lopp <jameson.lopp at gmail.com
> <mailto:jameson.lopp at gmail.com>> wrote:
>
>> Since "buried deployments" are specifically in reference to
>> historical consensus changes, I think the question is more one of
>> human consensus than machine consensus. Is there any disagreement
>> amongst Bitcoin users that BIP34 activated at block 227931, BIP65
>> activated at block 388381, and BIP66 activated at block 363725?
>> Somehow I doubt it.
>>
>> It seems to me that this change is merely cementing into place a few
>> attributes of the blockchain's history that are not in dispute.
>>
>> - Jameson
>>
>> On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> Actually this does nothing to provide justification for this
>> consensus rule change. It is just an attempt to deflect criticism
>> from the fact that it is such a change.
>>
>> e
>>
>> > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak at gmail.com
>> <mailto:btcdrak at gmail.com>> wrote:
>> >
>> > I think this is already covered in the BIP text:-
>> >
>> > "As of November 2016, the most recent of these changes (BIP 65,
>> > enforced since December 2015) has nearly 50,000 blocks built on
>> top of
>> > it. The occurrence of such a reorg that would cause the activating
>> > block to be disconnected would raise fundamental concerns about the
>> > security assumptions of Bitcoin, a far bigger issue than any
>> > non-backwards compatible change.
>> >
>> > So while this proposal could theoretically result in a consensus
>> > split, it is extremely unlikely, and in particular any such
>> > circumstances would be sufficiently damaging to the Bitcoin
>> network to
>> > dwarf any concerns about the effects of this proposed change."
>> >
>> >
>> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
>> > <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> 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).
>> >>
>> >> e
>> >>
>> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Recently Bitcoin Core merged a simplification to the consensus
>> rules
>> >> surrounding deployment of BIPs 34, 66, and 65
>> >> (https://github.com/bitcoin/bitcoin/pull/8391
>> <https://github.com/bitcoin/bitcoin/pull/8391>;), and though the
>> change is a
>> >> minor one, I thought it was worth documenting the rationale in
>> a BIP for
>> >> posterity.
>> >>
>> >> Here's the abstract:
>> >>
>> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated
>> via miner
>> >> signaling in block version numbers. Now that the chain has
>> long since passed
>> >> the blocks at which those consensus rules have triggered, we
>> can (as a
>> >> simplification and optimization) replace the trigger mechanism
>> by caching
>> >> the block heights at which those consensus rules became enforced.
>> >>
>> >> The full draft can be found here:
>> >>
>> >>
>> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki
>> <https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki>;
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>> >>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>> >>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>>
>>
>
>
> _______________________________________________
> 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/20161116/794ee05f/attachment.html>;
Thomas Kerin [ARCHIVE] /
npub1e4…nt5am
2023-06-07 17:54:20
in reply to nevent1q…slsn
Author Public Key
npub1e4azew50kk9xzvfpqxzlyftkjt6kken0kf9lnncpdj524f9y4cqsfnt5amPublished at
2023-06-07 17:54:20Event JSON
{
"id": "c504e1c22b2b4671035017db7b43ea74c169e2f4905553c80d216719d61c6f4e",
"pubkey": "cd7a2cba8fb58a6131210185f2257692f56b666fb24bf9cf016ca8aaa4a4ae01",
"created_at": 1686160460,
"kind": 1,
"tags": [
[
"e",
"50cde70d11f9c69cc787e52010ba0256918f920ad1f9811ad6566a1543ec1282",
"",
"root"
],
[
"e",
"a625bffedb808502edc8daeb3cddde5a8ccd05e375f22d69ea560dd9e51c32c4",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2016-11-16\n📝 Original message:BIP30 actually was given similar treatment after a reasonable amount of\ntime had passed.\nhttps://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392\n\nYou are also missing BIP50: 'March 2013 Chain For Post-Mortem', which\nneither benefited nor improved bitcoin, but did document an event for\nposterity.\n\nThis is not a hard fork. Removing ISM just means we've committed to\nthose soft-forks only locking into the chain we use now.\n\nOn 11/16/2016 01:58 PM, Eric Voskuil via bitcoin-dev wrote:\n\u003e This sort of statement represents one consequence of the\n\u003e aforementioned bad precedent.\n\u003e\n\u003e Are checkpoints good now? Are hard forks okay now?\n\u003e\n\u003e What is the maximum depth of a reorg allowed by this non-machine\n\u003e consensus?\n\u003e\n\u003e Shouldn't we just define a max depth so that all cruft deeper than\n\u003e that can just be discarded on a regular basis?\n\u003e\n\u003e Why are there activation heights defined by this hard fork if it's not\n\u003e possible to reorg back to them?\n\u003e\n\u003e The \"BIP\" is neither a Proposal (it's been decided, just documenting\n\u003e for posterity), nor an Improvement (there is no actual benefit, just\n\u003e some tidying up in the notoriously obtuse satoshi code base), nor\n\u003e Bitcoin (a hard fork defines an alt coin, so from Aug 4 forward it has\n\u003e been CoreCoin).\n\u003e\n\u003e e\n\u003e\n\u003e On Nov 16, 2016, at 5:29 AM, Jameson Lopp \u003cjameson.lopp at gmail.com\n\u003e \u003cmailto:jameson.lopp at gmail.com\u003e\u003e wrote:\n\u003e\n\u003e\u003e Since \"buried deployments\" are specifically in reference to\n\u003e\u003e historical consensus changes, I think the question is more one of\n\u003e\u003e human consensus than machine consensus. Is there any disagreement\n\u003e\u003e amongst Bitcoin users that BIP34 activated at block 227931, BIP65\n\u003e\u003e activated at block 388381, and BIP66 activated at block 363725?\n\u003e\u003e Somehow I doubt it.\n\u003e\u003e\n\u003e\u003e It seems to me that this change is merely cementing into place a few\n\u003e\u003e attributes of the blockchain's history that are not in dispute.\n\u003e\u003e\n\u003e\u003e - Jameson\n\u003e\u003e\n\u003e\u003e On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e Actually this does nothing to provide justification for this\n\u003e\u003e consensus rule change. It is just an attempt to deflect criticism\n\u003e\u003e from the fact that it is such a change.\n\u003e\u003e\n\u003e\u003e e\n\u003e\u003e\n\u003e\u003e \u003e On Nov 15, 2016, at 9:45 AM, Btc Drak \u003cbtcdrak at gmail.com\n\u003e\u003e \u003cmailto:btcdrak at gmail.com\u003e\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e I think this is already covered in the BIP text:-\n\u003e\u003e \u003e\n\u003e\u003e \u003e \"As of November 2016, the most recent of these changes (BIP 65,\n\u003e\u003e \u003e enforced since December 2015) has nearly 50,000 blocks built on\n\u003e\u003e top of\n\u003e\u003e \u003e it. The occurrence of such a reorg that would cause the activating\n\u003e\u003e \u003e block to be disconnected would raise fundamental concerns about the\n\u003e\u003e \u003e security assumptions of Bitcoin, a far bigger issue than any\n\u003e\u003e \u003e non-backwards compatible change.\n\u003e\u003e \u003e\n\u003e\u003e \u003e So while this proposal could theoretically result in a consensus\n\u003e\u003e \u003e split, it is extremely unlikely, and in particular any such\n\u003e\u003e \u003e circumstances would be sufficiently damaging to the Bitcoin\n\u003e\u003e network to\n\u003e\u003e \u003e dwarf any concerns about the effects of this proposed change.\"\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev\n\u003e\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e \u003e\u003e NACK\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e Horrible precedent (hardcoding rule changes based on the\n\u003e\u003e assumption that\n\u003e\u003e \u003e\u003e large forks indicate a catastrophic failure), extremely poor\n\u003e\u003e process\n\u003e\u003e \u003e\u003e (already shipped, now the discussion), and not even a material\n\u003e\u003e performance\n\u003e\u003e \u003e\u003e optimization (the checks are avoidable once activated until a\n\u003e\u003e sufficiently\n\u003e\u003e \u003e\u003e deep reorg deactivates them).\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e e\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev\n\u003e\u003e \u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e Hi,\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e Recently Bitcoin Core merged a simplification to the consensus\n\u003e\u003e rules\n\u003e\u003e \u003e\u003e surrounding deployment of BIPs 34, 66, and 65\n\u003e\u003e \u003e\u003e (https://github.com/bitcoin/bitcoin/pull/8391\n\u003e\u003e \u003chttps://github.com/bitcoin/bitcoin/pull/8391\u003e), and though the\n\u003e\u003e change is a\n\u003e\u003e \u003e\u003e minor one, I thought it was worth documenting the rationale in\n\u003e\u003e a BIP for\n\u003e\u003e \u003e\u003e posterity.\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e Here's the abstract:\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated\n\u003e\u003e via miner\n\u003e\u003e \u003e\u003e signaling in block version numbers. Now that the chain has\n\u003e\u003e long since passed\n\u003e\u003e \u003e\u003e the blocks at which those consensus rules have triggered, we\n\u003e\u003e can (as a\n\u003e\u003e \u003e\u003e simplification and optimization) replace the trigger mechanism\n\u003e\u003e by caching\n\u003e\u003e \u003e\u003e the block heights at which those consensus rules became enforced.\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e The full draft can be found here:\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e\n\u003e\u003e https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki\n\u003e\u003e \u003chttps://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki\u003e\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e _______________________________________________\n\u003e\u003e \u003e\u003e bitcoin-dev mailing list\n\u003e\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e _______________________________________________\n\u003e\u003e \u003e\u003e bitcoin-dev mailing list\n\u003e\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e\u003e \u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161116/794ee05f/attachment.html\u003e",
"sig": "740548599836cdeaaa632cb27b6f07ed13864de768a74831240fcf264b36365af80b361f3fa19bde79cb3c891366ecde89b1b154c91d24206886204da806e8c0"
}