path: root/1b/c64aaef8dcdbdff45950f5f60e1d680fb11b72

Return-Path: <rebroad@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 582882C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  2 Jun 2017 12:29:40 +0000 (UTC)
Received: by mail-ua0-f169.google.com with SMTP id j17so43856061uag.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAKzdR-qYjK0WHL51x4wJGpBuqjUu-Q8nBEPcLfj_qao=b-ZzaA@mail.gmail.com>
References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com>
	<CADJgMztpmcC_rv_oKYn_jRhLzx2FbtxgPUshcPDJpQVZYBcJzw@mail.gmail.com>
	<CAKzdR-qYjK0WHL51x4wJGpBuqjUu-Q8nBEPcLfj_qao=b-ZzaA@mail.gmail.com>
From: R E Broadley <rebroad+linuxfoundation.org@gmail.com>
Date: Fri, 2 Jun 2017 14:29:19 +0200
X-Google-Sender-Auth: EOdS4P37IPze_Q8w67iVLZTfzzY
Message-ID: <CAFBxzAD4C_0DwzRw4M=e2bASPPT-wgD7jM=LVpnMzM3Ki+j0NQ@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <btcdrak@gmail.com> 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

<div dir=3D"ltr">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&#39;s clear that the signalling was dis=
honest, then it needs to abort, IMHO.</div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Thu, Apr 6, 2017 at 10:42 PM, Sergio Demian Le=
rner via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>The 95% miner signaling is important to prevent two Bitcoin forks,=
 such as what happened with Ethereum HF and Ethereum Classic.</div><div><br=
></div>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<div>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&#39;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.</div><div><br></div><div>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<div>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&#39;t affect Bitcoin (the segwit2mb fork).</div><div><br>=
</div></div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Mon, Apr 3, 2017 at 11:40 AM, B=
tc Drak <span dir=3D"ltr">&lt;<a href=3D"mailto:btcdrak@gmail.com" target=
=3D"_blank">btcdrak@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><span>On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bit=
coin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>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 sho=
uld occur 2016 blocks after its lock-in time)</div></div></blockquote><div>=
<br></div></span><div>Miners signalling they have upgraded by flipping a bi=
t 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&#39=
;t upgrade, what will happen?<br></div><div><br></div><div>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. Howeve=
r, I have failed to understand your point about 95% miner signalling in rel=
ation to a hard fork, so I am eagerly awaiting your explanation.</div></div=
></div></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--94eb2c13a5f09fd5230550f94e05--