What stops me from POS minting several different chains at once?

I’m confused.

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.[/quote]

Let me preface this with: I have yet to read the Peercoin source code.

How can this be the case? The blockchain solves the problem of consensus on ordering of transactions, similarly to a regular double spend, couldn’t an attacker try to double spend their stake by sending one stake generation to some nodes, and a different one to others? Now the entire network is out of sync with regards to stake, and it has no method to consense, I assume that is an unacceptable outcome, so that must not be the case. Am I mistaken?

Also: I’m new to the forum, I’ve been following peercoin for some time and I want it to succeed since I’m somewhat doubtful about the long term stability of PoW networks. Still, PoS is a hard problem and I’m not convinced it’s solved in peercoin right now, which is why I’m participating in this thread! I also independently started a reddit thread out of curiosity just today (someone linked me here from there, so here I am)

I think what we need to do initially is stop arguing in technical babble geekspeak in order to come up with a real world plausable scenario, and then see how the Peercoin network would adapt.

I’ll come up with the scenario, and see how it could be executed:

Use an example of a blackhat person named Jack, who is sinister and evil.

Jack wants to “double spend” a transaction.

How would he do that with his stake, or minting orphan forks? That everyone is arguing about?

How can this be the case? The blockchain solves the problem of consensus on ordering of transactions, similarly to a regular double spend, couldn’t an attacker try to double spend their stake by sending one stake generation to some nodes, and a different one to others? Now the entire network is out of sync with regards to stake, and it has no method to consense, I assume that is an unacceptable outcome, so that must not be the case. Am I mistaken?[/quote]

Indeed this is a problem. I checked the source code again. This is certainly why Sunny allows duplicate “when there is orphan child block” (https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1987). (And not to allow initial download as I first thought)
In the situation you describe, each node will accept only one block and refuse the other one, but only until an orphan child of the rejected block appears.
So when the network is split like this, the first new block propagating will force its parent block to be accepted even if it’s a duplicate one.

I’m new here too.
Studying the source code was long but very instructive and reassuring because I found the most of the answers I was looking for.

I believe on the contrary that technical speak is best to answer these questions, where the final answer lies in the source code.

[quote=“ppcman, post:22, topic:1394”]I’ll come up with the scenario, and see how it could be executed:

Use an example of a blackhat person named Jack, who is sinister and evil.

Jack wants to “double spend” a transaction.

How would he do that with his stake, or minting orphan forks? That everyone is arguing about?[/quote]

This is an interesting question but also very vast. Maybe another thread would be better?

I understand what you are saying but it still seems theoretical to me, and unrealistic. Is there anyway someone can diagram or mathematically prove that there is any benefit to minting on several chains at once? Using your example, I can see how you can say you have nothing to lose by minting BOTH chains; but what I don’t understand is what do you actually have to gain from this? I can see how a rational person would mint both if there was a benefit to it. I just don’t get where you come up with figures such as 90% and 10%. How do you calculate that there actually is a benefit?
Can you explain how over time someone will have a marginal increase in total return by minting multiple chains? It seems to me that it doesn’t matter, because ultimately once you mint on an accepted chain, the coin age gets depleted, and you just have to wait for more coin age just like everyone else.

[quote=“sigmike, post:23, topic:1394”]Indeed. I checked the source code again. This is certainly why Sunny allows duplicate “when there is orphan child block” (https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1987). (And not to allow initial download as I first thought)
In the situation you describe, each node will accept only one block and refuse the other one, but only until an orphan child of the rejected block appears.
So when the network is split like this, the first new block propagating will force its parent block to be accepted even if it’s a duplicate one.[/quote]

I looked over the source and it appears that you may be right about the standard client performing this check. This is entirely irrelevant though, because there is nothing to stop me from commenting out some of these redundancy checks, compiling my own client, and minting on multiple chains concurrently. In other words, this cannot be enforced at the protocol level currently, only by the client. Remember, when bitcoin mining started everyone was using the bitcoin client to mine (something nobody does anymore). The protocol needs to be robust enough to prevent scenarios like this.

[quote=“AlphaBar, post:25, topic:1394”][quote=“sigmike, post:23, topic:1394”]In the situation you describe, each node will accept only one block and refuse the other one, but only until an orphan child of the rejected block appears.
So when the network is split like this, the first new block propagating will force its parent block to be accepted even if it’s a duplicate one.[/quote]

I looked over the source and it appears that you may be right about the standard client performing this check. This is entirely irrelevant though, because there is nothing to stop me from commenting out some of these redundancy checks, compiling my own client, and minting on multiple chains concurrently. In other words, this cannot be enforced at the protocol level currently, only by the client. Remember, when bitcoin mining started everyone was using the bitcoin client to mine (something nobody does anymore). The protocol needs to be robust enough to prevent scenarios like this.[/quote]

