path: root/a3/8cbce004ed36a506c5fbff4221aa60df678994

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 8A8F2BC6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Jul 2015 16:26:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com
	[209.85.192.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 71AFEF0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Jul 2015 16:26:31 +0000 (UTC)
Received: by qgy5 with SMTP id 5so5110027qgy.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Jul 2015 09:26:30 -0700 (PDT)
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=ITpuAswkUwsfAW5nkV6h03AKdRa9WR6Pi5YDqf/9FfY=;
	b=RM+6+02+SWCs6sCuY1yUsRsljLpYt6V6MB5KojtpK2UPeR3WfsZDiG/kww+EKJGz1l
	INgP+APfaRvx/+QuoAn5M/D5ELUz8z/SGLru8E1D0SdefATZAZSSYZoDf5OvsmuQYt1t
	zVK3GkBRpgz/ob+ob278VlRk6KYt4v2WKDSJN7uVN/89q6bRqAJwyo2C86oSZwlr4akG
	X8ApPsUnDZv1k8BvnIwfGuz06a4Nht1fanxGusgSWJ/jTFkxQqKIrnCwbl3Enl0dRAjs
	5dMXUbGJTXznX1JFi7YyOMIgahMUihMnq5CObC98JQ0l9xJy49uSA3/nINtE3Nvjkfa7
	Bb4w==
MIME-Version: 1.0
X-Received: by 10.140.152.207 with SMTP id 198mr9234560qhy.69.1436631990572;
	Sat, 11 Jul 2015 09:26:30 -0700 (PDT)
Received: by 10.140.93.162 with HTTP; Sat, 11 Jul 2015 09:26:30 -0700 (PDT)
In-Reply-To: <719E65A8-AC95-408C-8E00-FB06DCC6CDB1@hashingit.com>
References: <CAFdHNGg2dezj4V-i-E6dRLp99nZMQ_ErKdBo0OgQJ=9WPm90jQ@mail.gmail.com>
	<CABm2gDoAa5F5crO4enKO-Qqb+Zd3=9b8ohBDYmrygsPSWdevoQ@mail.gmail.com>
	<CAE-z3OWOoHfMaEN04CQ-j8tzmAr1+Evjh+tfHRDbF6F1jxykHA@mail.gmail.com>
	<CAFdHNGj8BXAazAtHZsPe0qwxjRaxn6fQ4G-==bLCqwp+QH09Kg@mail.gmail.com>
	<CAE-z3OW8rOmnBOpK=mFdxK_sATNL-2TRhqzv=r0in3EzF4cGoA@mail.gmail.com>
	<719E65A8-AC95-408C-8E00-FB06DCC6CDB1@hashingit.com>
Date: Sat, 11 Jul 2015 17:26:30 +0100
Message-ID: <CAE-z3OVztaWW7RYLyHUF=JxqDoM+fWFQFcB7EhxZ=cDwKNwwJw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1135a2d4789bec051a9bf3ad
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] SPV Mining reveals a problematic incentive issue.
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: Sat, 11 Jul 2015 16:26:32 -0000

--001a1135a2d4789bec051a9bf3ad
Content-Type: text/plain; charset=UTF-8

On Sat, Jul 11, 2015 at 4:04 PM, Dave Hudson <dave@hashingit.com> wrote:

> This would probably be worse. The 1 MB would include the highest fee
> transactions, leaving the lowest fees in the remaining 0.5 MB.
>

Right, in the example, I was assuming all transactions had the same fee per
byte.


> If hashing isn't constantly applied all the time then the inter-block
> times will expand and the difficulty will reduce. This means that a pool
> that decides to use all of its available hashing 100% of the time now has a
> distinct advantage over those who are playing nicely. This is the same
> problem that the "proof of idle" idea had; it only works if no-one chooses
> to try to exploit it (which seems very unlikely).
>

Uh, I don't think so.  Pools would offer a price per hash based on how much
tx fees that they can get at that moment.

Offering more than that would mean they make a loss on average.

Say, for the sake of argument that over a nominal 10 minute period we see
> 10 BTC worth of transaction fees. If the mempool is empty of interesting
> fees at the start of a block then we might like to imagine that rational
> miners will power down their hashing to save energy costs until the fees
> are worthwhile. Let's assume, for the sake of argument, that this nominally
> takes 5 minutes.
>

I think the hardware would be able to power down nearly instantly.
Granted, if they have generators or similar, they may not be able to do it
so fast.

Switching to an altcoin is pretty much instant though.


> After 5 minutes we go from 0% to 100% as all hashing engines switch on.
> The difficulty will have corrected to mean that 100% of the work will
> nominally happen in the next 5 minutes, but that means that a malicious
> miner has a 2x amplification of their nominal hashing rate to do mischief
> in the preceding 5 minutes.
>

