Punishing minting on multiple chains

General
21

[quote=“Sentinelrv, post:20, topic:2849”]Sunny gave an update about Sigmike’s proposal here…

http://www.peercointalk.org/index.php?topic=3344.msg32385#msg32385

The NuBits project has implemented a change that rejects blocks if the same stake has produced multiple blocks within a short time window. This is a fix for the nothing at stake issue PoS has been widely criticized for. We have taken precautions to ensure this block rejection can’t split the network. The fix referred to by Sunny and Sentinelrv comes from the NuBits code base. This is another example of how Peercoin and NuBits will strengthen each other.

22

[quote=“Jordan Lee, post:21, topic:2849”][quote=“Sentinelrv, post:20, topic:2849”]Sunny gave an update about Sigmike’s proposal here…

http://www.peercointalk.org/index.php?topic=3344.msg32385#msg32385

The NuBits project has implemented a change that rejects blocks if the same stake has produced multiple blocks within a short time window. This is a fix for the nothing at stake issue PoS has been widely criticized for. We have taken precautions to ensure this block rejection can’t split the network. The fix referred to by Sunny and Sentinelrv comes from the NuBits code base. This is another example of how Peercoin and NuBits will strengthen each other.[/quote]

Excellent, I cannot wait until that criticism is dead and gone forever!

23

[quote=“Jordan Lee, post:21, topic:2849”][quote=“Sentinelrv, post:20, topic:2849”]Sunny gave an update about Sigmike’s proposal here…

http://www.peercointalk.org/index.php?topic=3344.msg32385#msg32385

The NuBits project has implemented a change that rejects blocks if the same stake has produced multiple blocks within a short time window. This is a fix for the nothing at stake issue PoS has been widely criticized for. We have taken precautions to ensure this block rejection can’t split the network. The fix referred to by Sunny and Sentinelrv comes from the NuBits code base. This is another example of how Peercoin and NuBits will strengthen each other.[/quote]

Couldn’t the attacker simply use multiple stakes? This would be the same odds of producing successive blocks right?

24

[quote=“Jordan Lee, post:21, topic:2849”][quote=“Sentinelrv, post:20, topic:2849”]Sunny gave an update about Sigmike’s proposal here…

http://www.peercointalk.org/index.php?topic=3344.msg32385#msg32385

The NuBits project has implemented a change that rejects blocks if the same stake has produced multiple blocks within a short time window. This is a fix for the nothing at stake issue PoS has been widely criticized for. We have taken precautions to ensure this block rejection can’t split the network. The fix referred to by Sunny and Sentinelrv comes from the NuBits code base. This is another example of how Peercoin and NuBits will strengthen each other.[/quote]
Thank you for this explanation.

But I think that rejecting blocks on a client level will not silence the critics. I think Sigmike proposed this change due to the fact that there should be incentive to keep minting keys private. I.e. if someone publishes his minting key to the public, he has to fear that another person submits a block for him as well and in result there wont be any reward.
I think, in terms of security, we will not win very much compared to Sunny’s implementation.
Here is the reason:
Let’s say we have a egoistic minter. He finds a valid kernel and submits it to the main chain. After the main chain found another block on top of the egoistics minter block, the egoistic minter can mess around with his kernel -the kernel should be valid for two hours - and submit it to any other chain. Thus he can participate for free in a bribery attack or he can just support a parallel chain, in case this parallel chain overtakes the mainchain. Under normal conditions, i.e. most clients run the official code, the second submit of the kernel will be thrown away. But If there are many egoistic minter with modifed sourcecode, theoretically, there might be a problem. That is why punishing minting on a protocol level would be better.

25

There seems to be some criticism here. Just letting Sigmike and Jordan know…

http://www.reddit.com/r/peercoin/comments/2fytcl/nothing_at_stake_criticism_may_soon_be_gone_for/

26

[quote=“Sentinelrv, post:25, topic:2849”]There seems to be some criticism here. Just letting Sigmike and Jordan know…

http://www.reddit.com/r/peercoin/comments/2fytcl/nothing_at_stake_criticism_may_soon_be_gone_for/[/quote]

Could be my fault for titling it the way I did. No one claimed to have solved it, just applying a fix.

27
Thus he can participate for free in a bribery attack or he can just support a parallel chain, in case this parallel chain overtakes the mainchain.

Doesn’t it imply the fact that the attacker is duplicating his stake and therefore undergoing the disincentive?
If yes, then the attacker is economically irrational, which could happen but might happen only rarely…

28

[quote=“cryptog1, post:27, topic:2849”]

