Thomas Kerin [ARCHIVE] on Nostr: 📅 Original date posted:2016-11-16 📝 Original message:BIP30 actually was given ...
📅 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>;
📝 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>;