[PPC] PPCoin 0.2 Proposal

[killerstorm]

PoW is costly in energy and capital investment, but PoS is costly too to the attackers as they will lose the value of their currency holdings as Market loses confidence in the currency.

Have you ever heard about prisoner's dilemma? Nash equilibrium can be bad for everyone.

If someone actually accumulated such vast wealth and be crazy enough to mount the attack,

You don't really have a security mindset, do you? You shouldn't be operating with categories like 'crazy', you should look at various attack motives, e.g. what would a rational entity do? What if somebody will try to kill your currency if he has a stake in a competing currency?

First of all, accumulating vast wealth isn't necessary. Once you've made a block with double-spending txn, you can bribe stake-holders to build blocks on top of your block to force a reorg. Rational stake holders would do that because that doesn't cost them anything: they will earn their bounty in either case, but in case of reorg they get an extra reward (bribe).

You say that then their currency holdings become less valuable? No, one double-spend won't cause devaluation. The knowledge that such double-spend is possible will make it worthless from the start.

This is just game theory basics.

I suspect that he would not be able to remain anonymous, and folks would find out about him and mobs probably would lynch him.

If you assume that then your protocol is based on trust, essentially. There is much better protocol based on trust: Ben Laurie's mintettes. http://www.links.org/files/distributed-currency.pdf Please check it.

Besides that, assumption that there is just one wealthy guy is just wrong. You should assume that people can sell their signatures, form alliances and whatnot.

You are thinking in right direction: punishing mis-behaving stakeholders can work. But it should be a part of your crypto protocol, you should not assume availability of a lynching mob.

[Sunny King]

I had a strange dream this morning.

I am a fairly spiritual guy and do meditations sometimes. I don't often have this type of vivid dreams where I can remember some details. And I don't believe in coincidences, so I would love to share with all of you my dream.

I went to the street and there was perhaps some sort of checkpoints. Agents are there maybe to check people's ID's.

I printed out some random guy's photo from the Internet and bring it to the agent, he rejected it and ask me to go back.

I was feeling a bit frustrated and wanted to get out. Then with a bit surprise I received a mail with a passport in it. I tried to remember how I did apply for this passport and what my name should be with this passport. I had a hard time recalling it still before I get to see the agent. Then with a bit relief I finally saw the passport is from Sweden and my new name is Korean. I was filled with joy and my hand almost shook when signing it with a pen.

Then I woke up.

I don't really fully understand the meaning of this dream. But that's not important. I wanted to share this dream with all of you because I think, given our differences, maybe we didn't fully understand our purpose, maybe we were meant to be a bigger team doing something truly great. I used to tell folks that I thought Bitcoin was the single most important event in the entire financial history of humanity, bigger than gold, bigger than fiat. Because I think it changes the foundational fabric of our society known as private property.

So yes I really cherish what I did with the ppcoin project, this is probably the best work I have ever produced. Yes I have limitations, maybe lot's of them. I thought about quitting the project several times. But I persisted. Now here we are, I hope we can understand our differences, and truly help out each other to fulfill our destiny.

Peace and Love

[killerstorm]

Well, if you want to work further on proof-of-stake approach I strongly recommend reading other proposals and discussing them.

Particularly, check this one: https://en.bitcoin.it/wiki/Proof_of_Stake#Meni.27s_implementation

Note that each particular implementation detail is there for a reason. Particularly, it includes a way to punish malicious stakeholders:

If an address signs two conflicting blocks, its weight is reset to 0. This is to limit the power of malicious stakeholders.

Malicious stakeholders

The system is resilient against stakeholders who misuse their signature power, even if they have a majority of the bitcoins. Since their only obligation is to not sign conflicting blocks, the only way they could double-spend is if they first sign one block so it achieves a majority, then sign a different one so that it achieves a bigger majority. Generally this will not work. A short while after a majority is achieved, most of the network will be aware of the relevant signatures. If a different signature is broadcast, the conflict will be detected and both signatures will be ignored.

Also I think that cementing is a great idea, but I'm not sure it can work in 'energy-efficient' variant.

[Bitcoin Oz]

Well, if you want to work further on proof-of-stake approach I strongly recommend reading other proposals and discussing them.

Particularly, check this one: https://en.bitcoin.it/wiki/Proof_of_Stake#Meni.27s_implementation

Note that each particular implementation detail is there for a reason. Particularly, it includes a way to punish malicious stakeholders:

