Casper for Peercoin

This thread will be aimed at answering the question of “what would it look like?” and “how?” It is specifically not for “should we?” or “why not?”

I will take most of my understanding of casper from this document:

Hastened Convergence

At the core of casper is consensus-by-bet. It is a mechanism by which people bond their tokens to gain stake in a betting game on which blockchain will win. This harnesses the power of competition to achieve consensus more rapidly than peercoin proof of stake. In peercoin this would seem to require minters to all participate in each block together rather than stochastically deciding a dictator for each block. One direction for this conversation is to seek a mechanism for blending stochastic block decisions with a concept of betting on whether or not a fork will happen. The other (exhaustive?) direction points toward toward finding a way for every minter to participate in each block.

Enhanced Stochastic Convergence

Take peercoin precisely as it is currently. Allow people to bond their peercoin in a betting game on which blockchain will win in the event of a fork. Force the losers to pay the winners using the bonded coins.

Let someone bond their coins to a particular block at will. Because I’m about to heavily abuse casper language here, let’s say someone “binds” X coins to block A. In the event of an orphanage of a bound block, all bound coins on the orphaned block go to holders of bound coins on the included block. So if someone binds X coins to block A, while two other people bind Y and Z coins to block B, in the case where block A is orphaned the address that bound Y coins would earn XY/(Y+Z) coins while the address that bound Z coins would earn XZ/(Y+Z) coins. The address that bound X coins to an orphaned block would of course sacrifice all X coins.

Economic Consequences

Smart clients would be made to maximize the chances of binding included blocks. Minters and miners would build on top of blocks that contain their own bets, giving them an advantage in the betting game. In what ways does this enhance convergence? Does it maintain decentralization? Are there obvious improvements such as how to do byzantine fault tolerance?

What are other possible implimentations you can think of?

Just for the sake of context, have you read through this thread?

https://www.peercointalk.org/index.php?topic=3334.msg32187#msg32187

Hrobeers… Hrobeers… Bueller

could this introduce a vulnerability where someone with a large stake could double spend by making a huge bet on an alternative chain and in consequence other bets will join him and miners will then build on that chain [self fulfilling prophecy effect]? it feels it accelerates convergence as it reduces alt chains BUT convergence might not be on the “right” chain

also if there is a big bet on a chain someone might purposely push another chain to get those coins. so this may reduce the number of alt chains, but those left might me “stronger”

[quote=“Nagalim, post:1, topic:4054”]This thread will be aimed at answering the question of “what would it look like?” and “how?” It is specifically not for “should we?” or “why not?”

I will take most of my understanding of casper from this document:

Hastened Convergence

At the core of casper is consensus-by-bet. It is a mechanism by which people bond their tokens to gain stake in a betting game on which blockchain will win. This harnesses the power of competition to achieve consensus more rapidly than peercoin proof of stake. In peercoin this would seem to require minters to all participate in each block together rather than stochastically deciding a dictator for each block. One direction for this conversation is to seek a mechanism for blending stochastic block decisions with a concept of betting on whether or not a fork will happen. The other (exhaustive?) direction points toward toward finding a way for every minter to participate in each block.

Enhanced Stochastic Convergence

Take peercoin precisely as it is currently. Allow people to bond their peercoin in a betting game on which blockchain will win in the event of a fork. Force the losers to pay the winners using the bonded coins.

Let someone bond their coins to a particular block at will. Because I’m about to heavily abuse casper language here, let’s say someone “binds” X coins to block A. In the event of an orphanage of a bound block, all bound coins on the orphaned block go to holders of bound coins on the included block. So if someone binds X coins to block A, while two other people bind Y and Z coins to block B, in the case where block A is orphaned the address that bound Y coins would earn XY/(Y+Z) coins while the address that bound Z coins would earn XZ/(Y+Z) coins. The address that bound X coins to an orphaned block would of course sacrifice all X coins.

Economic Consequences

