[ANN] [PPC] PPCoin Released! - First Long-Term Energy-Efficient Crypto-Currency

[Sunny King]

2+ million coins mined early, yesterday little over 9k ... you really think that most people are dumb enough to buy PPC even at 0.00013 rate?

Coinotron under 10 Ghashes, BitParking under 5 Ghashes, Vircurex reports network hashrate around 135 Ghashes. That is so cool, few people
have the most old and new coins, and have enough stake to do whatever they want to, including limitless free double-spends attempts.

PPCoin is early-adopter scam coin, nothing more.

Sure you are welcome to create a no-early-adopter commie coin to compete in the market. In my opinion it's one of the architect's jobs to protect the interest of 'early adopters' because they deserve it. Welcome to the world of free market  

The first day mintage is naturally high for any publicly pre-announced coin because miners would pile in at the release. We had already done a couple things to alleviate it, by starting difficulty at 256 and continuously adjust difficulty at every block. So there are less than 1000 initial low difficulty blocks. Compare this to a coin that doesn't take these measures, for example freicoin started difficulty at 1 and has more than 10000 low difficulty blocks.

As far as I am concerned ppcoin project is currently the only project in production implementing alternative technology to bitcoin, nearly all other altcoins are carbon copies of bitcoin. So I am sure there are astute users out there that would disagree with you as to ppcoin's value.

[Jutarul]

2+ million coins mined early, yesterday little over 9k ... you really think that most people are dumb enough to buy PPC even at 0.00013 rate?

PPCoin is early-adopter scam coin, nothing more.

"If" ppcoin is a success, then 0.00013 is still a bargain. The people who mine first (2+ million coins) are not necessarily the ones which make the most profit. If the first miners sell cheap (because they had no costs), then others in the free market are there to profit from future appreciation.

Also - stay real. 2 million ppc at 0.0001BTC/PPC is 200 BTC, which really isn't a lot of value.

It seems though that the coin generation schedule is a bit off. Sunny once estimated that the coin generation should average 15-20 million PPC per year. With a fluctuation between 40k-5k, averaging 20k/day we're at 7.3 million PPC per year. So even without asics in the wild, it seems that coin generation already massively slowed down.

In any event, don't focus on the trading economics of a cryptocurrency, but on it's properties instead - that what gives it long-term value...

[Sunny King]

Vircurex reports network hashrate around 135 Ghashes.

As I have been discussing with Sunny King in PM because of all the variables in the design of PPCoin, everything changes each block, its next to impossible to calculate the real hash rate. I assure you its nowhere near 135 GH/s.

I can confirm that vircurex hash rate estimate is not accurate. However its not 'next to impossible' to estimate ppcoin network hash rate. I have already discussed this topic in my weekly update #12 last November:

• Regarding network hash rate, since ppcoin is designed with variable spacing target for proof-of-work blocks, you cannot directly compare network hash rate to other block chains based on proof-of-work difficulty. To estimate network hash rate you would need to first get an estimate of current proof-of-work spacing target (in seconds), by counting the number of proof-of-work blocks in the last 24 hours for example. The formula to calculate the total network hash rate is: hash rate = difficulty * 4G / spacing target.

Jorgeminator made a hash rate comparison between freicoin, terracoin and ppcoin, which I believe is reasonably accurate:

Here you go  

It is also next to impossible to guarantee that for a given hashrate the coin will be at a certain difficulty within a certain period of time. Our PM discussions have made me think I should apply the PPCoin difficulty algorithm to Bitcoin and demonstrate what happens. I imagine Bitcoin's difficulty would be somewhere in the trillions (or worse) with the PPCoin difficulty adjustment algorithm.

Take calculations like the one done by Vircurex, which probably assumes a constant difficulty and a 10 minute block spacing, with a grain of salt.

Why do you want to apply a variable spacing design to a pure proof-of-work coin? There is no need for that. I was only recommending freicoin to adopt the continuous difficulty adjustment, not variable spacing target. Besides I have never claimed that a high difficulty means superior network protection, so why bother? But even if you do, ppcoin only makes proof-of-work difficulty between 0x - 11x larger so I don't know where you get this trillion number.

It's true that hash rate is a good indication of network strength for proof-of-work coins, but for ppcoin it's the contrary. A lower hash rate is preferred by ppcoin, as it's an indication of energy efficiency. Indeed even as a hybrid design, ppcoin is a lot more energy efficient to a pure proof-of-work coin of comparable market cap.

[galambo]

Jorgeminator made a hash rate comparison between freicoin, terracoin and ppcoin, which I believe is reasonably accurate:

Here you go  

He did this with the numbers ABE gives out, which only works for coins that use the Bitcoin difficulty adjustment. Do you think your coins hashrate was bouncing up and down like that?

[galambo]

