<div dir="ltr">On Wed, Nov 16, 2016 at 5:58 AM, Eric Voskuil via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>This sort of statement 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 forked 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 certain 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, however. If they ever do, Bitcoin has far worse things to worry about (years-deep reorgs, or SHA256 collisions).<br><br></div><div>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.<br><br>-- <br></div><div>Pieter<br><br></div></div></div></div>