public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: kjj <bitcoin-devel@jerviss.org>
Cc: Bitcoin Dev <Bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] we can all relax now
Date: Wed, 6 Nov 2013 19:17:46 +0100	[thread overview]
Message-ID: <CAKaEYhLpr24+7B0w410S7XdGgyOU4vsv07uv2e6yvYNKV8ZQJQ@mail.gmail.com> (raw)
In-Reply-To: <5279D49D.5050807@jerviss.org>

[-- Attachment #1: Type: text/plain, Size: 3172 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4224 bytes --]

  parent reply	other threads:[~2013-11-06 18:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06  5:33 [Bitcoin-development] we can all relax now kjj
2013-11-06  9:26 ` Frank F
2013-11-06 11:35 ` Jeff Garzik
2013-11-06 18:06   ` Christophe Biocca
2013-11-07  3:44     ` Peter Todd
2013-11-07  4:15       ` Kyle Jerviss
2013-11-07  4:33         ` Peter Todd
2013-11-07  4:59           ` Kyle Jerviss
2013-11-07 13:09             ` Peter Todd
2013-11-07  4:56       ` Gavin Andresen
2013-11-07 13:24         ` Peter Todd
2013-11-07 16:14           ` Mike Hearn
2013-11-07 18:28             ` Daniel Lidstrom
2013-11-08 19:49               ` Andreas M. Antonopoulos
2013-11-08 20:33                 ` Gregory Maxwell
2013-11-15 10:58               ` Peter Todd
2013-11-07  8:07       ` Jannes Faber
2013-11-07  5:24     ` Kyle Jerviss
2013-11-06 18:17 ` Melvin Carvalho [this message]
2013-11-06 22:19 ` Jouke Hofman
2014-05-10 11:05 ` E willbefull

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKaEYhLpr24+7B0w410S7XdGgyOU4vsv07uv2e6yvYNKV8ZQJQ@mail.gmail.com \
    --to=melvincarvalho@gmail.com \
    --cc=Bitcoin-development@lists.sourceforge.net \
    --cc=bitcoin-devel@jerviss.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox