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 16EBF259 for ; Wed, 16 Nov 2016 23:48:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7923A133 for ; Wed, 16 Nov 2016 23:48:04 +0000 (UTC) Received: by mail-vk0-f43.google.com with SMTP id x186so128589597vkd.1 for ; Wed, 16 Nov 2016 15:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DWkpM18obvqgpd/vNXYp9Qy7wPnykugsdwstSTKTqgE=; b=IL31K9AYMveElxXmcNH1CIJM8oxrXRfwtj+a5T27AdvQ4uv0rlbvwNIGYpEYBDpgnb UhU5jTa7IumKTCZcm4uMFTxBnEU1uV6wcVPM3MHB90D3H0HYnJJXLAixcZ8w17sqYXKO F/W7X2v0keEFxKjO7yZrJ2Fr/vxSMNbUuB/VzI+3OFaMzMuFC0FLcxda6mvkwKH3fDj9 qnzk6msrGY3xGpQavlPdcWGuFcSASaJnQnqEDy3qmsTmlXhhP9c3GnZMHBapdniGIw2C ZUQOUVKkMl5+nmRX7C6Qyszq6qRJ9To6QksqsMhdwDyZaiAXU89WCpxxxwaFWkA3ySHe idHQ== 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=DWkpM18obvqgpd/vNXYp9Qy7wPnykugsdwstSTKTqgE=; b=Gf1SYUKfat7yEcKV0ONDhrzIdyH6t4zoCyZP1wXnSFpuUXic/r7/YmGJ8apm/0Uznn 2bc/Uf+em+LX8NgOXolK4CPcyu/ZvdQHJstm7QDCZEsCV+XjbrobzZMUVXKrgX4mcWeu mPs3i19dnvMyYOUHAnG4DTEQ73lY73QpGfuSkYIGn7+rmh+tgsrEZvYsaoukTqQqeOj1 /hhxEVogSiFZlGYhAaIItjRKpCfTI+DZDpjBlWsONX1Iq6Scqzcxct0ykP2TtvRhzqZY g/bEQ2QTBKqkSTE2MfHHaKMmfVF4LLF4E6i5z/vAeWy93WPDr4goZDEe+2eNM79Xj9SX m8GA== X-Gm-Message-State: AKaTC01PFedKAbqxw3r3BcEBLikLIDGJjksGoEELNWP4K+WzJakrMR1CP3+pAgKJ+Eq/P7B3uYj/gDG4qzdPbA== X-Received: by 10.31.94.84 with SMTP id s81mr62721vkb.167.1479340083548; Wed, 16 Nov 2016 15:48:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.41.15 with HTTP; Wed, 16 Nov 2016 15:48:02 -0800 (PST) In-Reply-To: References: <33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org> From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Thu, 17 Nov 2016 00:48:02 +0100 Message-ID: To: Eric Voskuil , Bitcoin Protocol Discussion Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no 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 23:48:05 -0000 On Wed, Nov 16, 2016 at 2:58 PM, Eric Voskuil via bitcoin-dev wrote: > This sort of statement represents one consequence of the aforementioned bad > precedent. > > Are checkpoints good now? Checkpoints are not necessary for consensus and work is being done to remove them completely from Bitcoin Core in particular. > Are hard forks okay now? I personally think uncontroversial hardforks are ok. > What is the maximum depth of a reorg allowed by this non-machine consensus? Good question, specially if we plan to do this with future buried deployments. What about 1 year reorg? > Shouldn't we just define a max depth so that all cruft deeper than that can > just be discarded on a regular basis? Not sure I understand this question. > Why are there activation heights defined by this hard fork if it's not > possible to reorg back to them? If this is a hardfork, it is one that will only be visible if/when there's a very deep reorg , one of the kind where we can practically consider Bitcoin done (and only if some nodes keep the ISM code). But I could accept that definition. Another way to see it (even though other said the optimization part was not important) as such an optimization and simplification. The way I see it, ISM and BIP9 are just coordination mechanisms for uncontroversial rule changes. Once the coordination happened and is long in the past, I really don't see the problem with replacing the mechanism with a simpler height. > 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). Mhmm, I disagree on the notion that any hardfork necessarily represents an altcoin. It is certainly an improvement in the sense that it simplifies implementations and optimizes validation. You may argue that you don't consider the improvement important though. These changes to Bitcoin Core could be rolled back (and obviously other implementations don't need to adopt them unless they want to benefit from the simplification/optimization or fear such a long reaorg), but I really hope we don't. Trying to understand you better... Accepting your definition of this as a hardfork, do you oppose to it simply because it is a hardfork, or because you consider this "hardfork" a bad idea for some reason I am missing?