If an address signs two conflicting blocks, its weight is reset to 0. This is to limit the power of malicious stakeholders.

Malicious stakeholders

The system is resilient against stakeholders who misuse their signature power, even if they have a majority of the bitcoins. Since their only obligation is to not sign conflicting blocks, the only way they could double-spend is if they first sign one block so it achieves a majority, then sign a different one so that it achieves a bigger majority. Generally this will not work. A short while after a majority is achieved, most of the network will be aware of the relevant signatures. If a different signature is broadcast, the conflict will be detected and both signatures will be ignored.

Also I think that cementing is a great idea, but I'm not sure it can work in 'energy-efficient' variant.

I like the idea of punishment for misbehaving 

[killerstorm]

Sunny King have provided only a very vague description of an algorithm, but as I understand, his PPCoin 0.2 Proposal is a variation of cunicula's algorithm: https://en.bitcoin.it/wiki/Proof_of_Stake#Cunicula.27s_Implementation_of_Mixed_Proof-of-Work_and_Proof-of-Stake

I.e. your hash target is lowered by your stake. Something like

Code:

hash-target = difficulty-target/f(coin-confirmation)

where f is some monotonic function.

This formula is just as vulnerable as your previous formula. For example, if f is identity, a person with 5% of coins and 5% of hashing power (which he needs to borrow only temporarily, i.e. rent from Amazon) can do a 50-block deep reorg once in 138 days.

So, do not even bother. Check discussion here: https://bitcointalk.org/index.php?topic=102355.msg1133808#msg1133808

I could provide recommendation on how to strengthen it, but I have absolutely no motivation to help Sunny King as he has numerous attitude problems:

• he does not bother to reveal all algorithm details
• yet he is very busy promoting his cryptocoin
• he tends to ignore or dismiss criticism, i.e. "we'll solve this crucial issue some time later"

So at this point I see PPCoin as a get-rich-quick project, and with such attitude it will never be secure. If you stay with PPCoin, there WILL be double-spends.

Finally, I would note that there is an energy-efficient pure PoS system proposal: it is Etlase2's Decrits. Whole proposal seems to be overly complex, but core protocol which secures transactions is incredibly simple and I'm fairly sure it is actually secure.

[cunicula]

Sunny King have provided only a very vague description of an algorithm, but as I understand, his PPCoin 0.2 Proposal is a variation of cunicula's algorithm: https://en.bitcoin.it/wiki/Proof_of_Stake#Cunicula.27s_Implementation_of_Mixed_Proof-of-Work_and_Proof-of-Stake

I.e. your hash target is lowered by your stake. Something like

Code:

hash-target = difficulty-target/f(coin-confirmation)

where f is some monotonic function.

This formula is just as vulnerable as your previous formula. For example, if f is identity, a person with 5% of coins and 5% of hashing power (which he needs to borrow only temporarily, i.e. rent from Amazon) can do a 50-block deep reorg once in 138 days.

• he does not bother to reveal all algorithm details
• yet he is very busy promoting his cryptocoin
• he tends to ignore or dismiss criticism, i.e. "we'll solve this crucial issue some time later"

So at this point I see PPCoin as a get-rich-quick project, and with such attitude it will never be secure. If you stay with PPCoin, there WILL be double-spends.

Finally, I would note that there is an energy-efficient pure PoS system proposal: it is Etlase2's Decrits. Whole proposal seems to be overly complex, but core protocol which secures transactions is incredibly simple and I'm fairly sure it is actually secure.

Whether what killerstorm says has validity or not obviously depends on what the monotonic function f() is. Define coin-confirmation=c

If we have f(c)=c for all c, then the system is as killerstorm describes. -> 10% of hashing power and 10*n times as many coin-confirmations as the average miner is sufficient to create a fork of length n