If you change your own client the other nodes will still behave like this. They still won’t accept your duplicate block (unless there’s already a new chain based on it).

[quote=“sigmike, post:26, topic:1394”][quote=“AlphaBar, post:25, topic:1394”][quote=“sigmike, post:23, topic:1394”]In the situation you describe, each node will accept only one block and refuse the other one, but only until an orphan child of the rejected block appears.
So when the network is split like this, the first new block propagating will force its parent block to be accepted even if it’s a duplicate one.[/quote]

I looked over the source and it appears that you may be right about the standard client performing this check. This is entirely irrelevant though, because there is nothing to stop me from commenting out some of these redundancy checks, compiling my own client, and minting on multiple chains concurrently. In other words, this cannot be enforced at the protocol level currently, only by the client. Remember, when bitcoin mining started everyone was using the bitcoin client to mine (something nobody does anymore). The protocol needs to be robust enough to prevent scenarios like this.[/quote]

If you change your own client the other nodes will still behave like this. They still won’t accept your duplicate block (unless there’s already a new chain based on it).[/quote]

Well, it’s probably [citation needed] rational to continue to forward other blocks as long as they aren’t competing with one of yours. Assuming it is rational (pending further thought) I suppose it’s also rational for users to run modified clients which forego this check and happily forwards all blocks received. Given a certain density of these modified clients, the “nothing at stake” problem returns, as they can (even just amongst themselves) produce the blocks needed to “free up” stake spent in losing chains. At the very least though, this is almost certainly not the current situation, but it’s worth considering alongside the rest of this.

I agree the incentive is very small, if not negligible.

In peercoin your potential PoS reward increases whatever happens because your coin age increases over time. So if you mint on the wrong chain, the only drawback is you may have to wait more. It may double the time required to get your PoS reward, but you’ll get more coins when you finally get it.

[quote=“sigmike, post:23, topic:1394”]Indeed this is a problem. I checked the source code again. This is certainly why Sunny allows duplicate “when there is orphan child block” (https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1987). (And not to allow initial download as I first thought)
In the situation you describe, each node will accept only one block and refuse the other one, but only until an orphan child of the rejected block appears.
So when the network is split like this, the first new block propagating will force its parent block to be accepted even if it’s a duplicate one.[/quote]

First of all, thanks for citing code, that helps me get “oriented” in the peercoin source code, and also conclusively answers my question. As AlphaBar mentions, it may not always be a safe assumption that all nodes are running clients which use this check, but let’s (pretty safely IMHO) assume that >99% of nodes on the network are running the mainline Peercoin client, but we’re rational, willing, and able to change our own client.

I believe our decision whether to attempt to “double spend” our stake is influenced by:

Pro.
Chance of chain being chosen
Block Reward

versus

Con.
Chance of wasting stake (Chance of being the tail of a losing chain)
Amount of lost block reward for a given time.

I’m not sure how exactly to model this, but I think we can make a reasonable attempt. I’m not prepared to at the moment though.

Chance of chain being chosen depends highly on other nodes, and we can only really guess at this, looking at the likelihood in the past of a given chain X behind the winning chain ever superceding the winning chain, the chance of wasting stake also depends highly on other nodes, but I think we can measure a baseline by figuring out the average length of orphaned chains following their fork, though I expect a network of rational miners might have a longer average length.

I understand why you may want your own duplicate blocks to be propagated, but I can’t see why you’d change your client to help other duplicate blocks to propagate. It brings you zero benefits and it adds risk to the network.

If I wasn’t able to mint in the current winning chain, I could allow alternative chains to propagate hoping to have more (or a sooner) chance to mint on that chain. I assert it’s definitely a non-zero benefit, but it may well be miniscule…

An alternative chain won’t give you more chances to generate a PoS block.

Your ability to find a PoS block is only determined by:

  • the block of the last transaction of your coins (its time, your transaction index, etc.)
  • the current time
  • the current difficulty
  • and the age of your coins.
    There’s nothing related to the current chain (i.e. recent blocks).

The code is here: https://github.com/ppcoin/ppcoin/blob/master/src/kernel.cpp#L248
A hash is generated from the block of your coins and the current time, and it’s compared to the difficulty adjusted with your coin age.

So you have exactly the same probability to generate a PoS block on every chain at a given time.

sigmike - there is a small incentive for the minters to disable duplicate stake detection because the de-duplication depends on which fork you see first. This comment explains: https://bitcointalk.org/index.php?topic=101954.msg1277594#msg1277594