I think you need to split it into hashers and pools, rather than miners.
Hashers have to pay electricity costs to keep their equipment running.
Powering down for 5 minutes is cheaper than using that hashing for other
things.

The ratio of capital costs and electricity determines which wins out.

In the example given, it would work out as something like this.

0 mins: pool offers 0
2 mins: pool offers 20% of average
4 mins: pool offers 40% of average
6 mins: pool offers 60% of average
8 mins: pool offers 80% of average
10 mins: pool offers 100% of average
12 mins: pool offers 120% of average
14 mins: pool offers 140% of average
...

This means that more and more miners will accept the offer as time passes.
If a miner was using solar power for their miners, then they might as well
run it for the full 10 mins, since it is pointless to leave the equipment
off.  With batteries they could shift some of their output to the more
profitable period.

Such a malicious miner would choose to spend their 5 minutes re-mining the
> previous block, but dropping some amount of the transactions from it. Let's
> say that they try to re-mine only 9.5 BTC out the previous 10 BTC. If they
> succeed then they're offering everyone else an extra 0.5 BTC (5%) if they
> mine on top of their re-mined block and as an incentive to orphan the
> original block. Rational miners would definitely choose to build on the
> re-mined block because they get more reward from doing so.
>

If they find that block, it will be a tie with the other block, but created
much later.  That means that nobody will build on the block they found.


> Of course the extra hashing that our malicious miner is doing will
> actually push the difficulty back up somewhat, but they're still running at
> an advantage over the long-term. I've also ignored some of the other
> security implications of the hashing amplification effects (e.g. 25% of the
> hash rate can end up controlling 50% of the blocks in the scenario above).
>
> I think mining strategy once minting fees are greatly reduced is an
interesting question.  We can't assume that miners are all going to build
on the tip.

In your example, you can bribe the miner of the next block by paying to
OP_TRUE.

A <- B <-C

Assume that C pays 1BTC in fees and the miner creates a new version of C
that pays 1.1BTC in fees.

C' pays 1.1 BTC in fees and also pays 0.05BTC to OP_TRUE.

This means that miners who build on C' instead of C get a 0.05BTC 'bribe'
to ignore the fact that C' was found much later.

It isn't clear if other miners would be better off building D anyway, since
they could take 100% of the fees.

If the average fees per block was 1BTC and someone send a block that pays
10BTC in fees, it could stall the block chain.  You can do the same bribery
trick.

If C has the 10BTC transaction, you can create a C' block and pay 1BTC to
OP_TRUE.  The miner who builds on C' include a transaction which pays that
money to him.

Another miner can produce C'' that pays 2BTC to OP_TRUE.


> The only way I can see that this wouldn't be the case would be if there
> were always useful fees available to mine immediately after a block is
> found. If block space is kept moderately scarce then immediately a block is
> found then everyone will keep mining and the incentives to try to
> deliberately orphan the last block are dramatically reduced.
>

True, if there is multiple blocks worth of transactions in the memory pool,
then losing one block's worth of transactions won't drop the total fees
down to zero.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jul 11, 2015 at 4:04 PM, Dave Hudson <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:dave@hashingit.com" target=3D"_blank">dave@hashingit.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 style=3D"word-wrap:break-word"><div><div>This would probably be worse. The=
 1 MB would include the highest fee transactions, leaving the lowest fees i=
n the remaining 0.5 MB.</div></div></div></blockquote><div><br></div><div>R=
ight, in the example, I was assuming all transactions had the same fee per =
byte.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div style=3D"word-wrap:break-word"><div>If hashing isn&#39;t consta=
ntly applied all the time then the inter-block times will expand and the di=
fficulty will reduce. This means that a pool that decides to use all of its=
 available hashing 100% of the time now has a distinct advantage over those=
 who are playing nicely. This is the same problem that the &quot;proof of i=
dle&quot; idea had; it only works if no-one chooses to try to exploit it (w=
hich seems very unlikely).</div></div></blockquote><div><br></div><div>Uh, =
I don&#39;t think so.=C2=A0 Pools would offer a price per hash based on how=
 much tx fees that they can get at that moment. <br><br></div><div>Offering=
 more than that would mean they make a loss on average.<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-w=
ord"><div>Say, for the sake of argument that over a nominal 10 minute perio=
d we see 10 BTC worth of transaction fees. If the mempool is empty of inter=
esting fees at the start of a block then we might like to imagine that rati=
onal miners will power down their hashing to save energy costs until the fe=
es are worthwhile. Let&#39;s assume, for the sake of argument, that this no=
minally takes 5 minutes.</div></div></blockquote><div><br></div><div>I thin=
k the hardware would be able to power down nearly instantly.=C2=A0 Granted,=
 if they have generators or similar, they may not be able to do it so fast.=