[I don't know where killer-storms 138 day number comes from, but I'm going to assume the number is accurate here. Note that because the formula looks like this if a 50-block reorg can be done once every 138 days, then a six-block reorg can be done once every 16-17 days.  In order to attack and mine 6 consecutive blocks once every 16 days, the attacker is not mining. If he mined, then he would get 115 blocks during this period. Instead he gets 6-7 plus a double spend opportunity. One-off double-spend profit has to be about 20 times the block reward for this to payoff. To be safe, you would need to wait for more than 6 confirms on a txn worth more than 20 times block reward. Even here, I don't see why this is a big concern.]

If we have f(c)=c^(1/4) for all c -> 10% of hashing power and 10^4*n times as many coin-confirmations as the average miner is sufficient to create a fork of length n

[ This modification increases the waiting time from 138 days to 10^4*138 days or 3778 years. Waiting 450 years for a single 6 block double-spend is a good investment if the double-spend profit exceeds the block reward from 1 million mined blocks + interest and you have a strong bequest motive. 6 confirms should be enough for any size of txn.]

If we have f(c)=c^(1/g) for all c -> 10% of hashing power and 10^g*n times as many coin-confirmations as the average miner is sufficient to create a fork of length n

[increasing g makes double-spends more difficult, but makes persistently disrupting the network easier. The optimal choice of g is debatable. ]

If we have f(c)=1 for all c, then the system is identical to bitcoin.  -> 10% of hashing power is never sufficient to double-spend for n blocks

[for bitcoin double-spending and having the power to persistently disrupt the network are equivalent.]

Of course other mixes of hashing power and stake are possible. As g increases and n increase, the waiting time necessary to double spend increases.

Yes, the attacker can spend a lot of amount of money on rented hashing power to double-spend. But by doing this, the attacker sacrifices income from legit mining. Double-spending is unlikely to be highly profitable. A big barrier is not needed.

That is not a major problem. Killerstorm is exaggerating. However, it is 100% essential to think carefully about design and debate design choices. Killerstorm is 100% right about this.

[markm]

So basically Sunny King is a reincarnation or emulation of RealSolid, in effect?

-MarkM-

[killerstorm]

Definitely not as bad as RealSolid. At least implementation is open source...

But the fact that he's going to change implementation at whim, without much discussion and review should be alarming.

Some quotes from a recent update:

• PPCoin has sailed through our first week with aplomb. -- this ignores shitload of criticism it got
• In v0.2 a main chain protocol upgrade is expected as I described ... The code of this has been done, ... Over next week v0.2 code would go through testing and be prepared for release. -- No detailed description of changes, no real discussion, no review process. People will have to accept change blindly, in a short time frame.
• First week total mintage is 3~4 million coins.  -- I don't really understand mintage formula, but it looks like early adopters (including Sunny King?) get a sizable bonus.

It looks like Sunny King shares some traits with RealSolid, although they are of a milder form...

[Sunny King]

Definitely not as bad as RealSolid. At least implementation is open source...

But the fact that he's going to change implementation at whim, without much discussion and review should be alarming.

Some quotes from a recent update:

• PPCoin has sailed through our first week with aplomb. -- this ignores shitload of criticism it got
• In v0.2 a main chain protocol upgrade is expected as I described ... The code of this has been done, ... Over next week v0.2 code would go through testing and be prepared for release. -- No detailed description of changes, no real discussion, no review process. People will have to accept change blindly, in a short time frame.
• First week total mintage is 3~4 million coins.  -- I don't really understand mintage formula, but it looks like early adopters (including Sunny King?) get a sizable bonus.

It looks like Sunny King shares some traits with RealSolid, although they are of a milder form...

I offered this thread for discussion, but I didn't get a lot of feedback with merits. I am not going to wait forever to make this important change. People can get a fair assessment of where we are and start participating if previously they didn't because of fear of permanent centralization.

Our formula is very different from cunicula's as we don't involve proof-of-work difficulties in the calculations of proof-of-stake difficulties. We have 2 independent difficulties. So no your hashing power would only help in accumulating coin age first before you can have some say in whether to reorganize.

So far I only see cunicula can offer a civil and friendly discussion among those who claim they have better designs. I hope this situation would change as we progress.

As for your jealousy of early adopters should we succeed, I think I have made it clear. You would have only yourself to blame if you were blinded by your own prejudice.

[Sunny King]

Since killerstorm questioned our review process, so I am making a public statement here:

Scott and I have been reviewing each other's code since the project began. Scott is currently busy with personal matters so he should greet you all on the forum in the near future. We are still a small team so there is no such formal process as Bitcoin. But as we progress and the project matures, more public review would be involved in decision making.

Best Regards,

[cunicula]

Since killerstorm questioned our review process, so I am making a public statement here:

Scott and I have been reviewing each other's code since the project began. Scott is currently busy with personal matters so he should greet you all on the forum in the near future. We are still a small team so there is no such formal process as Bitcoin. But as we progress and the project matures, more public review would be involved in decision making.

Best Regards,

Sunny, it would help if you made discussions between you and Scott completely public rather than secret. You could have the best method. However, to convince others of this, you need to explain:

a) precisely what you are doing
b) the reasons why you are doing it

