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

[dooglus]

Most (if not all) of the other clients I use list orphans, so I don't understand why CLAM wouldn't. A block which is subsequently orphaned starts as a valid transaction, right? So the client would actually have to delete the transaction from the wallet, rather than just changing its status from immature to orphan. Another possibility is that 'listtransactions' simply ignores orphans, but ListTransactions in rpcwallet.cpp does refer to entry.push_back(Pair("category", "orphan")).

Does the QT client show orphans? If so, why is the behaviour different with the headless client?

I saw your post last night and decided to experiment with the two versions of the client to see what happened. I'm sure I've seen orphaned blocks in the QT client but never in the headless one. I loaded up a wallet from a headless client into the QT client, and saw that it didn't show the orphans. I figure the orphans only show if they happen *while the QT client is running*.

The QT wallet is really laggy for me. It spends almost all its time updating the confirmation count in the thousands of rows of the transaction table and almost no time listening to me. So I typed "clamd stop" to stop it. Unfortunately I was logged in to the Just-Dice staking wallet at the time, so it stopped JD's staking and not the QT client. 8 hours later I realised my mistake.

I guess anyone solo-staking had a great night!

http://www.presstab.pw/phpexplorer/CLAM/ has charts of network difficulty:

   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. 

   Just stating the facts.  I have no idea why it seems to work.  I always thought the wallet just had your addresses and Keys.  The rest is figured out from the block chain and stored in the database files.  For some reason an orphan on one machine is showing up in the transaction history of another client. 

They both use the same copy of wallet.dat, but I guess the QT client has some kind of additional storage. I never really understood the QT client. We should really get to the bottom of this. I often switch between wallets by shutting down the client and moving wallet.dat files around. If the QT has its own separate storage, do I need to be moving that too? Or does it have a section of wallet.dat that only it knows about?

[NoobKidOnTheBlock]

Hey mates I'm a first time Clamhead here and I've got a little question to ask some professionals.  For the staking of my CLAMS is it better to put them all in 1 CLAM chunks opposed to putting them all in one big chunk or several big chunks? I just would like to know the most optimal way to stake them if someone would be ever so kind as to give me their honest opinion Cheers

[casinobitco]

Hi Folks - Technical question here for the developers....

