Topic: [ANN] [PPC] PPCoin Beta Release Soon (Read 18958 times)

Update:

Release build (including source code) is now available at http://www.ppcoin.org/.
(Sourceforge)

Too bad the release doesn't follow the Alt-coin RFC

The RFC only represents my opinion and nothing else, and you're free to ignore it of course.
Key elements from your launch, that I'm missing, is a better launch schedule.

When coins are released too quickly, this creates an unfair advantage to early adopters until information about the coin spreads and is evaluated by the community.

I'm looking forward to reading your whitepaper, will do it in a day or two.

Good luck!

Thanks for the comments. Once the beta release settles down a bit I may get around to answer some questions and concerns.

I have created a wiki page and provided a sample ppcoin configuration file.
Release builds will be available shortly.

As I understand it, you are not distributing txn fees to proof-of-stake 'miners'. Instead, you are destroying txn fees. Is that right?

I am concerned that proof-of-stake miners may fail to include txns in the blockchain, since inclusion does not benefit them.

Also, as I understand it, you can contribute stake without necessarily submitting significant work to accompany it. There are two issues with this:

1) It make double-spend attacks easier because they no longer have meaningful hardware and electricity requirements.
2) Stake-owners might create alternate histories. i.e. Say I utilize aged coins at block t to mine a block. At block t-1, my aged coins still exist and can be used to mine another block. If I have nasty inclinations, I could utilize my aged coins multiple times and create several different branches at block t. Subsequent miners would not be able to easily distinguish which one of these branches is the "correct" fork and thus add to them all.

If you require significant work to accompany stake (e.g. by making the proof-of-work difficulty target a decreasing function of the aged coin stake accompanying the work), then you could avoid problem 2 entirely. I suspect that you could also substantially alleviate problem 1 as well. I believe that incorporating a significant proof-of-work submission would substantially increase the number of aged coins you need to successfully carry out a double spend (fixing the probability of success and the number of blocks you are trying to roll back).

I hope that you will look for ways to address double-spends without relying on the stop-gap measure of checkpoints. Checkpointing is quite unpopular. Incorporating a larger proof-of-work component and requiring people to wait longer to have confidence in the irreversibility of high-value sends might be a better solution.  

Anyways, delightful to see a beta and I hope people will play around with attacking it.

Yeah, Voices from Beyond the Veil are telling me that "continuous adjustment" is likely to end in tears.

First, what Syke said.
Master-checkpoints are too similar to Soiledcoin's "cop nodes", and much like soiledcoin's cop nodes could trivially be used to rollback/freeze a TX a certain government's lackeys dislike, should said lackeys grab the dev by the cojones (which is so much easier when one of the devs has provided what seems to be his IRL name in the whitepaper)

Second, I'm no analyst but this


Seems like a really bad move.

With bitcoin, you could use Finney attacks to take candies from babies who didn't wait for 2-5 confirms, and you needed a large pile of expensive equipment and electricity to do so.

With this design, you can take candies from babies who don't want to wait for "central checkpoint" message to "immortalize" their TX with but a pile of old coins.
And then you just wait for your pile of coins to "age again" and take the candy from another baby.
RINSE
REPEAT

And the only way the baby can counter that is waiting for the kind central checkpoint. Which makes one wonder just how often will it happen.

Third, "continuous" adjustment of not one, but two targets seems like an extremely...
...bold...
... move.

I mean, if continuous adjustment is such a wonderful idea, why didn't bitcoin devs switch to continuous adjust already?

No, it's not acceptable.

DOA blockchain. I'm sure there will be some pump-n-dump, but in the end, it'll die.

Looking forward to this

Update:

Our paper is now published at http://www.ppcoin.org/.

Release builds have been completed and block chain is on schedule to start at

SUNDAY 2012-08-19 18:00:00 UTC

Release build and source code will be released 5 minutes before block chain start time.

Thank you for your support!

So, how about some more info on how your implementation of proof-of-stake works ? Any juicy techy bits ?

Come on guys, making people learn your mechanics from code is just mean 

I will be there on sunday to support you with your coin best of luck and hope the release goes ahead!!

Will u be releasing a wallet and miner??


BTC: 18R5YiVKqtEsru8y4wCANQPJ81AJCk5Esi
LTC: LbMPUzwPRkWa5hCJGrEiRCeoYExY6Ujt1D
LQC: vbJVpeF82Ezd3Dx8ubWeiFeEguFwPctzJL
I0C: jU8MuSJcw7XmauyddGFSoo5HzEAPgjxfsz
IXC: xhUfkeNiVGaWFkEcuv8tTUGHX6PLt9dZ94

We are busy preparing the final build of the release. Official block chain is tentatively scheduled to start at SUNDAY 2012-08-19 18:00:00 UTC

Disclaimer: This is experimental beta software so play at your own risk. We reserve the right to restart block chain should severe flaws require such actions but we will try our best to avoid such scenario as much as possible.

Release builds will be available for download a few hours before the scheduled block chain start time. Source code and design paper will be available around the same time or earlier.

Thank you for your support!

smoothie: proof-of-work uses same hash of Bitcoin, sha256 times 2. You should be able to use most Bitcoin mining tools although we have only tested with cgminer.

Etlase2: there is good reason that checkpoint is still needed in the first place, even when network is matured and one does not care about practical impact of large reorganization of the block chain. Once more detail of the design is made public later this week I can discuss more about that. Although for practical reasons we favor having a more limited time checkpoint such as less than one day behind the latest block to guarantee the safety of large transfers, at the very least during the early stage of the network.

Can you elaborate on how the proof of stake will work? And why is a central checkpoint involved if there is proof of stake?

And personally I wouldn't use the same license as bitcoin as it allows closed source developing. Or at least release the daemon under GPL and the client under MIT if necessary.

 11 Posts and you have almost been a year on this? I know I sound like an ass when I say this but seriously. You think BBQ Coin II: Judgement Day is really worth it? You might stand to make more money by putting this effort into an existing project. No one is asking the right questions here. Probably because like i said BBQ2 J-Day.

What algorithm are you using to mine with?

Mining is compatible with Bitcoin mining, but not merge-minable with Bitcoin.

Regarding checkpointing I know it's going to be controversial so I'll try to explain here:

 - Centrally broadcasted checkpointing is not considered part of the immutable core of the protocol, but is needed to make commerce practical as proof-of-stake is somewhat weaker in protection against double spending. Initially it is enforced strongly to protect against malicious powerful miners during the early mining stage. In the future it may be relaxed or replaced with a decentralized version should such algorithm become ready.

 - We consider the checkpointing mechanism a more centralized version of Bitcoin's checkpointing, but not as centralized as SolidCoin's trust node. This is because if the node generating checkpoints fails or disconnects, block chain still continues, but in SolidCoin's case if trust node fails block chain would stop, and that's why they need 10 of those I think. So checkpoints are a centralized form of protection of the block chain, but that doesn't invalidate the purpose of miners/minters as block chain can run on it's own without the protection of checkpoints, albeit with some higher risk.

  - We did fret over this issue during our development, but this is currently the best practical solution we deem ready for release. I am sure we will revisit this topic in the future.

Hope this helps.

Gpu mining? Cpumining?

I see the next version of SolidCoins.

If it is some king of "centralized", already "51% protected"... Why it needs the miners?