You have done (a) and (b) to some degree, but you could really do a much better job. If you do so, it will be much easier to have a constructive debate. I think everyone wants this.
Transparency will shut down comparisons between you and Realsolid. I think that differentiating yourself from Realsolid is highly desirable.

[killerstorm]

I offered this thread for discussion, but I didn't get a lot of feedback with merits.

How people are supposed to discuss if you give no detailed description of proposed changes?

I am not going to wait forever to make this important change.

Cryto research usually works like this: Researchers release papers with detailed description of their constructs, then they wait for years while other researchers analyze these constructs and try to find weaknesses. And if after years of research no significant weaknesses are found somebody might consider practical use of those constructs, e.g. hashing algorithms.

I'm not saying that you should wait for years, but you should publish a detailed description and wait at least a month while people analyze it.

Otherwise you should call it your personal experiment rather than some valuable cryptocurrency.

People can get a fair assessment of where we are and start participating if previously they didn't because of fear of permanent centralization.

So you just want wider a adoption, i.e. ability to sell your coins, right?

I see no other reason why you want wider participation, attention from experts is not proportional to number of users you have.

Our formula is very different from cunicula's as we don't involve proof-of-work difficulties in the calculations of proof-of-stake difficulties. We have 2 independent difficulties. So no your hashing power would only help in accumulating coin age first before you can have some say in whether to reorganize.

Am I supposed to just imagine some formula here or something?

Here's what I read in paper:

Thus the more coin age consumed in the kernel, the easier meeting the hash target protocol.

This is exactly how Cunicula's formula works. How many targets you have is irrelevant, important part is that one can compensate for a lack of hashing power with larger coin-age.

So, basically, one can wait till his coins age, and then make a lot of blocks in a short interval of time (using limited hashing power) to achieve a double-spend. Is there anything in your formula which prevents this?

So far I only see cunicula can offer a civil and friendly discussion among those who claim they have better designs. I hope this situation would change as we progress.

You aren't offering a civil and friendly discussion in the first place: you are not showing your magic formula.

As for your jealousy of early adopters should we succeed, I think I have made it clear. You would have only yourself to blame if you were blinded by your own prejudice.

lolwut

So, again: early adopters are top priority to you, security is lowest priority. And, well, that "blame yourself" thing makes it even closer to pump&dump.

Scott and I have been reviewing each other's code since the project began.

So? There should be a public review of an algorithm, not a private review of code.

Your code is already public (which is good), but if people have to decipher algorithms it doesn't encourage analysis at all.

[Sunny King]

Sunny, it would help if you made discussions between you and Scott completely public rather than secret. You could have the best method. However, to convince others of this, you need to explain:

a) precisely what you are doing
b) the reason why you are doing it

Once you do (a) and (b), it will be much easier to have a constructive debate. I think everyone wants this. Transparency will shut down any comparison between you and Realsolid.

I think I have put enough detail into the design paper which is intended for other crypto-currency designers. I am actually quite puzzled why our fellow proof-of-stake designers have so much trouble understanding basic aspects of our design. If you really want to know more details, the code is also your friend.

I apologize here as my time is limited as I have a lot of things to do in the first couple weeks of the release. But I will try to answer more questions when I can have some more free time.

I do encourage our fellow designers to examine our code. In my opinion you have to spend effort to get familiar with Bitcoin code. If you don't, you are not going to be a successful designer no matter how many design proposals you pump out and argue it to death on a forum.

Best Regards,

[Sunny King]

Our formula is very different from cunicula's as we don't involve proof-of-work difficulties in the calculations of proof-of-stake difficulties. We have 2 independent difficulties. So no your hashing power would only help in accumulating coin age first before you can have some say in whether to reorganize.

Am I supposed to just imagine some formula here or something?

Here's what I read in paper:

Thus the more coin age consumed in the kernel, the easier meeting the hash target protocol.

This is exactly how Cunicula's formula works. How many targets you have is irrelevant, important part is that one can compensate for a lack of hashing power with larger coin-age.

So, basically, one can wait till his coins age, and then make a lot of blocks in a short interval of time (using limited hashing power) to achieve a double-spend. Is there anything in your formula which prevents this?

