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 A823A10B6 for ; Wed, 21 Feb 2018 17:27:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f195.google.com (mail-pf0-f195.google.com [209.85.192.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C96CF1E1 for ; Wed, 21 Feb 2018 17:27:52 +0000 (UTC) Received: by mail-pf0-f195.google.com with SMTP id t15so922739pfh.9 for ; Wed, 21 Feb 2018 09:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=A44gjt3b+aYD1jg0judhRmF7m0IQubMBy3CFRxOX6Bk=; b=hjMX07mpClk+1nZ3kBg9NxVhq8Gj4Tp9zYMS7IoyF4zuvqFcxQJEDLCd2qX0uMx+Aa eyk5E52tymSnBG10chuLWYc9G169TuY/UCZPb0ZxY/b8Doft6g4rbmrdA05NT4JM5fnk By5YzsF9JQpYFCGYfid+NSzjC4lfCynDusJEG3X7QJebtw+8CQVBw90v6RjL+6I+YTBx 6OVF6foCKJzY3vLq5KZFq7l7AVxrr9DO4/mW5Y9jwBMeUTKy4jr3rLTbLr1Ym8I1JUb0 LCGxWe3OIw3QbPDxR6EQ4PxXoTmy6PsJNnwhrAz+dV3/0A7Wetn3beADX4pcA0x83qJi Wt6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=A44gjt3b+aYD1jg0judhRmF7m0IQubMBy3CFRxOX6Bk=; b=VprBxP4ptTTwKe+JM8evcD5NJeXGbB9s5VEI3i+azVJ6SOfPfat/kXfAtGjMPdNUJH Q1u3edkAsxMuzwQdNRVFDmlhYVmXhZOK2sNLMdQPL3WZagbhXvvrSijpb8u/T7+YOSKB xgox+vnaFBotRV0kkkKNLnjtna4IXAfZCV9dMOhX1J7YGBQMsrbxhfqyU1B9AvLQX1zh 3/zU1LF+JWEPvkIIUKMi6J/vLSianOeDAk8kxTHwUp+WeIUJnmuac+mbaC6HFnu3Bxb2 3YQLxUg0Hy0N9Hx7fYtzp1IyWLeWaAVZKcZKQxR1Zthi+JW4RMJa7nirWjmrq5OeL+if getw== X-Gm-Message-State: APf1xPDW1X4p5vqRbSIWNxg6RET0RdMcr5o9a04sytlwutmAGbGnAZ+r zQJZXx7adTRqf9MjdfMGjIzR293A X-Google-Smtp-Source: AH8x225SjnbyklhT3sceI0LSNz7JT6N6t2DjkVmxnv5cmwD2CKhlUaaOj8oti9fJmgI4yvHBWW57GA== X-Received: by 10.98.64.73 with SMTP id n70mr4065339pfa.142.1519234071975; Wed, 21 Feb 2018 09:27:51 -0800 (PST) Received: from ?IPv6:2601:600:a080:16bb:89c4:67fa:69d5:d805? ([2601:600:a080:16bb:89c4:67fa:69d5:d805]) by smtp.gmail.com with ESMTPSA id z17sm22915313pfh.183.2018.02.21.09.27.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 09:27:51 -0800 (PST) To: Marco Falke , Bitcoin Protocol Discussion References: <8fb2e424-268c-7433-5f6b-5fbab5c5cc5c@voskuil.org> From: Eric Voskuil Message-ID: <458f13b8-ab09-400f-b5cb-c6fa42726244@voskuil.org> Date: Wed, 21 Feb 2018 09:27:53 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TpUWnk2fUOcL6vipbq4pH1pm75iCXTPDo" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 X-Mailman-Approved-At: Thu, 22 Feb 2018 04:29:29 +0000 Subject: Re: [bitcoin-dev] Amend the BIP 123 process to include 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, 21 Feb 2018 17:27:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TpUWnk2fUOcL6vipbq4pH1pm75iCXTPDo Content-Type: multipart/mixed; boundary="hzsKqEaKJ23Kwf8nFoJxO9ubAYCJiKoJk"; protected-headers="v1" From: Eric Voskuil To: Marco Falke , Bitcoin Protocol Discussion Message-ID: <458f13b8-ab09-400f-b5cb-c6fa42726244@voskuil.org> Subject: Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments References: <8fb2e424-268c-7433-5f6b-5fbab5c5cc5c@voskuil.org> In-Reply-To: --hzsKqEaKJ23Kwf8nFoJxO9ubAYCJiKoJk Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 02/18/2018 10:57 AM, Marco Falke via bitcoin-dev wrote: >> They also do not require software coordination. Therefore, why should = there be >> BIPs at all? Seems to me that we should instead add these documents to= >> https://github.com/bitcoin-core/docs >=20 > Consensus is not trivial. I think documentation is important, even if > it seems simple to some. > Personally, I don't care too much where to place the documentation, > but the BIPs repo seems a good place, since it also hosts other > informational documents. >=20 > To prevent "two BIPs for every protocol change", related buried > deployments could be bundled. E.g. the ISM BIP 90 change. You seem to have missed the point. Either the "buried deployment" is a consensus rule, and requires a BIP, or it is not a consensus rule, and does not warrant a BIP. You are arguing that it is not a consensus rule, yet requires a BIP. You also strongly imply that it is a consensus rule ("consensus is important"= ). If it is a consensus rule it is either a hard fork (valid tx set expansion) or a soft fork (valid tx set contraction). You are attempting to create an independent category that violates this clear engineering definition. The category you desire is actually a subcategory of hard fork (employing an arbitrary threshold for likelihood of causing a chain split). > On Wed, Feb 14, 2018 at 6:57 PM, Eric Voskuil wrote:= >> On 02/14/2018 02:01 PM, Marco Falke via bitcoin-dev wrote: >>> I define a buried deployment as a consensus rule change that affects >>> validity of blocks that are buried by a sufficiently large number of >>> blocks in the current valid most-work chain, >> >> Sufficient for what, specifically? >=20 > Sufficiently large to prevent potential bike-shedding. The expected > number of blocks in two weeks could be considered a lower bound. Then > multiply that by 10 or 20. The arbitrary threshold. It seems it could be anything. Such a definition has no clear *engineering* usefulness. >>> but the current block (and all its parents) remain valid. >> >> Remain valid in the case where the depth assumption is "sufficient" to= >> ensure that a chain split is not possible? >> >> If this was true (which it is not), it would imply that there is no >> reason to validate any block deeper than the most recent 25,000. >> Presumably this means that people may continuously rely on some >> authority (like Bitcoin Core?) to determine the checkpoint for tip-25,= 000. >> > Note that a checkpoint *freezes* the chain completely at a given > height. Buried deployments are *not* checkpoints. You are arguing a point that I did not make. The issue is that you argue a "buried deployment" hard fork cannot create a chain split. This itself implies that the chain is "frozen" at the depth below which the chain cannot be split. In other words, by accepting your logic, we must conclude there is no reason whatsoever to validate the chain prior to that depth. This would lead to the conclusion that check-pointing the chain to that depth is always sufficient validation. > Also note that buried deployments only make sense after a protocol > upgrade has happened (i.e. a soft fork or hard fork). If a miner has > the resources to cause a chain split, they could trivially do that > even in the complete absence of buried deployments. Buried deployments > are *not* a solution to 50% attacks. Not sure why you are making this obvious but seemingly-irrelevant point. >>> BIP 123 suggests that BIPs in the consensus layer should be assigned = a >>> label "soft fork" or "hard fork". However, I think the differentiatio= n >>> into soft fork or hard fork should not be made for BIPs that document= >>> buried deployments. In contrast to soft forks and hard forks, buried >>> deployments do not require community and miner coordination for a saf= e >>> deployment. >> >> They can only avoid this requirement based on the assumption that the >> hard fork cannot result in a chain split. This is not the case. >> >>> For a chain fork to happen due to a buried deployment, a massive chai= n >>> reorganization must be produced off of a block in the very past. >> >> In other words a "buried deployment" is a hard fork that is not likely= >> to cause a chain split. This is a subjective subcategory of hard fork,= >> not an independent category - unless maybe you can show that there is >> the 25,000 blocks number is an objective threshold. >=20 > Please note that a buried deployment can very well be a soft fork. I > think this makes it even clearer, that such a label makes no sense for > buried deployments. No, it cannot. Removal of an activated soft fork (valid tx set contraction) is a hard fork (valid tx set expansion), and a new activation rule for an active soft fork creates a path to that removal. Given this error you may want to reconsider your proposal. >>> In the extremely unlikely event of such a large chain reorganization,= >>> Bitcoin's general security assumptions would be violated regardless o= f >>> the presence of a buried deployment. >> >> This is untrue. The "security assumptions" of Bitcoin do not preclude >> deep reorganizations. >> >> e --hzsKqEaKJ23Kwf8nFoJxO9ubAYCJiKoJk-- --TpUWnk2fUOcL6vipbq4pH1pm75iCXTPDo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJajawZAAoJEDzYwH8LXOFOY6MH/0Wi6O+l9+ddnc4HvQfE0+fV ynIZVTw1nPafWXavU2/1zgOaW7ySRd9a7Nb3dAVDXzinvI6jvecyN99SKWNPT7CE hJeLeSAFhNUf6NJ3XCxr0zBkJcpzYfSz8YHyJRsiiIoeMqrsvt+2R0qHHLnPj3D3 rkV7j4onnuyZX8X21issgiNXK5oqxofnjxTC/XK5oC0yfbEr72Lj48eGWFUXVC+e e7cxCZse1WvbvhAQBb4tENogkerIFjsiVxQ9hoJ5dmKhFA+++kZlNg/gNza0uRNp XTtudyV1RLNkLMNC5AtAjlj/HbWcbUzuvcln52mvdLQbFtZ7jC7fiDlA5VS9cxg= =HyhT -----END PGP SIGNATURE----- --TpUWnk2fUOcL6vipbq4pH1pm75iCXTPDo--