path: root/1f/79b8f7c8b5ad0f89e794962d881463e6e565b4

Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6CDD4EA0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Feb 2016 10:58:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com
	[209.85.223.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7352A16C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Feb 2016 10:58:28 +0000 (UTC)
Received: by mail-io0-f172.google.com with SMTP id 9so31538683iom.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Feb 2016 02:58:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
	:content-type; bh=iHz6Wx5udNdRrPm2Udmd4fkF5Q/1Wp2Pp/jvFPRwCSk=;
	b=JnJDCBijy+JbW4DgbCh/1cmfq+jzgGiye7XOc5H0l+ltibYH7E0TToxlXiHw9oOWf6
	zWMZwalfqeqCOCNdwcLwuFB8x47foPhL3aLD+m8tXoEMFHClq7ouQn1/P7sEPAG8Vxlt
	Cqh4sMACFdtVj4PwWl5g1RjQkPZ4lAdPaWsp26DaHuWS+a9iqPXeb4wLeCf/+iiL0DRn
	WlaQi8dcfctRyCwxfj5SkHFMwk++IjdJW7xD6Zi1bVVuXhAe0Ar2U4EXH2AgSf4xxGl2
	/B9PpRo+Elf9VkPozYhdsy/9ga3uZ+1ec32miJrL1f3rw77mjWH5wNnLK58K8i1irx2n
	GJtQ==
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:date
	:message-id:subject:from:cc:content-type;
	bh=iHz6Wx5udNdRrPm2Udmd4fkF5Q/1Wp2Pp/jvFPRwCSk=;
	b=PvYklOav+PIL8XtCsXM6amywvrMhe+Xl+yS+9gDClx9JIh9Z4OqNrlqY5u0D0+mHXJ
	CHp+GbDPKV+XoXj5ZrQJ2CESk07RbLcIp4KZ/dHLPcZ3XIueQc8m0R9R2pMFs0HNtvxg
	dtRvAP2s4jhMSJ4H6Pw3nekjBhirfW81Rju9GiWJrm8LIplJp5GqxQJiOEhj3Ej+GfUX
	Ryi6jiqZ2BL0TfBO3Evt1vJAAvmcNEUe4n4NDllbXPAsBdtIuPqSAN/IWroA4uq+If03
	sGMssuxzLqWS6Qjve/Vq7oROp9FU/kAlkl1XYB01fu9dWPGtwqzNm7SfnCHpNZ9xXdvV
	QSKw==
X-Gm-Message-State: AG10YOQqKncYqiBrIRo+F+N2PmBQ5YrJrJl2ZlP5CZnpZ9cWTrhg5bkIsasGBfRAkXcN6FOtGhtSmLkhgwv6vg==
MIME-Version: 1.0
X-Received: by 10.50.43.136 with SMTP id w8mr15943600igl.26.1456311507343;
	Wed, 24 Feb 2016 02:58:27 -0800 (PST)
Received: by 10.79.128.149 with HTTP; Wed, 24 Feb 2016 02:58:27 -0800 (PST)
In-Reply-To: <CADvTj4ovkoQPYWMs7j6tCqh2205OUm-xXY=fx11FQBjOkTeMjA@mail.gmail.com>
References: <CADvTj4ovkoQPYWMs7j6tCqh2205OUm-xXY=fx11FQBjOkTeMjA@mail.gmail.com>
Date: Wed, 24 Feb 2016 10:58:27 +0000
Message-ID: <CAE-z3OWUjXmm3t0XJfM9uEv5AKakCAT0nq1=8gXJAxXhW0DPPg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e011602a813e31d052c81f2a1
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
	RCVD_IN_DNSWL_LOW 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] Multi-Stage Merge-Mine Headers Hard-Fork BIP
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 24 Feb 2016 10:58:29 -0000

--089e011602a813e31d052c81f2a1
Content-Type: text/plain; charset=UTF-8

You need more detail for it to be a BIP.

New Header

new_header.prev = hash of previous header's bitcoin header
new_header.small_nonce = 4 byte nonce
new_header.big_nonce = 8 byte nonce

new_header.... (Can contain any new fields desired)

Fake Block

block.version = 4
block.prev = new_header.prev
block.merkle = calculate_merkle(coinbase)
block.timestamp = block.getPreviousBlock().median_time_past + 1
block.bits = calculate_bits()
block.nonce = new_header.small_nonce
block.tx_count = 1

Coinbase

coinbase.version = 1
coinbase.tx_in_count = 0
coinbase.tx_out_count = 1
coinbase.tx_out[0].value = 0
coinbase.tx_out[0].pk_script = "OP_RETURN"