Here's a question for you, how is PPCoin going to remove the centralized checkpoint sharing when difficulty target is based on the immediately preceding block? What happens to a coin that does this and has a reorg? I guess that means Freicoin can't use your difficulty adjustment algorithm. This is the reason for the 8 block delay for the filter output.

[Sunny King]

Here's a question for you, how is PPCoin going to remove the centralized checkpoint sharing when difficulty target is based on the immediately preceding block? What happens to a coin that does this and has a reorg? I guess that means Freicoin can't use your difficulty adjustment algorithm. This is the reason for the 8 block delay for the filter output.

I don't know why you think deriving difficulty from preceding block(s) would cause any problem with reorganization, are you suggesting that bitcoin's block 2016*n would also have problems with reorganization? Difficulty is checked when connecting block, and it doesn't matter if you derive it from last two blocks or from last 2016 blocks.

As for Jorgeminator's difficulty chart I can't vouch for it's accuracy 100% but indeed there were several major peaks over 200ghs, because I basically check coinotron and bitparking pools pretty much every day.

[galambo]

Here's a question for you, how is PPCoin going to remove the centralized checkpoint sharing when difficulty target is based on the immediately preceding block? What happens to a coin that does this and has a reorg? I guess that means Freicoin can't use your difficulty adjustment algorithm. This is the reason for the 8 block delay for the filter output.

I don't know why you think deriving difficulty from preceding block(s) would cause any problem with reorganization, are you suggesting that bitcoin's block 2016*n would also have problems with reorganization? Difficulty is checked when connecting block, and it doesn't matter if you derive it from last two blocks or from last 2016 blocks.

As for Jorgeminator's difficulty chart I can't vouch for it's accuracy 100% but indeed there were several major peaks over 200ghs, because I basically check coinotron and bitparking pools pretty much every day.

Bitcoin's readjustment gets a rate using two times and uses that to adjust the difficulty within the limiter. The chain with the highest difficulty is the one selected by the reorganization. Every single block in your chain depends upon the last blocks difficulty. We can't use it because we don't have central check pointing to say which blockchain is the true one. It adjusts too often to lead to a stable network without central checkpointing.

[Sunny King]

Here's a question for you, how is PPCoin going to remove the centralized checkpoint sharing when difficulty target is based on the immediately preceding block? What happens to a coin that does this and has a reorg? I guess that means Freicoin can't use your difficulty adjustment algorithm. This is the reason for the 8 block delay for the filter output.

I don't know why you think deriving difficulty from preceding block(s) would cause any problem with reorganization, are you suggesting that bitcoin's block 2016*n would also have problems with reorganization? Difficulty is checked when connecting block, and it doesn't matter if you derive it from last two blocks or from last 2016 blocks.

As for Jorgeminator's difficulty chart I can't vouch for it's accuracy 100% but indeed there were several major peaks over 200ghs, because I basically check coinotron and bitparking pools pretty much every day.

Bitcoin's readjustment gets a rate using two times and uses that to adjust the difficulty within the limiter. The chain with the highest difficulty is the one selected by the reorganization. Every single block in your chain depends upon the last blocks difficulty. We can't use it because we don't have central check pointing to say which blockchain is the true one. It adjusts too often to lead to a stable network without central checkpointing.

I think you probably have some misunderstanding here. Reorganization has nothing to do with how often difficulty is adjusted, nor how many blocks are used to adjust difficulty. If you are concerned with difficulty changing every block that would weaken confirmations, yes there is a slight weakening in that attacker can override n-confirmations with his own n-blocks, n>=2, but not for 1-confirmation, as difficulty on both branches is the same for the first branching block. But no, I don't think it means you require checkpoint to protect the network, as bitcoin has the same issue albeit only every 2016 blocks. You can mitigate this problem by using older blocks to derive the new difficulty though, which forces multiple blocks on both branches to be at the same difficulty for the same height.

[doublec]

Here's a question for you, how is PPCoin going to remove the centralized checkpoint sharing when difficulty target is based on the immediately preceding block? What happens to a coin that does this and has a reorg? I guess that means Freicoin can't use your difficulty adjustment algorithm. This is the reason for the 8 block delay for the filter output.

Devcoin adjusts on every block IIRC and doesn't have checkpointing. Have you take a look how they do it?

[Sunny King]

A quick look at Chris's devcoin repository shows that devcoin difficulty is derived from previous 144 blocks (average over one day, they started this continuous adjustment at block 10700). While ppcoin's difficulty is derived from previous 2 blocks (exponential moving average over one week).

https://github.com/doublec/devcoin/blob/master/src/main.cpp#L678

[Sunny King]

It seems though that the coin generation schedule is a bit off. Sunny once estimated that the coin generation should average 15-20 million PPC per year. With a fluctuation between 40k-5k, averaging 20k/day we're at 7.3 million PPC per year. So even without asics in the wild, it seems that coin generation already massively slowed down.