<br><br></div><div>Switching to an altcoin is pretty much instant though.<b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div style=3D"word-wrap:break-word"><div>After 5 minutes we go from 0% to 1=
00% as all hashing engines switch on. The difficulty will have corrected to=
 mean that 100% of the work will nominally happen in the next 5 minutes, bu=
t that means that a malicious miner has a 2x amplification of their nominal=
 hashing rate to do mischief in the preceding 5 minutes.</div></div></block=
quote><div><br></div><div>I think you need to split it into hashers and poo=
ls, rather than miners.=C2=A0 Hashers have to pay electricity costs to keep=
 their equipment running.=C2=A0 Powering down for 5 minutes is cheaper than=
 using that hashing for other things.<br><br></div><div>The ratio of capita=
l costs and electricity determines which wins out.<br><br></div><div>In the=
 example given, it would work out as something like this.<br><br></div><div=
>0 mins: pool offers 0<br></div><div>2 mins: pool offers 20% of average<br>=
</div><div>4 mins: pool offers 40% of average<div>6 mins: pool offers 60% o=
f average<div>8 mins: pool offers 80% of average<div>10 mins: pool offers 1=
00% of average</div><div>12 mins: pool offers 120% of average<br>14 mins: p=
ool offers 140% of average<br></div></div></div></div>...<br>=C2=A0<br></di=
v><div class=3D"gmail_quote">This means that more and more miners will acce=
pt the offer as time passes.=C2=A0 If a miner was using solar power for the=
ir miners, then they might as well run it for the full 10 mins, since it is=
 pointless to leave the equipment off.=C2=A0 With batteries they could shif=
t some of their output to the more profitable period. <br></div><div class=
=3D"gmail_quote"><br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 style=3D"word-wrap:break-word"><div>Such a malicious miner would choose to=
 spend their 5 minutes re-mining the previous block, but dropping some amou=
nt of the transactions from it. Let&#39;s say that they try to re-mine only=
 9.5 BTC out the previous 10 BTC. If they succeed then they&#39;re offering=
 everyone else an extra 0.5 BTC (5%) if they mine on top of their re-mined =
block and as an incentive to orphan the original block. Rational miners wou=
ld definitely choose to build on the re-mined block because they get more r=
eward from doing so.</div></div></blockquote><div><br></div><div>If they fi=
nd that block, it will be a tie with the other block, but created much late=
r.=C2=A0 That means that nobody will build on the block they found.<br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div s=
tyle=3D"word-wrap:break-word"><div>Of course the extra hashing that our mal=
icious miner is doing will actually push the difficulty back up somewhat, b=
ut they&#39;re still running at an advantage over the long-term. I&#39;ve a=
lso ignored some of the other security implications of the hashing amplific=
ation effects (e.g. 25% of the hash rate can end up controlling 50% of the =
blocks in the scenario above).</div><div><br></div></div></blockquote><div>=
I think mining strategy once minting fees are greatly reduced is an interes=
ting question.=C2=A0 We can&#39;t assume that miners are all going to build=
 on the tip.<br><br></div><div>In your example, you can bribe the miner of =
the next block by paying to OP_TRUE.<br><br></div><div>A &lt;- B &lt;-C<br>=
<br></div><div>Assume that C pays 1BTC in fees and the miner creates a new =
version of C that pays 1.1BTC in fees.<br><br></div><div>C&#39; pays 1.1 BT=
C in fees and also pays 0.05BTC to OP_TRUE.<br><br></div><div>This means th=
at miners who build on C&#39; instead of C get a 0.05BTC &#39;bribe&#39; to=
 ignore the fact that C&#39; was found much later.<br><br></div><div>It isn=
&#39;t clear if other miners would be better off building D anyway, since t=
hey could take 100% of the fees.<br><br></div><div>If the average fees per =
block was 1BTC and someone send a block that pays 10BTC in fees, it could s=
tall the block chain.=C2=A0 You can do the same bribery trick.<br><br></div=
><div>If C has the 10BTC transaction, you can create a C&#39; block and pay=
 1BTC to OP_TRUE.=C2=A0 The miner who builds on C&#39; include a transactio=
n which pays that money to him. <br><br></div><div>Another miner can produc=
e C&#39;&#39; that pays 2BTC to OP_TRUE.<br></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-wor=
d"><div></div><div>The only way I can see that this wouldn&#39;t be the cas=
e would be if there were always useful fees available to mine immediately a=
fter a block is found. If block space is kept moderately scarce then immedi=
ately a block is found then everyone will keep mining and the incentives to=
 try to deliberately orphan the last block are dramatically reduced.</div><=
/div></blockquote></div><br></div><div class=3D"gmail_extra">True, if there=
 is multiple blocks worth of transactions in the memory pool, then losing o=
ne block&#39;s worth of transactions won&#39;t drop the total fees down to =
zero.<br></div></div>

--001a1135a2d4789bec051a9bf3ad--