Sorry, meant to include the list before. Switching to inline reply
   since I want to reply to separate points separately.
   On Fri, Feb 7, 2014 at 12:40 PM, Lodewijk andré de la porte
   <[1]l@odewijk.nl> wrote:

   2014-02-07 Sean Lynch <[2]seanl@literati.org>:

     Substitute "CPU power" for "wealth," and your claim about trust
     equally applies to the current proof-of-work function. I don't
     accept your premise that giving more power to wealthy people is
     somehow worse than giving more power to people with lots of CPU
     power (i.e. wealthy people).

   Ah, yes. But now you're confusing some things.
   I can calculate that a certain transaction is no longer worth
   falsifying. Let's say that there's 10,000 USD (10kusd) required to fake
   a single block.
   Now my transaction is buried 5 blocks. Setting apart a block just for
   the sake of luck-prevention I can say that if my transaction is <40kUSD
   it is now entirely safe. It is not worth it to revert it.
   Unless someone wants to mess with me (specifically me) it will not be
   done. If I suspect someone wants to mess with me I only have to
   estimate how much he can spend messing with me.
   Block reward kind of throws a wrench into the story. It drastically
   reduces the actual cost of mining a block. Still I can say with math
   that it isn't worth it after a while.

   With proof of stake I cannot do such math. I'm subjected not to the
   will of the rich to mess with me. Not the will of the rich to waste
   money on me. And the cost of faking a chain does not grow with it's
   length, unless it's a proof-of-work-and-stake. In which case I'm really
   wondering why you're taking two risks.

   Either way, this is not equivalent to introducing trust into the system
   where it did not exist before. My claim about proof-of-stake not being
   trust any more than proof-of-work is stands.
   I was proposing using coin days destroyed as part of the "difficulty"
   computation, which would mean they actually DO have value, since you
   cannot use the same coin days more than once, and they would reduce the
   number of CPU cycles you need to burn in order to produce a block. The
   idea is to reduce the cost of mining in terms of pure CPU cycles by
   giving value to something that currently has no value: coin days. So
   you actually CAN do such math still.
   This is not a pure proof-of-stake system, though. I am as skeptical of
   pure proof of stake as you are.

   I'm more strongly in favor of using citizen's ID's as provided by
   governments for the purpose of voting on blocks than in proof of stake.

   Not knowing you, this doesn't tell me much, since the same could be
   said of the most statist friend I actually tolerate, the one who thinks
   Bitcoin should die in a fire. I'm guessing that this means "not in
   favor of it at all."
   There are a couple of problems people are trying to solve with
   proof-of-stake. The first is that the value of mining will eventually
   go down, meaning people will be willing to devote less computing power
   to it, reducing the cost of an attack. The second is that, even if it
   didn't go down, we don't necessarily want a huge fraction of the
   world's computing power devoted to mining. The goal is to take some
   limited resource that doesn't depend on a trusted third party and that
   is difficult to corner and use that to distribute voting authority. In
   addition, we'd like the people doing the voting to have an economic
   incentive to vote correctly. Bitcoin does that by paying them to vote
   and revoking the payment if their block doesn't end up in the main
   chain. Proof-of-stake does it by hoping that the voters care about the
   integrity of the system, similar to only allowing landowners to vote,
   only (hopefully) without the ability to prevent others from becoming
   stakeholders, which I think is your main worry about it.
   Incidentally, the coin days are from ALL of the transactions in the
   block, not just your own. I'm not sure if I was clear about that
   before. You could maybe override a transaction that had fewer coin
   days, but you'd have to burn a similar amount (though less) of CPU time
   in addition.
   Speaking of which, is there any reason peers couldn't watch for forks
   and incorporate any still-valid transactions into new blocks and
   permanently blacklist any outputs that get double-spent? You could
   create a special "blacklist" transaction that just incorporates the two
   separate spends into the main chain, so that everyone could validate
   that the account holder attempted to double spend.

References

   1. mailto:l@odewijk.nl
   2. mailto:seanl@literati.org