Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com
	designates 209.85.216.52 as permitted sender)
	client-ip=209.85.216.52; envelope-from=mike@coinlab.com;
	helo=mail-qa0-f52.google.com; 
MIME-Version: 1.0
In-Reply-To: <201206042105.27064.luke@dashjr.org>
References: <201206030052.17128.luke@dashjr.org>
	<201206040204.57503.luke@dashjr.org>
	<CAErK2CjpSb=Rb+evWg+_fs0brBfTDe3_HM1z-an0picb_8tzpQ@mail.gmail.com>
	<201206042105.27064.luke@dashjr.org>
Date: Mon, 4 Jun 2012 17:00:25 -0700
Message-ID: <CAErK2Cj8hciP2FNtmvCf726gEWdFjO6=W5j4yTCrEYKFtXMKPA@mail.gmail.com>
From: Mike Koss <mike@coinlab.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=20cf3074b3ec793ff504c1ae560a
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Defeating the block withholding attack
Precedence: list

--20cf3074b3ec793ff504c1ae560a
Content-Type: text/plain; charset=ISO-8859-1

I don't understand how your proposal will work for decentralized pools -
can you explain it more concretely?

What would the new block header look like?

What is required for a share to to be earned?

What is required for a block to be valid (added to Block Chain)?

I don't think I understand what you mean by NextBlockCandidate.  Perhaps a
concrete example using difficulty 1.7 million would be instructive.

On Mon, Jun 4, 2012 at 2:05 PM, Luke-Jr <luke@dashjr.org> wrote:

> On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote:
> > As I understand the attack, the attacker gets compensated for the shares
> > they earn, but the pool will be denied any valid blocks found.  The
> > attacker DOES NOT have access to the Bitcoins earned in the unreported
> > block (only the mining pool has access to the Coinbase address and
> > transactions in the block).
>
> With decentralized pools, the attacker does have access to the block, and
> can
> potentially submit it to the Bitcoin network directly bypassing the pool
> if it
> benefits them to do so.
>
> > So it's a zero-net-cost attack for the attacker (but no chance of making
> a
> > profit) to hurt the pool operator.
>
> Because of the above, there is a possibility an attacker can make a profit.
>
> > The only way to detect such an attack now is to look for "unlucky"
> miners;
> > at the current difficulty, you can't detect this cheat until many
> millions
> > of shares have been earned w/o a qualifying block.  Since an attacker can
> > also create many fake identities, they can avoid detection indefinitely
> by
> > abandoning each account after a million earned shares.
>
> There are other modes of detection, but nobody has bothered to implement
> them
> since attackers can easily do a simple workaround in an arms race.
>
> > I don't understand your proposal for fixing this.  You would have to come
> > up with a scheme where:
> >
> > - The miner can detect a qualifying hash to earn a share.
> > - Not be able to tell if the hash is for a valid block.
>
> With my proposal, miners can find shares, but won't know if it's a valid
> block
> until the subsequent block is also found (that subsequent block might not
> end
> up being a real block in the big picture).
>
> > The way I would do this is to have a secret part (not shared with the
> > miners) of a block that is part of the merkle hash, which is also used
> in a
> > secondary hash.  Difficulty is then divide into two parts: the first,
> > solved by the miner (earning a "share" - e.g., 1 in 4 Billion hashes).
>  And
> > a second, solved by the pool (1 in Difficulty shares).  A valid block
> would
> > have to exhibit a valid Share Hash AND a valid Pool Hash in order to be
> > accepted.
>
> This only works for centralized pools, which are contrary to the health of
> the
> Bitcoin network. Decentralized pools cannot have a secret.
>


-- 
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)

A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.

--20cf3074b3ec793ff504c1ae560a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I don&#39;t understand how your proposal will work for decentralized pools =
- can you explain it more concretely?<div><br></div><div>What would the new=
 block header look like?</div><div><br></div><div>What is required for a sh=
are to to be earned?</div>
<div><br></div><div>What is required for a block to be valid (added to Bloc=
k Chain)?</div><div><br></div><div>I don&#39;t think I understand what you =
mean by NextBlockCandidate. =A0Perhaps a concrete example using difficulty =
1.7 million would be instructive.</div>
<div><br><div class=3D"gmail_quote">On Mon, Jun 4, 2012 at 2:05 PM, Luke-Jr=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:luke@dashjr.org" target=3D"_blank"=
>luke@dashjr.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 class=3D"im">On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote:<br>
&gt; As I understand the attack, the attacker gets compensated for the shar=
es<br>
&gt; they earn, but the pool will be denied any valid blocks found. =A0The<=
br>
&gt; attacker DOES NOT have access to the Bitcoins earned in the unreported=
<br>
&gt; block (only the mining pool has access to the Coinbase address and<br>
&gt; transactions in the block).<br>
<br>
</div>With decentralized pools, the attacker does have access to the block,=
 and can<br>
potentially submit it to the Bitcoin network directly bypassing the pool if=
 it<br>
benefits them to do so.<br>
<div class=3D"im"><br>
&gt; So it&#39;s a zero-net-cost attack for the attacker (but no chance of =
making a<br>
&gt; profit) to hurt the pool operator.<br>
<br>
</div>Because of the above, there is a possibility an attacker can make a p=
rofit.<br>
<div class=3D"im"><br>
&gt; The only way to detect such an attack now is to look for &quot;unlucky=
&quot; miners;<br>
&gt; at the current difficulty, you can&#39;t detect this cheat until many =
millions<br>
&gt; of shares have been earned w/o a qualifying block. =A0Since an attacke=
r can<br>
&gt; also create many fake identities, they can avoid detection indefinitel=
y by<br>
&gt; abandoning each account after a million earned shares.<br>
<br>
</div>There are other modes of detection, but nobody has bothered to implem=
ent them<br>
since attackers can easily do a simple workaround in an arms race.<br>
<div class=3D"im"><br>
&gt; I don&#39;t understand your proposal for fixing this. =A0You would hav=
e to come<br>
&gt; up with a scheme where:<br>
&gt;<br>
&gt; - The miner can detect a qualifying hash to earn a share.<br>
&gt; - Not be able to tell if the hash is for a valid block.<br>
<br>
</div>With my proposal, miners can find shares, but won&#39;t know if it=
9;s a valid block<br>
until the subsequent block is also found (that subsequent block might not e=
nd<br>
up being a real block in the big picture).<br>
<div class=3D"im"><br>
&gt; The way I would do this is to have a secret part (not shared with the<=
br>
&gt; miners) of a block that is part of the merkle hash, which is also used=
 in a<br>
&gt; secondary hash. =A0Difficulty is then divide into two parts: the first=
,<br>
&gt; solved by the miner (earning a &quot;share&quot; - e.g., 1 in 4 Billio=
n hashes). =A0And<br>
&gt; a second, solved by the pool (1 in Difficulty shares). =A0A valid bloc=
k would<br>
&gt; have to exhibit a valid Share Hash AND a valid Pool Hash in order to b=
e<br>
&gt; accepted.<br>
<br>
</div>This only works for centralized pools, which are contrary to the heal=
th of the<br>
Bitcoin network. Decentralized pools cannot have a secret.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Mike Koss<di=
v>CTO, CoinLab</div><div>(425) 246-7701 (m)</div><div><br></div><div><a hre=
f=3D"http://coinlab.com/a-bitcoin-primer.pdf" target=3D"_blank">A Bitcoin P=
rimer</a>=A0- What you need to know about Bitcoins.</div>
<br>
</div>

--20cf3074b3ec793ff504c1ae560a--