MIME-Version: 1.0
In-Reply-To: <A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.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: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, 16 Nov 2016 17:50:53 -0800
Message-ID: <CAPg+sBiGwz23mm5fCKUrg7GpWwuJ=3Nf2DcN89KxG=g_Wz4vBw@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11478b7080403d0541756b64
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
Precedence: list

--001a11478b7080403d0541756b64
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 16, 2016 at 5:58 AM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This sort of statement represents one consequence of the aforementioned
> bad precedent.
>
> Are checkpoints good now?
>

So far in this discussion, and in a thread that has forked off, I think 3
cases of implementation aspects have been mentioned that under certain
circumstances result in the validity of chains changing:
* Buried softforks (by simplifying the activation rules for certain rules)
* Not verifying BIP30 after BIP34 is active (since only under a SHA256^2
collision a duplicate txid can occur)
* The existence (and/or removal) of checkpoints (in one form or another).

None of these will influence the accepted main chain, however. If they ever
do, Bitcoin has far worse things to worry about (years-deep reorgs, or
SHA256 collisions).

If you were trying to point out that buried softforks are similar to
checkpoints in this regard, I agree. So are checkpoints good now? I believe
we should get rid of checkpoints because they seem to be misunderstood as a
security feature rather than as an optimization. I don't think buried
softforks have that problem.

-- 
Pieter

--001a11478b7080403d0541756b64
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Nov 16, 2016 at 5:58 AM, Eric Voskuil via bitcoin-=
dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</sp=
an> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"auto"><div></div><div>This sort of stat=
ement represents one consequence of the aforementioned bad precedent.</div>=
<div><br></div><div>Are checkpoints good now?<br></div></div></blockquote><=
div><br></div><div>So far in this discussion, and in a thread that has fork=
ed off, I think 3 cases of implementation aspects have been mentioned that =
under certain circumstances result in the validity of chains changing:<br><=
/div><div>* Buried softforks (by simplifying the activation rules for certa=
in rules)<br></div><div>* Not verifying BIP30 after BIP34 is active (since =
only under a SHA256^2 collision a duplicate txid can occur)<br></div><div>*=
 The existence (and/or removal) of checkpoints (in one form or another).<br=
><br></div><div>None of these will influence the accepted main chain, howev=
er. If they ever do, Bitcoin has far worse things to worry about (years-dee=
p reorgs, or SHA256 collisions).<br><br></div><div>If you were trying to po=
int out that buried softforks are similar to checkpoints in this regard, I =
agree. So are checkpoints good now? I believe we should get rid of checkpoi=
nts because they seem to be misunderstood as a security feature rather than=
 as an optimization. I don&#39;t think buried softforks have that problem.<=
br><br>-- <br></div><div>Pieter<br><br></div></div></div></div>

--001a11478b7080403d0541756b64--