@NickSzabo4 h/t @petertoddbtc for link to Pieter Wuille's sim.
Good simulation of 20 MB block size: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08161.html … cf. observed bandwidth: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08010.html …pic.twitter.com/77qfAGGbAC
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Attackers can intentionally delay large blocks, creating havoc w/much less than 51% mining power: http://eprint.iacr.org/2015/578.pdf (h/t
@Nightwolf42) -
@NickSzabo4@Nightwolf42 ... but they could intentionally delay small blocks, too, causing exactly the same havoc. -
@gavinandresen@Nightwolf42 No. The larger the block size, the easier it is to hide the attack among the natural variation of bandwidth. -
@gavinandresen@Nightwolf42 + paper demonstrates that scalability optimizations have already introduced new security holes. -
@NickSzabo4@Nightwolf42 Easy to mitigate attacks described in that paper: run two (or eleven) nodes; big miners/exchanges do that already. - 1 more reply
New conversation -
-
-
@alness@Nightwolf42 No, that makes the problem worse. Control of centralized custom n/w makes attacks far easier still.Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
@alness@Nightwolf42 What does that accomplish? They've still lost the race. -
@NickSzabo4@gavinandresen Maybe they just shouldn't mine...
End of conversation
New conversation -
-
-
@pierebel@NickSzabo4 Haven't you heard? we've abandoned the BIP process in favor of willy-nillyness ;)Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.