Escrow attack on Proof-of-Stake

[astor]

In a Proof-of-Stake system similar to bitcoin, a large number of coins could lie dormant and accrue 'coin days'.   If these coins are in escrow, like on Mt.Gox, their 'coin days' could be used to do an attack on the network.

Thus any large escrow service would be a threat to the network, in addition to large miners.

Thus either escrow services must pay interest, or the need for escrow should be eliminated by a better block chain design and p2p exchanges.

[1714859882]

1714859882

[magnificat_mafia]

have you read the white paper.  stop being such a scrub

[astor]

Yes I've read the paper.

Maybe you didn't understand the attack.  The attack is that the escrow service cooperates with a miner to destroy coin days.

[tacotime]

This is prevented by checkpointing (centralized control)

https://bitcointalk.org/index.php?topic=152809.msg1636798#msg1636798

If you can circumvent checkpointing, you can easily double spend with stake blocks

Exchanges can defend against these attacks by simply ignorning stake blocks for the purpose of confirmation.

[xorxor]

coindays is not stake!!!

coindays destroyed in POS block generation are awarded in a 1% roi.
if you find a block and destroy coinage of 10000 coins lying in there for 365 days, wou will be rewarded 100 coins.

but that would not make it easy for you to attack. generation is baset not on coinage, but on stake.
stake is only generated up to 90 days so it cannot be super charged for an attack, also new 3.0 protocol has protection against finding pos block one by one.


checkpointing is still there, but just in case of som unknown vulnerabilities. users trust developer so there is actualy not mush pressure from PPC supporters to remove it.

there are no known possible atacks that would be easier on PPC than on any other coin including BTC.
 

[tacotime]

stake is only generated up to 90 days so it cannot be super charged for an attack, also new 3.0 protocol has protection against finding pos block one by one.

checkpointing is still there, but just in case of som unknown vulnerabilities. users trust developer so there is actualy not mush pressure from PPC supporters to remove it.

there are no known possible atacks that would be easier on PPC than on any other coin including BTC.

The new protocol (as far as I can tell) just makes it harder to spam consecutive blocks from a single source (again, it's hard to tell because SK doesn't want to explain it in simple pseudocode) -- but I think you can still do it if you keep multiple wallets.  For instance, if you have 500 clients all with some coins 90 days old, and you keep them offline then suddenly bring them online, you might be able too.

[Balthazar]

if you find a block and destroy coinage of 10000 coins lying in there for 365 days, wou will be rewarded 100 coins.

No, because there is limit for coinage in PPC and NVC, 90 days. You will receive ~ 25 coins.

The new protocol (as far as I can tell) just makes it harder to spam consecutive blocks from a single source (again, it's hard to tell because SK doesn't want to explain it in simple pseudocode) -- but I think you can still do it if you keep multiple wallets.  For instance, if you have 500 clients all with some coins 90 days old, and you keep them offline then suddenly bring them online, you might be able too.

There is no difference between "1 wallet" and "500 wallets" configurations.

[Sunny King]

if you find a block and destroy coinage of 10000 coins lying in there for 365 days, wou will be rewarded 100 coins.

No, because there is limit for coinage in PPC and NVC, 90 days. You will receive ~ 25 coins.

xorxor is correct, 90 day limit only applies to kernel hash weighting, but when calculating reward full coin age is used. So you do get 100 coins provided you are online long enough to generate stakes.

[tacotime]

There is no difference between "1 wallet" and "500 wallets" configurations.

So the number of stake blocks that would be generated after bringing them online after a 90 day period is the same?

[Balthazar]

So the number of stake blocks that would be generated after bringing them online after a 90 day period is the same?

It's almost the same as 100 mhash/s vs. 100 x 1 mhash/s for PoW system.

For example:

PoW diff-1 is ~ 4.29 * 10^9 hashes per block
PoS diff-1 is ~ 4.29 * 10^9 coin-day-second per block

P.S. I was wrong about reward, sorry.

[tacotime]