This is a "nuclear option" attack that knocks out the main chain.  The
median time past will increase very slowly.  It only needs to increase by 1
every 6th blocks.  That gives an increase of 336 seconds for every
difficulty update.  This will cap the update rate, so give an increase of
4X every doubling.

The new headers will end up not meeting the difficulty, so they will
presumably just repeat the last header?

If the bitcoin chain stays at constant difficulty, then each quadrupling
will take more time.

After 2 weeks: 4XDiff   (2 weeks per diff period)
After 10 weeks: 16XDiff (8 weeks per diff period)
After 42 weeks: 256XDiff (32 weeks per diff period)


On Wed, Feb 24, 2016 at 5:52 AM, James Hilliard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> https://github.com/bitcoin/bips/pull/340
>
> BIP: ?
> Title: 2016 Multi-Stage Merge-Mine Headers Hard-Fork
> Author: James Hilliard <james.hilliard1@gmail.com>
> Status: Draft
> Type: Standards Track
> Created: 2016-02-23
>
> ==Abstract==
>
> Use a staged hard fork to implement a headers format change that is
> merge mine incompatible along with a timewarp to kill the previous
> chain.
>
> ==Specification==
>
> We use a block version flag to activate this fork when 3900 out of the
> previous 4032 blocks have this the version flag set. This flag locks
> in both of the below stages at the same time.
>
> Merge Mine Stage: The initial hard fork is implemented using a merge
> mine which requires that the original pre-fork chain be mined with a
> generation transaction that creates no new coins in addition to not
> containing any transactions. Additionally we have a consensus rule
> that requires that ntime be manipulated on the original chain to
> artificially increase difficulty and hold back the original chain so
> that all non-upgraded clients can never catch up with current time.
> The artificial ntime is implemented as a consensus rule for blocks in
> the new chain.
>
> Headers Change Stage: This is the final stage of the hard fork where
> the header format is made incompatible with merge mining, this is
> activated ~50,000 blocks after the Merge Mine Stage and only at the
> start of the 2016 block difficulty boundary.
>
> ==Motivation==
>
> There are serious issues with pooled mining such as block withhold
> attacks that can only be fixed by making major changes to the headers
> format.
>
> There are a number of other desirable header format changes that can
> only be made in a non-merge mine compatible way.
>
> There is a high risk of there being two viable chains if we don't have
> a way to permanently disable the original chain.
>
> ==Rationale==
>
> Our solution is to use a two stage hard fork with a single lock in period.
>
> The first stage is designed to kill off the previous chain by holding
> back ntime to artificially increase network difficulty on the original
> chain to the point where it would be extremely difficult to mine the
> 2016 blocks needed to trigger a difficulty adjustment. This also makes
> it obvious to unupgraded clients that they are not syncing properly
> and need to upgrade.
>
> By locking in both stages at the same time we ensure that any clients
> merge mining are also locked in for the headers change stage so that
> the original chain is dead by the time the headers change takes place.
>
> We timewarp over a year of merge mining to massively increase the
> difficulty on the original chain to the point that it would be
> incredibly expensive to reduce the difficulty enough that the chain
> would be able to get caught up to current time.
>
> ==Backward Compatibility==
>
> This hardfork will permanently disable all nodes, both full and light,
> which do not explicitly add support for it.
> However, their security will not be compromised due to the implementation.
> To migrate, all nodes must choose to upgrade, and miners must express
> supermajority support.
>
> ==Reference Implementation==
>
> TODO
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--089e011602a813e31d052c81f2a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>You need more detail for it to be a BIP.<br=
><br></div><div></div><div>New Header<br><br></div><div>new_header.prev =3D=
 hash of previous header&#39;s bitcoin header<br></div><div>new_header.smal=
l_nonce =3D 4 byte nonce<br></div><div>new_header.big_nonce =3D 8 byte nonc=
e<br><br>new_header.... (Can contain any new fields desired)<br></div><div>=
<br></div><div>Fake Block<br></div><div><br></div><div>block.version =3D 4<=
br></div><div>block.prev =3D new_header.prev<br></div><div>block.merkle =3D=
 calculate_merkle(coinbase)<br></div><div>block.timestamp =3D block.getPrev=
iousBlock().median_time_past + 1<br></div><div>block.bits =3D calculate_bit=
s()<br></div><div>block.nonce =3D new_header.small_nonce<br></div><div>bloc=
k.tx_count =3D 1<br></div><div><br></div><div>Coinbase<br></div><div><br></=
div><div>coinbase.version =3D 1<br></div><div>coinbase.tx_in_count =3D 0<br=
></div><div>coinbase.tx_out_count =3D 1<br></div><div>coinbase.tx_out[0].va=
lue =3D 0<br>coinbase.tx_out[0].pk_script =3D &quot;OP_RETURN&quot;<br></di=
v><div><br></div></div>This is a &quot;nuclear option&quot; attack that kno=
cks out the main chain.=C2=A0 The median time past will increase very slowl=
y.=C2=A0 It only needs to increase by 1 every 6th blocks.=C2=A0 That gives =
an increase of 336 seconds for every difficulty update.=C2=A0 This will cap=
 the update rate, so give an increase of 4X every doubling.<br><br></div><d=
