Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 329. (Read 1151252 times)

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/

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

Got it.  Thanks, I guess I forgot that it's okay to concatenate #defined symbols and string literalsYah, 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!

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.

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:


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:


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

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


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.

Glad to you hear you will be joining the CLAM family

---

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.

---

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

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

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':


The relevant code change is this:


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

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

Hi. I answered this question yesterday.

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

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?

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

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:






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?

   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. 

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 don't know if the headless client keeps track of the blocks it staked that were later orphaned.

Here's what I see in the logfile when a block I staked is orphaned:


That "stake -1 for [me]" is me losing 1 CLAM of staking reward, and someone else getting it instead. But the block doesn't show up in 'listtransactions' at all that I can see. I don't think those lines are even logged if you aren't tracking amounts staked (which is turned on when you run 'getstakedbyaddress' the first time).

I've probably mentioned this before, but I've never seen an orphan.

Over 3 headless clients (of varying versions) I have minted more than 500 blocks over the past year, but not one of them shows an entry for an orphan.

I don't know whether it's just pure luck that all my generated blocks went through, or if there have been orphans, and for some reason they have not been recorded as such. The former seems unlikely.

Well, if you were getting 5% orphans before JD and 11% after, maybe JD has doubled your orphan rate. Even before JD the staking will have been dominated by a few large wallets I guess. I'm thinking there wouldn't have been any with >50% of the stake weight, but there still will have been some big ones.


Shortly after the hard fork everyone was on their own version of the chain. It was so easy to stake for the first hour after the fork that everyone was staking every few minutes.


The CLAM client seems to truncate its logfile sometimes, so I don't have much history. Here's what I do have:


CLAM blocks are mostly tiny and so quick to broadcast. I don't know if there's much to be gained by sending your blocks to JD first, but maybe it would help.


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...

   I've tried blocks of 50 and blocks of 5.  I'm currently using splitsize = 5 and combinelimit = 5 .  These are set in the clam.conf file.  After watching my staking info in the debug log, and now tracking it for a bit, I'm finding that looking at one days data is not the way to go.  And at your number of clams, I would think you'll need to look at, at least 2-3 weeks data to get an idea how your doing.  One day you might get 2-3 stakes and the next few days get nothing, and think something is wrong (at least I did).

   Also an interesting point.  I usually end up staking when the network weight is on the high side.  I would expect my staking to go up as the weight decreases but thats not the case.   

   I'm doing this more to help the network, then to try to beat Just-dice.  As long as I'm "somewhat" close I'm happy.     

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?