path: root/1d/d52381b9ea260835b5583bbf403e9328e1a37a

Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8192B105E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Dec 2015 19:07:26 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A09FE120
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Dec 2015 19:07:25 +0000 (UTC)
Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197]
	(may be forged)) (authenticated bits=0)
	by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tBTJ7Lu7019628
	(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
	Tue, 29 Dec 2015 11:07:22 -0800
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: Jonathan Toomim <j@toom.im>
In-Reply-To: <CAGLBAhdqKLgK09s5Mp6C4nv0k4hHBYM5c8NpgP5G7J110NseqQ@mail.gmail.com>
Date: Tue, 29 Dec 2015 11:08:16 -0800
Message-Id: <386A5974-2368-4CA5-93BC-0DD7D5DA9D3D@toom.im>
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>
To: Dave Scotese <dscotese@litmocracy.com>
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVbiJx99LPgGGboCJQtZXKyFjBsYSdZrfEcSDbNeKV8Ytt2/ZDmZmBOZfAa0qiuGSVG9jaUIAffuwpzoHkUuQF/M
X-Sonic-ID: C;VGRxY1+u5RGeV/8vZz0oYQ== M;lAr0Y1+u5RGeV/8vZz0oYQ==
X-Sonic-Spam-Details: 3.8/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
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: Tue, 29 Dec 2015 19:07:26 -0000


--Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098"


--Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Ultimately, a self-interested miner will chose to build on the block =
that leaves the most transaction fees up for grabs. (This usually means =
the smallest block.) It's an interesting question whether the default =
behavior for Core should be the rational behavior (build on the =
"smallest" block in terms of fees) or some other supposedly altruistic =
behavior (most BTCDD). This also applies to the decision of the "same =
time" threshold -- a selfish miner will not care if the blocks arrived =
at about the same time or not.

I currently do not have a strong opinion on what that behavior should =
be, although if the blocksize limit were increased substantially, I may =
prefer the selfish behavior because it ends up also being fail-safe =
(punishes selfish mining using large blocks or fee-stealing attempts).


On Dec 29, 2015, at 10:59 AM, 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
>=20
> http://bitcoin.stackexchange.com/questions/39226
>=20
> 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."
>=20
> I will write a BIP if anyone agrees it's a good idea.
>=20
>=20
> 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.
>=20
> 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.
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
>=20
>=20
> --
> I like to provide some work at no charge to prove my value. Do you =
need a techie?
> I own Litmocracy and Meme Racing (in alpha).
> I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
> I also code for The Dollar Vigilante.
> "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


--Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>Ultimately, a self-interested miner will chose =
to build on the block that leaves the most transaction fees up for =
grabs. (This usually means the smallest block.) It's an interesting =
question whether the default behavior for Core should be the rational =
behavior (build on the "smallest" block in terms of fees) or some other =
supposedly altruistic behavior (most BTCDD). This also applies to the =
decision of the "same time" threshold -- a selfish miner will not care =
if the blocks arrived at about the same time or =
not.</div><div><br></div><div>I currently do not have a strong opinion =
on what that behavior should be, although if the blocksize limit were =
increased substantially, I may prefer the selfish behavior because it =
ends up also being fail-safe (punishes selfish mining using large blocks =
or fee-stealing attempts).</div><div><br></div><br><div><div>On Dec 29, =
2015, at 10:59 AM, Dave Scotese via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
dir=3D"ltr"><div>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 <br><br><a =
href=3D"http://bitcoin.stackexchange.com/questions/39226">http://bitcoin.s=
tackexchange.com/questions/39226</a><br><br></div>Key components =
are:<br><ul><li>Compute BitcoinDaysDestroyed using only transactions =
that have been in your mempool for some time as oBTCDD ("old =
BTCDD").</li><li>Use "nearly the same time" 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 nearly 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 reduce the =
profitability of withholding block solutions by severely reducing the =
chances that a block solved a while ago can orphan one solved =
recently.&nbsp; "Came in first" seems more easily gamed than "most =
oBTCDD".&nbsp; As I wrote there, "<em>old coins</em> is always a =
dwindling resource and <em>global nodes willing to help cheat</em> is =
probably a growing one."<br></p><p>I will write a BIP if anyone agrees =
it's a good idea.<br></p></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly =
via bitcoin-dev <span dir=3D"ltr">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">On Mon, Dec 28, 2015 at 2:12 PM, Peter =
Todd via bitcoin-dev&nbsp;<span dir=3D"ltr">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span>&nbs=
p;wrote:<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're blocksize is small enough that propagation =
time<br>
is negligable to profitability, then selfish mining attacks with =
&lt;30%<br>
hashing power aren't much of a concern - they'll be naturally =
defeated<br>
by anti-DoS/anti-sybil =
measures.<br></blockquote><div><br></div></span><div>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 &lt;$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.</div></div></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitco=
in-dev</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div =
class=3D"gmail_signature"><div dir=3D"ltr">I like to provide some work =
at no charge to prove my value. Do you need a techie?&nbsp; <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'm the webmaster for <a =
href=3D"http://www.voluntaryist.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>"He ought to find it more profitable to play by the =
rules" - Satoshi Nakamoto</div></div>
</div>
_______________________________________________<br>bitcoin-dev mailing =
list<br><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br>https://lists.linuxfoundation.org/mailman/listinf=
o/bitcoin-dev<br></blockquote></div><br></body></html>=

--Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098--

--Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJWgtohAAoJEIEuMk4MG0P1as0H/jb70xk0KQ/49VGzxO9S0WB5
Jb6mXlIhaiB9/VJCrPiUoSoI6pNxPuXl5j5oTtO8r8JoqLfqLRUAs7E2YIyH54Xj
UMu/1EuTdWTo1rZFhGBCWl/hR56XiRwbyKIrPWVPw9ntoA6EJoCjpjXfDJye419B
2Uel0UtXDxRgHQKjcYXmbspEu8/9qjBMtab/3Ds2TcxF7Ot37JNoSbLECyEtgo2H
6TjSp9dLwCWT42+aTHNKiPGaPgIE4V5QrXwsaRyWYt6uX410YEo+LyCthRyC/Vxq
pquw3gxQ4z0S4BkAj7GUkNSbKyp0oNtuX/O2GtHP1WOL7cQTwgueEfKiMjQ7kqs=
=rjfG
-----END PGP SIGNATURE-----

--Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42--