Return-Path: <me@thomaskerin.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5E6F3B55
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
<CADJgMzunxU2-7Z_ZPafNY4BPRu0x9oeh6v2dg0nUYqxJbXeGYA@mail.gmail.com>
<33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org>
<CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
<A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
From: Thomas Kerin <me@thomaskerin.io>
Message-ID: <e86b5b85-591d-5342-6a75-3ebd501f1789@thomaskerin.io>
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: <A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <jameson.lopp@gmail.com
> <mailto: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
>> <mailto: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
>> <mailto: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 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
>> > <bitcoin-dev@lists.linuxfoundation.org
>> <mailto: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
>> <mailto: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
>> <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
>> <https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buri=
ed-deployments.mediawiki>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@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@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@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@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------AC73D1ED2AFEEA48DAF61F37
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
BIP30 actually was given similar treatment after a reasonable amount
of time had passed. <br>
<a class="moz-txt-link-freetext" href="https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392">https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392</a><br>
<br>
You are also missing BIP50: 'March 2013 Chain For Post-Mortem',
which neither benefited nor improved bitcoin, but did document an
event for posterity. <br>
<br>
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. <br>
<br>
<div class="moz-cite-prefix">On 11/16/2016 01:58 PM, Eric Voskuil
via bitcoin-dev wrote:<br>
</div>
<blockquote
cite="mid:A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<div>This sort of statement represents one consequence of the
aforementioned bad precedent.</div>
<div><br>
</div>
<div>Are checkpoints good now? Are hard forks okay now?</div>
<div><br>
</div>
<div>What is the maximum depth of a reorg allowed by this
non-machine consensus?</div>
<div><br>
</div>
<div>Shouldn't we just define a max depth so that all cruft deeper
than that can just be discarded on a regular basis?</div>
<div><br>
</div>
<div>Why are there activation heights defined by this hard fork if
it's not possible to reorg back to them?</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>e</div>
<div><br>
On Nov 16, 2016, at 5:29 AM, Jameson Lopp <<a
moz-do-not-send="true" href="mailto:jameson.lopp@gmail.com">jameson.lopp@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>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 <span
class="gmail-blob-code-inner"><span
class="gmail-pl-c1">227931,</span></span> BIP65
activated at block <span class="gmail-blob-code-inner"><span
class="gmail-pl-c1">388381, and BIP66 activated at
block </span></span><span
class="gmail-blob-code-inner"><span
class="gmail-pl-c1">363725? Somehow I doubt it.<br>
<br>
</span></span></div>
<span class="gmail-blob-code-inner"><span
class="gmail-pl-c1">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.<br>
<br>
</span></span></div>
<span class="gmail-blob-code-inner"><span
class="gmail-pl-c1">- Jameson<br>
</span></span></div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Nov 15, 2016 at 5:42 PM,
Eric Voskuil via bitcoin-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
e<br>
<div class="HOEnZb">
<div class="h5"><br>
> On Nov 15, 2016, at 9:45 AM, Btc Drak <<a
moz-do-not-send="true"
href="mailto:btcdrak@gmail.com">btcdrak@gmail.com</a>>
wrote:<br>
><br>
> I think this is already covered in the BIP
text:-<br>
><br>
> "As of November 2016, the most recent of these
changes (BIP 65,<br>
> enforced since December 2015) has nearly 50,000
blocks built on top of<br>
> it. The occurrence of such a reorg that would
cause the activating<br>
> block to be disconnected would raise
fundamental concerns about the<br>
> security assumptions of Bitcoin, a far bigger
issue than any<br>
> non-backwards compatible change.<br>
><br>
> So while this proposal could theoretically
result in a consensus<br>
> split, it is extremely unlikely, and in
particular any such<br>
> circumstances would be sufficiently damaging to
the Bitcoin network to<br>
> dwarf any concerns about the effects of this
proposed change."<br>
><br>
><br>
> On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil
via bitcoin-dev<br>
> <<a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>>
wrote:<br>
>> NACK<br>
>><br>
>> Horrible precedent (hardcoding rule changes
based on the assumption that<br>
>> large forks indicate a catastrophic
failure), extremely poor process<br>
>> (already shipped, now the discussion), and
not even a material performance<br>
>> optimization (the checks are avoidable once
activated until a sufficiently<br>
>> deep reorg deactivates them).<br>
>><br>
>> e<br>
>><br>
>> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar
via bitcoin-dev<br>
>> <<a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>>
wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Recently Bitcoin Core merged a
simplification to the consensus rules<br>
>> surrounding deployment of BIPs 34, 66, and
65<br>
>> (<a moz-do-not-send="true"
href="https://github.com/bitcoin/bitcoin/pull/8391"
rel="noreferrer" target="_blank">https://github.com/bitcoin/<wbr>bitcoin/pull/8391</a>),
and though the change is a<br>
>> minor one, I thought it was worth
documenting the rationale in a BIP for<br>
>> posterity.<br>
>><br>
>> Here's the abstract:<br>
>><br>
>> Prior soft forks (BIP 34, BIP 65, and BIP
66) were activated via miner<br>
>> signaling in block version numbers. Now
that the chain has long since passed<br>
>> the blocks at which those consensus rules
have triggered, we can (as a<br>
>> simplification and optimization) replace
the trigger mechanism by caching<br>
>> the block heights at which those consensus
rules became enforced.<br>
>><br>
>> The full draft can be found here:<br>
>><br>
>> <a moz-do-not-send="true"
href="https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki"
rel="noreferrer" target="_blank">https://github.com/sdaftuar/<wbr>bips/blob/buried-deployments/<wbr>bip-buried-deployments.<wbr>mediawiki</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> bitcoin-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
>> <a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> bitcoin-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
>> <a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
>><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------AC73D1ED2AFEEA48DAF61F37--