path: root/54/401495263cbe023d9dc27fbf0503c0e88c50f9

Return-Path: <ethan.scruples@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4AF8BC50
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Sep 2018 18:00:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com
	[209.85.210.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 03AFF7E4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Sep 2018 18:00:40 +0000 (UTC)
Received: by mail-ot1-f43.google.com with SMTP id a19-v6so5411516otl.12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Sep 2018 11:00:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=7Vvg1lA+KdI4xsu7GOe2m/j7MkSKYXop0+kvNNATF/Y=;
	b=BJUqHB4rsgmM5qyq2mF+fI3WEiIc+B0GSUkCAlETXz8Yj6m2NGLGor2r0M0aryzTKZ
	rsqS2eciaQZJ2Fg5Ex/fDCThTQzxhtoq3cdfWl8YWToJ8AohVjbvaTouC3DqRsK5NqEy
	E98iNe73YCpLGcceAnoSSwPkzBEdKSJcQ947KwkhV3AzHfgZEQZNEvuXy0m7vghvjhYI
	8l5NIivH4GBuxWGAaVvs22Lgmua3p3NNchnSP7A3MBSHCecOb77g3lczco/RXGa/ly9w
	UsYJTyXjfp5wbEqtAUZexSYJO8xZrr0R6z+Nlr48MV0aDVkex/EZj6brUrEKA+UKOIeo
	9bEg==
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=7Vvg1lA+KdI4xsu7GOe2m/j7MkSKYXop0+kvNNATF/Y=;
	b=rIGGvJNgDyKAhJARnnOjku3HDKBnuhzgnpOGsxeGXbl95u6blN7X7VsaIhQRTuQP61
	BWWaeqg09NkGmyJ4jk+I+Y/VKewgSTBuLLbh0eQx+z9AVF3js2QhNHu3ma8RMmKZz4Vt
	bLeCLUw70rZcNgGuYaQwshz1UJ8kXK+YaCVBNTMXT4BcQiolPVj3HHmIibYPFjylbMNv
	clNozlqL9nx2e+xu8Ss5YCe0ovKslzncRP7r6dbo9rZGGPNGjuQhhO81BpQk3GJpzgQt
	IeAUjEC0/uKOHE9t6z8eKfgeER55Vc64pt/9YxoF3xs6xN3e2KSGJTaT1q+nrrOHAgKV
	14CA==
X-Gm-Message-State: APzg51Bz8tlHpnC6FifGCSBffzkG9yTQsnrv9EFNrs2NwxJ1jnB2W1Ss
	jI3PMmDi1/LTVLE27c6R7zKfxVa3xtmd8YN7Pc0=
X-Google-Smtp-Source: ANB0VdbcCbTxGgcS/JgpsfmHCKkFb8co6/wtK5IdkL6eJSejpv8C+ilDsa7omNz+aniDt7wMNK7hBk6jrZ1Yct0zgZ0=
X-Received: by 2002:a9d:63d8:: with SMTP id
	e24-v6mr4913146otl.233.1536948040211; 
	Fri, 14 Sep 2018 11:00:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAL8tG=k+kXHMbQdUXO3BXKv7fQwp5t2QuaQut7sPUtEYgwzn0A@mail.gmail.com>
	<CAL8tG=mui_izrob0V66QqNzSJs1Lpbm0xxUYMpzb65-JR9QhRw@mail.gmail.com>
	<CACiOHGzZ3VQVDsRdU6wsC+mqYJ6nTa4sm4snqDNTcR6x5XP2=Q@mail.gmail.com>
	<CAL8tG=kKwjbR4-rOn8K3-=myW5Nx6ugkyPWTTy9c+r0wrA6i0A@mail.gmail.com>
In-Reply-To: <CAL8tG=kKwjbR4-rOn8K3-=myW5Nx6ugkyPWTTy9c+r0wrA6i0A@mail.gmail.com>
From: Moral Agent <ethan.scruples@gmail.com>
Date: Fri, 14 Sep 2018 14:00:29 -0400
Message-ID: <CACiOHGz7hFeGKLmUDvsEp-yjiiEfdCWBeKya0ZDVGCeO+1VgZg@mail.gmail.com>
To: Andrew K <onelineproof@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f99f500575d89968"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE 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, 14 Sep 2018 18:36:53 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Selfish Mining Prevention
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, 14 Sep 2018 18:00:42 -0000

--000000000000f99f500575d89968
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you, and my apologies. I should have sent that link just to you and
not put everyone on cc.

On Fri, Sep 14, 2018 at 1:30 PM Andrew <onelineproof@gmail.com> wrote:

> (reposting to whole list instead of just him) @Moral Agent:
> Interesting proposal though it introduces some elements
> of proof of stake so it would be more controversial in my view. Also,
> something needs to be explained about how this would not create an
> attack where difficulty is frequently dropping by 25%, and suddenly we
> find ourselves with a very low difficulty and PoW attacks can easily
> happen. I need to analyse your proposal more, but I prefer to discuss
> it on your blog instead of here just to limit the side topics and
> focus only on my proposal.
>
> No one has yet given me a good reason for why not to support my proposal.=
..
>
> On Fri, Sep 14, 2018 at 2:49 PM, Moral Agent <ethan.scruples@gmail.com>
> wrote:
> > You might be interested in an idea I wrote about that is in a similar
> spirit
> > here:
> >
> >
> https://medium.com/coinmonks/taming-large-miners-with-helper-blocks-6ae67=
ac242f6
> >
> > From the article:
> >
> > When a block is solved, it randomly selects one satoshi from the utxo s=
et
> > and gives whomever controls that satoshi the power to generate a =E2=80=
=9CHelper
> > Block=E2=80=9D. The Helper Block commits to a subset of transactions fo=
r
> inclusion
> > in the next block. A miner can accept the Helper Block by including the
> > suggested transactions and giving the associated transaction fees to a
> > payment address specified in the Helper Block. Miners who do not use a
> > Helper Block must satisfy a 25% higher difficulty.
> >
> > On Fri, Sep 14, 2018 at 9:56 AM Andrew via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> I discussed this more at bitcointalk:
> >> https://bitcointalk.org/index.php?topic=3D4998410.0
> >>
> >> The attacks I'm interested in preventing are not only selfish mining
> >> and collusion, but also more subtle attacks like block withholding,
> >> and in general anything that aims to drive out the competition in
> >> order to increase hashrate fraction. I also scrapped the idea of
> >> changing the block subsidies, and I am only focuses on fees.
> >>
> >> You can read more about the motivation and details in the bitcointalk
> >> thread, but my proposal in short would be to add the concept of
> >> "reserve fees". When a user makes a transaction, for each txout
> >> script, they can add parameters that specify the fraction of the total
> >> fee that is held in "reserve" and the time it is held in "reserve"
> >> (can set a limit of 2016 blocks). This "reserve" part of the fee will
> >> be paid to miners if the hashrate rises. So if hashrate is currently h
> >> and peak hashrate (from past year) is p, then for each period (1 day),
> >> a new hashrate is calculated h1, and if h1 > h, then the fraction
> >> (h1-h)/p from the reserve fees created in the past 2016 blocks will be
> >> released to miners for that period (spread out over the 144 blocks in
> >> that period). And this will keep happening as long as hashrate keeps
> >> rising, until the "contract" expires, and the leftover part can be
> >> used by the owner of the unspent output, but it can only be used for
> >> paying fees, not as inputs for future transactions (to save on block
> >> space).
> >>
> >> This should incentivize miners to not drive out the competition, since
> >> if they do, there will be less of these reserve fees given to miners.
> >> Yes in the end the miners will get all the fees, but with rising
> >> hashrate they get an unconditional subsidy that does not require
> >> transactions, thus more space for transactions with fees.
> >>
> >> I can make a formal BIP and pull request, but I need to know if there
> >> is interest in this. Now fees don't play such a large part of the
> >> block reward, but they will get more important, and this change
> >> wouldn't force anything (would be voluntary by each user), just miners
> >> have to agree to it with a soft fork (so they don't spend from the
> >> anyone-can-spend outputs used for reserve fees). Resource requirements
> >> for validation are quite small I believe.
> >>
> >> On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail.com> wrote=
:
> >> > As I understand, selfish mining is an attack where miners collude to
> >> > mine at a lower hashrate then with all miners working independently.
> >> > What are the current strategies used to prevent this and what are th=
e
> >> > future plans?
> >> >
> >> > One idea I have is to let the block reward get "modulated" according
> >> > to peak hashrate. Say p is the peak hashrate for 365 periods (1 year=
)
> >> > consisting of 144 blocks, h is the hashrate of the last 144 block (1
> >> > day) period, and r is the base subsidy (12.5 BTC currently). You can
> >> > then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
> >> > peak you get the full reward. Otherwise you get less, down to a min =
of
> >> > 0.5 r.
> >> >
> >> > If miners were to collude to mine at a lower than peak hashrate, the=
n
> >> > they may be able to do it profitably for 144 blocks, but after that,
> >> > the reward would get modulated and it wouldn't be so much in their
> >> > interest to continue mining at the lower hashrate.
> >> >
> >> > What flaws are there with this? I know it could be controversial due
> >> > to easier mining present for early miners, so maybe it would have to
> >> > be done in combination with a new more dynamic difficulty adjustment
> >> > algorithm. But I don't see how hashrate can continue rising
> >> > indefinitely, so a solution should be made for selfish mining.
> >> >
> >> > Also when subsidies stop and a fee market is needed, I guess a porti=
on
> >> > of the fees can be withheld for later if hashrate is not at peak.
> >> >
> >> >
> >> > --
> >> > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
> >>
> >>
> >>
> >> --
> >> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
>

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

<div dir=3D"ltr">Thank you, and my apologies. I should have sent that link =
just to you and not put everyone on cc.</div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr">On Fri, Sep 14, 2018 at 1:30 PM Andrew &lt;<a href=3D"mai=
lto:onelineproof@gmail.com">onelineproof@gmail.com</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">(reposting to whole list instead of just him=
) @Moral Agent:<br>
Interesting proposal though it introduces some elements<br>
of proof of stake so it would be more controversial in my view. Also,<br>
something needs to be explained about how this would not create an<br>
attack where difficulty is frequently dropping by 25%, and suddenly we<br>
find ourselves with a very low difficulty and PoW attacks can easily<br>
happen. I need to analyse your proposal more, but I prefer to discuss<br>
it on your blog instead of here just to limit the side topics and<br>
focus only on my proposal.<br>
<br>
No one has yet given me a good reason for why not to support my proposal...=
<br>
<br>
On Fri, Sep 14, 2018 at 2:49 PM, Moral Agent &lt;<a href=3D"mailto:ethan.sc=
ruples@gmail.com" target=3D"_blank">ethan.scruples@gmail.com</a>&gt; wrote:=
<br>
&gt; You might be interested in an idea I wrote about that is in a similar =
spirit<br>
&gt; here:<br>
&gt;<br>
&gt; <a href=3D"https://medium.com/coinmonks/taming-large-miners-with-helpe=
r-blocks-6ae67ac242f6" rel=3D"noreferrer" target=3D"_blank">https://medium.=
com/coinmonks/taming-large-miners-with-helper-blocks-6ae67ac242f6</a><br>
&gt;<br>
&gt; From the article:<br>
&gt;<br>
&gt; When a block is solved, it randomly selects one satoshi from the utxo =
set<br>
&gt; and gives whomever controls that satoshi the power to generate a =E2=
=80=9CHelper<br>
&gt; Block=E2=80=9D. The Helper Block commits to a subset of transactions f=
or inclusion<br>
&gt; in the next block. A miner can accept the Helper Block by including th=
e<br>
&gt; suggested transactions and giving the associated transaction fees to a=
<br>
&gt; payment address specified in the Helper Block. Miners who do not use a=
<br>
&gt; Helper Block must satisfy a 25% higher difficulty.<br>
&gt;<br>
&gt; On Fri, Sep 14, 2018 at 9:56 AM Andrew via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I discussed this more at bitcointalk:<br>
&gt;&gt; <a href=3D"https://bitcointalk.org/index.php?topic=3D4998410.0" re=
l=3D"noreferrer" target=3D"_blank">https://bitcointalk.org/index.php?topic=
=3D4998410.0</a><br>
&gt;&gt;<br>
&gt;&gt; The attacks I&#39;m interested in preventing are not only selfish =
mining<br>
&gt;&gt; and collusion, but also more subtle attacks like block withholding=
,<br>
&gt;&gt; and in general anything that aims to drive out the competition in<=
br>
&gt;&gt; order to increase hashrate fraction. I also scrapped the idea of<b=
r>
&gt;&gt; changing the block subsidies, and I am only focuses on fees.<br>
&gt;&gt;<br>
&gt;&gt; You can read more about the motivation and details in the bitcoint=
alk<br>
&gt;&gt; thread, but my proposal in short would be to add the concept of<br=
>
&gt;&gt; &quot;reserve fees&quot;. When a user makes a transaction, for eac=
h txout<br>
&gt;&gt; script, they can add parameters that specify the fraction of the t=
otal<br>
&gt;&gt; fee that is held in &quot;reserve&quot; and the time it is held in=
 &quot;reserve&quot;<br>
&gt;&gt; (can set a limit of 2016 blocks). This &quot;reserve&quot; part of=
 the fee will<br>
&gt;&gt; be paid to miners if the hashrate rises. So if hashrate is current=
ly h<br>
&gt;&gt; and peak hashrate (from past year) is p, then for each period (1 d=
ay),<br>
&gt;&gt; a new hashrate is calculated h1, and if h1 &gt; h, then the fracti=
on<br>
&gt;&gt; (h1-h)/p from the reserve fees created in the past 2016 blocks wil=
l be<br>
&gt;&gt; released to miners for that period (spread out over the 144 blocks=
 in<br>
&gt;&gt; that period). And this will keep happening as long as hashrate kee=
ps<br>
&gt;&gt; rising, until the &quot;contract&quot; expires, and the leftover p=
art can be<br>
&gt;&gt; used by the owner of the unspent output, but it can only be used f=
or<br>
&gt;&gt; paying fees, not as inputs for future transactions (to save on blo=
ck<br>
&gt;&gt; space).<br>
&gt;&gt;<br>
&gt;&gt; This should incentivize miners to not drive out the competition, s=
ince<br>
&gt;&gt; if they do, there will be less of these reserve fees given to mine=
rs.<br>
&gt;&gt; Yes in the end the miners will get all the fees, but with rising<b=
r>
&gt;&gt; hashrate they get an unconditional subsidy that does not require<b=
r>
&gt;&gt; transactions, thus more space for transactions with fees.<br>
&gt;&gt;<br>
&gt;&gt; I can make a formal BIP and pull request, but I need to know if th=
ere<br>
&gt;&gt; is interest in this. Now fees don&#39;t play such a large part of =
the<br>
&gt;&gt; block reward, but they will get more important, and this change<br=
>
&gt;&gt; wouldn&#39;t force anything (would be voluntary by each user), jus=
t miners<br>
&gt;&gt; have to agree to it with a soft fork (so they don&#39;t spend from=
 the<br>
&gt;&gt; anyone-can-spend outputs used for reserve fees). Resource requirem=
ents<br>
&gt;&gt; for validation are quite small I believe.<br>
&gt;&gt;<br>
&gt;&gt; On Sat, Sep 1, 2018 at 12:11 AM, Andrew &lt;<a href=3D"mailto:onel=
ineproof@gmail.com" target=3D"_blank">onelineproof@gmail.com</a>&gt; wrote:=
<br>
&gt;&gt; &gt; As I understand, selfish mining is an attack where miners col=
lude to<br>
&gt;&gt; &gt; mine at a lower hashrate then with all miners working indepen=
dently.<br>
&gt;&gt; &gt; What are the current strategies used to prevent this and what=
 are the<br>
&gt;&gt; &gt; future plans?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; One idea I have is to let the block reward get &quot;modulate=
d&quot; according<br>
&gt;&gt; &gt; to peak hashrate. Say p is the peak hashrate for 365 periods =
(1 year)<br>
&gt;&gt; &gt; consisting of 144 blocks, h is the hashrate of the last 144 b=
lock (1<br>
&gt;&gt; &gt; day) period, and r is the base subsidy (12.5 BTC currently). =
You can<br>
&gt;&gt; &gt; then make the max block reward 0.5 r (1 + h/p). So if hashrat=
e is at<br>
&gt;&gt; &gt; peak you get the full reward. Otherwise you get less, down to=
 a min of<br>
&gt;&gt; &gt; 0.5 r.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; If miners were to collude to mine at a lower than peak hashra=
te, then<br>
&gt;&gt; &gt; they may be able to do it profitably for 144 blocks, but afte=
r that,<br>
&gt;&gt; &gt; the reward would get modulated and it wouldn&#39;t be so much=
 in their<br>
&gt;&gt; &gt; interest to continue mining at the lower hashrate.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; What flaws are there with this? I know it could be controvers=
ial due<br>
&gt;&gt; &gt; to easier mining present for early miners, so maybe it would =
have to<br>
&gt;&gt; &gt; be done in combination with a new more dynamic difficulty adj=
ustment<br>
&gt;&gt; &gt; algorithm. But I don&#39;t see how hashrate can continue risi=
ng<br>
&gt;&gt; &gt; indefinitely, so a solution should be made for selfish mining=
.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Also when subsidies stop and a fee market is needed, I guess =
a portion<br>
&gt;&gt; &gt; of the fees can be withheld for later if hashrate is not at p=
eak.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; PGP: B6AC 822C 451D 6304 6A28=C2=A0 49E9 7DB7 011C D53B 5647<=
br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; PGP: B6AC 822C 451D 6304 6A28=C2=A0 49E9 7DB7 011C D53B 5647<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
<br>
-- <br>
PGP: B6AC 822C 451D 6304 6A28=C2=A0 49E9 7DB7 011C D53B 5647<br>
</blockquote></div>

--000000000000f99f500575d89968--