From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5E6F3B55 for ; Wed, 16 Nov 2016 14:27:54 +0000 (UTC) X-Greylist: delayed 00:08:50 by SQLgrey-1.7.6 Received: from thomaskerin.io (static.204.212.9.5.clients.your-server.de [5.9.212.204]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8535D310 for ; Wed, 16 Nov 2016 14:27:52 +0000 (UTC) Received: from [10.137.3.15] (chomsky.torservers.net [77.247.181.162]) by thomaskerin.io (Postfix) with ESMTPSA id 2536111981094; Wed, 16 Nov 2016 14:19:00 +0000 (UTC) To: Eric Voskuil , Bitcoin Protocol Discussion References: <33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org> From: Thomas Kerin Message-ID: Date: Wed, 16 Nov 2016 14:18:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AC73D1ED2AFEEA48DAF61F37" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 14:27:54 -0000 This is a multi-part message in MIME format. --------------AC73D1ED2AFEEA48DAF61F37 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 > 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 >> > > 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 > > 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 activati= ng >> > 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 >> > > > 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 >> >> > > 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 enforce= d. >> >> >> >> The full draft can be found here: >> >> >> >> >> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-burie= d-deployments.mediawiki >> >> >> >> >> _______________________________________________ >> >> bitcoin-dev mailing list >> >> bitcoin-dev@lists.linuxfoundation.org >> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> >> >> >> _______________________________________________ >> >> bitcoin-dev mailing list >> >> bitcoin-dev@lists.linuxfoundation.org >> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------AC73D1ED2AFEEA48DAF61F37 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 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@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@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@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@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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------AC73D1ED2AFEEA48DAF61F37--