Topic: [ANN] [PPC] PPCoin 0.3.0 Release - Upgrade Required - page 2. (Read 20827 times)

This morning  I performed upgrade. Coinotron is using version 0.3.0 now.

2 days left before protocol switch to v0.3. Please upgrade to 0.3.0 as soon as possible if you haven't done so.

Just use any standard bitcoin miner. Largest pool is http://ppcpool.bitparking.com/pool

hi how can we mine for it?

ppcoin-0.3.0-win32-setup.exe is for Windows. mac build is not supported right now.

Is there going to be a client for windows or mac?

Reminder that upgrade to 0.3 is required before March 20th.

Yes Qt GUI is included in v0.3.0. For windows you just download ppcoin-0.3.0-win32-setup.exe and run it to install.

Great coin!

I have some difficulty understanding how to install it in Windows. Could someone provide a simple guide for downloading and installing PPCoin in Windows?

I assume a GUI is included?

Reading up on this coin and getting more and more enthusiastic 

Reminder that upgrade to 0.3 is required before March 20th.

You can mine both types of blocks with the qt version, I can confirm this still works in 0.3.

Does the QT version also do the proof of stake calculation or do I have to run the daemon?

CheckStakeModifierCheckpoints() is just used to make sure the stake modifier computation is deterministic and every node computes to the same value. It's only checked with a few blocks, like the hard checkpoint that bitcoin uses.

It's not actually part of the protocol itself. The reason it was there is because of the complexity of modifier computation there could be bugs that made it non-deterministic. I put it there just so if someone runs into it then I would know a bug exists with the modifier computation.

Each block stores its then-current modifier in its block index. When stake hash is computed, the coin (txout) generating the stake kernel must hash with the modifier that's 9 days into the future of the coin. There is no central clock involved.

As I understand it, PPCoin's original POS has a problem that the POS is really POW in disguise: miners could twiddle values fast and do computation to boost their PoS chances. This is a typical problem for PoS systems: "nothing is at stake", holding something doesn't translate into a finite resource you consume as you attempt to mine. Likewise, they could manipulate timestamps to improve their stake effectiveness.

You appear to have fixed this by constraining the values that can be twiddled for POS, so extra twiddling can't give you a gain over other miners. This produces a problem that no active PoS miners may be able to solve a block, so it appears that you've fixed that by using your checkpoint mechanism as a centrally controlled TICK that announces a modification value the PoS miners include in their PoS (CheckStakeModifierCheckpoints()).  So now the speed of PoS searching is ultimately limited by how fast your checkpoint clock 'ticks' by announcing new modifications.   Have I got that right?

[Edit: I pulled out a bunch of conclusions which are probably wrong, in the likely case that I'm wrong above.]

Of course, I could be totally off in space. Reverse engineering behavior from source takes some effort, and I did nothing beyond letting the diff scroll over my screen— I'm mostly only interested in what you're doing academically, and that would better wait for someone to produce a clear writeup of it.

Checkpoint still needs to be strong as that's how the network survived the vulnerability in 0.2. Also ppcoin market is still tiny it's easy to buy a bunch of coins and try controlling via proof-of-stake.

I am not aware of any centrally controlled clock that you are talking about. Could you expand on that?

Yes, if your block is the last selected block you can change 1 bit of the modifier (giving you two choices). It's a slight advantage, not enough to pose immediate threat like in v0.2 protocol.

The only dishonesty here is your claim that I've been dishonest. As you can see in the thread, Joel has (generally?) agreed with every attack scenario on the ripple distributed consensus I've proposed. It's unclear how serious they might be because its unclear how validator trust would be configured. Joel points out that in practice it might be fine.

Actually _disclosing_ how a thing that you're asking people to use and put value it works is the most effective remedy to people spreading 'dishonesty' about it. Secrecy doesn't prevent someone who wants to make dishonest claims is not at all inhibited by secrecy. Quite the opposite, being secretive about it is an open invitatation for people to speculate that it works however they want to claim it works— both in more secure than reality and less secure than reality directions.

I certainly agree with not giving people exploit walkthroughs on systems people depend on... but that doesn't excuse swapping out a consensus algorithm and not explaining how its supposed to work. No point in arguing it— Sunny can shy the sunshine as much as he likes: everyone else is free to run far, far away.

If anyone wants to speculate on the changes: here is a diff to get you started.

I do note that the "eventually be removed" centralized control over the blockchain identity are still there, even though the system has transitioned to mostly POS mining, and in fact it seems to have been made _much_ more central to the system: Now a centrally controlled clock must tick to advance the stake search. It also seems to me that whomever can create these modifiers could also use computation to choose ones that advantage their own stake.

Reminder that upgrade to 0.3 is required before March 20th.

This kind of proves the point that the design should be discussed openly.

What is the problem with that? Do you fear that by discussing it publicly that someone may find an exploit in your algorithm? Gavin makes a valid point that the two he mentions in QUOTES are worlds apart.

not sure what all the secrecy of the design is about....but then again like you said...we'll just have to resort to the code which limits the participants in the discussion to only those who know how to read source code. In my opinion that is close-minded.

But to each his own.

Glad Gavin commented on this.

No problem, thanks galambo 

I think your difficulty adjustment is a pretty good demonstration that cryptocurrency is not as delicate as a lot of people claim it is. Also see the 'resurrection' of BBQCoin.

However, I'm not sure if it is a good idea to use your idea for a coin as large as bitcoin. I'm still inclined to think that using a average of many past points is better than an EMA for this application. Who knows, you may be right.

Anyways, congratulations. I haven't had the chance to see what the problem was. Programming is not my background, to be honest.