[ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin"

[dooglus]

I'm no expert in C, so maybe you guys who are can enlightenme a bit.  This is the code after the change, right?

Code:

return strprintf(
             "HTTP/1.1 %d %s\r\n"
             "Date: %s\r\n"
             "Connection: %s\r\n"
             "Content-Length: %"PRIszu"\r\n"
             "Content-Type: application/json\r\n"
             "Server: novacoin-json-rpc/%s\r\n"
             "\r\n"

First of all, I would have thought that strprintf would take a pointer to a char array (a C string) as its first parameter, to fall inline with fprintf (prints to a file handle) and sprintf (prints to a stream).  I would have thought it would have been strprintf(char * str, char * fmt, ...);   But it looks like the first arg here is a format (it has the formatting stuff in there %d, %s, etc).  Also, since the inner " surrounding PRIszu aren't escaped, that should mean that the string terminates and beings again, but what kind of symbol is PRIszu?  And isn't it in a weird place between two parts of a string continuation literal?

Thanks for any comments, sorry my knowledge is so rudimentary here.  I thought I knew something about C syntax but I'm totally surprised that this compiles at all.

I think your post here ages you. Since ANSI first published the C specification, writing two strings next to each other concatenates them, and so this is legal:

#define W "world"
printf("Hello, "W"!\n");

I think it only looks weird to someone who learned K&R C, pre-ANSI C.

PRIszu is conditionally #defined to %lu or some such, depending on which compiler is being used. I think the issue here is that it is #defined to the wrong formatting string - like "%lu" is being interpreted as "%l" + "u".

strprintf is also #defined, in tinyformat.h, and returns a new string object:

#define strprintf tfm::format

Are you thinking of the standard library stdio.h function sprintf()?

[dooglus]

   The Qt client shows the orphans under transactions.  I run a headless client for staking, and then a QT client for monitoring.  The QT shows the orphans, even though they are generated by the headless guy.  They have 2 different copies of the same wallet. 

What if the QT isn't running when the orphan block is staked and orphaned? Does it still show the orphan? I think it needs to 'see it happening' in real time for it to show up.

Maybe if you copy the wallet where it happened to the machine where you run QT, then QT will show the orphan. But I'm not sure.

[tspacepilot]

I'm no expert in C, so maybe you guys who are can enlightenme a bit.  This is the code after the change, right?

Code:

return strprintf(
             "HTTP/1.1 %d %s\r\n"
             "Date: %s\r\n"
             "Connection: %s\r\n"
             "Content-Length: %"PRIszu"\r\n"
             "Content-Type: application/json\r\n"
             "Server: novacoin-json-rpc/%s\r\n"
             "\r\n"

First of all, I would have thought that strprintf would take a pointer to a char array (a C string) as its first parameter, to fall inline with fprintf (prints to a file handle) and sprintf (prints to a stream).  I would have thought it would have been strprintf(char * str, char * fmt, ...);   But it looks like the first arg here is a format (it has the formatting stuff in there %d, %s, etc).  Also, since the inner " surrounding PRIszu aren't escaped, that should mean that the string terminates and beings again, but what kind of symbol is PRIszu?  And isn't it in a weird place between two parts of a string continuation literal?

Thanks for any comments, sorry my knowledge is so rudimentary here.  I thought I knew something about C syntax but I'm totally surprised that this compiles at all.

I think your post here ages you. Since ANSI first published the C specification, writing two strings next to each other concatenates them, and so this is legal:

#define W "world"
printf("Hello, "W"!\n");

I think it only looks weird to someone who learned K&R C, pre-ANSI C.

PRIszu is conditionally #defined to %lu or some such, depending on which compiler is being used. I think the issue here is that it is #defined to the wrong formatting string - like "%lu" is being interpreted as "%l" + "u".

Got it.  Thanks, I guess I forgot that it's okay to concatenate #defined symbols and string literals

strprintf is also #defined, in tinyformat.h, and returns a new string object:

#define strprintf tfm::format

Are you thinking of the standard library stdio.h function sprintf()?

Yah, I was thinking of fprintf and sprintf, both of which take the first argument as the place where the string ends up (either a File or a stream) and return value indicates success or failure or whatever.  Just taking that convention, I would have guessed that strprintf would have a corrollary signature: first arg being the pointer to a location where the result of the format operation would end up, and a return value indicating success or failure or whatever.  I think that at least in some old style C (ha!) that you would pass in the location to be written to in order to ensure that the caller has access to that memory location, ie so that the variable is in scope for the caller.  Anyway, thanks for the education!

[dalvi]

Sorry if that is stupid guys, but how can I "mine" this coin?

[tspacepilot]

Sorry if that is stupid guys, but how can I "mine" this coin?

You have to have at least some clam to get started (because it's a proof-of-stake coin for additional money generated).  You may already have some CLAM in your control if you have BTC,LTC, or DOGE private keys which were funded above some dust threshhold as of some day in early 2014 (May? Not sure).

For more details about how the staking works (the process of generating new clams), see this:

http://clamclient.com/digging-for-clams/

[dalvi]

OK, so I basically need to have some CLAMs on my qt wallet, and leave it open as much as possible? That's it? Much fairer than all those hardware-heavy minings of other coins
And how can I know what is the probability of geting one clam based on how much CLAMs I have, by time period?
PS: sorry for the bad english

[dooglus]

And how can I know what is the probability of geting one clam based on how much CLAMs I have, by time period?
PS: sorry for the bad english

One CLAM is created every minute, so 1440 per day.

There are about 600k CLAMs trying to stake.

600k/1440 = 416.666

So each 416 CLAMs can expect to stake about once per day.

If you have 41 CLAMs, you can expect them to stake about every 10 days.

And so on.

[tspacepilot]

And how can I know what is the probability of geting one clam based on how much CLAMs I have, by time period?
PS: sorry for the bad english

One CLAM is created every minute, so 1440 per day.

There are about 600k CLAMs trying to stake.

600k/1440 = 416.666

So each 416 CLAMs can expect to stake about once per day.

If you have 41 CLAMs, you can expect them to stake about every 10 days.

And so on.

I guess that means that difficulty will get harder in the fuature as more clams are created.  You said nowadays there are 600K trying to stake.  With 1.4K created each day, then, unless many clams are lost, I guess staking will be twice as hard in approx 2 years when there are 1200K trying to stake.

[dooglus]

I guess that means that difficulty will get harder in the fuature as more clams are created.  You said nowadays there are 600K trying to stake.  With 1.4K created each day, then, unless many clams are lost, I guess staking will be twice as hard in approx 2 years when there are 1200K trying to stake.

Yes - you can see how the difficulty has gone up over time here:

http://www.presstab.pw/phpexplorer/CLAM/charts.php?type=posdifficulty

The drop just before block 400k was a JD user withdrawing 5 CLAMs over and over again into their local wallet as an easy way of splitting their coins up. The wallet spent all its time trying to decide which outputs to use so it was too busy to stake. After that I put a limit on the number of withdrawals you can make, and moved most of the coins to the staking wallet.

The drop just a few days ago was due to me typing "clamd stop" in the wrong window, thinking I was shutting down my local CLAM client, but actually shutting down the JD staking wallet.

[tspacepilot]

I guess that means that difficulty will get harder in the fuature as more clams are created.  You said nowadays there are 600K trying to stake.  With 1.4K created each day, then, unless many clams are lost, I guess staking will be twice as hard in approx 2 years when there are 1200K trying to stake.

Yes - you can see how the difficulty has gone up over time here:

http://www.presstab.pw/phpexplorer/CLAM/charts.php?type=posdifficulty

The drop just before block 400k was a JD user withdrawing 5 CLAMs over and over again into their local wallet as an easy way of splitting their coins up. The wallet spent all its time trying to decide which outputs to use so it was too busy to stake. After that I put a limit on the number of withdrawals you can make, and moved most of the coins to the staking wallet.

The drop just a few days ago was due to me typing "clamd stop" in the wrong window, thinking I was shutting down my local CLAM client, but actually shutting down the JD staking wallet.

Wow, so when is CLAM going to be officially rechristened as JDCOIN?

[dooglus]

Bounty offer:

I need two new CLAM vanity addresses. One for the hot wallet, and one for the staking wallet.

I want them both to start with xJDCLAMZ, case sensitive.

I want them both to use *compressed* public keys.

The standard vanitygen program isn't able to make CLAM addresses. I made a fork here:
  https://github.com/dooglus/vanitygen
which does.

My public key for vanitygen is:

Code:

048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB

Once you've built my fork of vanitygen, run it like this:

Code:

./vanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ

-C to generate CLAM addresses
-k to keep going after finding the first one
-P to specify my public key

I don't have a graphics card. You might find that oclvanitygen works better, but I've never even been able to check if it works at all. I made some changes to have it accept -C but don't know whether I did it right. If you want to check, generate an xJD address, post the privkey here and I'll tell you if it works for me.

I'll pay 50 CLAM to the finder(s) of each of the first two working private keys posted here. Only unedited posts will count, so I can check the post timestamps.

[K1773R]

Bounty offer:

I need two new CLAM vanity addresses. One for the hot wallet, and one for the staking wallet.

I want them both to start with xJDCLAMZ, case sensitive.

I want them both to use *compressed* public keys.

The standard vanitygen program isn't able to make CLAM addresses. I made a fork here:
  https://github.com/dooglus/vanitygen
which does.

My public key for vanitygen is 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD18 97F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB

Once you've built my fork of vanitygen, run it like this:

./vanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD18 97F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ

-C to generate CLAM addresses
-k to keep going after finding the first one
-P to specify my public key

I don't have a graphics card. You might find that oclvanitygen works better, but I've never even been able to check if it works at all. I made some changes to have it accept -C but don't know whether I did it right. If you want to check, generate an xJD address, post the privkey here and I'll tell you if it works for me.

I'll pay 50 CLAM to the finder(s) of each of the first two working private keys posted here. Only unedited posts will count, so I can check the post timestamps.

using OCL, is this correct?

Code:

Pattern: xJDC                                                                  
Address: xJDCQtZP9MTyDVhUwHeNX7HYhXqhDuZMN1
Privkey: LmGxCNahLoFuYHsFXoYbG8T3ggjK9dBud5V7JxW8fMs1WPYYMBPQ

[RussianRaibow]

Bounty offer:

I need two new CLAM vanity addresses. One for the hot wallet, and one for the staking wallet.

I want them both to start with xJDCLAMZ, case sensitive.

I want them both to use *compressed* public keys.

The standard vanitygen program isn't able to make CLAM addresses. I made a fork here:
  https://github.com/dooglus/vanitygen
which does.

My public key for vanitygen is 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD18 97F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB

Once you've built my fork of vanitygen, run it like this:

./vanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD18 97F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ

-C to generate CLAM addresses
-k to keep going after finding the first one
-P to specify my public key

I don't have a graphics card. You might find that oclvanitygen works better, but I've never even been able to check if it works at all. I made some changes to have it accept -C but don't know whether I did it right. If you want to check, generate an xJD address, post the privkey here and I'll tell you if it works for me.

I'll pay 50 CLAM to the finder(s) of each of the first two working private keys posted here. Only unedited posts will count, so I can check the post timestamps.

Sorry, I do not understand exactly how CLAM works, but when someone is generating an address for you, wont he have access on the private key as well and thereby the ability to spend your fund on that address in future ?

[dooglus]

using OCL, is this correct?

Code:

Pattern: xJDC                                                                  
Address: xJDCQtZP9MTyDVhUwHeNX7HYhXqhDuZMN1
Privkey: LmGxCNahLoFuYHsFXoYbG8T3ggjK9dBud5V7JxW8fMs1WPYYMBPQ

No. That gives me these two CLAM addresses (one's compressed, one isn't):

xBhBpydGF9xduGRSBt3uSWENqaeKiZRzvX
xMiZ42BzUjeRgpa45Q4tWkzdeMsHhyP2U5

Neither starts xJDC.

Maybe my patch to oclvanitygen.c was bad.

[dooglus]

Sorry, I do not understand exactly how CLAM works, but when someone is generating an address for you, wont he have access on the private key as well and thereby the ability to spend your fund on that address in future ?

It's more about how vanitygen works. If you give it a -P pubkey argument, the private key won't be useful for anyone who doesn't have the corresponding private key. And I only posted the pubkey.

[dooglus]

using OCL, is this correct?

Code:

Pattern: xJDC                                                                  
Address: xJDCQtZP9MTyDVhUwHeNX7HYhXqhDuZMN1
Privkey: LmGxCNahLoFuYHsFXoYbG8T3ggjK9dBud5V7JxW8fMs1WPYYMBPQ

No. That gives me these two CLAM addresses (one's compressed, one isn't):

xBhBpydGF9xduGRSBt3uSWENqaeKiZRzvX
xMiZ42BzUjeRgpa45Q4tWkzdeMsHhyP2U5

Neither starts xJDC.

Maybe my patch to oclvanitygen.c was bad.

Ah - that Privkey you gave me is the actual privkey for an xJDC address. Did you specify the -P flag and the pubkey? It looks like either you didn't, or oclvanitygen is ignoring it.

[K1773R]

using OCL, is this correct?

Code:

Pattern: xJDC                                                                  
Address: xJDCQtZP9MTyDVhUwHeNX7HYhXqhDuZMN1
Privkey: LmGxCNahLoFuYHsFXoYbG8T3ggjK9dBud5V7JxW8fMs1WPYYMBPQ

No. That gives me these two CLAM addresses (one's compressed, one isn't):

xBhBpydGF9xduGRSBt3uSWENqaeKiZRzvX
xMiZ42BzUjeRgpa45Q4tWkzdeMsHhyP2U5

Neither starts xJDC.

Maybe my patch to oclvanitygen.c was bad.

Ah - that Privkey you gave me is the actual privkey for an xJDC address. Did you specify the -P flag and the pubkey? It looks like either you didn't, or oclvanitygen is ignoring it.

yes, -P dosnt work for OCL it was ignored.

[tspacepilot]

built your client and copied in your command, but it doesn't like the invocation:

Code:

tsp@citrus:~/src/vanitygen-dooglus$ ./vanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD18 97F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ
Invalid base pubkey

Edit: now I got it running, I copied the pubkey from the code element rather than the main text and it's working now

[dooglus]

Ah - that Privkey you gave me is the actual privkey for an xJDC address. Did you specify the -P flag and the pubkey? It looks like either you didn't, or oclvanitygen is ignoring it.

yes, -P dosnt work for OCL it was ignored.

It isn't ignored for me. If I copy it wrong it complains, and if I get it right it accepts it and goes on to find that I don't have a suitable video card:

Code:

$ ./oclvanitygen -CkP xx8F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ
Invalid base pubkey

$ ./oclvanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ
Difficulty: 888446610538
clGetPlatformIDs(0): Unknown code -1001
clGetPlatformIDs(0): Unknown code -1001
Available OpenCL platforms:

$ 

[K1773R]

Ah - that Privkey you gave me is the actual privkey for an xJDC address. Did you specify the -P flag and the pubkey? It looks like either you didn't, or oclvanitygen is ignoring it.

yes, -P dosnt work for OCL it was ignored.

It isn't ignored for me. If I copy it wrong it complains, and if I get it right it accepts it and goes on to find that I don't have a suitable video card:

Code:

$ ./oclvanitygen -CkP xx8F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ
Invalid base pubkey

$ ./oclvanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ
Difficulty: 888446610538
clGetPlatformIDs(0): Unknown code -1001
clGetPlatformIDs(0): Unknown code -1001
Available OpenCL platforms:

$ 

oclvanitygen has no working -P switch... also check --help

Code:

./oclvanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ
Invalid character '0' in prefix '048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB'
Difficulty: 888446610538
[32.19 Mkey/s][total 209715200][Prob 0.0%][50% in 5.3h]