Typo: In BitShares X, the minting reward comes solely from newly minted coins... I don't believe that is what you meant to say.
Overall I would like to say this document represents significant thought and is much appreciated. The major concept which I liked was the division of fees into two classes: immediate and time delayed. This allows production of blocks when there are no transactions. My feeling on this point is that a successful network never has periods of no transactions. And something like BTS X which has bids and asks should have many more transactions than bitcoin. Therefore, this feature would have little long term benefit and much added complexity.
Reserve funds can be used for more than one purpose. It's not necessary to track the reserve as a separate account; rather you can view it as a ceiling on the printing press.
The reduction in hashing power to something that like 20 HPM based upon the output reference( trx_id +output index) would incentivize creating many small balances assuming the probability per satoshi was unchanged.
I had intended to include a section on why this objection doesn't matter, but I think it somehow got lost during editing. The hash stream is modulated by your balance. E.g. if you keep balance B in one address, B / k of your hashes pass (where k is much larger than B, depending on boost and network rate). If you keep balance B in n addresses, you produce n times as many hashes, but the probability that each hash passes is reduced to B / (kn). The two effects cancel; thus the small balance strategy doesn't give you an advantage or disadvantage with respect to minting speed (of course small balances suffer other penalties, e.g. doing anything with many small balances will probably involve large fees). But you got me thinking and I realized there's a different incentive to create many small balances; to fix it, I make the boost function constant. See the latest commit.
The goal is to have large balances sign off.
I have a feeling that the only reason you care about large balances is that the only *obvious* way to prove that N coins approve of the network state is to record signoffs from M individual coin holders who collectively hold N coins. Making sure M is small is the only way this approach can keep blockchain storage required under control.
My proposal is a *non-obvious* way to prove that N coins approve of the network state: Have each coin that approves produce a hash stream, and record the size of the smallest hash produced. You should then be able to use standard probability theory to say N exceeds a certain size with high confidence. The required blockchain storage is O(1) regardless of how many balances sign off. Thus the total security (in terms of number of coins that approve the current state) can be increased because all balances are now allowed to participate in signoff, not just large ones.
The risk of fraud / theft / incompetence will be enough to keep the size of mining pools under control. The rewards will be small enough that few will want to put their funds in such a pool.
The recent Mt. Gox situation gives me serious doubts about this assertion.
So long as the best block chose based upon total votes (CDD) an attacker will have limited nonce search space because every time a new transaction comes in they will have to restart their search.
I'm not quite sure what you're trying to say. Could you clarify?