This discussion has been useful to me. I am starting to agree with Sunny that this incentive is so tiny that it will not lead to a tragedy of the commons and that using an alternative client to gain this advantage at the cost of network security will probably not be widespread. It seems the bigger potential vulnerability in PPC lies in the fact that double spend attacks are not costly because you do not lose coin age when you attempt an unsuccessful double-spend (maybe a subject for another thread).

An alternative chain won’t give you more chances to generate a PoS block.

Your ability to find a PoS block is only determined by:

  • the block of the last transaction of your coins (its time, your transaction index, etc.)
  • the current time
  • the current difficulty
  • and the age of your coins.
    There’s nothing related to the current chain (i.e. recent blocks).

The code is here: https://github.com/ppcoin/ppcoin/blob/master/src/kernel.cpp#L248
A hash is generated from the block of your coins and the current time, and it’s compared to the difficulty adjusted with your coin age.

So you have exactly the same probability to generate a PoS block on every chain at a given time.[/quote]

Thanks for linking code again. Hrm, it looks like GetKernelStakeModifier() doesn’t do what I thought, it changes over time rather than every block, so I guess you’re right there’s no point in that.

[quote=“AlphaBar, post:33, topic:1394”]sigmike - there is a small incentive for the minters to disable duplicate stake detection because the de-duplication depends on which fork you see first. This comment explains: https://bitcointalk.org/index.php?topic=101954.msg1277594#msg1277594

This discussion has been useful to me. I am starting to agree with Sunny that this incentive is so tiny that it will not lead to a tragedy of the commons and that using an alternative client to gain this advantage at the cost of network security will probably not be widespread. It seems the bigger potential vulnerability in PPC lies in the fact that double spend attacks are not costly because you do not lose coin age when you attempt an unsuccessful double-spend (maybe a subject for another thread).[/quote]

Thanks for pointing to the bitcointalk reference. The problem is perhaps not only in loosing compund interest itself but that many small coin holders aren’t expected to see a POS block for a very long time, hence are discouraged to borther with POS alltogether. There are 21 million PPCs so if you have 21PPC, your chance of getting one POS block is about one in a million. There are 144 POS blocks per day, you can expect to find a POS block in about 19 years. So as an incentive to keep the network secure, the POS reward is rather distant unless you own more than hundreds of PPCs. There are other ways to increase the speed of finding a POS block without even modifying the source code such as here. Frankly if PPS has an explosion of valuation, I don’t see why many people don’t use a wallet with a “quicker” POS minter to get POS reward soonner and get compound interest.

edit: corrected error in POS blocks/day

So the official client is only minting with one hash per second? Doesn’t this mean I could make a “minter” program which hashes as fast as it can? What about Peercoins energy efficiency if I do this? I would waste more electricity this way.

So the official client is only minting with one hash per second? Doesn’t this mean I could make a “minter” program which hashes as fast as it can? What about Peercoins energy efficiency if I do this? I would waste more electricity this way.[/quote]

That is what I remembered. It’s a low number for a low difficulty to meet the 10min/POS-block target.

If you hash multiple times in the same second, you’ll get the same hash each time. This is because the hash is based on static data + the current time in seconds.

Wow, that is an impressive idea. Hashing static data + Time means one block per second. Nevertheless, I could use a 10 second window for my timestamp to generate 10 hashes a second, right?

Let me try to explain Multiple Stake Minting:

If there are two blocks with the number 10,000 found within seconds of each other, both propagate the network. Now, other minters can not know which of these two blocks will be in the longest chain. The longest chain is decided once one fork finds block 10,001. Other minters SHOULD mint both chains to get the best chances on getting a Proof-of-Stake reward.

Yes you can generate the 10 hashes of the next 10 seconds in 1 second. But if you repeat the process the next second, you’ll get 9 hashes you already have and only 1 new. So you’re back to 1 per second.

You can generate hashes for many seconds in advance, but your block may be rejected if the timestamp is too far in the future.

[quote=“lacksfish, post:39, topic:1394”]Let me try to explain Multiple Stake Minting:

If there are two blocks with the number 10,000 found within seconds of each other, both propagate the network. Now, other minters can not know which of these two blocks will be in the longest chain. The longest chain is decided once one fork finds block 10,001. Other minters SHOULD mint both chains to get the best chances on getting a Proof-of-Stake reward.[/quote]

That’s what was discussed above.
You have the same chance to find a block on each chain. So you don’t get more chances on finding a block.
What you get is only more chance that your block will end up in the main chain instead of the orphaned one, at the cost of destabilizing a little the network.
In the other hand if you don’t do that and you end up having minted on the wrong chain you only loose time, not reward. You’ll get your reward later (along the new accumulated reward).