Interesting article on POS by Vitalik Buterin

#1

https://blog.ethereum.org/2014/07/05/stake/

It looks like the perfectly secure POS doesn’t exist yet. What do you think?

#2

Define “perfectly secure” plz.

#3

Good point. May be as secure as Bitcoin POW?

#4

Then it’s not secure at all, I suspect u need less money to 51%-attack Bitcoin than u need to buy 51% of peercoins.

#5

Then it’s not secure at all, I suspect u need less money to 51%-attack Bitcoin than u need to buy 51% of peercoins.[/quote]

You’re right, it was certainly a bad example, I was focusing on the cost of mining forks.

Just a precision, you only need 51% of the minting coins, so currently 1-2M peercoins should be enough.

#6

Fantastic post. Very thought-provoking.

Vitalik says that minters will mine on both chains in a fork scenario, because of expected return of 0.0199 return instead of 0.01. I disagree: I think that a minter who gains so little in assisting an attacker would rather not assist in order to preserve the value of his minting coins. Remember that, in Peercoin, the minter is gaining only compound interest on the 1% by assisting the attack, which is quite a low reward. This may be too little benefit to offset the risk of damaging the integrity of the network in which the minter holds a stake, unless the minter is able to quickly short the market while assisting in the attack.

EDIT: 1% compounded monthly (the fastest compounding possible in Peercoin) is equivalent to 1.0046% compounded annually. Not a lot of incentive to assist an attacker!

#7

Here is Jordan Lee on the subject of Nothing at Stake attack:

#8

I think there’s a problem with Jordan’s analysis.

[quote=“Jordan Lee, post:5, topic:2518”]I would like to present the specific steps of an attack exploiting the “nothing at stake” phenomena. As you will see, the attack does not pose a serious threat to the network.

  1. Alter the client source code to not include any transactions in a block except your own.

  2. Write a utility that can sign and automatically issue a transaction to transfer coins from and to addresses of your choosing.

  3. Build and deploy your altered Peercoin client to 10 different virtual machines.

  4. Open exchange accounts with 10 different exchanges. In each virtual machine, configure the utility you wrote to transfer the same coins to a unique exchange address. You are attempting a double spend, or in this case, you try to spend the same coins 10 times.

  5. Mint on all 10 virtual machines using the same wallet on each while sending out transactions spending your coins to ten different exchange deposit addresses. Other nodes will only accept a single transaction: the one they received first. You only have about a 10% chance of the exchange nodes receiving the spend you wanted it to (this works the same in a proof of work system like Bitcoin). If any other client besides the attackers’ finds the next block, the multiple spend is resolved and the coins cannot be used again to attempt a multiple spend in the next block. The attempt to get the double or multi spend confirmed failed. If the attacker is very lucky and finds the very next block after sending out multi spends (using 10 machines does not increase the attacker’s likelihood of finding the next block), there will be 10 forks with 10 different spends of the same coins with one confirmation. No other transactions will be included in these 10 competing blocks.

  6. We now have 10 Peercoin forks, all of which are being minted on. Clients run by others will decide which fork to mint on based on which of the 10 competing blocks they received first.

  7. The next block will be minted. If it is minted by someone else other than the attacker, which is the overwhelming likelihood, this new block defines the best chain and consensus is restored across the entire network. All legitimate transactions excluded from the previous block are included in this block. In the unlikely event that the next block is minted by the attacker, all 10 forks will continue.

  8. As soon as anyone else on the network besides the attacker finds a single block, the attack is defeated. Double spends (or 10 spends in our case) disappear and all other transactions are confirmed normally.

Let’s consider the above attack scenario for someone who has accumulated 6% of all Peercoins, meaning they spent at least $2,400,000 USD on Peercoins at today’s prices and split them up into 6 different outputs or addresses (one for each of the 6 consecutive blocks they need). Let’s assume they waited 90 days to mint with those coins. Such a person might have a 3% chance of finding the next block. If they succeed at getting one and only one confirmation on their multiple spends they cannot defraud an exchange (because they typically require 6 confirmations). They have less than a 0.1% chance of getting two blocks in a row and around 0.003% of find three in a row. The chance they will find six blocks in a row is 0.00000000729%. They must wait 90 days to get another optimal chance to attack after a failed attempt.

If they fork the network for one or two blocks and their double spend is successful for only one or two blocks, they can’t defraud an exchange but they might harm the value of their own investment if the market is not impressed by these one or two block forks. Because 6 consecutive blocks are needed to defraud an exchange from double spending, even a very large stakeholder would have a negligible chance of success. If they got somewhat close to success but failed (the overwhelming likelihood) it would lower the value of their Peercoins as the market priced in worries of a possible future success. The odds of gain are strongly against you because any near success that ultimately fails can hurt the value of your Peercoins.

The endeavor cannot be embarked upon with an expectation of financial gain. Financial loss is far, far more likely. The loss of large amounts of time is certain. Additionally, few people have the skills to mount such a complicated attack. The fact that such forks have not been known to occur suggests no one has attempted it, precisely because it is extremely unlikely to result in financial gain while much more likely to result in loss.[/quote]
This attack assumes that the attack transaction is broadcast first, and then the attacker hopes to mint blocks. Instead, a smart attacker would wait to get lucky and mint a full attack chain ahead of time. Then, attacker would broadcast the transaction, wait for confirmations, and finally broadcast the attack chain. This way, the attacker only consumes coindays with a successful attack, and there is truly “nothing at stake” while waiting to get lucky for the attack.

#9

@Chronos not exactly. Nothing-at-stake is about leveraging attacking power by rational (? w/o fee-based reward this point is questionable, valid f.e. for Blackcoin and NXT) mint-on-every-chain minters.

#10

Nxt has also an interesting thread about this topic and are also responding to Vitalik if you like to know more about it.

Check it out here: https://nxtforum.org/general-discussion/bounty-for-successful-nothing-at-stake-attack/?all

Returning a favour as someone posted a link into Pillow’s thread.

#11

[quote=“mably, post:1, topic:2637”]https://blog.ethereum.org/2014/07/05/stake/

It looks like the perfectly secure POS doesn’t exist yet. What do you think?[/quote]

Thanks for the link. I haven’t finish reading all of it, but about the nothing-at-stake problem, he refers to his slasher link which seems to define (in the third paragraph) double spend as being able to spend again after 1 confirmation, while in reality most cryptocoin receivers take 6-10 confirmations. The number of confirmation totally changes the problem.

#12

I’m not sure this is an issue with Peercoin: I’m not really familiar with Peercoin source code yet, but it seems that if you get to mint on one fork, you also get to mint on the other one, provided there was no change of modifier since the beginning of the fork. The only thing in the computation of the score that does not depend on the output you are using as kernel is the modifier: https://github.com/ppcoin/ppcoin/blob/master/src/kernel.cpp#L331.