Imagine there being a split in the Peercoin blockchain. (Can this only happen when a 51% attack occurs?)
What stops me from minting my stake on both chains at once? Is this considered to be an attack/threat/issue? If so, can it be dealt with?
Opinions highly appreciated!
I think Andrew Miller put it best: "The trouble with Proof-of-stake is that there is nothing at stake."
Consider the basic function of [b]proof-of-work and the blockchain[/b]: together, they [b]let the network come to a consensus when there are two (or more) different, competing chains.[/b]
Miners must decide to dedicate their hashing power to just one chain-- they cannot "bet on" more than one. So their best strategy is to work on the chain that they think most other miners are working on, and that quickly drives the system to a consensus on a single, best chain.
The trouble with proof-of-stake is there is no natural incentive stopping a miner from assigning their stake to multiple, competing chains. If you try to create such a system, you “go meta” – you started by trying to solve the transaction double-spend problem (which proof-of-work and the blockchain handle nicely), and end up trying to solve a proof-of-stake double-spend problem.
I’m going to follow this thread, because it’s certainly an interesting question. I’m trying to learn as much as I can about the inner workings of crypto currencies, and the idea of “constructing” blocks to meet a specific condition (either PoW or PoS) is something that is very arcane to me.
[b]Block Signatures and Duplicate Stake Protocol[/b]
Each block must be signed by its owner to prevent the same proof-of-stake from being
copied and used by attackers.
A duplicate-stake protocol is designed to defend against an attacker using a single proof-
of-stake to generate a multitude of blocks as a denial-of-service attack. Each node
collects the (kernel, timestamp) pair of all coinstake transactions it has seen. If a receivedblock contains a duplicate pair as another previously received block, we ignore such
duplicate-stake block until a successor block is received as an orphan block.
Maybe this is the solution already, but I don’t fully understand the above explanation. Can someone more educated in Peercoin explain it in less technical words?
Each block must be signed by its owner to prevent the same proof-of-stake from being
copied and used by attackers.
A duplicate-stake protocol is designed to defend against an attacker using a single proof-
of-stake to generate a multitude of blocks as a denial-of-service attack. Each node
collects the (kernel, timestamp) pair of all coinstake transactions it has seen. If a receivedblock contains a duplicate pair as another previously received block, we ignore such
duplicate-stake block until a successor block is received as an orphan block.
Maybe this is the solution already, but I don’t fully understand the above explanation. Can someone more educated in Peercoin explain it in less technical words?[/quote]
explanation in layman terms will be great. would like to include on my working deck too…
Each block must be signed by its owner to prevent the same proof-of-stake from being
copied and used by attackers.
A duplicate-stake protocol is designed to defend against an attacker using a single proof-
of-stake to generate a multitude of blocks as a denial-of-service attack. Each node
collects the (kernel, timestamp) pair of all coinstake transactions it has seen. If a receivedblock contains a duplicate pair as another previously received block, we ignore such
duplicate-stake block until a successor block is received as an orphan block.
Maybe this is the solution already, but I don’t fully understand the above explanation. Can someone more educated in Peercoin explain it in less technical words?[/quote]
When I read that, this is what it means to me:
When it sees that transaction, it also sees some mumbo jumbo generated by a timestamp that is uniquely generated by your computer, and the date and time of the transaction, marking your stake to the network as unique.
So if it receives another one of the same, it assumes the first one is valid, and the second one gets orphaned.
Each block must be signed by its owner to prevent the same proof-of-stake from being
copied and used by attackers.
A duplicate-stake protocol is designed to defend against an attacker using a single proof-
of-stake to generate a multitude of blocks as a denial-of-service attack. Each node
collects the (kernel, timestamp) pair of all coinstake transactions it has seen. If a receivedblock contains a duplicate pair as another previously received block, we ignore such
duplicate-stake block until a successor block is received as an orphan block.
Maybe this is the solution already, but I don’t fully understand the above explanation. Can someone more educated in Peercoin explain it in less technical words?[/quote]
This is a simple duplicate check: once you get the luck to generate a PoS block, you can’t reuse that luck to generate other PoS blocks (actually you can, but the network won’t propagate them thanks to this check).
The source code is here: https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1985
The ability to generate a PoS block is basically finding a timestamp (current time) that, hashed with a kernel (the last output of one of your coin transactions), gives a hash that satisfies the difficulty adjusted by the coin age of the kernel.
Without this duplicate check, you could generate as many PoS block as you want once you find a working (kernel, timestamp) pair.
The comment in the source code says it allows “duplicate stake […] when there is orphan child block”. I think this only triggers when you receive a block for which you already have a orphan child (during the initial download for example).
So as I understand it (I spent a few hours analyzing the peercoin source code yesterday), yes, this check prevents you from minting on multiple blockchains because only the first PoS block will be propagated by the network. This is very similar to the way double spend transactions aren’t propagated.
[quote=“lacksfish, post:1, topic:1394”]Imagine there being a split in the Peercoin blockchain. (Can this only happen when a 51% attack occurs?)
What stops me from minting my stake on both chains at once? Is this considered to be an attack/threat/issue? If so, can it be dealt with?
Opinions highly appreciated!
I think Andrew Miller put it best: "The trouble with Proof-of-stake is that there is nothing at stake."
Consider the basic function of [b]proof-of-work and the blockchain[/b]: together, they [b]let the network come to a consensus when there are two (or more) different, competing chains.[/b]
Miners must decide to dedicate their hashing power to just one chain-- they cannot "bet on" more than one. So their best strategy is to work on the chain that they think most other miners are working on, and that quickly drives the system to a consensus on a single, best chain.
The trouble with proof-of-stake is there is no natural incentive stopping a miner from assigning their stake to multiple, competing chains. If you try to create such a system, you “go meta” – you started by trying to solve the transaction double-spend problem (which proof-of-work and the blockchain handle nicely), and end up trying to solve a proof-of-stake double-spend problem.
(Further reference)[/quote]
To make it simple, only the first valid PoS block is accepted by the chain, if anyone else submitted a valid PoS after already found block it will be rejected (orphaned). If by a chance the blockchain gets forked (as happened to bitcoin last year) we will have to decide quickly which chain to follow and orphan the other, in that case anything that you minted or mined in the orphaned block will not count towards the selected chain.
Respectfully, I think you guys are missing the point. Of course proof of stake has duplicate stake detection and will ignore double minting with the same stake. That is not the question. The question is, what prevents a rational person from minting on multiple chains concurrently. For example, let’s assume that the longest chain has a 90% chance of being master and a 10% chance of being overtaken by the second longest chain. The default peercoin client will only mint on the longest chain, but a rational person with access to an alternative client would mint on BOTH chains because they have nothing to lose by doing this. In fact, over time they will have a marginal increase in total return by doing this. If everybody did this there would be no consensus, and even if MANY people did this there would be a significant security risk. I believe the answer to the question is that PPC has not implemented a solution to this very real vulnerability.
What exactly does it mean for you to mint both chains?
To mint 2 chains you can reuse the same (kernel, timestamp) pair you found to generate 2 PoS block on top of 2 distinct chains. If you do that, the network will only propagate the first block you send so it won’t work.
If you have enough coin age and luck you can find another (kernel, timestamp) pair that works and propagate another PoS block on top of another chain. But this is limited: only people with large coin age can do that, and not indefinitely because their coin age decreases each time they use it on the main chain. So I can’t see a scenario where so many people could do this simultaneously that it would be a significant security risk.
A solution has been proposed which involves punishment of people who mint multiple chains. But if you use multiple kernels to double mint, I don’t think we can identify you’re only one person (in the same way we can’t know 2 addresses belong to the same person). So it’s not much better than just ignoring duplicate PoS.
It would still detect people using the same kernel with different timestamps though. But to be able to find a kernel and 2 timestamps that work you must have a very large coin age on this kernel, and you’ll spend all this coin age in the operation.
[quote=“sigmike, post:15, topic:1394”]What exactly does it mean for you to mint both chains?
To mint 2 chains you can reuse the same (kernel, timestamp) pair you found to generate 2 PoS block on top of 2 distinct chains. If you do that, the network will only propagate the first block you send so it won’t work.[/quote]
You are misunderstanding the objective here. It is NOT to mint two verified blocks with the same stake input. The fact that you do not know and can never know which chain will eventually be master means that you are better off minting on all chains. It is true that only 1 of the chains you mint will become master, but by minting on only one chain (even if it is significantly more likely to become master), you are always forgoing SOME income by forsaking the possibility that a different chain will become master. Thus, the financial incentive is to always mint on all chains.
Again, the issue is that your coin age does not “decrease” if you mint on a chain that does NOT become master. On the other hand, if you mint on all chains you are increasing the probability that you will have a confirmed stake block in the master chain, whichever it ends up being.
[quote=“sigmike, post:15, topic:1394”]A solution has been proposed which involves punishment of people who mint multiple chains. But if you use multiple kernels to double mint, I don’t think we can identify you’re only one person (in the same way we can’t know 2 addresses belong to the same person). So it’s not much better than just ignoring duplicate PoS.
It would still detect people using the same kernel with different timestamps though. But to be able to find a kernel and 2 timestamps that work you must have a very large coin age on this kernel, and you’ll spend all this coin age in the operation.[/quote]
It is actually easily verifiable since your stake input is the same. The complexity comes in awareness of the orphaned chains and application of the “punishment” for an already minted block (not unsolvable).
As someone who is relatively new to the deeper-level functionality of cryptocurrencies, is there a brief summary or good resource to review to start to understand the how/why for how chains are selected and what it really means to generate an orphaned chain?
I’m not sure I follow why it is a problem if someone attempts to solve a block using stake on all chains at once, if only one chain becomes the master. Also, for someone to even attempt to mint on all (unsolved?) chains, does that mean that they would have needed to customize their Peercoin daemon to do that?
[quote=“AlphaBar, post:16, topic:1394”]You are misunderstanding the objective here. It is NOT to mint two verified blocks with the same stake input.
[…]
Again, the issue is that your coin age does not “decrease” if you mint on a chain that does NOT become master. On the other hand, if you mint on all chains you are increasing the probability that you will have a confirmed stake block in the master chain, whichever it ends up being.[/quote]
But if you mint on two chains with 2 different stakes, one of the chains will be the master and the coin age you used on it will vanish. On the next block you have one stake less to mint with (for 30 days). So you can’t do that for a long time.
And to do that you need a lot of coin age (enough to mint 2 blocks at the same time). Since you engage a lot of coin age, you also consume a lot, so you have much less to repeat the process.
It decreases the security of the network. If someone attempts to push another chain, you basically help him by minting his chain. So he may need less than 51% to make a 51% attack.
You use the same stake input on each of the competing chains, not 2 different stakes. All except one become orphaned and therefore you lost nothing on the orphaned chains. You are not decreasing your stake across multiple chains, you are minting with the same stake input on each of the competing chains.
Anyway, to answer the last quote, you can’t use the same stake input on each of the competing chains because the network won’t propagate that, as said earlier.