Thus he can participate for free in a bribery attack or he can just support a parallel chain, in case this parallel chain overtakes the mainchain.

Doesn’t it imply the fact that the attacker is duplicating his stake and therefore undergoing the disincentive?
If yes, then the attacker is economically irrational, which could happen but might happen only rarely…[/quote]
No he is not undergoing the disincentive, if he submits the stake on another chain again after a valid block is found on his first block. If the protocol would make both stakes invalid, there is the risk of reorganization.

29

[quote=“josojo, post:28, topic:2849”][quote=“cryptog1, post:27, topic:2849”]

Thus he can participate for free in a bribery attack or he can just support a parallel chain, in case this parallel chain overtakes the mainchain.

Doesn’t it imply the fact that the attacker is duplicating his stake and therefore undergoing the disincentive?
If yes, then the attacker is economically irrational, which could happen but might happen only rarely…[/quote]
No he is not undergoing the disincentive, if he submits the stake on another chain again after a valid block is found on his first block. If the protocol would make both stakes invalid, there is the risk of reorganization.[/quote]

So what is the typical minting duplication pattern that the design of sigmike would protect the network from and is that pattern the most frequent one?

30

Do not get this discussion the wrong way. Sigmike proposal is working fine, as long as a maturity of the clients runs the right sourcecode. Only if malicious code is in the game, doubleminting has a chance. Since the incentive for a malicious code is relative negligible, we are pretty safe.

But of course it would be nicer to have a protection on protocol level. Maybe this would even open the opportunity to introduce constant block reward and hence a better incentive for minting.

31
Since the incentive for a malicious code is relative negligible

Assuming that the sigmike disincentive is not implemented, can you explain why the incentive to mint on several blockchains at the same time with the same stake is rather low?

32

the incentive to run malicious code is rather low, since there is just a chance to earn compound interests by minting on several chains.

Imagine the following scenario: you find a new kernel and you can submit this kernel to the mainchain or an attackchain. If you submit it only to the mainchain, you are risking that the attackchain overtakes the mainchain and you do not get your reward immedately. You need to wait until your stake generates a new block for the attackchain. This could take many days. But since you earn only a annual 1 % reward, although it took longer your reward is still the 1 % annual reward. You are only loosing small amounts of compound interests, if you submit your stake later.

33

Here is a quote from Gavin.

The trouble with Proof-of-stake is that there is nothing at stake." Consider the basic function of proof-of-work and the blockchain: together, they let the network come to a consensus when there are two (or more) different, competing chains. 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. [b]The trouble with proof-of-stake is there is no natural incentive stopping a miner from assigning their stake to multiple, competing chains[/b]. 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.

Here is a quote from Vitalik Buterin.

Here's what NaS means. Suppose that you have a chain C1, and then some attacker with P portion of network hashpower decides to start trying to fork your blockchain starting N blocks ago. Then, there are two competing chains, C1 and C2. Now, look at it from the point of view as an ordinary forger. You have four options:
  1. Try to forge on neither chain.
  2. Try to forge on C1 only.
  3. Try to forge on C2 only.
  4. Try to forge on C1 and C2 simultaneously.

Because there is no significant cost to forging that is external to the blockchain, like there is with PoW, (4) is an actually viable strategy (in Bitcoin, (4) would have cost you 2x as much mining power). b is clearly the best from a revenue standpoint, because it gives you a reward if either chain ultimately wins[/b], whereas the “honest” strategy, (2), gives you only rewards if C1 wins. Hence, all purely self-interested forgers will forge on C1 and C2, altruists will forge on C1 only, and the attacker will forge on C2 only. Thus, in order for the attack to win, the attacker will need to overpower only the altruists, not 51% of the entire network.

You guys are secure now because everyone is using the default client, which I presume enforces the “forge on C1 only” rule. Later on, clients designed and downloaded by users motivated solely by financial interest may well switch to double-forging. An analog of this problem exists for every PoS system to date with the exception, as I described in my article, of permanent-genesis-nobility and TaPoS.

How can Gavin say that there is no natural incentive stopping a minter from assigning their stake to multiple chains?
A minter has a huge incentive to mint only on the correct chain because if he mint all the chains and one day happens that a dishonest chain takes the place of the main chain, both the minter’s stake and the POS protocol become istantly worthless, since at that point it becomes evident to everyone that the protocol is no more a reliable safe and honest ledger.

Vitalik’s conclusion is wrong when he says: i is clearly the best from a revenue standpoint, because it gives you a reward if either chain ultimately wins[/i].
Here he is assuming that if the dishonest chain wins there will be no consequences and everybody will continue to give value to the protocol as if nothing has happened.
This is wrong because in case C2 wins both the “extra” reward you would get and your stake become worthless, so in reality you end up losing all you have and destroying the weapon that can free humanity.
So you don’t really have to be altruist to mint only on the correct chain, you just have to be mentally sane in my opinion.

