MIME-Version: 1.0
In-Reply-To: <CAGLBAhdqKLgK09s5Mp6C4nv0k4hHBYM5c8NpgP5G7J110NseqQ@mail.gmail.com>
References: <20151219184240.GB12893@muck>
	<CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com>
	<4882BD35-D890-4860-9222-5C23AEB6AE89@mattcorallo.com>
	<CAAcC9yspsPs3gbumS4rTOg-P-=V=tycn2Z1nVPGGHwJ-nP+PBg@mail.gmail.com>
	<20151220044450.GA23942@muck>
	<CAP3QyGJD3SaM6Bvvw66jAvVFkQhrfJfRQTxbbe8a=O1zK_P6tw@mail.gmail.com>
	<20151228191228.GC12298@muck>
	<CAAre=ySPjm+cyLdBY_CZkLdfXE3OFYgECEUq05AyWfY0q1KuTQ@mail.gmail.com>
	<CAGLBAhdqKLgK09s5Mp6C4nv0k4hHBYM5c8NpgP5G7J110NseqQ@mail.gmail.com>
Date: Tue, 29 Dec 2015 13:25:17 -0600
Message-ID: <CAJfRnm6akNXAQkXtPNu_bVFA7uuDUmeQ6L9oONq06Jo7r=wMmA@mail.gmail.com>
From: Allen Piscitello <allen.piscitello@gmail.com>
To: Dave Scotese <dscotese@litmocracy.com>
Content-Type: multipart/alternative; boundary=001a113ad09ebde2df05280e6194
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
Precedence: list

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

How could this possibly be enforced?

On Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There have been no decent objections to altering the block-selection
> mechanism (when two block solutions appear at nearly the same time) as
> described at
>
> http://bitcoin.stackexchange.com/questions/39226
>
> Key components are:
>
>    - Compute BitcoinDaysDestroyed using only transactions that have been
>    in your mempool for some time as oBTCDD ("old BTCDD").
>    - Use "nearly the same time" to mean separated in time by your guess
>    of the average duration of block propagation times.
>    - When two block solutions come in at nearly the same time, build on
>    the one that has the most oBTCDD, rather than the one that came in first.
>
> The goal of this change is to reduce the profitability of withholding
> block solutions by severely reducing the chances that a block solved a
> while ago can orphan one solved recently.  "Came in first" seems more
> easily gamed than "most oBTCDD".  As I wrote there, "*old coins* is
> always a dwindling resource and *global nodes willing to help cheat* is
> probably a growing one."
>
> I will write a BIP if anyone agrees it's a good idea.
>
> On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> Far more concerning is network propagation effects between large and
>>> small miners. For that class of issues, if you are in an environemnt
>>> where selfish mining is possible - a fairly flat, easily DoS/sybil
>>> attacked network topology - the profitability difference between small
>>> and large miners even *without* attacks going on is a hugely worrying
>>> problem. OTOH, if you're blocksize is small enough that propagation time
>>> is negligable to profitability, then selfish mining attacks with <30%
>>> hashing power aren't much of a concern - they'll be naturally defeated
>>> by anti-DoS/anti-sybil measures.
>>>
>>
>> Let's agree that one factor in mining profitability is bandwidth/network
>> reliability/stability. Why focus on that vs electricity contracts or
>> vertically integrated chip manufacturers? Surely, sufficient network
>> bandwidth is a more broadly available commodity than <$0.02/kwh
>> electricity, for example. I'm not sure that your stranded hydroelectric
>> miner is any more desirable than thousands of dorm room miners with access
>> to 10gbit university connections and free electricity.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">How could this possibly be enforced?</div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Tue, Dec 29, 2015 at 12:59 PM,=
 Dave Scotese via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div>There have been no decent objections to altering the bloc=
k-selection mechanism (when two block solutions appear at nearly the same t=
ime) as described at <br><br><a href=3D"http://bitcoin.stackexchange.com/qu=
estions/39226" target=3D"_blank">http://bitcoin.stackexchange.com/questions=
/39226</a><br><br></div>Key components are:<br><ul><li>Compute BitcoinDaysD=
estroyed using only transactions that have been in your mempool for some ti=
me as oBTCDD (&quot;old BTCDD&quot;).</li><li>Use &quot;nearly the same tim=
e&quot; to mean separated in time by your guess of the average duration of =
block propagation times.<br></li><li>When two block solutions come in at ne=
arly the same time, build on the one that has the most oBTCDD, rather than =
the one that came in first.</li></ul><p>The goal of this change is to reduc=
e the profitability of withholding block solutions by severely reducing the=
 chances that a block solved a while ago can orphan one solved recently.=C2=
=A0 &quot;Came in first&quot; seems more easily gamed than &quot;most oBTCD=
D&quot;.=C2=A0 As I wrote there, &quot;<em>old coins</em> is always a dwind=
ling resource and <em>global nodes willing to help cheat</em> is probably a=
 growing one.&quot;<br></p><p>I will write a BIP if anyone agrees it&#39;s =
a good idea.<br></p></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote"><div><div class=3D"h5">On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brig=
htly via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div><div class=3D"h5"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex">On Mon, Dec 28, 2015 at 2:12 PM, P=
eter Todd via bitcoin-dev=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt;</span>=C2=A0wrote:<br>
Far more concerning is network propagation effects between large and<br>
small miners. For that class of issues, if you are in an environemnt<br>
where selfish mining is possible - a fairly flat, easily DoS/sybil<br>
attacked network topology - the profitability difference between small<br>
and large miners even *without* attacks going on is a hugely worrying<br>
problem. OTOH, if you&#39;re blocksize is small enough that propagation tim=
e<br>
is negligable to profitability, then selfish mining attacks with &lt;30%<br=
>
hashing power aren&#39;t much of a concern - they&#39;ll be naturally defea=
ted<br>
by anti-DoS/anti-sybil measures.<br></blockquote><div><br></div></span><div=
>Let&#39;s agree that one factor in mining profitability is bandwidth/netwo=
rk reliability/stability. Why focus on that vs electricity contracts or ver=
tically integrated chip manufacturers? Surely, sufficient network bandwidth=
 is a more broadly available commodity than &lt;$0.02/kwh electricity, for =
example. I&#39;m not sure that your stranded hydroelectric miner is any mor=
e desirable than thousands of dorm room miners with access to 10gbit univer=
sity connections and free electricity.</div></div></div></div>
<br></div></div><span class=3D"">__________________________________________=
_____<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>
<br></span></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888888=
"><br><br clear=3D"all"><br>-- <br><div><div dir=3D"ltr">I like to provide =
some work at no charge to prove my value. Do you need a techie?=C2=A0 <br>I=
 own <a href=3D"http://www.litmocracy.com" target=3D"_blank">Litmocracy</a>=
 and <a href=3D"http://www.memeracing.net" target=3D"_blank">Meme Racing</a=
> (in alpha). <br>I&#39;m the webmaster for <a href=3D"http://www.voluntary=
ist.com" target=3D"_blank">The Voluntaryist</a> which now accepts Bitcoin.<=
br>I also code for <a href=3D"http://dollarvigilante.com/" target=3D"_blank=
">The Dollar Vigilante</a>.<br>&quot;He ought to find it more profitable to=
 play by the rules&quot; - Satoshi Nakamoto</div></div>
</font></span></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>
<br></blockquote></div><br></div>

--001a113ad09ebde2df05280e6194--