path: root/f8/e68fb653967d9511c7e9644eb37f1440de1bd7

Return-Path: <miron@hyper.to>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0A3C7C26
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  3 Nov 2017 01:02:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com
	[209.85.220.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED7634CE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  3 Nov 2017 01:02:36 +0000 (UTC)
Received: by mail-qk0-f172.google.com with SMTP id x82so1495370qkb.12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 02 Nov 2017 18:02:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=niftybox-net.20150623.gappssmtp.com; s=20150623;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=4RZ0oS7Wg4LwHD+L6veVxdAmOG4uPeZDaA1qMN7QAeQ=;
	b=1mxShVQ/f9eMphpsxfdpecBYdJE43BthyTo8uu9AGX0rg0+k+hYlIKwJaLZL4z3Pfc
	6VrjnP4ZFvsZ2QcGWdJjbQQOcToQ8iYMeZcisr2bCHJ7HtR7UYB69Bxc3lY95dCXIn6R
	vwyAPG5AkozxqYw7/hcAcrE6JDEW0FkLjGBi1NJsZ7o0VyeHRqXCLoznhd25CNKUgUeD
	PUt5v1y7+Ioy+ARfHYAPsEyVfOgP5jmc1sUJNb+k2vSzIsKNo5wynj9KQN49aM/QQ9J8
	C5GQq+6Wwa27fszeHf/HSi4z9emHzRzv0cn2huPNw4FcowsgrxdRRWtn26TtQjfvQNqp
	cmWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=4RZ0oS7Wg4LwHD+L6veVxdAmOG4uPeZDaA1qMN7QAeQ=;
	b=qY/RVvDvkMqlLuCDoPz5uzJBCmTj+JSlDEIe7roAlAPE1OOKJxTOoKPbWFeuIsZzdK
	+c6WUiGjgmOUwqT0i7zN6a0kgoUwS/NXJPozR1aJ6339SRzLKUvBnCDSyMjFlszqr98D
	ma364tIJlbavj5Raz+tpOXgwKNs/O2ivBuRSwGxB42x+uvvJxe2XpXeXf1znAfmuiCqm
	ZAyP8oqzD3K2MnUu1lHjUN1SglnEVMCEYZW19pHAqsqDyXjWdjL8AK90S/QRl0wQq8gK
	3VmPWODscZAO8CszdSF8xbb+/WDh5og0mq8M3D5fcTHTEBBJT2eICho7N5rD/rpfJk2w
	TfsA==
X-Gm-Message-State: AMCzsaVdVzEbF01tbOtvtkWFFOJ2xfEcAw9LHsOjDaR2yMkFaqPOUfXd
	QAAd6rLoVFSw43ptDN/ooVtUJErmB7HucVy0ybRZ8A==
X-Google-Smtp-Source: ABhQp+TLIdtaT5SohLYv3Qw4dBGN5uHtT8ORYnxIlcBk1xzlF+/l/yp+ynlNXE4lkCcZPrxSEFOPuaPcBY2kFw8N/PI=
X-Received: by 10.55.175.132 with SMTP id y126mr7737140qke.45.1509670955842;
	Thu, 02 Nov 2017 18:02:35 -0700 (PDT)
MIME-Version: 1.0
References: <CAB0O3SVjhG19R61B78hFCPwfwWemTXj=tOsvgAgoNbjFYXXAtg@mail.gmail.com>
	<D075DBB7-1C8A-4F83-9C0E-CC2321A8C5A7@taoeffect.com>
In-Reply-To: <D075DBB7-1C8A-4F83-9C0E-CC2321A8C5A7@taoeffect.com>
From: Devrandom <c1.bitcoin@niftybox.net>
Date: Fri, 03 Nov 2017 01:02:25 +0000
Message-ID: <CAB0O3SU56tGzKMZtfQWohi9vggij9U07uNJrvGQTSo7g4Mh4HQ@mail.gmail.com>
To: Tao Effect <contact@taoeffect.com>
Content-Type: multipart/alternative; boundary="94eb2c0629360d15e6055d09a96a"
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=disabled
	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, 03 Nov 2017 01:40:50 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Introducing a POW through a soft-fork
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, 03 Nov 2017 01:02:38 -0000

--94eb2c0629360d15e6055d09a96a
Content-Type: text/plain; charset="UTF-8"

I am also concerned.  However, this proposal allows two POWs to coexist and
allows for gradual transitions. This is hopefully a less disruptive
approach since it allows cooperative miners to migrate over time.  And of
course, as a soft-fork it keeps backwards compatibility with existing
software.

On Thu, Nov 2, 2017 at 4:55 PM Tao Effect <contact@taoeffect.com> wrote:

> Just going to throw in my support for a POW change, not any particular
> implementation, but the idea.
>
> Bitcoin is technically owned by China now. That's not acceptable.
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> Feedback is welcome on the draft below.  In particular, I want to see if
> there is interest in further development of the idea and also interested in
> any attack vectors or undesirable dynamics.
>
> (Formatted version available here:
> https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>
> # Soft-fork Introduction of a New POW
>
> ## Motivation:
>
> - Mitigate mining centralization pressures by introducing a POW that does
> not have economies of scale
> - Introduce an intermediary confirmation point, reducing the impact of
> mining power fluctuations
>
> Note however that choice of a suitable POW will require deep analysis.
> Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are
> not, unexpected/covert optimization.
>
> In particular, unexpected/covert optimizations, such as ASCIBOOST, present
> a potential centralizing and destabilizing force.
>
> ## Design
>
> ### Aux POW intermediate block
>
> Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
> alternates between the two POWs.
> Each aux-POW block points to the previous normal block and contains
> transactions just like a normal block.
> Each normal block points to the previous aux-POW block and must contain
> all transactions from the aux-POW block.
> Block space is not increased.
>
> The new intermediate block and the pointers are introduced via a soft-fork
> restriction.
>
> ### Reward for aux POW miners
>
> The reward for the aux POW smoothly increases from zero to a target value
> (e.g. 1/2 of the total reward) over time.
> The reward is transferred via a soft-fork restriction requiring a coinbase
> output to an address published in the
> aux-POW block.
>
> ### Aux POW difficulty adjustment
>
> Difficulty adjustments remain independent for the two POWs.
>
> The difficulty of the aux POW is adjusted based on the average time
> between normal block found
> to aux block found.
>
> Further details are dependent on the specific POW.
>
> ### Heaviest chain rule change
>
> This is a semi-hard change, because non-upgraded nodes can get on the
> wrong chain in case of attack.  However,
> it might be possible to construct an alert system that notifies
> non-upgraded nodes of an upcoming rule change.
> All blocks are still valid, so this is not a hardforking change.
>
> The heaviest chain definition changes from sum of `difficulty` to sum of:
>
>     mainDifficulty ^ x * auxDifficulty ^ y
>
> where we start at:
>
>     x = 1; y = 0
>
> and end at values of x and y that are related to the target relative
> rewards.  For example, if the target rewards
> are equally distributed, we will want ot end up at:
>
>     x = 1/2; y = 1/2
>
> so that both POWs have equal weight.  If the aux POW is to become
> dominant, x should end small relative to y.
>
>
> ## Questions and Answers
>
> - What should be the parameters if we want the aux POW to have equal
> weight? A: 1/2 of the reward should be transferred
> to aux miners and x = 1/2, y = 1/2.
>
> - What should be the parameters if we want to deprecate the main POW?  A:
> most of the reward should be transferred to
> aux miners and x = 0, y = 1.  The main difficulty will tend to zero, and
> aux miners will just trivially generate the
> main block immediately after finding an aux block, with identical content.
>
> - Wasted bandwidth to transfer transactions twice?  A: this can be
> optimized by skipping transactions already
> transferred.
>
> - Why would miners agree to soft-fork away some of their reward?  A: they
> would agree if they believe that
> the coins will increase in value due to improved security properties.
>
> ## Open Questions
>
> - After a block of one type is found, we can naively assume that POW will
> become idle while a block of the other type is being mined.  In practice,
> the spare capacity can be used to find alternative ("attacking") blocks or
> mine other coins.  Is that a problem?
> - Is selfish mining amplified by this scheme for miners that have both
> types of hardware?
>
> ## POW candidates
>
> - SHA256 (i.e. use same POW, but introduce an intermediate block for
> faster confirmation)
> - Proof of Space and Time (Bram Cohen)
> - Equihash
> - Ethash
>
> ## Next Steps
>
> - evaluate POW candidates
> - evaluate difficulty adjustment rules
> - simulate miner behavior to identify if there are incentives for
> detrimental behavior patterns (e.g. block withholding / selfish mining)
> - Protocol details
>
> ## Credits
>
> Bram Cohen came up with a similar idea back in March:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

--94eb2c0629360d15e6055d09a96a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am also concerned.=C2=A0 However, this proposal allows t=
wo POWs to coexist and allows for gradual transitions. This is hopefully a =
less disruptive approach since it allows cooperative miners to migrate over=
 time.=C2=A0 And of course, as a soft-fork it keeps backwards compatibility=
 with existing software.<br><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
>On Thu, Nov 2, 2017 at 4:55 PM Tao Effect &lt;<a href=3D"mailto:contact@ta=
oeffect.com">contact@taoeffect.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div style=3D"word-wrap:break-word">Just going to throw in m=
y support for a POW change, not any particular implementation, but the idea=
.<div><br></div><div>Bitcoin is technically owned by China now. That&#39;s =
not acceptable.</div><div><br></div><div>- Greg<br><div>
<span style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-s=
tyle:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;font-variant-ligatures:normal;font-variant-numeric:normal;=
font-variant-alternates:normal;font-variant-east-asian:normal;line-height:n=
ormal"><br class=3D"m_-9151628905807909183Apple-interchange-newline">--</sp=
an><br style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-=
style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:nor=
mal;text-align:start;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px;font-variant-ligatures:normal;font-variant-numeric:normal=
;font-variant-alternates:normal;font-variant-east-asian:normal;line-height:=
normal"><span style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:14p=
x;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spac=
ing:normal;text-align:start;text-indent:0px;text-transform:none;white-space=
:normal;word-spacing:0px;font-variant-ligatures:normal;font-variant-numeric=
:normal;font-variant-alternates:normal;font-variant-east-asian:normal;line-=
height:normal">Please do not email me anything that you are not comfortable=
 also sharing</span><span style=3D"color:rgb(0,0,0);font-family:Helvetica;f=
ont-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;font-variant-ligatures:normal;font-var=
iant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:=
normal;line-height:normal">=C2=A0with the NSA.</span>
</div>
<br><div><blockquote type=3D"cite"></blockquote></div></div></div><div styl=
e=3D"word-wrap:break-word"><div><div><blockquote type=3D"cite"><div>On Oct =
31, 2017, at 10:48 PM, Devrandom via bitcoin-dev &lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt; wrote:</div><br class=3D"m_-9151628905807909183Appl=
e-interchange-newline"></blockquote></div></div></div><div style=3D"word-wr=
ap:break-word"><div><div><blockquote type=3D"cite"><div><div dir=3D"ltr"><s=
pan style=3D"color:rgb(33,33,33);font-size:13px">Hi all,</span><div style=
=3D"color:rgb(33,33,33);font-size:13px"><br></div><div style=3D"color:rgb(3=
3,33,33);font-size:13px">Feedback is welcome on the draft below.=C2=A0 In p=
articular, I want to see if there is interest in further development of the=
 idea and also interested in any attack vectors or undesirable dynamics.</d=
iv><div style=3D"color:rgb(33,33,33);font-size:13px"><br></div><div style=
=3D"color:rgb(33,33,33);font-size:13px">(Formatted version available here:=
=C2=A0<a href=3D"https://github.com/devrandom/btc-papers/blob/master/aux-po=
w.md" target=3D"_blank">https://github.com/devrandom/btc-papers/blob/master=
/aux-pow.md</a> )</div><div style=3D"color:rgb(33,33,33);font-size:13px"><b=
r></div><div style=3D"color:rgb(33,33,33);font-size:13px"><div># Soft-fork =
Introduction of a New POW</div><div><br></div><div>## Motivation:<br></div>=
<div><br></div><div>- Mitigate mining centralization pressures by introduci=
ng a POW that does not have economies of scale</div><div>- Introduce an int=
ermediary confirmation point, reducing the impact of mining power fluctuati=
ons</div><div><br></div><div>Note however that choice of a suitable POW wil=
l require deep analysis.=C2=A0 Some pitfalls include: botnet mining, POWs t=
hat seem ASIC resistant but are not, unexpected/covert optimization.</div><=
div><br></div><div>In particular, unexpected/covert optimizations, such as =
ASCIBOOST, present a potential centralizing and destabilizing force.</div><=
div><br></div><div>## Design</div><div><br></div><div>### Aux POW intermedi=
ate block</div><div><br></div><div>Auxiliary POW blocks are introduced betw=
een normal blocks - i.e. the chain alternates between the two POWs.</div><d=
iv>Each aux-POW block points to the previous normal block and contains tran=
sactions just like a normal block.</div><div>Each normal block points to th=
e previous aux-POW block and must contain all transactions from the aux-POW=
 block.</div><div>Block space is not increased.</div><div><br></div><div>Th=
e new intermediate block and the pointers are introduced via a soft-fork re=
striction.</div><div><br></div><div>### Reward for aux POW miners</div><div=
><br></div><div>The reward for the aux POW smoothly increases from zero to =
a target value (e.g. 1/2 of the total reward) over time.</div><div>The rewa=
rd is transferred via a soft-fork restriction requiring a coinbase output t=
o an address published in the</div><div>aux-POW block.</div><div><br></div>=
<div>### Aux POW difficulty adjustment</div><div><br></div><div>Difficulty =
adjustments remain independent for the two POWs.</div><div><br></div><div>T=
he difficulty of the aux POW is adjusted based on the average time between =
normal block found</div><div>to aux block found.</div><div><br></div><div>F=
urther details are dependent on the specific POW.</div><div><br></div><div>=
### Heaviest chain rule change</div><div><br></div><div>This is a semi-hard=
 change, because non-upgraded nodes can get on the wrong chain in case of a=
ttack.=C2=A0 However,</div><div>it might be possible to construct an alert =
system that notifies non-upgraded nodes of an upcoming rule change.</div><d=
iv>All blocks are still valid, so this is not a hardforking change.</div><d=
iv><br></div><div>The heaviest chain definition changes from sum of `diffic=
ulty` to sum of:</div><div><br></div><div>=C2=A0 =C2=A0 mainDifficulty ^ x =
* auxDifficulty ^ y</div><div><br></div><div>where we start at:</div><div><=
br></div><div>=C2=A0 =C2=A0 x =3D 1; y =3D 0</div><div><br></div><div>and e=
nd at values of x and y that are related to the target relative rewards.=C2=
=A0 For example, if the target rewards</div><div>are equally distributed, w=
e will want ot end up at:</div><div><br></div><div>=C2=A0 =C2=A0 x =3D 1/2;=
 y =3D 1/2</div><div><br></div><div>so that both POWs have equal weight.=C2=
=A0 If the aux POW is to become dominant, x should end small relative to y.=
</div><div><br></div><div><br></div><div>## Questions and Answers</div><div=
><br></div><div>- What should be the parameters if we want the aux POW to h=
ave equal weight? A: 1/2 of the reward should be transferred</div><div>to a=
ux miners and x =3D 1/2, y =3D 1/2.</div><div><br></div><div>- What should =
be the parameters if we want to deprecate the main POW?=C2=A0 A: most of th=
e reward should be transferred to</div><div>aux miners and x =3D 0, y =3D 1=
.=C2=A0 The main difficulty will tend to zero, and aux miners will just tri=
vially generate the</div><div>main block immediately after finding an aux b=
lock, with identical content.</div><div><br></div><div>- Wasted bandwidth t=
o transfer transactions twice?=C2=A0 A: this can be optimized by skipping t=
ransactions already</div><div>transferred.</div><div><br></div><div>- Why w=
ould miners agree to soft-fork away some of their reward?=C2=A0 A: they wou=
ld agree if they believe that</div><div>the coins will increase in value du=
e to improved security properties.</div><div><br></div><div>## Open Questio=
ns</div><div><br></div><div>- After a block of one type is found, we can na=
ively assume that POW will become idle while a block of the other type is b=
eing mined.=C2=A0 In practice, the spare capacity can be used to find alter=
native (&quot;attacking&quot;) blocks or mine other coins.=C2=A0 Is that a =
problem?</div><div>- Is selfish mining amplified by this scheme for miners =
that have both types of hardware?</div><div><br></div><div>## POW candidate=
s</div><div><br></div><div>- SHA256 (i.e. use same POW, but introduce an in=
termediate block for faster confirmation)</div><div>- Proof of Space and Ti=
me (Bram Cohen)</div><div>- Equihash</div><div>- Ethash</div><div><br></div=
><div>## Next Steps</div><div><br></div><div>- evaluate POW candidates</div=
><div>- evaluate difficulty adjustment rules</div><div>- simulate miner beh=
avior to identify if there are incentives for detrimental behavior patterns=
 (e.g. block withholding / selfish mining)</div><div>- Protocol details</di=
v><div><br></div><div>## Credits</div><div><br></div><div>Bram Cohen came u=
p with a similar idea back in March:</div><div><a href=3D"https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html" target=3D"_b=
lank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/01=
3744.html</a></div></div></div></div></blockquote></div></div></div><div st=
yle=3D"word-wrap:break-word"><div><div><blockquote type=3D"cite"><div>
_______________________________________________<br>bitcoin-dev mailing list=
<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br><a href=3D"https://lists.l=
inuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://=
lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div></block=
quote></div><br></div></div></blockquote></div></div>

--94eb2c0629360d15e6055d09a96a--