Am i the only one who thinks there’s really no “nothing at stake issue” for POS?

34

I think the threat, if any, of NaS is that it increases the chance of double spend. Some scenarios -

A dishonest minter could double spend an amount that is small enough not many people notices, and only cause negligible damage to Peercoin reputation. For example the double spend attack to a web gambling site by ghash.io almost went un-noticed. The damage will be bigger when others learns about it and start to do it. Then everyone starts to do it to reduce personal loss.
It’s a case of tragedy of the commons.

A dishonest minter could double spend and sell all his Peercoins before market reacts.

Someone who wants to sabotage Peercoin wants the price to crash at the cost of his coins.

35

yes mhps I agree with you, there are situations where people might want to double mint.

I think the most critical scenario is when people are shorting ppc. Think about the scenario, where you have some ppc minting and at the same time shorting many more ppc on an exchange. Then you would profit bigtime if there occurs a double spend.

My conclusion so far:
punishing on a protocol level would help improve security and calm critics.

Thus I would like to continue to discuss the downside of a protocol level punishment.
-We have already collected that it would increase complexity and blockchain size.
-And there was the critic of Cunicula - describing a risk of reorganization - , but I think I defended my solution against this one.
-Furthermore, chronos mentioned that my solution would destroy the fungibility of Peercoin. But I don’t think that this is a major point, since you must commit an public double mint attack, before your account gets frozen and you are no longer able to mint for 3 years. In this occasion everyone sees that you committed this “crime” and there is no subjective judgement needed. It would just be a freezing by an official peercoin protocol.

Do you have any more arguments against punishments on protocol level?
If Sunny reads this, I would like to hear why didn’t you implement an punishment of double minting on a protocol level?

36

[quote=“josojo, post:35, topic:2849”]My conclusion so far:
punishing on a protocol level would help improve security and calm critics.[/quote]

From what I have seen, heavy weight critics have either been misunderstanding the facts (Maxwell) or critisizing on theoretical or priciple arguement (Cunicula, killerstorm). You can’t calm the latter ones with discouragement solutions because determined attackers will attack at any cost. There has to be a solution that places a technical hard stop to any attack.

37

[quote=“josojo, post:32, topic:2849”]the incentive to run malicious code is rather low, since there is just a chance to earn compound interests by minting on several chains.

Imagine the following scenario: you find a new kernel and you can submit this kernel to the mainchain or an attackchain. If you submit it only to the mainchain, you are risking that the attackchain overtakes the mainchain and you do not get your reward immedately. You need to wait until your stake generates a new block for the attackchain. This could take many days. But since you earn only a annual 1 % reward, although it took longer your reward is still the 1 % annual reward. You are only loosing small amounts of compound interests, if you submit your stake later.[/quote]

I see. So the economic incentive to submit your stake to several chains is not enough to justify such an action from the holder.
Now I see another potential issue with peercoin. How difficult is it for someone to create an attackchain?
If it is easy, then we would end up having to make a choice among a large amount of chains all the time, which would disrupt the network.
In the case of bitcoin and litecoin, it seems that it is very difficult because you need to accumulate proofs of work, which is energy-expensive.
But in case of peercoin, you need to accumulate proof of stake, which is not so much energy-intensive.
So I am wondering why peercoin hasnt’ had any trouble dealing with multiple forks so far…
I know; there is no economic incentive to do so but still, some malicious users may be tempted to do so, especially if they want to harm peercoin, if the process of peercoin chain creation is cheap…

38
My conclusion so far: punishing on a protocol level would help improve security and calm critics.

My understanding is that the following is already implemented:

  • detection of duplicate blockchain.
    If a duplicate blockchain is detected, the duplicate blockchain is ignored.

This should be enough to solve the nothing at stake issue, imo.

On top of that if you add a disincentive for reusing your stake, you reduce drastically the chance of stake reuse.

By the way, what would be the difference between punishing on a protocol level and on a client level?

39

[quote=“josojo, post:35, topic:2849”]Do you have any more arguments against punishments on protocol level?
If Sunny reads this, I would like to hear why didn’t you implement an punishment of double minting on a protocol level?[/quote]

