Jameson Lopp [ARCHIVE] on Nostr: 📅 Original date posted:2016-11-16 📝 Original message:Since "buried deployments" ...
📅 Original date posted:2016-11-16
📝 Original message: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> 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> 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> 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> 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), 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
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> 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
> >>
> _______________________________________________
> 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/fbdc0efa/attachment.html>;
📝 Original message: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> 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> 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> 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> 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), 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
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> 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
> >>
> _______________________________________________
> 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/fbdc0efa/attachment.html>;