Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <melvincarvalho@gmail.com>) id 1Ve7ft-0001Sd-Ss
	for Bitcoin-development@lists.sourceforge.net;
	Wed, 06 Nov 2013 18:17:53 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.179 as permitted sender)
	client-ip=209.85.223.179; envelope-from=melvincarvalho@gmail.com;
	helo=mail-ie0-f179.google.com; 
Received: from mail-ie0-f179.google.com ([209.85.223.179])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Ve7fs-0007Mf-KK
	for Bitcoin-development@lists.sourceforge.net;
	Wed, 06 Nov 2013 18:17:53 +0000
Received: by mail-ie0-f179.google.com with SMTP id aq17so18565895iec.10
	for <Bitcoin-development@lists.sourceforge.net>;
	Wed, 06 Nov 2013 10:17:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.178.202 with SMTP id da10mr3490880igc.44.1383761867113;
	Wed, 06 Nov 2013 10:17:47 -0800 (PST)
Received: by 10.64.17.167 with HTTP; Wed, 6 Nov 2013 10:17:46 -0800 (PST)
In-Reply-To: <5279D49D.5050807@jerviss.org>
References: <5279D49D.5050807@jerviss.org>
Date: Wed, 6 Nov 2013 19:17:46 +0100
Message-ID: <CAKaEYhLpr24+7B0w410S7XdGgyOU4vsv07uv2e6yvYNKV8ZQJQ@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: kjj <bitcoin-devel@jerviss.org>
Content-Type: multipart/alternative; boundary=089e015386f08b565f04ea862a1b
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: doubleclick.net]
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(melvincarvalho[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Ve7fs-0007Mf-KK
Cc: Bitcoin Dev <Bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] we can all relax now
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2013 18:17:54 -0000

--089e015386f08b565f04ea862a1b
Content-Type: text/plain; charset=ISO-8859-1

On 6 November 2013 06:33, kjj <bitcoin-devel@jerviss.org> wrote:

> One of the things that really gets me going is when someone devises a
> model, tests it against itself, and then pretends that they've learned
> something about the real world.
>
> Naturally, the Selfish Mining paper is exactly this sort of nonsense.
> Their model is one with no latency, and one where the attacker has total
> visibility across the network.  An iterated FSM is not a suitable
> simulation of the bitcoin system.  The bitcoin network does not have
> states, and to the extent that you can pretend that we do, you can't
> simulate transitions between them with static probabilities.
>
> The authors understand this deep down inside, even though they didn't
> work out the implications.  They handwave the issue by assuming a total
> sybil attack, and in true academic spirit, they don't realize that the
> condition necessary for the attack is far, far worse than the attack
> itself.
>
> Greg said he'd like to run some simulations, and I'm thinking about it
> too.  Unfortunately, he is busy all week, and I'm lazy (and also busy
> for most of tomorrow).
>
> If neither of us get to it first, I'm willing to pitch in 1 BTC as a
> bounty for building a general bitcoin network simulator framework. The
> simulator should be able to account for latency between nodes, and
> ideally within a node.  It needs to be able to simulate an attacker that
> owns varying fractions of the network, and make decisions based only on
> what the attacker actually knows.  It needs to be able to simulate this
> "attack" and should be generic enough to be easily modified for other
> crazy schemes.
>
> (Bounty offer is serious, but expires in one year [based on the earliest
> timestamp that my mail server puts on this email], and /may/ be subject
> to change if the price on any reputable exchange breaks 1000 USD per BTC
> in that period.)
>
> Basically, the lack of a decent network simulator is what allowed this
> paper to get press.  If the author had been able to see the importance
> of the stuff he was ignoring, we wouldn't be wasting so much time
> correcting him (and sadly the reporters that have no way to check his
> claims).
>
> https://bitcointalk.org/index.php?topic=324413.msg3495663#msg3495663
>

Thanks for posting this bounty.  I'm interested in working on it, and will
give it a try.  I also have some other commitments, so I suspect you guys
will finish it first tho... but if not, I'll post details of the simulator.


>
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 6 November 2013 06:33, kjj <span dir=3D"ltr">&lt;<a href=3D"mail=
to:bitcoin-devel@jerviss.org" target=3D"_blank">bitcoin-devel@jerviss.org</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">One of the things that really gets me going =
is when someone devises a<br>
model, tests it against itself, and then pretends that they&#39;ve learned<=
br>
something about the real world.<br>
<br>
Naturally, the Selfish Mining paper is exactly this sort of nonsense.<br>
Their model is one with no latency, and one where the attacker has total<br=
>
visibility across the network. =A0An iterated FSM is not a suitable<br>
simulation of the bitcoin system. =A0The bitcoin network does not have<br>
states, and to the extent that you can pretend that we do, you can&#39;t<br=
>
simulate transitions between them with static probabilities.<br>
<br>
The authors understand this deep down inside, even though they didn&#39;t<b=
r>
work out the implications. =A0They handwave the issue by assuming a total<b=
r>
sybil attack, and in true academic spirit, they don&#39;t realize that the<=
br>
condition necessary for the attack is far, far worse than the attack itself=
.<br>
<br>
Greg said he&#39;d like to run some simulations, and I&#39;m thinking about=
 it<br>
too. =A0Unfortunately, he is busy all week, and I&#39;m lazy (and also busy=
<br>
for most of tomorrow).<br>
<br>
If neither of us get to it first, I&#39;m willing to pitch in 1 BTC as a<br=
>
bounty for building a general bitcoin network simulator framework. The<br>
simulator should be able to account for latency between nodes, and<br>
ideally within a node. =A0It needs to be able to simulate an attacker that<=
br>
owns varying fractions of the network, and make decisions based only on<br>
what the attacker actually knows. =A0It needs to be able to simulate this<b=
r>
&quot;attack&quot; and should be generic enough to be easily modified for o=
ther<br>
crazy schemes.<br>
<br>
(Bounty offer is serious, but expires in one year [based on the earliest<br=
>
timestamp that my mail server puts on this email], and /may/ be subject<br>
to change if the price on any reputable exchange breaks 1000 USD per BTC<br=
>
in that period.)<br>
<br>
Basically, the lack of a decent network simulator is what allowed this<br>
paper to get press. =A0If the author had been able to see the importance<br=
>
of the stuff he was ignoring, we wouldn&#39;t be wasting so much time<br>
correcting him (and sadly the reporters that have no way to check his<br>
claims).<br>
<br>
<a href=3D"https://bitcointalk.org/index.php?topic=3D324413.msg3495663#msg3=
495663" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D324413.=
msg3495663#msg3495663</a><br></blockquote><div><br></div><div>Thanks for po=
sting this bounty.=A0 I&#39;m interested in working on it, and will give it=
 a try.=A0 I also have some other commitments, so I suspect you guys will f=
inish it first tho... but if not, I&#39;ll post details of the simulator.<b=
r>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
November Webinars for C, C++, Fortran Developers<br>
Accelerate application performance with scalable programming models. Explor=
e<br>
techniques for threading, error checking, porting, and tuning. Get the most=
<br>
from the latest Intel processors and coprocessors. See abstracts and regist=
er<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60136231&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60136231&amp;iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div>

--089e015386f08b565f04ea862a1b--