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

[omahapoker]

0.0081. i know clam chart like the back of my hand.

[tokeweed]

[Vortex20000]

Should I be laughing...?

[almightyruler]

Still having problems.

   "difficulty" : 43742.95218211,
    "search-interval" : 16,
    "weight" : 98.24037299,
    "netstakeweight" : 541828.10622686,
    "expectedtime" : 307566

This is a relatively modest balance, but I'm starting to become concerned about the length of time since I last staked. As I write this message, it has been 2014621 seconds (over 23 days) since my client last minted a block. According to the above estimate, I should mint a block in about 3.5 days.

Each time I check, the client is using zero CPU, and does not seem to be trying to stake.

reservebalance is set to false (amount=0)

I upgraded to the latest version a couple of days ago, but behaviour has not changed.

Any ideas?

[Vortex20000]

Still having problems.

   "difficulty" : 43742.95218211,
    "search-interval" : 16,
    "weight" : 98.24037299,
    "netstakeweight" : 541828.10622686,
    "expectedtime" : 307566

This is a relatively modest balance, but I'm starting to become concerned about the length of time since I last staked. As I write this message, it has been 2014621 seconds (over 23 days) since my client last minted a block. According to the above estimate, I should mint a block in about 3.5 days.

Each time I check, the client is using zero CPU, and does not seem to be trying to stake.

reservebalance is set to false (amount=0)

I upgraded to the latest version a couple of days ago, but behaviour has not changed.

Any ideas?

Your wallet is unencrypted and staking=1?

[almightyruler]

Your wallet is unencrypted and staking=1?

Yep. Not encrypted, and staking=true

{
    "enabled" : true,
    "staking" : true,
    "errors" : "",
    "currentblocksize" : 2424,
    "currentblocktx" : 3,
    "pooledtx" : 3,
    "difficulty" : 44303.37167201,
    "search-interval" : 16,
    "weight" : 98.24037299,
    "netstakeweight" : 465015.25390677,
    "expectedtime" : 308638
}

[dooglus]

Yep. Not encrypted, and staking=true

Are you seeing any orphaned blocks, or just nothing at all?

Edit: some very rough calculations:

Every minute, you should have a (your weight)/(network weight) chance of staking.

100/500e3

That's a 1 - 100/500e3 chance of not staking in any given minute.

That's a (1 - 100/500e3) ^ (24*60) = 0.75 chance of not staking in any given day

And a (1 - 100/500e3) ^ (24*60*23) = 0.00133 chance of not staking in 23 days

That's a 1 in 753 chance of not staking in 23 days.

So I'm saying there's a chance, but it seems likely by now that something's not working right.

Version v1.4.8 of the client, which I tagged for building yesterday and should have binaries available for download soon logs how long each staking attempt took, like this:

2015-02-18 05:09:45 stake took 7s
2015-02-18 05:10:00 stake took 6s
2015-02-18 05:10:17 stake took 7s
2015-02-18 05:10:32 stake took 6s
2015-02-18 05:10:49 stake took 7s
2015-02-18 05:11:03 successful stake took 5s
2015-02-18 05:11:03 CheckStake() : new proof-of-stake block found 

You can expect to see each attempt take 0s if you only have a small number of outputs to check each 16 seconds, but the fact that you see it at all is proof that it is attempting to stake.

Another thing to check is whether you have the client configured to hold your balance in "reserve". There's a setting where you can specify that you want to always keep a certain balance available, and that balance never attempts to stake. If you have it set to the same as your full balance you would see what you're seeing.

[almightyruler]

Yep. Not encrypted, and staking=true

Are you seeing any orphaned blocks, or just nothing at all?