Smart clients would be made to maximize the chances of binding included blocks. Minters and miners would build on top of blocks that contain their own bets, giving them an advantage in the betting game. In what ways does this enhance convergence? Does it maintain decentralization? Are there obvious improvements such as how to do byzantine fault tolerance?

What are other possible implimentations you can think of?[/quote]

Large stakeholders will always have power just as large miners do.
The question is: who do you trust more, a large stakeholder or a large miner?

Nothing at stake is a valid theory that we should not ignore.
It is true that a large stakeholder can double spend a transaction originating from one of his addresses if he is able to mint several blocks in a row on fork of the chain.
However, if the stake is nicely distributed this attack has an extremely low probability of success. Next to fair distribution, this is the reason ppc started out with a high percentage of PoW blocks that decreases over time.

The betting on valid forks worries me more as it opens to floor to a whole new range of attacks between bettors, like some others already mentioned.

I have to admit that I’m a bit worried by a recent happening highlighted by [member=32055]paumiau[/member]: https://www.peercointalk.org/index.php?topic=4734.msg44793
[member=33073]marloon[/member] figured out that this orphan block issue is caused by a high stake minter dominating the chain for 1.5 days.
However, even the third richest address was able to mint more than 2 blocks in a row only a handful of times during this 1.5 day streak.
For a successful attack you need to mint a long streak right after the double spent transaction while the party you are cheating on should still believe the other fork.
And don’t forget that these days the PoS difficulty is very low.

It’s all about probabilities.
If there is one thing we should fix, it is to incentivize continuous minting as it would avoid these minting streaks from large holders.
Today, a nothing at stake attack is already extremely difficult to execute by the third largest address, but forcing continuous minting would make such an attack nearly impossible.

I agree Casper theoretically fixes nothing at stake, but by doing so it opens the floor for other attacks that might have much higher probability of success.
So let’s not try to ride the hype and let’s focus on the critique that is valid and figure out how we can lower the probabilities.
Bitcoin is full of theoretical attacks, but they are difficult to execute, there is no reason to introduce complexity to fully block a theoretical attack.

maybe ETH needs casper because of the poor distribution the ICO created, and maybe they needed the hard fork because PoS would not be viable if the hacker kept the funds. liabilities that arise with complexity

Correct! And let’s not forget that Eth needs Casper for marketing.

i think it’s more for the difficulty bomb, basically their PoW is flawed

I do not want to be the Grinch but I was a little bit surprised when I saw the third richest address minted 12 blocks blocks in a row on August 10th.

Yes there is a large probability of getting a large sequence somewhere in the streak.
But you should be able to time that streak right after a double spend and make sure that the receiving party keeps following the other fork and honestly believes it received the money for a while.
And exactly that is extremely hard to do.

And don’t forget that you only cheated with your money paid to other parties you expect something in return from, just like you would tell you credit card company that you didn’t receive any goods for your payment.
Parties receiving large sums of Peercoins need to do their homework and look at the number of confirmations on all forks. (Maybe this is something PeerKeeper should report :slight_smile: )

However I still agree that we should try to avoid those minting streaks. We need to come up with a simple way to make minters mint continuously.

But this is not the major security flaw the Bitcoin and Ethereum folks are calling it.

Let me tell you a true story.

A friend of a friend (and yes, I do know the person) was a security guard at a Casino.

Someone had been playing a slot there for over an hour, and won a car…

They had brought him over to the cashier to get the forms ready, sign the release, etc.

While they were waiting for the paperwork, he asked the security guard if he could play another nearby slot while he waited. They obliged him. Two minutes later, he won another car.

This is defined as an extremely rare event. No one thought for a second he’d win a second car, but he did. (No, this isn’t that Vacation movie with Chevy chase either)… this actually did happen.

Now looking back in history, we can say:

THATS IT! ALL SLOTS ARE VUNERABLE. This guy won two cars! Do you know what the chance of that happening is? All slots need to be replaced with caper and ethereum immediately all over the world!! OMG… The sky is falling.

Historical phenomenon doesn’t gauge the present or the future.

