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 6E25BAB6 for ; Thu, 17 Nov 2016 01:50:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F27571AD for ; Thu, 17 Nov 2016 01:50:54 +0000 (UTC) Received: by mail-vk0-f47.google.com with SMTP id x186so130414406vkd.1 for ; Wed, 16 Nov 2016 17:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZnMtF3wZmoSOMWNHkDaALlBsxOkcZyMiDDm++NDI3Dg=; b=orqx0Cji6LD/ZWpgc6Xs0zubkTr/EektsNofENGFGXLLeBUl3adiJ6tkLesuu8femi uNmDPPvJ5t8rjArZMnQfz6s5/IX8OyKmIGlOLBQ2K24ylCrLfBWfpM8gvekVW2hLZYZU yNYV54ccnwI4Hl2Nd0E9GhQqxFwWqL9N3VcUbXeO0okGOnIZJPZhOYFLSFNbUqgGfBfl GxkBk2IJWDQN1mmF9acnNjC0v4x034Rrqv5EzCnS97xOMAtq/yaPhFvkE3pnSGv/KVeD dEcdglR1yny/5ZrfUPw4Yz6/7AMK6vSLV7zwY97TCGR2N7PPfIG1tYJFZ1hviqxNpgXI 7GUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZnMtF3wZmoSOMWNHkDaALlBsxOkcZyMiDDm++NDI3Dg=; b=kFsMUzz9C1XvavdMjYhCZS1KAvREynSlfjzbv3jiIMjwIMdu0NupXdTNFnzuDGMvM2 GJwgN9SdH02EkBLe3y8nNWoZbehOz2hefxdtfSWWHlcMyUhk9dQjDm/Z18vtalREv0GD HiSgMdFmCicS6cNn05O1FXNu6ITeRz+r1eAoK/4a1QYpIaph+nazF9u18xa5wFD0/PC4 XkGR8zjdS1ieWm3Aqx1ssjUs490yvfwrZiHiAc2sfvMTAJTL4rjt7Pc/ukY+4JzshN5G qrlzeWkyUtlzhjMrDIGfLfyQsZcJLAdJLVyolLcsgwTRB6mSxHIQC8CbKIWcij160ceT xStQ== X-Gm-Message-State: AKaTC02L+17nKBNFeFHWWnKzhyX9qp8W35sWm2Hl4MoqErkEjUNb6P7je/90gu4Qgk64cxxle8z7ywBlB/sDgw== X-Received: by 10.31.108.144 with SMTP id j16mr212222vki.93.1479347454097; Wed, 16 Nov 2016 17:50:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.115.201 with HTTP; Wed, 16 Nov 2016 17:50:53 -0800 (PST) In-Reply-To: References: <33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org> From: Pieter Wuille Date: Wed, 16 Nov 2016 17:50:53 -0800 Message-ID: To: Eric Voskuil , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a11478b7080403d0541756b64 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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: Thu, 17 Nov 2016 01:50:55 -0000 --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
On Wed, Nov 16, 2016 at 5:58 AM, Eric Voskuil via bitcoin-= dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
This sort of stat= ement represents one consequence of the aforementioned bad precedent.
=

Are checkpoints good now?
<= 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:
<= /div>
* Buried softforks (by simplifying the activation rules for certa= in 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, howev= er. If they ever do, Bitcoin has far worse things to worry about (years-dee= p reorgs, or SHA256 collisions).

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't think buried softforks have that problem.<= br>
--
Pieter

--001a11478b7080403d0541756b64--