That's the other odd thing - according to my transaction list, none of the blocks I've created have ever been orphaned. The list shows 256 "generate" transactions, all with nonzero confirmations (ie, they've been accepted by the network). No mention of the word "orphan" anywhere. I've mentioned this before, as it does seem unusual. I'm running the headless daemon compiled from source.

Version v1.4.8 of the client, which I tagged for building yesterday and should have binaries available for download soon logs how long each staking attempt took, like this:

2015-02-18 05:09:45 stake took 7s
2015-02-18 05:10:00 stake took 6s
2015-02-18 05:10:17 stake took 7s
2015-02-18 05:10:32 stake took 6s
2015-02-18 05:10:49 stake took 7s
2015-02-18 05:11:03 successful stake took 5s
2015-02-18 05:11:03 CheckStake() : new proof-of-stake block found 

You can expect to see each attempt take 0s if you only have a small number of outputs to check each 16 seconds, but the fact that you see it at all is proof that it is attempting to stake.

Looks like I just missed out on that change - updated a couple of days ago, and neither the debug log or source contain the phrase "stake took." I'll compile a newer version and see what happens.

Another thing to check is whether you have the client configured to hold your balance in "reserve". There's a setting where you can specify that you want to always keep a certain balance available, and that balance never attempts to stake. If you have it set to the same as your full balance you would see what you're seeing.

That's 'reservebalance' and as per my earlier message there is definitely none reserved.

[dooglus]

Yep. Not encrypted, and staking=true

Are you seeing any orphaned blocks, or just nothing at all?

That's the other odd thing - according to my transaction list, none of the blocks I've created have ever been orphaned. The list shows 256 "generate" transactions, all with nonzero confirmations (ie, they've been accepted by the network). No mention of the word "orphan" anywhere. I've mentioned this before, as it does seem unusual. I'm running the headless daemon compiled from source.

Are you on the same fork as the rest of us?

$ clamd getblockcount
345127
$ clamd getblockhash 345123
f15274ca7233f757707905afe235045d2fb2a7228049c82a6bc46b30769c47ee

The first command should give a slightly higher number for you, depending on how long elapses between me writing and you reading. The second should give the exact same output.

You can expect to see each attempt take 0s if you only have a small number of outputs to check each 16 seconds, but the fact that you see it at all is proof that it is attempting to stake.

Looks like I just missed out on that change - updated a couple of days ago, and neither the debug log or source contain the phrase "stake took." I'll compile a newer version and see what happens.

I only made the change yesterday. It will be in v1.4.8, but no older version.

Another thing to check is whether you have the client configured to hold your balance in "reserve". There's a setting where you can specify that you want to always keep a certain balance available, and that balance never attempts to stake. If you have it set to the same as your full balance you would see what you're seeing.

That's 'reservebalance' and as per my earlier message there is definitely none reserved.

OK.

Since you're building from source, I can push a change that logs exactly why each attempt at staking fails, have you build that, and get you to post some sample output. That will let us know for sure whether the client is really trying to stake and just being unlucky or not.

Would that be useful?

[almightyruler]

Are you on the same fork as the rest of us?

$ clamd getblockcount
345127
$ clamd getblockhash 345123
f15274ca7233f757707905afe235045d2fb2a7228049c82a6bc46b30769c47ee

dooglus:

I'm definitely on the correct fork. Freshly compiled client is now logging information about staking...

2015-02-18 06:13:37 not tracking stake rewards yet
2015-02-18 06:13:56 not tracking stake rewards yet
2015-02-18 06:14:08 not tracking stake rewards yet
2015-02-18 06:15:45 stake took 0s
2015-02-18 06:16:01 stake took 0s
2015-02-18 06:16:17 stake took 0s
2015-02-18 06:16:33 stake took 0s
2015-02-18 06:16:49 stake took 0s
2015-02-18 06:17:05 stake took 0s
2015-02-18 06:17:21 stake took 0s
2015-02-18 06:17:37 stake took 0s
2015-02-18 06:17:41 not tracking stake rewards yet
2015-02-18 06:17:53 stake took 0s
2015-02-18 06:17:59 not tracking stake rewards yet
2015-02-18 06:18:09 stake took 0s
2015-02-18 06:18:25 stake took 0s
2015-02-18 06:18:42 stake took 0s
2015-02-18 06:18:58 stake took 0s
2015-02-18 06:19:14 stake took 0s
2015-02-18 06:19:30 stake took 0s

I guess that means each attempt is only taking a fraction of a second of CPU time, for each 16 second search interval? My wallet is fairly uncomplicated: 383 entries in total, and 2 unspent outputs (one dust). I'm used to seeing clients trying to stake consume double figure CPU percentage - sometimes even 100% - for an extended period of time.

Still doesn't explain why those attempts are not successful. The extra debugging info you mentioned would be appreciated.

BTW, can I PM you a small diff to ensure that clamd compiles cleanly under FreeBSD? I'm not familiar with git.

[garthkiser]

CLAM market cap exceeded 4000BTC today

or............

1 miiiiiiiiiiiiiiiiiiillion dollars!
http://imgur.com/EdPVrWW

[Vortex20000]

CLAM market cap exceeded 4000BTC today

or............

1 miiiiiiiiiiiiiiiiiiillion dollars!
http://imgur.com/EdPVrWW

Achievement get!

[SuperClam]

CLAM market cap exceeded 4000BTC today
or............
1 miiiiiiiiiiiiiiiiiiillion dollars!
http://imgur.com/EdPVrWW

Amazingly Awesome

[dooglus]

I guess that means each attempt is only taking a fraction of a second of CPU time, for each 16 second search interval? My wallet [has] 2 unspent outputs (one dust). I'm used to seeing clients trying to stake consume double figure CPU percentage - sometimes even 100% - for an extended period of time.

Every 16 seconds the client loops through your unspent outputs, checks which ones are old enough (>510 blocks since last stake, 4 hours since last transaction) and does a simple sha256 hash for each output. Since you only have 2 unspent outputs, that's basically 2 hashes. That takes approximately 0 seconds...

Still doesn't explain why those attempts are not successful. The extra debugging info you mentioned would be appreciated.

Here's the extra debugging version:

https://github.com/dooglus/clams/releases/tag/debug_staking_tag

Are you able to build from that? I guess you're downloading the whole .tar.gz archive each time, so that's where you'll find it.

If you build and run that, you'll see a bunch of extra debug logging. Each time a block is staked by the network you'll see a log like:

[STAKE] PASS: hash      38f3e302f765d3f21a83929dbd29d0d30a2259752d5c0ebdfdaa6e4ca3a
[STAKE]  <= target     2d4d3383b000000000000000000000000000000000000000000000000000
2015-02-18 07:21:55 SetBestChain: new best=ac14384781c33dc569d5218dd19912a67e7b7f16c13355eb6e3ae9934d7912f7  height=345208  trust=14360606016385876213  blocktrust=148138062331032  date=02/18/15 07:21:52
2015-02-18 07:21:55 ProcessBlock: ACCEPTED

To stake a block, the hash of the output that is trying to stake must be lower than the target hash. In this case 38f... is less than 2d4d... (it's one character shorter) and so it wins the right to stake.

Then every 16 seconds you'll see your outputs trying to stake:

[STAKE] searching for staking opportunity:
2015-02-18 07:22:09 [STAKE] checking 18 output(s)
2015-02-18 07:22:09 [STAKE] check fe7c7692b2ca1969ed4fb431144f6a15815f2a57b3bda9bbf8fcb2f338af9d28:107 (4.00 CLAM)
2015-02-18 07:22:09
[STAKE] fail: hash 413d56c739eb1bf553a51d7f642fe66d094f931746e433b14cda85178224d7ce
[STAKE]   > target     2d53118d2c00000000000000000000000000000000000000000000000000
2015-02-18 07:22:09 [STAKE] check fe7c7692b2ca1969ed4fb431144f6a15815f2a57b3bda9bbf8fcb2f338af9d28:125 (4.00 CLAM)
2015-02-18 07:22:09
[STAKE] fail: hash ccd1436cf112218abb68f704f1bfbd54f4b9206d3bc58dc76162af15a05e5266
[STAKE]   > target     2d53118d2c00000000000000000000000000000000000000000000000000

I have 18 unspent outputs, but I've cut the log off after the first 2 failed to stake. In both cases the hash is much bigger than the target, and so those outputs didn't get to stake.

BTW, can I PM you a small diff to ensure that clamd compiles cleanly under FreeBSD? I'm not familiar with git.

Of course.

[Nthused]

I guess that means each attempt is only taking a fraction of a second of CPU time, for each 16 second search interval? My wallet [has] 2 unspent outputs (one dust). I'm used to seeing clients trying to stake consume double figure CPU percentage - sometimes even 100% - for an extended period of time.

Every 16 seconds the client loops through your unspent outputs, checks which ones are old enough (>510 blocks since last stake, 4 hours since last transaction) and does a simple sha256 hash for each output. Since you only have 2 unspent outputs, that's basically 2 hashes. That takes approximately 0 seconds...

Still doesn't explain why those attempts are not successful. The extra debugging info you mentioned would be appreciated.

Here's the extra debugging version:

https://github.com/dooglus/clams/releases/tag/debug_staking_tag

Are you able to build from that? I guess you're downloading the whole .tar.gz archive each time, so that's where you'll find it.

If you build and run that, you'll see a bunch of extra debug logging. Each time a block is staked by the network you'll see a log like:

[STAKE] PASS: hash      38f3e302f765d3f21a83929dbd29d0d30a2259752d5c0ebdfdaa6e4ca3a
[STAKE]  <= target     2d4d3383b000000000000000000000000000000000000000000000000000
2015-02-18 07:21:55 SetBestChain: new best=ac14384781c33dc569d5218dd19912a67e7b7f16c13355eb6e3ae9934d7912f7  height=345208  trust=14360606016385876213  blocktrust=148138062331032  date=02/18/15 07:21:52
2015-02-18 07:21:55 ProcessBlock: ACCEPTED

To stake a block, the hash of the output that is trying to stake must be lower than the target hash. In this case 38f... is less than 2d4d... (it's one character shorter) and so it wins the right to stake.

Then every 16 seconds you'll see your outputs trying to stake:

[STAKE] searching for staking opportunity:
2015-02-18 07:22:09 [STAKE] checking 18 output(s)
2015-02-18 07:22:09 [STAKE] check fe7c7692b2ca1969ed4fb431144f6a15815f2a57b3bda9bbf8fcb2f338af9d28:107 (4.00 CLAM)
2015-02-18 07:22:09
[STAKE] fail: hash 413d56c739eb1bf553a51d7f642fe66d094f931746e433b14cda85178224d7ce
[STAKE]   > target     2d53118d2c00000000000000000000000000000000000000000000000000
2015-02-18 07:22:09 [STAKE] check fe7c7692b2ca1969ed4fb431144f6a15815f2a57b3bda9bbf8fcb2f338af9d28:125 (4.00 CLAM)
2015-02-18 07:22:09
[STAKE] fail: hash ccd1436cf112218abb68f704f1bfbd54f4b9206d3bc58dc76162af15a05e5266
[STAKE]   > target     2d53118d2c00000000000000000000000000000000000000000000000000

I have 18 unspent outputs, but I've cut the log off after the first 2 failed to stake. In both cases the hash is much bigger than the target, and so those outputs didn't get to stake.

BTW, can I PM you a small diff to ensure that clamd compiles cleanly under FreeBSD? I'm not familiar with git.

Of course.

So what is all this intended for dooglus ?
Is it for the next version of CLAM ?

[dooglus]

So what is all this intended for dooglus ?
Is it for the next version of CLAM ?

almightyruler has been complaining that his client isn't staking for quite a while now. It's just an attempt to get some insight into why it's happening.

I guess I'll tidy it up and include it in the next release for others to use. I'll make it so you don't get the output unless you specify "debug=stake" in the config because it's quite verbose.

[yudhistira]

  everytime update new wallet 

everything is oke
but tell me why this happen

[almightyruler]

Here's some of the debugging info... does "fail" mean it simply didn't find a suitable result that round, or that there's some issue?

2015-02-18 09:37:37

[STAKE] searching for staking opportunity:
2015-02-18 09:37:37 [STAKE] checking 2 output(s)
2015-02-18 09:37:37 [STAKE] check c186638669606cd9021accba7e869de4b492f8fd88f6b2521a887a1a018f5400:1   (0.00037299 CLAM)
2015-02-18 09:37:37
[STAKE] fail: hash a2659a05a7ecda7e4d8bf2ca7a1b72b92d6a62d8c3dcf515923e9fd6fd86a655
[STAKE]   > target        117158c07000000000000000000000000000000000000000000000000
2015-02-18 09:37:37 [STAKE] check c186638669606cd9021accba7e869de4b492f8fd88f6b2521a887a1a018f5400:2   (98.24 CLAM)
2015-02-18 09:37:37
[STAKE] fail: hash e87e1b115cf92df97624cefd872057718a3015219810186cec8449c8fada2475
[STAKE]   > target    4619f2d25f800000000000000000000000000000000000000000000000000
2015-02-18 09:37:37 stake took 0s
2015-02-18 09:37:53

[STAKE] searching for staking opportunity:
2015-02-18 09:37:53 [STAKE] checking 2 output(s)
2015-02-18 09:37:53 [STAKE] check c186638669606cd9021accba7e869de4b492f8fd88f6b2521a887a1a018f5400:1   (0.00037299 CLAM)
2015-02-18 09:37:53
[STAKE] fail: hash b279ff86a6e7716e1d1120cb33a783f2e2cb93c94932f8f24b13c73a24d4b4d1
[STAKE]   > target        117158c07000000000000000000000000000000000000000000000000
2015-02-18 09:37:53 [STAKE] check c186638669606cd9021accba7e869de4b492f8fd88f6b2521a887a1a018f5400:2   (98.24 CLAM)
2015-02-18 09:37:53
[STAKE] fail: hash 2b30a2c8de42083fd8e8856f9da54759efba100ccf35666d2b432b791793ac77
[STAKE]   > target    4619f2d25f800000000000000000000000000000000000000000000000000
2015-02-18 09:37:53 stake took 0s
2015-02-18 09:38:09

[STAKE] searching for staking opportunity:
2015-02-18 09:38:09 [STAKE] checking 2 output(s)
2015-02-18 09:38:09 [STAKE] check c186638669606cd9021accba7e869de4b492f8fd88f6b2521a887a1a018f5400:1   (0.00037299 CLAM)
2015-02-18 09:38:09
[STAKE] fail: hash ac53b692ddda2b4e41c09e93ccf3e9b10a26f878141d7b4337acdbfa2c7c962c
[STAKE]   > target        117158c07000000000000000000000000000000000000000000000000
2015-02-18 09:38:09 [STAKE] check c186638669606cd9021accba7e869de4b492f8fd88f6b2521a887a1a018f5400:2   (98.24 CLAM)
2015-02-18 09:38:09
[STAKE] fail: hash c9a81d2445def2d41130aed27593881720cc5278c9f7cf0ee1f4cfda32664fc7
[STAKE]   > target    4619f2d25f800000000000000000000000000000000000000000000000000
2015-02-18 09:38:09 stake took 0s


The only time it's showing PASS is when a network block arrives... I presume that's because the debug info is printed in AcceptBlock() (or whatever it's called).

2015-02-18 09:39:16
[STAKE] PASS: hash     1d2131bd79523c3b938f56a03e53c7a2284dacf34bc321ba20834a444811
[STAKE]  <= target     2dab2bf2f400000000000000000000000000000000000000000000000000
2015-02-18 09:39:16
[STAKE] PASS: hash     1d2131bd79523c3b938f56a03e53c7a2284dacf34bc321ba20834a444811
[STAKE]  <= target     2dab2bf2f400000000000000000000000000000000000000000000000000
2015-02-18 09:39:20 not tracking stake rewards yet
2015-02-18 09:39:20 SetBestChain: new best=f069b8fb12da5f94d275677c248ead85a656f197d22a2854b9bfaa7ed6909d78  height=345346  trust=14380133255292933361  blocktrust=146947369008225  date=02/18/15 09:39:12
2015-02-18 09:39:20 ProcessBlock: ACCEPTED

[picolo]

CLAM market cap exceeded 4000BTC today
or............
1 miiiiiiiiiiiiiiiiiiillion dollars!
http://imgur.com/EdPVrWW

Amazingly Awesome

I am feeling a huge market correction to sub 0.006 or even sub-0.005 soon.

[BayAreaCoins]

I am feeling a huge market correction to sub 0.006 or even sub-0.005 soon.

lol Zolace