Some background, PeerBet.org (one of the oldest dice sites around) has been looking to bring Clam to their list of viable Alt-Coins used on the site per many user requests. Technically it runs Windows Server (please don't ask why, we acquired it a year ago) and .NET

But we've been having issues integrating with the Clam Wallet (both 32 and 64 bit versions).


Request:

POST http://ianscott-pc:8341/ HTTP/1.1
Content-Type: application/json
Authorization: Basic dXB1bjp1cHB3
Host: ianscott-pc:8341
Content-Length: 70
Expect: 100-continue
Connection: Keep-Alive

{"jsonrpc":"1.0","id":1,"method":"getnewaddress","params":["PeerBet"]}


Response:

HTTP/1.1 200 OK
Date: Wed, 15 Jul 2015 19:22:41 +0000
Connection: keep-alive
Content-Length: 68u
Content-Type: application/json
Server: Clam-json-rpc/v1.4.10

{"result":"xGYKDfEtA215AWec3j1uZH5VJE4v1fXR3j","error":null,"id":1}


The issue is that 68u - HTTP says that has to be a number, so our process is failing all around.

Can you guys take a look and advise?

[dooglus]

Hey mates I'm a first time Clamhead here and I've got a little question to ask some professionals.  For the staking of my CLAMS is it better to put them all in 1 CLAM chunks opposed to putting them all in one big chunk or several big chunks? I just would like to know the most optimal way to stake them if someone would be ever so kind as to give me their honest opinion Cheers

Hi. I answered this question yesterday.

tl;dr: chunks of 5 or 10 is small enough.

Do you guys recommend combined the blocks after each stake my balance is 633 right now. They are staking, should i combine them or leave them as is?

what do you suggest for having better luck when it comes to staking?

The only reason to split your outputs up into smaller pieces is to reduce the effect of the 8 hour delay after staking. Suppose you're happy with the 8 hour delay being 1% of the time your coins are staking, so you only lose 1% to the delay. That means you would want the expected staking time for your outputs to be 800 hours each. The total network staking weight is currently around 700k, and the total network stakes 60 blocks per hour:

So we can calculate the size an output needs to be to have an expected time to stake of 800 hours. Then it will spend just 1% of its time maturing:

>>> weight = 700e3
>>> loss = 0.01
>>> delay = 8
>>> weight * loss / delay / 60
14.58333

There it is. You need to split your balance into pieces of size 14.6 CLAMs if you're happy to accept a 1% loss due to maturation delays.

>>> loss = 0.05
>>> weight * loss / delay / 60
72.91666

If you're happy to lose 5% to maturation delays, you can get away with staking with bigger outputs (size 73 CLAMs each). And so on.

To check my math I looked at the JD staking wallet.

It has 562819 CLAMs split into 32351 outputs very roughly the same size. The average output size is 17.397 CLAMs.

Currently, of the 562819 CLAM balance, 554969 is mature and 7850 is waiting to mature. So that's 1.39% of the balance that is currently waiting.

>>> loss = 0.0139
>>> weight * loss / delay / 60
20.270833

According to my calculations I would expect a 1.39% loss like that with outputs of size 20, so I'm doing a little worse than predicted. That probably means my guess for the total network staking weight was a bit wrong. If I change my guess to 600k it fits much better:

>>> weight = 600e3
>>> weight * loss / delay / 60
17.375

But can that be right? JD is staking 590k on its own.

Checking the rich list shows that other than JD there aren't many big addresses, and other than bitdice's 7k most of the other big addresses aren't staking (presumably being in poloniex's wallet, which we know doesn't stake).

It's look like maybe JD is much closer to 100% of the network staking weight than I previously thought, and the JD staking wallet's biggest competitor is the JD hot wallet...

[dooglus]

http://www.presstab.pw/phpexplorer/CLAM/ has charts of network difficulty:

It didn't take too long to get difficulty back to normal:

[dooglus]

Hi Folks - Technical question here for the developers....

Some background, PeerBet.org (one of the oldest dice sites around) has been looking to bring Clam to their list of viable Alt-Coins used on the site per many user requests. Technically it runs Windows Server (please don't ask why, we acquired it a year ago) and .NET

But we've been having issues integrating with the Clam Wallet (both 32 and 64 bit versions).


Request:

POST http://ianscott-pc:8341/ HTTP/1.1
Content-Type: application/json
Authorization: Basic dXB1bjp1cHB3
Host: ianscott-pc:8341
Content-Length: 70
Expect: 100-continue
Connection: Keep-Alive

{"jsonrpc":"1.0","id":1,"method":"getnewaddress","params":["PeerBet"]}


Response:

HTTP/1.1 200 OK
Date: Wed, 15 Jul 2015 19:22:41 +0000
Connection: keep-alive
Content-Length: 68u
Content-Type: application/json
Server: Clam-json-rpc/v1.4.10

{"result":"xGYKDfEtA215AWec3j1uZH5VJE4v1fXR3j","error":null,"id":1}


The issue is that 68u - HTTP says that has to be a number, so our process is failing all around.

Can you guys take a look and advise?

This rings a bell with me for some reason. I think I've seen issues with Windows adding a 'u' to numbers before somewhere, but I really don't remember where.

This is the commit which added the 'u':

commit 84a4a7763f386934da90e2bd1e355b70023fa9ca
Author: alexhz <balthazar@yandex.ru>
Date:   Mon Apr 15 18:39:58 2013 +0000

    update to 0.4 preview

The relevant code change is this:

    return strprintf(
             "HTTP/1.1 %d %s\r\n"
             "Date: %s\r\n"
-            "Connection: close\r\n"
-            "Content-Length: %d\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"

I'm guessing the Windows compiler isn't interpreting the %"PRIszu" in the same way as other compilers.

http://stackoverflow.com/questions/29154364/how-to-use-symbols-in-a-string may be relevant.

https://www.reddit.com/r/blackcoin/comments/2vgzum/rpc_for_blackcoind_in_windows_7/coj3z77 is about the same problem in blackcoin.

bitcoin/src/rpcprotocol.cpp simply has:

            "Content-Length: %u\r\n"

so maybe that's the best fix.

I opened a github issue about this: https://github.com/nochowderforyou/clams/issues/202

[SuperClam]

Hi Folks - Technical question here for the developers....
Some background, PeerBet.org (one of the oldest dice sites around) has been looking to bring Clam to their list of viable Alt-Coins used on the site per many user requests.

Glad to you hear you will be joining the CLAM family

Technically it runs Windows Server (please don't ask why, we acquired it a year ago) and .NET
But we've been having issues integrating with the Clam Wallet (both 32 and 64 bit versions).

The issue is that 68u - HTTP says that has to be a number, so our process is failing all around.
Can you guys take a look and advise?

This rings a bell with me for some reason. I think I've seen issues with Windows adding a 'u' to numbers before somewhere, but I really don't remember where.

It does seem familiar - I believe there was a user with a similar issue in IRC some time ago.
I believe he found a way to make it work in his situation.

I'm guessing the Windows compiler isn't interpreting the %"PRIszu" in the same way as other compilers.
http://stackoverflow.com/questions/29154364/how-to-use-symbols-in-a-string may be relevant.
https://www.reddit.com/r/blackcoin/comments/2vgzum/rpc_for_blackcoind_in_windows_7/coj3z77 is about the same problem in blackcoin.

bitcoin/src/rpcprotocol.cpp simply has:
            "Content-Length: %u\r\n"

so maybe that's the best fix.
I opened a github issue about this: https://github.com/nochowderforyou/clams/issues/202

The full Blackcoin commit made print changes across the board when fixing the issue, as well.

https://github.com/rat4/blackcoin/commit/c974b211f048e33138ad760571e53ef7dee19670

[tspacepilot]

This is the commit which added the 'u':

commit 84a4a7763f386934da90e2bd1e355b70023fa9ca
Author: alexhz <balthazar@yandex.ru>
Date:   Mon Apr 15 18:39:58 2013 +0000

    update to 0.4 preview

The relevant code change is this:

    return strprintf(
             "HTTP/1.1 %d %s\r\n"
             "Date: %s\r\n"
-            "Connection: close\r\n"
-            "Content-Length: %d\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"

I'm guessing the Windows compiler isn't interpreting the %"PRIszu" in the same way as other compilers.

http://stackoverflow.com/questions/29154364/how-to-use-symbols-in-a-string may be relevant.

https://www.reddit.com/r/blackcoin/comments/2vgzum/rpc_for_blackcoind_in_windows_7/coj3z77 is about the same problem in blackcoin.

bitcoin/src/rpcprotocol.cpp simply has:

            "Content-Length: %u\r\n"

so maybe that's the best fix.

I opened a github issue about this: https://github.com/nochowderforyou/clams/issues/202

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.

[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