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

smoothie

legendary

Activity: 2492

Merit: 1473

LEALANA Bitcoin Grim Reaper

Quote from: Sunny King on February 18, 2013, 10:09:17 PM

Smoothie, there is nothing to hide. I already discussed in my weekly updates thread a couple of weeks ago the general outline of it. If you are interested in studying it why don't you get started with the source code and then post intelligent questions in my disclosure thread for discussion?

I beg to differ. You briefly mentioned using previous block hashes to determine new POS hash.

That doesn't really say much.

But okay I will take a look at the code and as I am sure others will be looking at it as well.

To be honest, I'm not sure why you are forcing people to look only at the code as opposed to publicly disclosing your algorithm. Satoshi didn't have a problem with disclosing his...not sure why you would...but okay have it your way.

Sunny King

legendary

Activity: 1205

Merit: 1010

Smoothie, there is nothing to hide. I already discussed in my weekly updates thread a couple of weeks ago the general outline of it. If you are interested in studying it why don't you get started with the source code and then post intelligent questions in my disclosure thread for discussion?

smoothie

legendary

Activity: 2492

Merit: 1473

LEALANA Bitcoin Grim Reaper

Quote from: Sunny King on February 18, 2013, 06:52:15 PM

0.3.0 Released!

https://bitcointalksearch.org/topic/ann-ppc-ppcoin-030-release-upgrade-required-144964

Cheers!

You really need to disclose the new POS algorithm publicly.

I'll eventually get around to looking through the code but you may as well open up the discussion.

I mean, seriously, what is there to hide? You've been very quiet when it comes to discussing this particular topic in detail.

Why is that?

Sunny King

legendary

Activity: 1205

Merit: 1010

0.3.0 Released!

https://bitcointalksearch.org/topic/ann-ppc-ppcoin-030-release-upgrade-required-144964

Cheers!

AndyRossy

sr. member

Activity: 448

Merit: 250

cant wait for the new protocol

Sunny King

legendary

Activity: 1205

Merit: 1010

Quote from: doublec on February 17, 2013, 12:37:23 AM

I fired up bitparkings ppcoin exchange cold storage wallet to top up the exchange hot wallet and immediately found 85 POS blocks consecutively in a few minutes. Wow.

This is one of the issues hopefully addressed by the new protocol. As difficulty rises there would be more coins under active hashing thus increasing protection of the network.

Balthazar

legendary

Activity: 3108

Merit: 1359

Quote from: Sunny King on February 17, 2013, 12:11:34 AM

Quote from: Balthazar

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.

Yes, P2pool using additional coinbase output for user statistics distribution.

smoothie

legendary

Activity: 2492

Merit: 1473

LEALANA Bitcoin Grim Reaper

Quote from: doublec on February 17, 2013, 04:25:20 AM

Quote from: smoothie on February 17, 2013, 04:10:22 AM

Not with checkpointing in place as the solution.

Even with checkpointing it would be interesting. The blocks came very fast. If the target got 6 block notifications before a checkpoint had time to go out and be received it could have been double spent.

sounds so broken at this point...

most people who were interested in PPC are losing interest with all the delays in this new POS development.

I just find it odd that Sunny has not discussed the POS algorithm he has been developing and also not asked for community input.

It isn't a bad thing to ask for help when you need it. And if you feel you dont need help at least disclose the direction of the algorithm so people can test it.

The way I see it is if you finally release the new source and someone finds an exploit in the new POS alg, that could be 8 weeks of people waiting for nothing.

Seems like a bad approach...

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: smoothie on February 17, 2013, 04:10:22 AM

Not with checkpointing in place as the solution.

Even with checkpointing it would be interesting. The blocks came very fast. If the target got 6 block notifications before a checkpoint had time to go out and be received it could have been double spent.

smoothie

legendary

Activity: 2492

Merit: 1473

LEALANA Bitcoin Grim Reaper

Quote from: punin on February 17, 2013, 03:58:10 AM

Quote from: doublec on February 17, 2013, 12:37:23 AM

I fired up bitparkings ppcoin exchange cold storage wallet to top up the exchange hot wallet and immediately found 85 POS blocks consecutively in a few minutes. Wow.

Doesn't this give you possibilities for massive double spend?

Not with checkpointing in place as the solution.

Still waiting on the release of the so-called "new POS alg".

It's been about 6-8 weeks now at least since Sunny started redesigning the POS alg.

punin

hero member

Activity: 560

Merit: 500

Quote from: doublec on February 17, 2013, 12:37:23 AM

I fired up bitparkings ppcoin exchange cold storage wallet to top up the exchange hot wallet and immediately found 85 POS blocks consecutively in a few minutes. Wow.

Doesn't this give you possibilities for massive double spend?

doublec

legendary

Activity: 1078

Merit: 1005

I fired up bitparkings ppcoin exchange cold storage wallet to top up the exchange hot wallet and immediately found 85 POS blocks consecutively in a few minutes. Wow.

Sunny King

legendary

Activity: 1205

Merit: 1010

Quote from: Balthazar

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.

Balthazar

legendary

Activity: 3108

Merit: 1359

Quote from: rdponticelli on February 16, 2013, 08:27:54 PM

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

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

rdponticelli

sr. member

Activity: 325

Merit: 250

Our highest capital is the Confidence we build.

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

legendary

Activity: 3108

Merit: 1359

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

sr. member

Activity: 325

Merit: 250

Our highest capital is the Confidence we build.

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

Sunny King

legendary

Activity: 1205

Merit: 1010

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);
}
}

Sunny King

legendary

Activity: 1205

Merit: 1010

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

legendary

Activity: 1205

Merit: 1010

Quote from: dreamwatcher on February 07, 2013, 11:59:24 PM

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!

Topic: [ANN] [PPC] PPCoin Released! - First Long-Term Energy-Efficient Crypto-Currency - page 106. (Read 684839 times)