[148049] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] Bitcoin attack

daemon@ATHENA.MIT.EDU (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_l)
Wed Nov 6 14:01:02 2013

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAJu0RDxu9=MQZZOC5g1L7wxhSrSqN=k4+CrVvgX9tLKXce=dSQ@mail.gmail.com>
From: =?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?= <l@odewijk.nl>
Date: Wed, 6 Nov 2013 16:25:48 +0100
To: Marcel Popescu <mdpopescu@gmail.com>
Cc: cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

--===============8520678286440536105==
Content-Type: multipart/alternative; boundary=001a11c33676b6b4ad04ea83c491

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

2013/11/5 Marcel Popescu <mdpopescu@gmail.com>

> Have you guys seen this? http://arxiv.org/abs/1311.0243
>
> I'm a layman in the field, I have no clue on how to analyze it. I'm just
> bringing it up in case anyone else here cares about the subject.
>

It seems pretty correct to me. Although I find it very hard to believe in
the light of the vested 50% minimum attack speed.

The "of any size" claim is definitely too strong and they admit it
themselves. If you mine too slowly you're wasting so many blocks to attempt
to get to 2 blocks ahead the costs outweigh the benefits. It seems though
that the balance point may be around 1/4th of the network. And that anyone
higher than could profit greatly from this technique. I can't quite pierce
through their verbosity and see if they made mistakes in obtaining their
1/4th number.

Their algorithm is rather hard to read. Why code against the previous
difference and not the current difference? Weird. In fact the whole thing
qualifies for "hard to read" if you ask me.

I'm not sure if this exploit is a big problem. 1/4th is still "good
enough". Seriously worse than 50% though. Picking a random current block
does make the network less effective in mining overall as more work will be
spend on mining not-the-first-block. That implies that you'll be worse off
too, but I'm not 100% on that. I can see collaborations between pools (to
prefer each others' blocks) to be very profitable too. And not solvable at
all.

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

<div dir=3D"ltr">2013/11/5 Marcel Popescu <span dir=3D"ltr">&lt;<a href=3D"=
mailto:mdpopescu@gmail.com" target=3D"_blank">mdpopescu@gmail.com</a>&gt;</=
span><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><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 style=3D"font-family:georgia,serif">Have you guys see=
n this?=C2=A0<a href=3D"http://arxiv.org/abs/1311.0243" style=3D"font-famil=
y:arial" target=3D"_blank">http://arxiv.org/abs/1311.0243</a></div><div sty=
le=3D"font-family:georgia,serif">



<br></div><div style=3D"font-family:georgia,serif">I&#39;m a layman in the =
field, I have no clue on how to analyze it. I&#39;m just bringing it up in =
case anyone else here cares about the subject.</div></div></blockquote><div=
>

<br></div><div>It seems pretty correct to me. Although I find it very hard =
to believe in the light of the vested 50% minimum attack speed.</div><div><=
br></div><div>The &quot;of any size&quot; claim is definitely too strong an=
d they admit it themselves. If you mine too slowly you&#39;re wasting so ma=
ny blocks to attempt to get to 2 blocks ahead the costs outweigh the benefi=
ts. It seems though that the balance point may be around 1/4th of the netwo=
rk. And that anyone higher than could profit greatly from this technique. I=
 can&#39;t quite pierce through their verbosity and see if they made mistak=
es in obtaining their 1/4th number.</div>

<div><br></div><div>Their algorithm is rather hard to read. Why code agains=
t the previous difference and not the current difference? Weird. In fact th=
e whole thing qualifies for &quot;hard to read&quot; if you ask me.</div>

<div><br></div><div>I&#39;m not sure if this exploit is a big problem. 1/4t=
h is still &quot;good enough&quot;. Seriously worse than 50% though. Pickin=
g a random current block does make the network less effective in mining ove=
rall as more work will be spend on mining not-the-first-block. That implies=
 that you&#39;ll be worse off too, but I&#39;m not 100% on that. I can see =
collaborations between pools (to prefer each others&#39; blocks) to be very=
 profitable too. And not solvable at all.</div>

</div></div></div>

--001a11c33676b6b4ad04ea83c491--

--===============8520678286440536105==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============8520678286440536105==--

home help back first fref pref prev next nref lref last post