iv>The new headers will end up not meeting the difficulty, so they will pre=
sumably just repeat the last header?<br></div><div><br></div><div>If the bi=
tcoin chain stays at constant difficulty, then each quadrupling will take m=
ore time.<br><br></div><div>After 2 weeks: 4XDiff=C2=A0=C2=A0 (2 weeks per =
diff period)<br></div><div>After 10 weeks: 16XDiff (8 weeks per diff period=
)<br></div><div>After 42 weeks: 256XDiff (32 weeks per diff period)<br><br>=
</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On We=
d, Feb 24, 2016 at 5:52 AM, James Hilliard via bitcoin-dev <span dir=3D"ltr=
">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><a href=3D"https://github.com/bitcoin/bips/pull/34=
0" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/pul=
l/340</a><br>
<br>
BIP: ?<br>
Title: 2016 Multi-Stage Merge-Mine Headers Hard-Fork<br>
Author: James Hilliard &lt;<a href=3D"mailto:james.hilliard1@gmail.com">jam=
es.hilliard1@gmail.com</a>&gt;<br>
Status: Draft<br>
Type: Standards Track<br>
Created: 2016-02-23<br>
<br>
=3D=3DAbstract=3D=3D<br>
<br>
Use a staged hard fork to implement a headers format change that is<br>
merge mine incompatible along with a timewarp to kill the previous<br>
chain.<br>
<br>
=3D=3DSpecification=3D=3D<br>
<br>
We use a block version flag to activate this fork when 3900 out of the<br>
previous 4032 blocks have this the version flag set. This flag locks<br>
in both of the below stages at the same time.<br>
<br>
Merge Mine Stage: The initial hard fork is implemented using a merge<br>
mine which requires that the original pre-fork chain be mined with a<br>
generation transaction that creates no new coins in addition to not<br>
containing any transactions. Additionally we have a consensus rule<br>
that requires that ntime be manipulated on the original chain to<br>
artificially increase difficulty and hold back the original chain so<br>
that all non-upgraded clients can never catch up with current time.<br>
The artificial ntime is implemented as a consensus rule for blocks in<br>
the new chain.<br>
<br>
Headers Change Stage: This is the final stage of the hard fork where<br>
the header format is made incompatible with merge mining, this is<br>
activated ~50,000 blocks after the Merge Mine Stage and only at the<br>
start of the 2016 block difficulty boundary.<br>
<br>
=3D=3DMotivation=3D=3D<br>
<br>
There are serious issues with pooled mining such as block withhold<br>
attacks that can only be fixed by making major changes to the headers<br>
format.<br>
<br>
There are a number of other desirable header format changes that can<br>
only be made in a non-merge mine compatible way.<br>
<br>
There is a high risk of there being two viable chains if we don&#39;t have<=
br>
a way to permanently disable the original chain.<br>
<br>
=3D=3DRationale=3D=3D<br>
<br>
Our solution is to use a two stage hard fork with a single lock in period.<=
br>
<br>
The first stage is designed to kill off the previous chain by holding<br>
back ntime to artificially increase network difficulty on the original<br>
chain to the point where it would be extremely difficult to mine the<br>
2016 blocks needed to trigger a difficulty adjustment. This also makes<br>
it obvious to unupgraded clients that they are not syncing properly<br>
and need to upgrade.<br>
<br>
By locking in both stages at the same time we ensure that any clients<br>
merge mining are also locked in for the headers change stage so that<br>
the original chain is dead by the time the headers change takes place.<br>
<br>
We timewarp over a year of merge mining to massively increase the<br>
difficulty on the original chain to the point that it would be<br>
incredibly expensive to reduce the difficulty enough that the chain<br>
would be able to get caught up to current time.<br>
<br>
=3D=3DBackward Compatibility=3D=3D<br>
<br>
This hardfork will permanently disable all nodes, both full and light,<br>
which do not explicitly add support for it.<br>
However, their security will not be compromised due to the implementation.<=
br>
To migrate, all nodes must choose to upgrade, and miners must express<br>
supermajority support.<br>
<br>
=3D=3DReference Implementation=3D=3D<br>
<br>
TODO<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>

--089e011602a813e31d052c81f2a1--