Yeah current estimate would be 5m-10m coin production in 2013.

[Sunny King]

An user pmed me about paper wallet.

For now you can use command
ppcoind dumpprivkey <ppcoinaddress>
and then print it to paper

Later you can import it back to another wallet:
ppcoind importprivkey <ppcoinprivkey>

I am not familiar with paper wallet and QR code etc. Anyone has a good idea of how it works and maybe start a project to convert such a bitcoin tool for printing paper wallet?

Hi, I was wondering how do you generate a ppc address and matching private key for paper storage?

[Sunny King]

SOLVED!!

The solution involves patching PPCoin. I will put in the suggestion in github.

Basically it involves changing the base58.h file.Litecoin has an altered base58.h, and it appears that the file has to be changed whenever using a address version above 00.

In Base58.h

Code:

public:
    void SetSecret(const CSecret& vchSecret, bool fCompressed)
    {
        assert(vchSecret.size() == 32);
        SetData(fTestNet ? 239 : 128, &vchSecret[0], vchSecret.size());
        if (fCompressed)

Change the 239 to 245 (Testnet 128+117) 128 to 183 (Livenet 128+55)

Code:

public:
    void SetSecret(const CSecret& vchSecret, bool fCompressed)
    {
        assert(vchSecret.size() == 32);
        SetData(fTestNet ? 245 : 183, &vchSecret[0], vchSecret.size());
        if (fCompressed)

And again in here

Code:

bool IsValid() const
    {
        bool fExpectTestNet = false;
        switch(nVersion)
        {
            case 128:
                break;

            case 239:
                fExpectTestNet = true;
                break;

to:

Code:

bool IsValid() const
    {
        bool fExpectTestNet = false;
        switch(nVersion)
        {
            case 183:
                break;

            case 245:
                fExpectTestNet = true;
                break;

Thanks for the investigation of the compatibility issue with vanitygen. I have received the pull request and will give it a review by this weekend.

Good job!

[Sunny King]

The above change proposed by dreamwatcher is currently under review.

It appears to me that the base58 version of wallet private key is only used with dumpprivkey and importprivkey. However if anyone is aware of potential other uses that might cause compatibility issues with existing block chain/wallet please voice your opinion. I assume that there is no one using non-regular transaction types right now. I am also not aware of any transaction type that may involve base58 version of private keys.

At this point I am in favor of accepting a version of this proposal into v0.3, which means previously dumped keys via dumpprivkey would need to be dumped again once upgraded to v0.3, in terms of compatibility impact.

Any comments and concerns are very welcome.

[Sunny King]

Balthazar is working on p2pool support and asked me about getmemorypool problems.

Here is a patch needed to make it work I think (not tested yet), in addition to making p2pool aware of ppcoin's transaction format:

Code:

diff --git a/src/bitcoinrpc.cpp b/src/bitcoinrpc.cpp
index 4e17221..1ea6334 100644
--- a/src/bitcoinrpc.cpp
+++ b/src/bitcoinrpc.cpp
@@ -1994,7 +1994,12 @@ Value getmemorypool(const Array& params, bool fHelp)
         CBlock pblock;
         ssBlock >> pblock;

-        return ProcessBlock(NULL, &pblock);
+        static CReserveKey reservekey(pwalletMain);
+
+        if (!pblock.SignBlock(*pwalletMain))
+            throw JSONRPCError(-100, "Unable to sign block, wallet locked?");
+
+        return CheckWork(&pblock, *pwalletMain, reservekey);
     }
 }

[rdponticelli]

getmemorypool is removed upstream. It would be certainly better to implement getblocktemplate, if possible...

[Balthazar]

Block format of PPCoin/NovaCoin and Bitcoin is incompatible. So, there are no reasons to keep getmemotypool or merge getblocktemplate, we are free to implement new simple RPC call for our own purposes.

[rdponticelli]

Yes, obviously you're free to break every upstream api, and to implement any specific thing that you like. But the implicit cost of any unneeded divergence with bitcoin is massive, breaking compatibility with third party software which has to be adapted specifically to your coin, and making it impossible or tremendously difficulty to merge any upstream change...

[Balthazar]

breaking compatibility with third party software which has to be adapted specifically to your coin

It's already incompatible, and has to be adopted. 

[Sunny King]

It seems that current SignBlock implementation can't handle hashed public keys

Right. The node that publishes the block must write its public key into the output[0] of coinbase.

I am not familiar with what p2pool throws into output[0] of coinbase. I used to see some unknown data there on block explorers. One way is to overwrite output[0] with a pay-to-public-key output in getmemorypool, then sign the block again. However I am under the impression that p2pool is using output[0] for some specific purpose.