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

[dooglus]

This is one of the risks self staking carries...

Indeed, although of course there are risks with pooled staking too.

Dates                     Start Balance     Stakes      Avg/Day   Percentage     Orphans

6/22- 6/28 (7 days)  2456                 37.0027     5.2861     2.15%           2
6/29 -7/5                2493                 26.0005     3.7144     1.49%           2
7/6 - 7/12               2519                 27.0009     3.8571     1.53%           4   - I think 2 of these were due to my own network issue.   

The percentage would be better as a per-day number, and it would be interesting to see orphans as a % too. Did you stake 31 times most recently but only 27 survived? Or 27 times and only 23 survived? Either way, that's about a 15% orphan rate isn't it?

Anyone know how to get my clams back from the dice site? I had some in there and cannot figure out what my login was.

Like tsp says, there are contact details at the end of the FAQ tab on Just-Dice. Please include details of your deposits, withdrawals, balance, investments - whatever you can remember to identify your account and confirm that it is yours.

[chilly2k]

This is one of the risks self staking carries...

Indeed, although of course there are risks with pooled staking too.

Dates                     Start Balance     Stakes      Avg/Day   Percentage     Orphans

6/22- 6/28 (7 days)  2456                 37.0027     5.2861     2.15%           2
6/29 -7/5                2493                 26.0005     3.7144     1.49%           2
7/6 - 7/12               2519                 27.0009     3.8571     1.53%           4   - I think 2 of these were due to my own network issue.   

The percentage would be better as a per-day number, and it would be interesting to see orphans as a % too. Did you stake 31 times most recently but only 27 survived? Or 27 times and only 23 survived? Either way, that's about a 15% orphan rate isn't it?

   The stake number is actual stakes, not including orphans.  Would the orphans % be number of orphans / total stakes (valid + orphans)

for the last week.

date                      Starting balance     Stakes   Percentage  orphans.   orphan %

7/13                      2546                     5          .1963         
7/12                      2540                     6          .2362
7/11                      2537                     3          .1182           1            25%
7/10                      2532                     5          .1975           1            17%
7/09                      2531                     1          .0395           1            50%
7/08                      2531                     0           0             
7/07                      2527                     4          .1583           1            20%
7/06                      2519                     8          .3176

[dooglus]

Would the orphans % be number of orphans / total stakes (valid + orphans)

Yes.

for the last week.

date                      Starting balance     Stakes   Percentage  orphans.   orphan %

7/13                      2546                     5          .1963         
7/12                      2540                     6          .2362
7/11                      2537                     3          .1182           1            25%
7/10                      2532                     5          .1975           1            17%
7/09                      2531                     1          .0395           1            50%
7/08                      2531                     0           0             
7/07                      2527                     4          .1583           1            20%
7/06                      2519                     8          .3176

I guess 2500 is too small a number to quickly get an idea of the orphan rate, but that looks like 4 orphans out of 36 stakes, or 11% so far. The variance is huge, with your daily orphan rate ranging from 0% to 50%...

[chilly2k]

Would the orphans % be number of orphans / total stakes (valid + orphans)

Yes.

for the last week.

date                      Starting balance     Stakes   Percentage  orphans.   orphan %

7/13                      2546                     5          .1963         
7/12                      2540                     6          .2362
7/11                      2537                     3          .1182           1            25%
7/10                      2532                     5          .1975           1            17%
7/09                      2531                     1          .0395           1            50%
7/08                      2531                     0           0             
7/07                      2527                     4          .1583           1            20%
7/06                      2519                     8          .3176

I guess 2500 is too small a number to quickly get an idea of the orphan rate, but that looks like 4 orphans out of 36 stakes, or 11% so far. The variance is huge, with your daily orphan rate ranging from 0% to 50%...

Went back and looked at Mar/Apr and May.  I didn't have the patience to calculate how many Clams I had on each dates, so I just looked at the total stakes Vs orphans. 

March     131 stakes    5 orphans.     3.7%
April      124 stakes     8 orphans      6%
May       141 stakes     0 orphans

April was interesting.  There were 5 orphans between the 5th and 7th.  I don't remember anything going on, on my end at that time... 

Then just for giggles I went back to Oct.  This would be before JD came online

Oct    61 stakes   3 orphans.   4.7% 

     So I don't think the 15% orphan theory is really holding up.  I'm guessing I end up averaging about 4-6% orphans.  And that hasn't really changed since JD started.
 
I was going to look at Nov, but the 11th was he hard fork, and I ended up on the wrong chain for a little while.   24 orphans in 3 hours...  not good for the statistics. 

[SebastianJu]

Would the orphans % be number of orphans / total stakes (valid + orphans)

Yes.

for the last week.

date                      Starting balance     Stakes   Percentage  orphans.   orphan %

7/13                      2546                     5          .1963        
7/12                      2540                     6          .2362
7/11                      2537                     3          .1182           1            25%
7/10                      2532                     5          .1975           1            17%
7/09                      2531                     1          .0395           1            50%
7/08                      2531                     0           0            
7/07                      2527                     4          .1583           1            20%
7/06                      2519                     8          .3176

I guess 2500 is too small a number to quickly get an idea of the orphan rate, but that looks like 4 orphans out of 36 stakes, or 11% so far. The variance is huge, with your daily orphan rate ranging from 0% to 50%...

So when extrapolating the results how does he perform compared to just-dice wallet?

Could he lower the chance of getting orphaned when he makes sure that he sends his block to just-dice first? Can the clam client be sat up that way? I would try to contact the biggest wallets first to lower the time i get >50%. Though in fact, at the moment, one would need to ONLY propagate to just-dice. Not healthy for sure.