Let me give you an example here. If you have lot's of hashing power, can you pump out a lot of blocks in a short interval of time to compete with main chain? No you'd need more than everyone else combined.

Same with coin age here. You can accumulated a lot of coin age, but in order to beat main chain, you have to beat everyone else combined.

I hope you can spend some serious effort in understanding our design and in the future we can have more enjoyable discussions. You have to realize not everyone share the same ideology as you. In my opinion I have no obligation revealing my design to public before release. If that offends you, then so be it.

Best Regards,

[killerstorm]

Same with coin age here. You can accumulated a lot of coin age, but in order to beat main chain, you have to beat everyone else combined.

Cunicula also thought it's true, but I've demonstrated that one can easily manipulate things into his favor. Additionally, it turns out that total coin-confirmations is a totally meaningless metric: what matters is average coin-confirmations, and you can beat the average by waiting a bit.

In my opinion I have no obligation revealing my design to public before release. If that offends you, then so be it.

It doesn't offend me, at all. I just wanted to help. It looks like you don't need my help, that's OK.

I just want to warn people who consider using PPCoin that it is not possible to analyze how insecure next release will be.

[cunicula]

Let me give you an example here. If you have lot's of hashing power, can you pump out a lot of blocks in a short interval of time to compete with main chain? No you'd need more than everyone else combined.

Same with coin age here. You can accumulated a lot of coin age, but in order to beat main chain, you have to beat everyone else combined.

You cannot stockpile hashing power. You can stockpile coin age.

Killerstorm's point is that stockpiling coin age allows you to double-spend periodically. (of course you can checkpoint every block to prevent this, but...). Whether periodic double-spending is practically relevant or not depends on how frequently it can occur. Obviously once a decade is not a problem. Once a year should be fine too. Once a day would be cause for concern (and might potentially motivate a revision of your design). I'm fine with once every week, but I suspect Killerstorm has more stringent standards. I have no idea what other people think.

The frequency depends on your protocol design and the attacker's resources. Say a wicked stakeholder owns 5% of all coins and 5% of all computing power. I'd say this is a reasonable benchmark attacker (quite well-endowed, but not ridiculously so). He doesn't ever mine except to execute 6-block long reorgs. Can you give us an estimate of how frequently the he can execute these 6-block reorgs? The arithmetic behind the estimate will be really helpful here becuase it will clarify features of your design.

If you haven't worked this out before you can check out the recent posts by killerstorm and I where we try to 'hash out' this property in the context of my scheme. I'm not sure exactly how your scheme operates, but perhaps the math is similar.

[cunicula]

Cunicula also thought it's true, but I've demonstrated that one can easily manipulate things into his favor. Additionally, it turns out that total coin-confirmations is a totally meaningless metric: what matters is average coin-confirmations, and you can beat the average by waiting a bit.

The first part is true. However, "A bit" is misleading. Depending on the design specification, "a bit" could refer to two weeks, two years, or two thousand years.

[killerstorm]

As I understand, here's a formula (with a bit of description): https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp  CTransaction::CheckProofOfStake

This is somewhat different from Cunicula's proposal (particularly, one cannot iterate nonce to find matching hash), but it can be attacked in a similar way: attack should split his coins into many transactions, wait until they are mature enough and try to find a chain of matching blocks.

Numeric analysis is somewhat tricky (i.e. it takes more than 5 minutes), but a general idea is that if people do generate proof-of-stake blocks often, attacker having many aged coins will have an enormous advantage. I'll give you a hint: he can try to build many different chains out of his transactions, like billions of different combinations.

But I have no incentive to do a full analysis before a release.

[Sunny King]

You cannot stockpile hashing power. You can stockpile coin age.

Killerstorm's point is that stockpiling coin age allows you to double-spend periodically. (of course you can checkpoint every block to prevent this, but...). Whether periodic double-spending is practically relevant or not depends on how frequently it can occur. Obviously once a decade is not a problem. Once a year should be fine too. Once a day would be cause for concern (and might potentially motivate a revision of your design). I'm fine with once every week, but I suspect Killerstorm has more stringent standards. I have no idea what other people think.

The frequency depends on your protocol design and the attacker's resources. Say a wicked stakeholder owns 5% of all coins and 5% of all computing power. I'd say this is a reasonable benchmark attacker (quite well-endowed, but not ridiculously so). He doesn't ever mine except to execute 6-block long reorgs. Can you give us an estimate of how frequently the he can execute these 6-block reorgs? The arithmetic behind the estimate will be really helpful here becuase it will clarify features of your design.

