[Bitcoin-development] we can all relax now

[E willbefull]

I've created a simulation framework called simbit to simulate the selfish
mining attack, though it is general enough to simulate any p2p network. I
even put together a rough simulation of MinCen. The goal is to be fun/easy
to rapidly prototype protocols and strategies, and visualize them. It's
written in javascript, so it can be demoed in the web browser or run on
Node.

It's still in early alpha and a lot of things are missing.

https://github.com/ebfull/simbit

https://bitcointalk.org/index.php?topic=603171.0

Feedback is appreciated!


On Tue, Nov 5, 2013 at 10:33 PM, kjj <bitcoin-devel at 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140510/70b79ae9/attachment.html>