[ryanb]

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?

[chilly2k]

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?

   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.     

[dooglus]

that looks like 4 orphans out of 36 stakes, or 11% so far

I'm guessing I end up averaging about 4-6% orphans.  And that hasn't really changed since JD started.

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.

I was going to look at Nov, but the 11th was he hard fork, and I ended up on the wrong chain for a little while.   24 orphans in 3 hours...  not good for the statistics.

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.

So when extrapolating the results how does he perform compared to just-dice wallet?

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

$ grep 'stake -[0-9.]* for' ~/.clam/debug.log
2015-07-14 00:03:53 stake -1.0001 for xXMNNbSFrsWvsUqVQaEBCRaLfi47g9tFhX; not mine
2015-07-14 00:06:37 stake -1.0002 for xJDCLAMZsZg1YqGytiP9CRzYYdsrJXX9Kh; global = 100988.613508, address = 100873.601008
2015-07-14 00:06:37 stake -1.00 for xJDCLAMZsZg1YqGytiP9CRzYYdsrJXX9Kh; global = 100987.613508, address = 100872.601008
2015-07-14 03:27:57 stake -1.0002 for xJDCLAMZsZg1YqGytiP9CRzYYdsrJXX9Kh; global = 101160.617008, address = 101045.604508
2015-07-14 09:19:54 stake -1.0001 for xJDCLAMZsZg1YqGytiP9CRzYYdsrJXX9Kh; global = 101445.639508, address = 101330.627008
2015-07-14 18:02:37 stake -1.0001 for xJDCLAMZsZg1YqGytiP9CRzYYdsrJXX9Kh; global = 101873.7675494, address = 101758.7550494
2015-07-14 18:40:19 stake -1.00 for xJDCLAMZsZg1YqGytiP9CRzYYdsrJXX9Kh; global = 101904.7695494, address = 101789.7570494
2015-07-14 21:17:11 stake -1.0006 for xJDCLAMZsZg1YqGytiP9CRzYYdsrJXX9Kh; global = 102037.7909494, address = 101922.7784494
2015-07-15 03:14:21 stake -1.00 for xJDCLAMZsZg1YqGytiP9CRzYYdsrJXX9Kh; global = 102323.9023494, address = 102208.8898494
2015-07-15 05:44:13 stake -1.0001 for xJDCLAMZtRD72TC31E8SJ4a6ycFtnQyuDH; not mine
2015-07-15 09:02:04 stake -1.0002 for xJDCLAMZtRD72TC31E8SJ4a6ycFtnQyuDH; not mine
2015-07-15 09:38:27 stake -1.00 for xJDCLAMZsZg1YqGytiP9CRzYYdsrJXX9Kh; global = 102643.9272494, address = 102528.9147494

Those are the orphans the staking wallet saw in the last day and a half. Note that JD stakes two wallets - a 'staking wallet' (...CLAMZsZg...) with the majority of the coins in it, and a hot wallet (...CLAMZtRD...) with 20k to 30k in it. To further confuse matter I think the first few lines above were while a DDoS attack was ongoing and I ran the staking wallet on two machines at the same time so it was orphaning its own blocks.

Could he lower the chance of getting orphaned when he makes sure that he sends his block to just-dice first? Can the clam client be sat up that way? I would try to contact the biggest wallets first to lower the time i get >50%. Though in fact, at the moment, one would need to ONLY propagate to just-dice. Not healthy for sure.

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.

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

[almightyruler]

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.

[dooglus]

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.

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:

2015-07-16 06:28:35 ProcessBlock: ORPHAN BLOCK 0, prev=475ca4bf5b6f820bcd2c69012d067d21007ea574fe687f963b7bf6477b2990ac
2015-07-16 06:28:35 REORGANIZE
2015-07-16 06:28:35 REORGANIZE: Disconnect 1 blocks; 8f2c239cbde31f114576b54be4ba896148219c091256de60c30e4b05ef929935..ab753ae5180c6 359747f3dc19f72b8e8ede6fd2b99684895cd4aac962cd3db5c
2015-07-16 06:28:35 REORGANIZE: Connect 2 blocks; 8f2c239cbde31f114576b54be4ba896148219c091256de60c30e4b05ef929935..420da8e336730 453ef59c8a59288a75acb71afb848cc8e5d14913611a48eee6b
2015-07-16 06:28:35 out 17.3701 - in 16.37 = reward 1.0001
2015-07-16 06:28:35 stake -1.0001 for xJDCLAMZsZg1YqGytiP9CRzYYdsrJXX9Kh; global = 103672.9224494, address = 103557.9099494
2015-07-16 06:28:35 stake 1.0001 for xEK27EFqu1BdKQFxrN5UVVyNdaYgcoP83G; not mine
2015-07-16 06:28:35 stake 1.00 for xEGBfPzYdKvBfnfWTD67fXnyXmghqNn4oT; not mine
2015-07-16 06:28:35 REORGANIZE: done
2015-07-16 06:28:35 SetBestChain: new best=420da8e336730453ef59c8a59288a75acb71afb848cc8e5d14913611a48eee6b  height=556464  trust=54453135560456574575  blocktrust=255583568738615  date=07/16/15 06:28:32
2015-07-16 06:28:35 ProcessBlock: ACCEPTED

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

[almightyruler]

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.

I don't know if the headless client keeps track of the blocks it staked that were later orphaned.

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?

[chilly2k]

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.

I don't know if the headless client keeps track of the blocks it staked that were later orphaned.

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?

   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. 

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