Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 582882C for ; Fri, 2 Jun 2017 12:29:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9F15E106 for ; Fri, 2 Jun 2017 12:29:40 +0000 (UTC) Received: by mail-ua0-f169.google.com with SMTP id j17so43856061uag.3 for ; Fri, 02 Jun 2017 05:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=s1AxI9Lz5WmjB2RGEUA2flr6W9QkvX9pt+ky9BVCLnE=; b=KABW5VGirZkWbQQQTIIICSr9udNX40IkiHqeFUzMGoc0myhQ7yOMZVUh8WOt7JckSG hLg/MbgMeIULGT+VAUXWGqQWcGjBL2NmQLL5Xljkd3AIAAou8jgYXnyXbkVgDRl4jGpB /lzDhD/iLk/qT66qMkpneXbg7nNLDk9PWS1xT/vBVj/irCtpPoOAmqB5Q+Kng6ZIyqI0 ajVo4yFkFcbsTOif3s9Mvxr+2iIIK4LGJq1VzlVLEKB5+UsRGsG8BUWi0x8k6HsGr69A vK4eMu3WghUl3DgqgoF9oPsFnZqGI1fRwGGMUb1yot0LIsaPAivA9LshmWQA9q4g23t3 j3qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=s1AxI9Lz5WmjB2RGEUA2flr6W9QkvX9pt+ky9BVCLnE=; b=Sv4dksZ+ttUFDRegdC1FUEfso1AQq7CmLQ/3x8tI+W0OC5S6FmScboY7FeABWoBp3t mUAid0oaDvDrLSHFDC8rrneAhSUfbnbHYmtrjUv2gG3Z0eVNo9jQgBw21QdMmlaGGg/N XczkBWiPiUx66IHjsgMhclexyKnbe7nwcXV/pg46K8gffwmMUMMLPTbsOaQ0eqKUnt5o oMRHkQKgdRWw4e8FJs8XUEojGyZHxXAaX8gLgmo4KjXWCykcmOlcYRrr6f/oXQQcKDJ+ wQ/w0IVa71Ioie36ZDQ54p1wt3M9+8B4iyUqY2L14DvjLw3/2r5ICMoFNIvrCSlA0kDN 8+bQ== X-Gm-Message-State: AODbwcAtmnZUFOVbER+MKXf/j8X/cvOHinYYeeu6DkhRJQfhbjFXgo2S dCTHThCV3zlB75uZ1gFQNPq8wPqw8w== X-Received: by 10.176.90.140 with SMTP id w12mr3743731uae.53.1496406579726; Fri, 02 Jun 2017 05:29:39 -0700 (PDT) MIME-Version: 1.0 Sender: rebroad@gmail.com Received: by 10.176.23.35 with HTTP; Fri, 2 Jun 2017 05:29:19 -0700 (PDT) In-Reply-To: References: From: R E Broadley Date: Fri, 2 Jun 2017 14:29:19 +0200 X-Google-Sender-Auth: EOdS4P37IPze_Q8w67iVLZTfzzY Message-ID: To: Sergio Demian Lerner , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="94eb2c13a5f09fd5230550f94e05" 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 X-Mailman-Approved-At: Fri, 02 Jun 2017 13:33:14 +0000 Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments 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: Fri, 02 Jun 2017 12:29:41 -0000 --94eb2c13a5f09fd5230550f94e05 Content-Type: text/plain; charset="UTF-8" Miner signalling is not enough to avoid two forks - as has been proven in the past (e.g. when miners signaled they were fully validating blocks when there we in fact only validating headers). To really protect against two forks happening, the code needs to detect this happening (i.e. monitor the other fork) and if it's clear that the signalling was dishonest, then it needs to abort, IMHO. On Thu, Apr 6, 2017 at 10:42 PM, Sergio Demian Lerner via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The 95% miner signaling is important to prevent two Bitcoin forks, such as > what happened with Ethereum HF and Ethereum Classic. > > Bitcoin has a very slow difficulty re-targeting algorithm. A fork that has > just 95% miner support will initially (for 2016 blocks) be 5% slower (an > average block every 10 minutes and 30 seconds). The transaction capacity of > the new Bitcoin protocol is reduced only 5%. > However the chain with 5% if the hashing power not only has a 20x capacity > reduction, but confirms transactions in 20x more time. So the mempool will > grow 400 times. It must be noted that fees increased 10x from the moment > blocks were half full, to the moment blocks became saturated. I'm sure no > Bitcoin (pre-fork) user will be willing to pay 100x times the transaction > fees to use such a slow and insecure network. > > So a 6-block confirmation will take 20 hours in the original chain and the > original chain will be in this almost useless slow state for an average of > 2016 blocks, or 280 days. > If the original blockchain hard-forks to re-adjust the difficulty, then it > will just represent an alt-coin having 5% of Bitcoin community, and it > can't affect Bitcoin (the segwit2mb fork). > > > On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak wrote: > >> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> The hard-fork is conditional to 95% of the hashing power has approved >>> the segwit2mb soft-fork and the segwit soft-fork has been activated (which >>> should occur 2016 blocks after its lock-in time) >>> >> >> Miners signalling they have upgraded by flipping a bit in the nVersion >> field has little relevance in a hard fork. If 100% of the hash power >> indicates they are running this proposal, but the nodes don't upgrade, what >> will happen? >> >> For the record, I actually talk a lot about hard forks with various >> developers and am very interested in the research that Johnson in >> particular is pioneering. However, I have failed to understand your point >> about 95% miner signalling in relation to a hard fork, so I am eagerly >> awaiting your explanation. >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c13a5f09fd5230550f94e05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Miner signalling is not enough to avoid two forks - as has= been proven in the past (e.g. when miners signaled they were fully validat= ing blocks when there we in fact only validating headers). To really protec= t against two forks happening, the code needs to detect this happening (i.e= . monitor the other fork) and if it's clear that the signalling was dis= honest, then it needs to abort, IMHO.

<= div class=3D"gmail_quote">On Thu, Apr 6, 2017 at 10:42 PM, Sergio Demian Le= rner via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:
The 95% miner signaling is important to prevent two Bitcoin forks,= such as what happened with Ethereum HF and Ethereum Classic.
Bitcoin has a very slow difficulty re-targeting algorithm. A fork th= at has just 95% miner support will initially (for 2016 blocks) be 5% slower= (an average block every 10 minutes and 30 seconds). The transaction capaci= ty of the new Bitcoin protocol is reduced only 5%.=C2=A0
However the ch= ain with 5% if the hashing power not only has a 20x capacity reduction, but= confirms transactions in 20x more time. So the mempool will grow 400 times= . It must be noted that fees increased 10x from the moment blocks were half= full, to the moment blocks became saturated. I'm sure no Bitcoin (pre-= fork) user will be willing to pay 100x times the transaction fees to use su= ch a slow and insecure network.

So a 6-block confi= rmation will take 20 hours in the original chain and the original chain wil= l be in this almost useless slow state for an average of 2016 blocks, or 28= 0 days.=C2=A0
If the original blockchain hard-forks to re-adjust the di= fficulty, then it will just represent an alt-coin having 5% of Bitcoin comm= unity, and it can't affect Bitcoin (the segwit2mb fork).

=

On Mon, Apr 3, 2017 at 11:40 AM, B= tc Drak <btcdrak@gmail.com> wrote:



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--94eb2c13a5f09fd5230550f94e05--