Just read your whitepaper.  I am impressed by the guts, but not by your solution.

Maybe some of these issues have been discussed in this long, long thread, but:

- Your quorum is not a quorum when put in a tree!
-  Assuming that attackers are randomly distributed is nonsense (sorry).  The sybil attack is as old as time.
- Thus your binomal distribution calculations are simply wrong, because the assumptions are wrong (sybil attack).
- The whitepaper does not describe what the consensus tree looks like.  Judging from the calculations in section 10, it seems like it could be a binary tree.
- A honest party cannot prove dishonesty with a properly programmed attacker using a simulated storage and controlling the (attacked) random generator (section 10).
- The number of messages required to keep consensus is very high. 
- Did I mention sybil attacks?  There is no protection!
- Section 6, what the cost of fetching a block from another participant needs to be is completely wrong in the whitepaper.   It is off by 5 orders of magnitude! (by 100.000x!).  This p0wns the consensus protocol, or this will indeed be an incredibly expensive storage platform.
- You allow changing the voter set in the consensus protocol without having consensus it seems.
- The proof of storage algorithm is way too naive when much, better algorithms exist.
- Nothing in the protocol requires a node from EVER SERVING DATA!
- Who is going to "fine" misbehaving nodes?  The only thing you will see are invalid quorums where data is held hostage.

This is like a swiss cheese!  Who reviewed this?