While in the middle of that “12 consecutive” minting streak, by the 6th block, there was no way of him knowing he’d mint a 7th… the chances became increasingly rare.

Notice he didn’t mint the next 1,000 blocks?

Also, there is a 520 confirmations before that minted block is considered valid.

So they minted 12 consecutive blocks, meanwhile it requires 520 confirms before those blocks are considered valid. This is so the network can handle network latency, DDoS, outages, etc.

If anyone thinks they can predict when they are going to mint 12 consecutive blocks, I ask:

a) Tell us the blocknumber you are going to mint 12 consecutive blocks 2 weeks in advance.

b) Prove a double spend by sending a transaction to 2 different PPC addresses I give you

The answer is, no one can predict when its possible, because no one will know how many people are going to be on the peercoin network at any given second.

So stop looking at past patterns …

…they are not conclusive for the present or future. This is not a weakness in the Peercoin protocol, it’s a standard possibility that is already accounted for…

Sheesh… IS this really what these other coins need to depend on to convince people of their superiority?

We appreciate the compliment - they are attacking Peercoin socially because they know it’s robust and designed by the very author who put Proof-of-stake into production.

That says a lot about who they’re reaaally worried about. :slight_smile:

ever considered to write a book? :slight_smile:
+1

While I agree with the gyst of what ppcman is saying, I am more concerned with potential schisms that this rare lucky chance thing might cause. You are correct that predicting such an event may be hard, but what if you didn’t need to predict it to harm the network? What if you harmed it by accident by minting a ton of blocks in a row not knowing that you were mistakenly overwriting a 6 or 7 block history made by others on another side of the network. These events usually burn a lot of coindays by people that are only staking once in a great while. What if their wallet didn’t connect up properly during that once in a great while that they turned their client on? A proof-of-smart-stake like casper ensures that there are clients actively trying to prevent events like this from occurring because they hurt people’s gambling odds. No one is betting on that individual’s block spam.

Now, it’s very possible that what I describe has a very low likelihood of occurring, even if every other day someone was doing a block spam like that. It is about one person generating 6 blocks without proper network connection. I simply don’t know enough about the deep workings to know the probability of that. There’s also the concern that a big stake like that would start kicking up the mint difficulty, i.e. shortening the time between blocks. So they may mint 6 blocks in half an hour, say. What are the odds that such an event causes a 6-block rewrite? How about 12 blocks in an hour?

I want to look at this from the main chain real quick. So let’s assume it’s chugging along at 6 blocks an hour. Now, the moment someone sees one of the rapid minter’s blocks they’ll pull it into the chain and be on the rapid side of the schism. In order for this to be a problem, someone would need to see multiple main chain blocks before they even see the rapid minter’s. From the rapid chain perspective, relay from their network would need to lag behind the main chain time on the order of minutes. Let’s pretend our rapid minter has x minutes of latency immediately after they are finished downloading the main chain. It seems to me like they’d need to generate all 6 blocks in those x minutes of latency. Are there any protections in the code against generating a lot of blocks yourself during extremely long latency periods? Perhaps we can just force people to not mint more than 5 blocks themselves without accepting one from another person. Clearly anyone can just edit out that code, but then they’re basically an attacker and are probably more looking for a double spend, which we’ve said is very hard to pull off. The accidental rewrite, however, implies that they are using the standard client and are voluntary for any softforks like this.

I agree with the gyst of your concern also Nagalim.

The concern echoed in these forums lately, is for rapid transactions, traditional Proof of Stake won’t work for Ethereum. They have no choice but to come up with an alternate method.

The same problem exists with Bitshares too.

Network latency and attack vectors become increasingly more difficult to handle when you don’t have enough people on the network. This is why Sunny King mirrored Bitcoin’s 10-minute block times. It’s a good idea.

Rapid transactions are meant to happen off-chain, via side-chains or centralized chains.

What we have now, is Bitshares, Steem, ETH all trying to have the benefits of PoS, but adding in all these fancy ways of getting around the “centralization” issue. But it is centralized.