If you haven't worked this out before you can check out the recent posts by killerstorm and I where we try to 'hash out' this property in the context of my scheme. I'm not sure exactly how your scheme operates, but perhaps the math is similar.

There is quite a few factor playing here. It depends on how much coin age is actively participating in block generation (i.e. running the stake minter with a hot wallet). If an attacker manages to beat this total coin age then he indeed can force large reorganization. I would say it is still quite a difficult job for a 5% stake owner. Hash power is irrelevant here, as the v0.2 main chain protocol pretty much gives proof-of-work block a zero score. How long it would take him to do it depends on the average age of the coins protecting the network. If it's 6 months, then the 5% attacker probably needs at least a couple years to pull it off.

It's more difficult to do a formal math analysis as in Satoshi's case. So I am in no hurry to offer such an analysis.

I actually think the bitcoin wiki page about proof-of-stake is quite well-written and I generally agree with the opinions expressed there. I am not as paranoid about this supposed large double-spending attack as I classify it on the same level of a 51% attack on proof-of-work. In terms of defense against some powerful institutions, I think it might turn out to be stronger than Bitcoin as it buys time for the stake owners to bail out and they can even use the profit to do some other good cause.

[cunicula]

There is quite a few factor playing here. It depends on how much coin age is actively participating in block generation (i.e. running the stake minter with a hot wallet). If an attacker manages to beat this total coin age then he indeed can force large reorganization. I would say it is still quite a difficult job for a 5% stake owner. Hash power is irrelevant here, as the v0.2 main chain protocol pretty much gives proof-of-work block a zero score. How long it would take him to do it depends on the average age of the coins protecting the network. If it's 6 months, then the 5% attacker probably needs at least a couple years to pull it off.

I don't know if this is correct or not because i don't know the details of your system (i.e. you say you are using pure proof-of-stake based on accumulated coin age, but I think you are using mixed proof-of-work/proof-of-stake). Let's assume it is pure proof-of-stake setting where coin age determines stake and hashing power is irrelevant. I'm going to assume you are doing this deterministically rather than via a lottery. [Some form of lottery might greatly improve things].

Let's make some assumptions to deal with the factors you mention. I'm going to assume that a unit of coin age is accumulated with every single block. I'm also going to assume 100% participation. I'm going to assume that coin-age is the only thing that influences mining success (say that stake mining has random elements but they are so small as to be negligible [as we will see this causes problems]). I'm going to ignore the existence of proof of work blocks and assume one stake block every 10 minutes. I'm going to normalize the total coin stock to 1.

Say there are n miners active, identical, legit miners each with a fraction c/n of all coins. They all actively participate. Due to symmetry, each miner mines 1 out of every n stake blocks and this occurs when he accumulates n stake confirmations. The amount of coin age which completes the winning block is  n*(c/n)=c.

[The miners are essentially waiting in a line of length n for there turn to mine a block. Each miner has a different position in line and they go back to the end after they reach the front. ]

There is also an attacker who holds all the remaining coins. His holdings are 1-(c/n)n=1-c. He does not mine, but waits to perform 6 block reorgs. To do this, he divides his coins across six accounts and each account holds (1-c)/6 coins. He waits w blocks between attacks. The interval is long enough to successfully attack if w(1-c)/6>c. Let's ignore discontinuities and approximate this with the equality condition: w=6c/(1-c).

How often can the attacker spring into action as a function of his wealth share, 1-c? See below

1-c        w
0.0005 11994
0.005   1194
0.05     114

So approximately the attacker who owns 0.05% of coins can strike once every 11194 blocks or about 4-5 times a year.
An attacker who owns 0.5% of coins can strike 40-50 times a year.
An attacker who owns 5% of coins can strike 400-500 times a year.

Thus, the concern that PPCoin is in the potentially worrisome daily double-spend category.

Note also that since mixed proof-of-work/proof-of-stake is not involved, there are no meaningful mining output losses for the attacker. He is just as efficient a miner as everyone else. Benefits from theft are in addition to his full legitimate mining income. (This is undesirable. Being sneaky like this should be costly. Introduce mixed proof-of-work/proof-of-stake and there are costs in terms of lost mining output.)