I’ve resisted further comments on this thread because I was waiting to see what others have to say. Also, it appears that Jordan Lee is indicating some additional adjustments that are already being implemented in the protocol which may change the dynamics of your proposal. The primary development team is clearly aware of this ongoing criticism, so I think it is reasonable to wait and see what’s included in the next release. I can imagine many valid reasons for withholding full public disclosure of upcoming protocol changes, so I wouldn’t be too surprised or concerned about a lack of further comments from Sunny, et al. on this specific topic.

Regarding specific arguments against the proposal, I continue to stand by my overall impression that there is no compelling reason to implement punitive damages beyond the currently proposed “passive” deterrents. Clearly client-level is not invulnerable, particular with “bribery attacks” as you warn, but again, I think the risk/benefit evaluation still favors the simplicity of client-level solutions. The voting transactions remain interesting, but I believe that increased complexity in the protocol also introduces the potential for new, unexpected weaknesses as well. For example, the lower PoSdif2 for voting may increase the threat of DoS/spamming while still not absolutely preventing any massive reorganization by substantial stakeholders. Why would a very large stakeholder (or cabal) not be able to withhold votes from the main chain and then submit overwhelming votes for the attack chain when it is prepared? Furthermore, since honest stakeholders would be discouraged from submitting additional voting stakes for prior transactions for fear of punishment, the attacker(s) would seem to gain even more ownership of the alternate chain.

Ultimately, I wonder if it is actually necessary to consider a new transaction type just to record misuse of stakes in the blockchain. Why would it not be possible simply to allow all behaving clients to include all coinstake transactions (even from orphans) in their submitted blocks? The transaction outputs would be declared invalid, but the coin-age could still somehow be considered spent. This way, anyone who allows their client to sign multiple blocks will end up either contributing to the main chain or losing stored coin-age. What additional value would voting transactions provide?

Edit: Nevermind about “overwhelming” the main chain, I remember now that the whole point is that you are including total cumulative votes in the revised chaintrust calculation… I can’t believe how hard it is for me to get unstuck from my misguided intuitions and biases on this concept!

40

[quote=“mhps, post:36, topic:2849”][quote=“josojo, post:35, topic:2849”]My conclusion so far:
punishing on a protocol level would help improve security and calm critics.[/quote]

From what I have seen, heavy weight critics have either been misunderstanding the facts (Maxwell) or critisizing on theoretical or priciple arguement (Cunicula, killerstorm). You can’t calm the latter ones with discouragement solutions because determined attackers will attack at any cost. There has to be a solution that places a technical hard stop to any attack.[/quote]
I am taking a different point of view.

Cuniculas critic is this one:

Quote from: cunicula on October 17, 2012, 03:20:09 PM

You do lose a little due to compound interest. I get 1% interest a year from PPCoin. This is compounded every time I get a block. Getting the block earlier increases the compounding frequency.
I concede that the benefit is extremely small.

My problem is as follows:

  1. There is a positive incentive to adopt modified code.
  2. The modified code invalidates the proof-of-stake mechanism.

A cheap attack is to release modified code and pay new users a small amount to adopt it. Stake contributed by these corrupted clients would no longer secure the network. You depend on the residual users who decide to use the original code out of altruism. Again, admittedly just a tiny bit of altruism would suffice to motivate them.

Anyways, the broader point is that security should be created by block validity rules. These rules are enforceable. Modifiable code should not be the basis for security.
The blockchain-based solution is to require stakeholders to submit work when they submit signatures. This rule can be enforced in the blockchain.


My proposal would eliminate the first point - the fact that there is a positive incentive to adopt modified code. In fact, one would get a punishment if one uses the modified code and mints on several branches. Hence it would resolve this kind of critics completely! Can you argue that?

and Sunny’s answer to Cunicula was:

This probably belongs to the same type of issues as the other open issue that minters may stop processing transactions. I generally consider under these type of situations most rational nodes would not try to modify client to gain very little profit. Tragedy of the commons most likely does not apply as the gain is minimal.

Ideally it would be nice to not have this type of issues, but in practice it might not be easy to completely rid of them given the design goals and other more serious attacks to defend. Also if it’s true that users are easily bribed to adopt corrupted clients, then there are likely a lot more tragedy of the commons type of attacks to all cryptocurrencies including bitcoin.


Fromhttps://bitcointalk.org/index.php?topic=101954.msg1278690#msg1278690

Thus Sunny admits that something like my proposal of punishment on a protocol level would be ideal, but his argument is that it opens new vulnerabilities. I would like know them!

killerstroms bribery attacks have a very small probability to succeed. But since they can be carried out for free, you can try as often as you want. Thus they might be dangerous. Just a small discouragement could do wonders, because then there are small cost and you will not participate in a bribery attack very often.
Of course, this does not completely resolve the problem, but even Bitcoin has not completely solved this problem.