path: root/2f/df94b68d2f70c34c199f348292263ffb296c53

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 AED97C0A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Sep 2018 14:49:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com
	[209.85.210.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CFCE53CC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Sep 2018 14:49:27 +0000 (UTC)
Received: by mail-ot1-f47.google.com with SMTP id v10-v6so4819285otk.7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Sep 2018 07:49:27 -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; 
	bh=razz3zvM3EyCvkh5u1yiz9c0Wfw24za+oBFi8qtX4JE=;
	b=jIVqw3pKOE8tZZ5WTfGU4+nOEzmmClVPZqOl0tjjcnUdtCVbIu4gK8WydKzGtn1Zko
	qirJiK01t6MtgFoL7ZgErQndrYZAAOibqUaj+PI1LVe6d09XUuouSHAVvpT4ErBrERro
	E5ROurufjaGAKKzpLkQft41jq5KPaHeARKok6O+hdo2lqcLs/EaQSySLu5l2EF9de5s6
	8Qh7sU/S/j1/7IhOLoyK/iwLH6cckcJoFMdcAbj3wRG+gnKMkqXivew6aAyXiK0VMuA4
	Uib5WIN2vC5DXurzlhbiWYwBrXbZMof+CwqXoQ7YKeuh6zwMLqotLjMtax+9jl0IPPhp
	3Iig==
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;
	bh=razz3zvM3EyCvkh5u1yiz9c0Wfw24za+oBFi8qtX4JE=;
	b=NpovvD3OJYpKAGWeAGLBdACFs96G5WMe3HhAzwNF20d4SDcDJFRN71izA5DU4jeU2P
	fMRBeQsUbAYBsWiLmF2C4nS60qcySwgpDhOSOsjcaxgUhZUuCAXwS8odx1h8UFnb3TqB
	Y0G+ru4+p8ItBADxkrpAhCRg3L4parj/pebp/BOE2qRsaua0mvol09euf8Ls9NET7zXK
	GCIJ90Iyqu8YNoNix87vuJ13OBeRIUcjxECleHlX+mqgNDKnmPXKUsdfJXeotk20lNA3
	DYxMjZPGlQYyw4BimP9IQx/sd0RUSFUaFpFIL5UsamxzCu9eC/M0NsczOF6p2BwakiqM
	jzpQ==
X-Gm-Message-State: APzg51BNCLL3iJu8ied4XxRlfSXdDo1L19KIa1pbDe+hS61wfrWD7MSv
	zfdgatw7You18c48a9Vys3CEMUjo2nXYGA7NkDY=
X-Google-Smtp-Source: ANB0VdaiLl73NwKohvdPdBzocfsxSE0lHI+RV41e8tPN8PCcg9fIFKel2NZu3ECKceCzoyuOMsp5PXs4b7hJnOcLnLo=
X-Received: by 2002:a9d:56a4:: with SMTP id
	o33-v6mr4860022oth.196.1536936567095; 
	Fri, 14 Sep 2018 07:49:27 -0700 (PDT)
MIME-Version: 1.0
References: <CAL8tG=k+kXHMbQdUXO3BXKv7fQwp5t2QuaQut7sPUtEYgwzn0A@mail.gmail.com>
	<CAL8tG=mui_izrob0V66QqNzSJs1Lpbm0xxUYMpzb65-JR9QhRw@mail.gmail.com>
In-Reply-To: <CAL8tG=mui_izrob0V66QqNzSJs1Lpbm0xxUYMpzb65-JR9QhRw@mail.gmail.com>
From: Moral Agent <ethan.scruples@gmail.com>
Date: Fri, 14 Sep 2018 10:49:16 -0400
Message-ID: <CACiOHGzZ3VQVDsRdU6wsC+mqYJ6nTa4sm4snqDNTcR6x5XP2=Q@mail.gmail.com>
To: onelineproof@gmail.com, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000001fc4970575d5ee74"
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 15:05:14 +0000
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 14:49:28 -0000

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

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-6ae67ac=
242f6

From the article:

When a block is solved, it randomly selects one satoshi from the utxo set
and gives whomever controls that satoshi the power to generate a =E2=80=9CH=
elper
Block=E2=80=9D. The Helper Block commits to a subset of transactions for in=
clusion
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 the
> > 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, then
> > 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 portion
> > 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
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div>You might be interested in an idea I=
 wrote about that is in a similar spirit here:</div><div><br></div><div><a =
href=3D"https://medium.com/coinmonks/taming-large-miners-with-helper-blocks=
-6ae67ac242f6">https://medium.com/coinmonks/taming-large-miners-with-helper=
-blocks-6ae67ac242f6</a></div><div><br></div><div>From the article:</div><d=
iv><br></div><div>When a block is solved, it randomly selects one satoshi f=
rom the utxo set and gives whomever controls that satoshi the power to gene=
rate a =E2=80=9CHelper Block=E2=80=9D. The Helper Block commits to a subset=
 of transactions for inclusion in the next block. A miner can accept the He=
lper Block by including the suggested transactions and giving the associate=
d transaction fees to a payment address specified in the Helper Block. Mine=
rs who do not use a Helper Block must satisfy a 25% higher difficulty.</div=
></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Sep 14=
, 2018 at 9:56 AM Andrew via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">I discussed this more at bitco=
intalk:<br>
<a href=3D"https://bitcointalk.org/index.php?topic=3D4998410.0" rel=3D"nore=
ferrer" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D4998410=
.0</a><br>
<br>
The attacks I&#39;m interested in preventing are not only selfish mining<br=
>
and collusion, but also more subtle attacks like block withholding,<br>
and in general anything that aims to drive out the competition in<br>
order to increase hashrate fraction. I also scrapped the idea of<br>
changing the block subsidies, and I am only focuses on fees.<br>
<br>
You can read more about the motivation and details in the bitcointalk<br>
thread, but my proposal in short would be to add the concept of<br>
&quot;reserve fees&quot;. When a user makes a transaction, for each txout<b=
r>
script, they can add parameters that specify the fraction of the total<br>
fee that is held in &quot;reserve&quot; and the time it is held in &quot;re=
serve&quot;<br>
(can set a limit of 2016 blocks). This &quot;reserve&quot; part of the fee =
will<br>
be paid to miners if the hashrate rises. So if hashrate is currently h<br>
and peak hashrate (from past year) is p, then for each period (1 day),<br>
a new hashrate is calculated h1, and if h1 &gt; h, then the fraction<br>
(h1-h)/p from the reserve fees created in the past 2016 blocks will be<br>
released to miners for that period (spread out over the 144 blocks in<br>
that period). And this will keep happening as long as hashrate keeps<br>
rising, until the &quot;contract&quot; expires, and the leftover part can b=
e<br>
used by the owner of the unspent output, but it can only be used for<br>
paying fees, not as inputs for future transactions (to save on block<br>
space).<br>
<br>
This should incentivize miners to not drive out the competition, since<br>
if they do, there will be less of these reserve fees given to miners.<br>
Yes in the end the miners will get all the fees, but with rising<br>
hashrate they get an unconditional subsidy that does not require<br>
transactions, thus more space for transactions with fees.<br>
<br>
I can make a formal BIP and pull request, but I need to know if there<br>
is interest in this. Now fees don&#39;t play such a large part of the<br>
block reward, but they will get more important, and this change<br>
wouldn&#39;t force anything (would be voluntary by each user), just miners<=
br>
have to agree to it with a soft fork (so they don&#39;t spend from the<br>
anyone-can-spend outputs used for reserve fees). Resource requirements<br>
for validation are quite small I believe.<br>
<br>
On Sat, Sep 1, 2018 at 12:11 AM, Andrew &lt;<a href=3D"mailto:onelineproof@=
gmail.com" target=3D"_blank">onelineproof@gmail.com</a>&gt; wrote:<br>
&gt; As I understand, selfish mining is an attack where miners collude to<b=
r>
&gt; mine at a lower hashrate then with all miners working independently.<b=
r>
&gt; What are the current strategies used to prevent this and what are the<=
br>
&gt; future plans?<br>
&gt;<br>
&gt; One idea I have is to let the block reward get &quot;modulated&quot; a=
ccording<br>
&gt; to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)<=
br>
&gt; consisting of 144 blocks, h is the hashrate of the last 144 block (1<b=
r>
&gt; day) period, and r is the base subsidy (12.5 BTC currently). You can<b=
r>
&gt; then make the max block reward 0.5 r (1 + h/p). So if hashrate is at<b=
r>
&gt; peak you get the full reward. Otherwise you get less, down to a min of=
<br>
&gt; 0.5 r.<br>
&gt;<br>
&gt; If miners were to collude to mine at a lower than peak hashrate, then<=
br>
&gt; they may be able to do it profitably for 144 blocks, but after that,<b=
r>
&gt; the reward would get modulated and it wouldn&#39;t be so much in their=
<br>
&gt; interest to continue mining at the lower hashrate.<br>
&gt;<br>
&gt; What flaws are there with this? I know it could be controversial due<b=
r>
&gt; to easier mining present for early miners, so maybe it would have to<b=
r>
&gt; be done in combination with a new more dynamic difficulty adjustment<b=
r>
&gt; algorithm. But I don&#39;t see how hashrate can continue rising<br>
&gt; indefinitely, so a solution should be made for selfish mining.<br>
&gt;<br>
&gt; Also when subsidies stop and a fee market is needed, I guess a portion=
<br>
&gt; of the fees can be withheld for later if hashrate is not at peak.<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; PGP: B6AC 822C 451D 6304 6A28=C2=A0 49E9 7DB7 011C D53B 5647<br>
<br>
<br>
<br>
-- <br>
PGP: B6AC 822C 451D 6304 6A28=C2=A0 49E9 7DB7 011C D53B 5647<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>

--0000000000001fc4970575d5ee74--