Bitshares claims that 100 witnesses is not centralized. If I can count a finite number, it’s still somewhat centralized.

Casper is talking about something similar. They want certain nodes to bet a security deposit, which means only a limited number of nodes in actual probability will be producing blocks and reaching consensus on the chain. Everyone else just listens to that consensus. This is somewhat centralized too.

We have cake. If you want icing, it should come separate from the cake, but still be useful with cake.

These guys want cake that when you bake it, the icing is already on the top of the cake. Conventional ovens can’t do that, so now they’re going to build new ovens to accomplish it.

There is no need to do all of that… Both of these technologies could have used Peercoin as a backbone currency with 10-minute blockspacing, and everything that occurred inbetween each 10 minute period could have been handled by their own systems.

I could go on and on… but eventually I’d have to produce an essay on the subject or my own deconstructive review which would be 30 pages long.

So what is it we’re talking about?

Seemingly this is what people are TRYING to talk about:

Casper and DPOS are superior to Peercoin in every aspect.

The answer is no, they aren’t. With the changes, they bring their own interesting problems yet to be seen.

We’re not competing in the same space.

To answer you specifically:

Let’s ponder this, and look at things a lot deeper if this is your genuine concern. I find it amazing that this hasn’t been a central concern that has plagued our network much over the last 4 years.

There’s probably multiple ways of addressing this issue. One of them has been checkpointing. People keep posting on these forums they want checkpointing removed. I’ve always wonder if these are sock puppets from other cryptocurrencies begging us to do it, so they can use their knowledge to try and exploit our network if checkpointing was removed prematurely.

Sunny King has suggested it might be time to remove Checkpointing as the default. It’s these types of questions we’ll need to have him make full answer towards.

Block time spacing, nodes on the network, coinage, which forks exchanges are on, are all variables, plus I’m sure there is even more. You can’t just fork the network willingly without Proof of stake with the right hash.

Forking the network against consensus “by accident”, as you put it, invalidating transactions and creating double spends, because half the world is not connected at the same time… there is a reorg procedure that can cause extra-delays during forks in Bitcoin as well. So it depends on what your moving.

If you send me a million dollars, I’m going to wait for more than 6 confirms.

If you send me 20 dollars, one confirm is good enough for me.

To reiterate this point. I spoke at length to someone who owns a Robocoin ATM. When Robocoin wanted licensing and to control everything, they wrote their own custom software on the machine. It’s actually quite trivial and possible to do…

When they first opened, 1 block confirm was enough. When they started moving serious cash, they upped it to 3 confirms. Now their machine responds “dynamically” to block generation. Where it comes from, what amounts are moving, by whom, what known miners are mining it, this, that, all kinds of stuff. Their bitcoin atm adjusts itself based on probabilities and will want more or less confirms dependent on what the health indicators of Bitcoin are. There’s a risk running that ATM for multiple reasons, and they’ve factored all of that into their code. One way or another the ATM continues to generate them profit, and they’ve built both a business model, as well as a technical flowchart to have it make sense.

One of the problems here, is that society in general, is a “headline news” based society. Some one throws up a scare in a headline, and everyone starts ducking for cover. Asking genuine questions is fine. But the emotion and energy behind such a disection of the Peercoin protocol is without warrant, because none of us have been studying the health of our network more than Sunny King himself.

He constantly comes out to answer questions, attend interviews, talk to the community, and we seem more interested in asking him things like “Do you own Peercoin?” or “Are you Satoshi” or “What other coins are you interested in?” – Really? While this is all fun. Everytime he leaves these interviews we slap ourselves in the forehead going “oh! wait! I should have asked him about this or that regarding attack possiblities, etc etc.”.

If we continue to waste his time during these types of interviews, then we only have ourselves to blame.

“If there is one thing we should fix, it is to incentivize continuous minting as it would avoid these minting streaks from large holders.” @hrobeers

Is this being worked on? I’m not sure what will be included in v0.6. @Sentinelrv - more information on PPC-specific development in the official updates would be appreciated. For example, checkpointing? cold minting?

