MIME-Version: 1.0
In-Reply-To: <EC9193E8-DEC6-413F-A9AC-903E26E51824@gmail.com>
References: <20151220132842.GA25481@muck>
	<ema8a70574-c28e-4c43-a1e3-5f2f4df7d3a2@platinum>
	<CABm2gDp4ac=E+T-FT=ZQPnW_ao2GdF1QOg8tROYoV=QKypQS1g@mail.gmail.com>
	<EC9193E8-DEC6-413F-A9AC-903E26E51824@gmail.com>
Date: Sat, 26 Dec 2015 19:01:59 +0100
Message-ID: <CABm2gDrkvsShE1Vbc9KVTTeFzjJJJrGj605pRxoOAWMwpMWn1w@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a1143da624e396d0527d0de34
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>, nbvfour@gmail.com
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
Precedence: list

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

The hashpower is a function of the block reward (subsidy + fees): it's
economically irrational to have costs greater than the reward (better just
turn off your miners) and in a perfect competition (a theoretical model)
profits tend to zero. That is, the costs tend to equal revenue (block
reward).
On Dec 26, 2015 6:38 PM, "Eric Lombrozo" <elombrozo@gmail.com> wrote:

> For simplicity, assume total network hashpower is constant. Also, assume
> the soft fork activates at the beginning of a retarget period.
>
> At the moment the soft fork activates, the effective difficulty is
> increased (by adding a second independent PoW check that must also be
> satisfied) which means more hashes on average (and proportionally more
> time) are required to find a block. At the end of the retarget period, th=
e
> difficulty is lowered so that if the second PoW difficulty were to be kep=
t
> constant the block interval would again average 10 mins.
>
> If we were to keep the second PoW difficulty constant, we would restore
> the same total PoW-to-time-unit ratio and the retarget difficulty would
> stabilize again so each block would once more require the same number of
> hashes (and same amount of time) on average as before.
>
> But we don't keep the second PoW difficulty constant - we increase it so
> once again more hashes on average are required to find a block by the sam=
e
> proportion as before. And we keep doing this.
>
> Now, the assumption that hashpower is constant is obviously unrealistic.
> If this is your bone of contention, then yes, I agree my model is overly
> simplistic.
>
> My larger point was to explore the extent of what's possible with only a
> soft fork - and we can actually go pretty far and even compensate for the=
se
> economic shifts by increasing block size and rewards. The whole thing is
> clearly a huge mess - and I wouldn't recommend actually doing it.
>
>
>
> On December 26, 2015 7:33:53 AM PST, "Jorge Tim=C3=B3n" <jtimon@jtimon.cc=
>
> wrote:
>>
>>
>> On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> > Unfortunately, this also means longer confirmation times, lower
>> throughput, and lower miner revenue. Note, however, that confirmations
>> would (on average) represent more PoW, so fewer confirmations would be
>> required to achieve the same level of security.
>> >
>>
>> I'm not sure I understand this. If mining revenue per unit of time drops=
,
>> total pow per unit of time should also drop. Even if the inter-block tim=
e
>> is increased, it's not clear to me that the pow per block would necessar=
ily
>> be higher.
>> What am I missing?
>>
>

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

<p dir=3D"ltr">The hashpower is a function of the block reward (subsidy + f=
ees): it&#39;s economically irrational to have costs greater than the rewar=
d (better just turn off your miners) and in a perfect competition (a theore=
tical model) profits tend to zero. That is, the costs tend to equal revenue=
 (block reward).<br>
</p>
<div class=3D"gmail_quote">On Dec 26, 2015 6:38 PM, &quot;Eric Lombrozo&quo=
t; &lt;<a href=3D"mailto:elombrozo@gmail.com">elombrozo@gmail.com</a>&gt; w=
rote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>For simpl=
icity, assume total network hashpower is constant. Also, assume the soft fo=
rk activates at the beginning of a retarget period.<br>
<br>
At the moment the soft fork activates, the effective difficulty is increase=
d (by adding a second independent PoW check that must also be satisfied) wh=
ich means more hashes on average (and proportionally more time) are require=
d to find a block. At the end of the retarget period,  the difficulty is lo=
wered so that if the second PoW difficulty were to be kept constant the blo=
ck interval would again average 10 mins.<br>
<br>
If we were to keep the second PoW difficulty constant, we would restore the=
 same total PoW-to-time-unit ratio and the retarget difficulty would stabil=
ize again so each block would once more require the same number of hashes (=
and same amount of time) on average as before.<br>
<br>
But we don&#39;t keep the second PoW difficulty constant - we increase it s=
o once again more hashes on average are required to find a block by the sam=
e proportion as before. And we keep doing this.<br>
<br>
Now, the assumption that hashpower is constant is obviously unrealistic. If=
 this is your bone of contention, then yes, I agree my model is overly simp=
listic.<br>
<br>
My larger point was to explore the extent of what&#39;s possible with only =
a soft fork - and we can actually go pretty far and even compensate for the=
se economic shifts by increasing block size and rewards. The whole thing is=
 clearly a huge mess - and I wouldn&#39;t recommend actually doing it.<br>
<br>
<br><br><div class=3D"gmail_quote">On December 26, 2015 7:33:53 AM PST, &qu=
ot;Jorge Tim=C3=B3n&quot; &lt;jtimon@jtimon.cc&gt; wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<p dir=3D"ltr"><br>
On Dec 26, 2015 9:24 AM, &quot;Eric Lombrozo via bitcoin-dev&quot; &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
 =C2=A0<br>
&gt; Unfortunately, this also means longer confirmation times, lower throug=
hput, and lower miner revenue. Note, however, that confirmations would (on =
average) represent more PoW, so fewer confirmations would be required to ac=
hieve the same level of security.<br>
&gt; =C2=A0</p>
<p dir=3D"ltr">I&#39;m not sure I understand this. If mining revenue per un=
it of time drops, total pow per unit of time should also drop. Even if the =
inter-block time is increased, it&#39;s not clear to me that the pow per bl=
ock would necessarily be higher.<br>
What am I missing?<br>
</p>
</blockquote></div></div></blockquote></div>

--001a1143da624e396d0527d0de34--