path: root/81/18328bc9a016e7a0c91f24ed73d29f3292d944

Return-Path: <admin@multipool.us>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 804F111BB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Dec 2015 19:33:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com
	[209.85.214.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5E2B9171
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Dec 2015 19:33:12 +0000 (UTC)
Received: by mail-ob0-f172.google.com with SMTP id bx1so120979831obb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 28 Dec 2015 11:33:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=multipool-us.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Gp+o9RlUAmgovNmCXl122PNMrtRAx9bL/IukXEKyjkI=;
	b=cHZ723cfYh0DgAWCv+2dGdXwEHrP9IBqMA0s6UeIm7JLX6qmfuhmGMlqBqJnH55m9q
	Obhycw3E06+gJL4t/fsavpEL0S/3fKctkn2jHCKyx4zp6q4j05WL0U3GntMm9IdvIbLk
	hbi3VUoKFFwSETwbkNTw/6VSHL0kQ7ACOLeGaaESG+ZnkFIbIq9PD/ke+3+nMTOpyQ7/
	tViNgsHhnWWf3Jy/P2tHn2W0zUFjw0VpUz7ElNrwpy+H7Y7akb+ze8TDdQbeDh9QeDM0
	cjmUUVTZ4OcmKjYmG7PsqjT/nN/NcWD1DC+oykTPfW3ahLMO+qcTVG+R8TZwvYr2TXFx
	kxGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Gp+o9RlUAmgovNmCXl122PNMrtRAx9bL/IukXEKyjkI=;
	b=UiSm8yZUAI6kis4S0tVkyYp+Y16cRnfWCcGiOqSNefmhfnYjSVrgkogt/JILmxfvT1
	i4ncRFkp9erPS724VLKH1gTn5mUaz+32ejQziup2XdqwvZLfZab0eItVe+rdDgtOFOeT
	6/QVwrA56pCqcSfZ/FOG4X2oMbOqukJUYF/HlRlUZ6j1SjlIGF1CPldKC91WKNJEhz4S
	2G+EW+kjJJbAqBczoEqOd9L5hcdnp+EAlpZ6SYfh0mJ7OMIp+7OvVz9C2UhZ5vG82F/A
	ytZbhisLldYtPZ1bvquaM21MHeDIa24eymImW3muywqycVrm4VlcoXWMxmq+d6nhEz1s
	5z/w==
X-Gm-Message-State: ALoCoQnfC+zvQy4CBcPppk0sbYAO0EQ599acuWiN/tYUHq8LWucvHyzvf5mbZja+g3pVqsw26c45J6Zzn+h00IJvHVpbGROm4Q==
MIME-Version: 1.0
X-Received: by 10.60.159.198 with SMTP id xe6mr32585136oeb.64.1451331191668;
	Mon, 28 Dec 2015 11:33:11 -0800 (PST)
Received: by 10.182.200.166 with HTTP; Mon, 28 Dec 2015 11:33:11 -0800 (PST)
In-Reply-To: <20151228191228.GC12298@muck>
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>
Date: Mon, 28 Dec 2015 11:33:11 -0800
Message-ID: <CAP3QyG+D3HCiVAkty2wXPRJw+dwcmNGV2Gn0gEdX8DyExaNSQQ@mail.gmail.com>
From: Multipool Admin <admin@multipool.us>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7bd6aaec219c610527fa6056
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,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: Mon, 28 Dec 2015 19:33:13 -0000

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

On Mon, Dec 28, 2015 at 11:12 AM, Peter Todd <pete@petertodd.org> wrote:

> On Sat, Dec 26, 2015 at 12:12:13AM -0800, Multipool Admin wrote:
> > Any attempt to 'fix' this problem, would most likely require changes to
> all
> > mining software, why not just make mining more decentralized in general=
?
> >
> > For example, allow anyone to submit proofs of work to Bitcoind that are
> > some fraction of the network difficulty and receive payment for them if
> > they're valid.  This would also encourage the proliferation of full nod=
es
> > since anyone could solo mine again.  Then, the next coinbase transactio=
n
> > could be split among, say, the top 100 proofs of work.
>
> That's certainly be a good place to be, but the design of Bitcoin
> currently makes achieving that goal fundementally difficult.
>

Agreed, however I don't think it would be impossible or even really that
difficult, and would be a great way to increase decentralization while
simultaneously fixing other issues with mining.

Proofs of work would be valid if they're built on top of the current block
hash, and we could require (difficulty/N) proofs of work that are >=3D
(difficulty/N) to assemble a valid block.  Same as mining shares work.

The block assembler who finds the final diff/N 'share' could get a small
bonus as an incentive to complete the block as quickly as possible.  Or
alternatively, a checksum could be computed of all the current diff/N
shares in the mempool and that way only the final share would need to be
broadcasted to the entire network, and clients with the correct checksum
could assemble the block themselves without having to download the entire
block.  This would drastically decrease data usage on the network.

> Eligius already does their miner payouts like this.
> >
> > If you want to fix an issue with mining, fix the selfish mining issue
> first
> > as it's a much larger and more dangerous potential issue.
>
> Do you specifically mean selfish mining as defined in Emin G=C3=BCn
> Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant
> issue in a scenario - one malicious miner with >30% hashing power -
> where you're already very close to the margins anyway; the difference
> between a 50% attack threshold and a 30% attack threshold isn't very
> significant.
>

Yes, that's what I'm talking about.


> 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.
>

The possibility that a previously 'good' actor with 30% of the hashpower
going 'rogue' becomes more and more of a concern as the block subsidy
decreases.


> > I don't believe it was ever clearly established whether Eligius suffere=
d
> a
> > block withholding attack or was just the victim of a miner with (what
> was,
> > at the time) a large amount of faulty hardware, however, from the
> > Bitcointalk threads at the time I believe it was assumed to be the
> latter.
>
> I think the latter was assumed as well, although ruling out of the
> former is impossible.
>
> Note though that Eligius is *not* the only pool to have had problems
> with block withholding, though AFAIK Eligius is the only one who has
> gone on record so far. (as I said in my original post, I'm relaying
> information given to me under condition of confidentiality)
>

What is the incentive not to go on record about this?

--Adam

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Dec 28, 2015 at 11:12 AM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Sat, Dec 26=
, 2015 at 12:12:13AM -0800, Multipool Admin wrote:<br>
&gt; Any attempt to &#39;fix&#39; this problem, would most likely require c=
hanges to all<br>
&gt; mining software, why not just make mining more decentralized in genera=
l?<br>
&gt;<br>
&gt; For example, allow anyone to submit proofs of work to Bitcoind that ar=
e<br>
&gt; some fraction of the network difficulty and receive payment for them i=
f<br>
&gt; they&#39;re valid.=C2=A0 This would also encourage the proliferation o=
f full nodes<br>
&gt; since anyone could solo mine again.=C2=A0 Then, the next coinbase tran=
saction<br>
&gt; could be split among, say, the top 100 proofs of work.<br>
<br>
</span>That&#39;s certainly be a good place to be, but the design of Bitcoi=
n<br>
currently makes achieving that goal fundementally difficult.<br></blockquot=
e><div><br></div><div>Agreed, however I don&#39;t think it would be impossi=
ble or even really that difficult, and would be a great way to increase dec=
entralization while simultaneously fixing other issues with mining.</div><d=
iv><br></div><div>Proofs of work would be valid if they&#39;re built on top=
 of the current block hash, and we could require (difficulty/N) proofs of w=
ork that are &gt;=3D (difficulty/N) to assemble a valid block.=C2=A0 Same a=
s mining shares work.</div><div><br></div><div>The block assembler who find=
s the final diff/N &#39;share&#39; could get a small bonus as an incentive =
to complete the block as quickly as possible.=C2=A0 Or alternatively, a che=
cksum could be computed of all the current diff/N shares in the mempool and=
 that way only the final share would need to be broadcasted to the entire n=
etwork, and clients with the correct checksum could assemble the block them=
selves without having to download the entire block.=C2=A0 This would drasti=
cally decrease data usage on the network.</div><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><span class=3D"">&gt; Eligius already does their miner pa=
youts like this.<br>
&gt;<br>
&gt; If you want to fix an issue with mining, fix the selfish mining issue =
first<br>
&gt; as it&#39;s a much larger and more dangerous potential issue.<br>
<br>
</span>Do you specifically mean selfish mining as defined in Emin G=C3=BCn<=
br>
Sirer/Ittay Eyal&#39;s paper? Keep in mind that attack is only a significan=
t<br>
issue in a scenario - one malicious miner with &gt;30% hashing power -<br>
where you&#39;re already very close to the margins anyway; the difference<b=
r>
between a 50% attack threshold and a 30% attack threshold isn&#39;t very<br=
>
significant.<br></blockquote><div><br></div><div>Yes, that&#39;s what I&#39=
;m talking about.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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><div>The po=
ssibility that a previously &#39;good&#39; actor with 30% of the hashpower =
going &#39;rogue&#39; becomes more and more of a concern as the block subsi=
dy decreases.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">&gt; I don&#39;t believe it was ever clearly established whether E=
ligius suffered a<br>
&gt; block withholding attack or was just the victim of a miner with (what =
was,<br>
&gt; at the time) a large amount of faulty hardware, however, from the<br>
&gt; Bitcointalk threads at the time I believe it was assumed to be the lat=
ter.<br>
<br>
</span>I think the latter was assumed as well, although ruling out of the<b=
r>
former is impossible.<br>
<br>
Note though that Eligius is *not* the only pool to have had problems<br>
with block withholding, though AFAIK Eligius is the only one who has<br>
gone on record so far. (as I said in my original post, I&#39;m relaying<br>
information given to me under condition of confidentiality)<br></blockquote=
><div><br></div><div>What is the incentive not to go on record about this?<=
/div><div><br></div><div>--Adam</div></div></div></div>

--047d7bd6aaec219c610527fa6056--