I think fixed POS block awards would incentivize continuous minting. Each POS block award would be fixed to the amount of PPC that would, in aggregate, result in a 1% annual increase in money supply. Currently, 24M coins in circulation, divided by 365 days, divided by 144 expected blocks per day (10min/block), times 0.01 =~ 4.5 PPC per POS block. So, whoever mints the next POS block would receive 4.5PPC regardless of the PPC & coinage staked. The probabilities of minting would remain the same, but the award would be fixed, Accordingly, large holders would all have to continuously mint to retain 1% increases and small holders could choose to participate in hopes of an outsized award.

Those who expend resources and continually mint (and boost the security of the network) would receive the 1% increase in money supply; those who don’t expend resources by continually mint would no longer be able to cherrypick their 1% award by minting from time to time.

J

@Justin618

A fixed block reward would be really bad as it would gamify the minting process. Multiple different minting strategies will be worked out as the reward will be the same if you mint a large or small output. Such gamification will cost time and money that will be paid by the network and it would incentivize orphaning blocks created by others.
In the end it will result in a centralisation of minting, making it very hard for the average holder to reliably find stake.

Fixed block rewards would completely destabilise our ecosystem.

Projects like PeerAssets could incentivize continuous minting to some extend. But rather than focusing on incentivizing continuous minting, I’d focus on lowering the threshold to use your coins to secure the threshold.
I’m working on a set of RFCs to securely outsource the minting process by pre-signing stake: https://github.com/peercoin/rfcs/blob/master/text/0003-multisig-minting/0003-multisig-minting.md

1 Like

I have been thinking about the fixed block reward for a while as well, because some other coins like Clams or Orbitcoin have that, and it is good to encourage minting. But I also agree that it would gamify the minting process, which would not be good at all. I think Sigmike was also against such a change.
Now, we have the opposite where it is possible to not care about minting for 10 years, and then pop up once and claim 10% reward.

I think a good compromise would be the one that Novacoin has chosen with a cap on the minting reward. We could for example cap the minting reward at 50 peercoin. That would still be very generous.With this cap in the protocol, you would have to mint once a year with a stack of 5000 in order to not lose out. With a stack of 500, you would have to mint once in 10 years.

Reduce the length you can go and still stack coinage. Currently, a 360 day output has the same reward as a 720 day output (citation needed). Reduce that so that if you mint within, say, 120 days there is no difference with what we have now, but if you wait 180 days then you lose some potential reward.

It should be noted that this penalizes small minters.

@hrobeers - Re “centralization of minting” and “orphaning blocks” - would certainly be undesirable and should be avoided. As to “gamify-ing” the minting process, I’m not sure if this a technical concern or more of a user adverse behavior problem. If the latter, I’m not sure I understand the concern (so what if each holder breaks apart their PPC into smaller bundles and tries to mint with each - everyone else will have the same opportunity to do so - and then everyone will be minting); and if the former, I have no ability to comment.

My suggestion was based on (1) the understanding that POS secures our system and incentivizing continuous minting was needed to boost security; and (2) the widely-acknowledged understanding that currently there is little incentive to mint but a couple of times a year, or less. As a general comment- if POS difficulty is a reflection of security - then continuous minters should be rewarded and sporadic/non minters punished. And I see no problem with small holders/non-minters paying a small price (and 1% is appropriately small) to piggy-back on a system secured through the expense and attention of others.

Thanks for responding. I’m glad to hear this was already considered and not pursued by developers with a much greater understanding of the technical side than me. I believe in POS and want PPC to have the most robust POS system.

It is not that simple. You cannot ignore the fact that not everyone is equally connected to the network.
Bitcoin mining pools have there own network parallel to the standard P2P network to get a competitive advantage over miners not connected to that network.

Pooling and specialized networks will be needed to increase your chances to contribute to securing the network.

With the current fixed yearly reward there is no competitive advantage that pays for the exploitation of such networks.