Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0CF14720 for ; Thu, 6 Apr 2017 21:03:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7AA5A20F for ; Thu, 6 Apr 2017 21:03:53 +0000 (UTC) Received: by mail-qk0-f173.google.com with SMTP id h67so48537854qke.0 for ; Thu, 06 Apr 2017 14:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zt+5gSPkEP6X1ACrOQ+ISuO9Nzrd454oaua+1xZp9RU=; b=Uxg71KpAX3xqpmCJm4rPWlm2NLNuRItxWzW83pbpD0GbdtZtiM0kBKz1A8xItWkPAO OiKDMz9cdfqn25tTgpJfIgJwHSDODWKpkoJjQMU8rTofxUFS4IB/JBADJdzeMzGYXeLP wIdTU45kKHwnEgMeFTkSldqKtpFXbBhyAqkbJAxQ1h2q61Sce0DwRNFTCiYmA6vpQN56 gPEUyHZ+fLYr939gvCaaL5VvL6IxBAPbv34792xLt11vluLiPXi9o3qn1HPc4AcYkD0s cszOGJQo61D3xQPSiYoxr9cXFMbr4J2FET6FT5lxjwb1HajSRrjNkAiDx5Gy1lYHzNWo /CjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Zt+5gSPkEP6X1ACrOQ+ISuO9Nzrd454oaua+1xZp9RU=; b=j/vvBMSpeM7hPzwh5Mol0d51PHht+z19inKHQ3VERxZ1Z7LgRMuBFlkZ33XhSmmq3o NKP4eukaX2o5dIbry4wxSJ8vKw8V9LXrZTuszwpt9jMkAdff4hKyOTXd2yJeyadGgusL wrrYn45tUKHFpzX6zUEJ6c7hf0FbR+adCtYc9RHft3MfBPw/oUf0IPp9cfMXW3h2NNDx 4Rr+yiOMl58XhsTI9pZrCw5nBn4MW9MR0ll6g99YD2wpmU8euMyRMnN307NfhanvMkH1 1M8Am9S+P878jbhpfWglljYxMYZT2CxwaqoMH7f/2QOwJp0fiT479Cb+hL3q2dPp0doT YTWQ== X-Gm-Message-State: AFeK/H0wFjt6Vx+VZm0ga1kz3SOVyRbNXBSeFbnE0i5NJkWRexRsButzAByZSlOAXexOxAb06Ypwt0P/5pEOXA== X-Received: by 10.55.8.5 with SMTP id 5mr25831338qki.265.1491512632758; Thu, 06 Apr 2017 14:03:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.170.220 with HTTP; Thu, 6 Apr 2017 14:03:12 -0700 (PDT) In-Reply-To: References: From: Sergio Demian Lerner Date: Thu, 6 Apr 2017 18:03:12 -0300 Message-ID: To: Btc Drak Content-Type: multipart/alternative; boundary=001a11487798a77245054c85d8fa X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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 Cc: Bitcoin Protocol Discussion 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: Thu, 06 Apr 2017 21:03:54 -0000 --001a11487798a77245054c85d8fa Content-Type: text/plain; charset=UTF-8 Ups. My mistake: the mempool will not grow 400 times, the is no square there. I will initially grow 20 times. Multiplied by the number of times a transaction may need to be replaced with one with higher fees. Maybe 50 times, but not 400. On Thu, Apr 6, 2017 at 5:42 PM, Sergio Demian Lerner < sergio.d.lerner@gmail.com> 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. >> > > --001a11487798a77245054c85d8fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ups. My mistake: =C2=A0the mempool will not grow 400 times= , the is no square there.
I will initially grow 20 times. Multiplied by = the number of times a transaction may need to be replaced with one with hig= her fees. Maybe 50 times, but not 400.


<= div class=3D"gmail_extra">
On Thu, Apr 6, 201= 7 at 5:42 PM, Sergio Demian Lerner <sergio.d.lerner@gmail.com&= gt; wrote:
T= he 95% miner signaling is important to prevent two Bitcoin forks, such as w= hat happened with Ethereum HF and Ethereum Classic.

Bit= coin has a very slow difficulty re-targeting algorithm. A fork that has jus= t 95% miner support will initially (for 2016 blocks) be 5% slower (an avera= ge block every 10 minutes and 30 seconds). The transaction capacity of the = new Bitcoin protocol is reduced only 5%.=C2=A0
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 wi= ll take 20 hours in the original chain and the original chain will be in th= is almost useless slow state for an average of 2016 blocks, or 280 days.=C2= =A0
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 <= btcdrak@gmail.com> wrote:
<= div dir=3D"ltr">
On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
The hard-f= ork is conditional to 95% of the hashing power has approved the segwit2mb s= oft-fork and the segwit soft-fork has been activated (which should occur 20= 16 blocks after its lock-in time)

Miners signalling they have upgraded by flipping a bit in the nVe= rsion 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 t= alk a lot about hard forks with various developers and am very interested i= n the research that Johnson in particular is pioneering. However, I have fa= iled to understand your point about 95% miner signalling in relation to a h= ard fork, so I am eagerly awaiting your explanation.


--001a11487798a77245054c85d8fa--