Right.  But, you need 6 blocks to double spend (unless there's some kind of "block trust score" system that ignores the number of blocks and just calculates how much to trust each stake block).

[Sunny King]

For those of you who can't be bothered to read (only a few hundred lines of) source code and constantly fault me for not teaching the new algorithm in fine detail, I am sorry I cannot take you seriously as a critic as I think to be a good critic you need to seriously spend some effort as well. Besides I have already outlined the algorithm in my weekly updates but some people don't read it either before throwing complaints.

I am very busy and continue to work hard in order to better compete in the cryptocurrency market. So get some coffee and start reading before I can start taking you seriously.

[tacotime]

^^  Thanks for the criticism.  Here's your enlightening weekly update:

v0.3.0 has been released. Upgrade should be performed before protocol switch on March 20th. A block chain re-download is necessary for the upgrade. See the 0.3 release thread for detailed instruction: https://bitcointalk.org/index.php?topic=144964.0
v0.3 protocol involves several changes, first the proof-of-stake hash modifier is switched to one computed from roughly 9 days worth of blocks. The blocks are grouped and 64 blocks are selected based on a 'selection hash'. Then each selected block contributes one bit to the modifier. The purpose of stake modifier is to prevent stake owner from manipulating future stake generation at the time the coin is confirmed into block chain.
Two other protocol changes are made: stake hash weight now starts from 0 at 30-day minimum age requirement; coinstake timestamp now must match block timestamp.

The 0.3 release thread for detailed instruction:

The protocol upgrade in 0.3.0 includes a new algorithm to derive proof-of-stake hash modifier, the entity that scrambles computation for stake owners, which replaces the current proof-of-stake difficulty used as modifier in 0.2 protocol. The design was started late September last year, when I first began to realize the issues with using difficulty as modifier. Honorary mention also goes to Jutarul, who independently discovered and verified an issue with using difficulty as modifier and published on bitcointalk in December last year, while successfully executed a demo attack on the block chain. Other changes in the protocol include starting hash weight from 0 at the 30-day mininum age, and requirement that coinstake timestamp must equal block timestamp. Overall 0.3 protocol should significantly strengthen the proof-of-stake protection and resolve the current known vulnerabilities.

https://bitcointalk.org/index.php?topic=144964.0

Here is your enlightening answer as to what these 400 lines of code accomplish in kernel.cpp:

Thanks. Surely you have already touched upon the reasons of what you refer to as 'opaque' development, mostly, due to lack of resources, secondly, for security concerns. I only have time to discuss the design with trusted peers before release. I hope you can understand that there is lot of work involved and it's not trivial work to even understand the design and its intricacies. There is no separate document, I have put some comments into the source code, it's not long at all, only about 400 lines in kernel.cpp and some of it is preexisting code in v0.2. Interested parties can take time to look at it, and discuss it maybe in my disclosure thread. I'll try to answer some of the questions along the way.

edit: Diff for anyone interested, took me a while to dig up
https://github.com/ppcoin/ppcoin/commit/b0b7eb2ecad409a2a98f6aa35bf99a4fb247ff35

[Balthazar]

unless there's some kind of "block trust score" system that ignores the number of blocks and just calculates how much to trust each stake block.

All systems ignores the number of blocks. The both PoW and PoS systems calculates "trust score" for each block.

In BTC-like systems, for example, this "trust score" comes from nBits field. You can't overwrite current chain with your own, if you have not enough "trust score" aka bnChainWork. Even if you generated 100x longer chain.

[tacotime]

All systems ignores the number of blocks. The both PoW and PoS systems calculates "trust score" for each block.

In BTC-like systems, for example, this "trust score" comes from nBits field. You can't overwrite current chain with your own, if you have not enough "trust score" aka bnChainWork. Even if you generated 100x longer chain.

I see, thank you for taking the time to answer my questions.  How do exchanges implement confirmation, then?  As you worked with BTC-e with NovaCoin, you must know.

[Balthazar]

How do exchanges implement confirmation, then? How do exchanges implement confirmation, then?

Merchant operator usually selects fixed confirmations amount and takes a risk of double-spend. This is the fundamental problem, one can't say what the chain is correct, if there are no another chains for trust score comparison. And it doesn't matter how many confirmations do you have, 6 or even 600.

[tacotime]

Okay, thank you for your answer.

[Balthazar]

Merchant operator usually selects fixed confirmations amount and takes a risk of double-spend. This is the fundamental problem, one can't say what the chain is correct, if there are no another chains for trust score comparison. And it doesn't matter how many confirmations do you have, 6 or even 600.

... but it's possible to estimate risks and select confirmations amount for your own situation. If attack costs more than transaction volume, you can trust it with lower amount of confirmations, for example.

[Sunny King]

How do exchanges implement confirmation, then? How do exchanges implement confirmation, then?

Merchant operator usually selects fixed confirmations amount and takes a risk of double-spend. This is the fundamental problem, one can't say what the chain is correct, if there are no another chains for trust score comparison. And it doesn't matter how many confirmations do you have, 6 or even 600.

More confirmations means more security from double-spend. It's same for proof-of-stake.

[Balthazar]

More confirmations means more security from double-spend. It's same for proof-of-stake.

Yes, because it decreases a risk and makes attacker costs higher. But you still can't say that N confirmations amount provides you the 100% protection against double-spend. Risk still exists, it can be 0.00000000001%, but it still exists. But everyday life is a complex of balanced risks, anyway.