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

[garthkiser]

Proof-of-stake = rewards go to the rich
Clamming-for-pearls = rewards go to the most dedicated workers

I know which world I'd rather live in.

The original Satashi dream behind cryptocurrency was to build a foundation for a new world. The CLAMS project is living and breathing that spirit.

Devs, don't fret harsh words from unhappy speculators. Dogs bark, the caravan passes.

[personOfUninterest]

Is this normal?

https://i.imgur.com/cAPw1VV.png?1

All I tried to do was start the client. Was running fine last night.

Edit - Uninstalled and reinstalled - nothing. Copy CLAM data folder (appdata). Delete original, starts ok. Shut it down and replace blkxxx.dat and wallet.dat with backups.

And, success. Somewhat - it opens but looks like the wallet is frozen but still dealing with files. I guess the problem was my computer crashed in the middle of the night.

Well, I've left it on all day, but it's still frozen. The data files (logs, chain etc) are still being wrote to disk in realtime, it's just the damn thing's frozen (and will get an end program dialog if i click it's window). Wonder if I'm still staking.

https://i.imgur.com/xFy9SZy.png

[almightyruler]

I did what I thought would be a quick hack to demonstrate that it's possible to determine the block reward in advance - but it's turned into something a bit more involved as I try to track down why it doesn't seem to be working. While it's possible that there's a problem with my head, I think it may actually be a problem with the code. In particular, these two lines:

Code:

        double multFactor = 3000; //Exponential Curve Factor
...
        double nCoefficient = pow(randCoefficient, multFactor);

If I'm thinking right, multiplying a number less than 1 (randCoefficient) to the power of 3000 (multFactor) is going to result in an absolutely tiny number, requiring an impossible level of precision, that cannot be represented by a double as anything other than 0.

That means this line:

Code:

        int64_t nSubsidy = ceil(((maxReward - minReward) * nCoefficient) + minReward);

Will always evaluate to minReward (0.1)

Here's some debug output with real world block hashes, showing that nCoefficient is always 0, therefore nSubsidy is always 0.1:

Code:

07/12/14 14:26:43 DebugProofOfStakeReward hash=29f0d2a76fdf4573847a seed=72824903 random=542291982 randCoefficient=0.252524 nCoefficient=0.000000 nSubsidy=0.10
07/12/14 14:28:16 DebugProofOfStakeReward hash=2d99d6f4ee45131ac67f seed=20032615 random=1693255362 randCoefficient=0.788483 nCoefficient=0.000000 nSubsidy=0.10
07/12/14 14:29:42 DebugProofOfStakeReward hash=f9866c8058933118ea75 seed=51482279 random=1715902391 randCoefficient=0.799029 nCoefficient=0.000000 nSubsidy=0.10
07/12/14 14:32:03 DebugProofOfStakeReward hash=643bfcdef7c6ae2c07e7 seed=182632574 random=3318700 randCoefficient=0.001545 nCoefficient=0.000000 nSubsidy=0.10
07/12/14 14:32:35 DebugProofOfStakeReward hash=43c409e4d4b3372218ed seed=57811342 random=1825586551 randCoefficient=0.850104984 nCoefficient=0.000000000 nSubsidy=0.10
07/12/14 14:32:48 DebugProofOfStakeReward hash=2d5a3f182d648612d8eb seed=140586382 random=2036807530 randCoefficient=0.948462417 nCoefficient=0.000000000 nSubsidy=0.10
07/12/14 14:35:12 DebugProofOfStakeReward hash=bfa797d451978c9a483b seed=147432579 random=463092525 randCoefficient=0.215644261 nCoefficient=0.000000000 nSubsidy=0.10
07/12/14 14:35:30 DebugProofOfStakeReward hash=cf2dee303d5ef0cb8e4f seed=252492004 random=1580658763 randCoefficient=0.736051595 nCoefficient=0.000000000 nSubsidy=0.10
07/12/14 14:36:00 DebugProofOfStakeReward hash=575cab3b77a4c635f444 seed=207839044 random=678160768 randCoefficient=0.315793216 nCoefficient=0.000000000 nSubsidy=0.10
07/12/14 14:41:24 DebugProofOfStakeReward hash=af3cd07b9b0af2da3c17 seed=254649281 random=1091820355 randCoefficient=0.508418472 nCoefficient=0.000000000 nSubsidy=0.10
07/12/14 14:42:15 DebugProofOfStakeReward hash=b98846a1e1595b07b671 seed=95452007 random=448878011 randCoefficient=0.209025113 nCoefficient=0.000000000 nSubsidy=0.10
07/12/14 14:42:42 DebugProofOfStakeReward hash=91a0ef3ed4daf73275b0 seed=259204955 random=1059632437 randCoefficient=0.493429805 nCoefficient=0.000000000 nSubsidy=0.10

[undergroundgeek]

I'm trying to stake, but the client says the coins aren't "mature".

8 hours, right?

Minimum Stake Age: 8 Hours

[phzi]

I did what I thought would be a quick hack to demonstrate that it's possible to determine the block reward in advance - but it's turned into something a bit more involved as I try to track down why it doesn't seem to be working. While it's possible that there's a problem with my head, I think it may actually be a problem with the code. In particular, these two lines:

[...]

Try some larger values. Your tests may be correct, but you're missing the 'lotto' aspect of this.  The odds of hitting a block greater then the minimum are fairly low.  Also, what happened to ceil() when calculating nSubsidy?  Shouldn't it be impossible to have an nSubsidy value less then 1 as a result of rounding with ceil()?

Here's how I read the code:

nSubsidy = ceil(((maxReward - minReward) * nCoefficient) + minReward);
nSubsidy = ceil(((1000 - .1) * nCoefficient) + .1)
nSubsidy = ceil((999.9 * nCoefficient) + .1)

Since ceil rounds up, if (999.9 * nCoefficient) is 0, then nSubsidy = 1.  So, for the lotto effect it must be true that (999.9 * nCoefficient) > .9:

nSubsidy = ceil(.9 + .1) = 1
nSubsidy = ceil(.91 + .1) = 2

So, what are the odds of hitting a lotto block?

(999.9 * nCoefficient) > .9
nCoefficient > .00090009
nCoefficient = randCoefficient^multFactor
nCoefficient = randCoefficient^3000
randCoefficient^3000 > .00090009
randCoefficient > .997665

So, you have 2,335/1,000,000 odds (467/200,000) of hitting a lotto block.

Of course, as randCoefficient grows, so does the reward.

nSubsidy = ceil(1.91 + .1) = 3
(999.9 * nCoefficient) > 1.91
nCoefficient > .00191019
randCoefficient^3000 > .00191019
randCoefficient > .997915

(2,085/1,000,000) odds of a reward >= 3

nSubsidy = ceil(98.91 + .1) = 100
(999.9 * nCoefficient) > 98.91
nCoefficient > .0989199
randCoefficient^3000 > .0989199
randCoefficient > .999229

(771/1,000,000) odds of a reward >= 100

nSubsidy = ceil(899.91 + .1) = 900
(999.9 * nCoefficient) > 899.91
nCoefficient > .9
randCoefficient^3000 > .9
randCoefficient > ~.999965

(35/1,000,000) odds of a reward >= 900

Max reward:
nSubsidy = ceil(998.91 + .1) = 1000
(999.9 * nCoefficient) > 998.91
nCoefficient > .99901
randCoefficient^3000 > .99901
randCoefficient > ~.9999996698

(almost impossible odds ~ 3/10,000,000)

I did this in my head while reading the code; no promises I didn't miss or miss-interpret something.

You ask for detailed information about the hard-fork.
I assume you have read the two paragraphs of explanation in the OP Post?

In addition, you are aware that the code applied, is not the code that was previously linked to by a community member; i.e. there are no "tiers" in the Lottery implementation?  The lottery implementation is an exponential decay function smoothly adjusting the reward?

Yes, indeed... my comments were based on my read-thru of the latest github commits and the OP in this thread.

The fact that the lottery is an exponential decay function is exactly what I am asking that you explain properly in the OP.  Most people can't be expected to read or test the code to understand this, and I suggest that your explanations have been a bit overly simple so far.  How about a nice graph/chart showing the odds of different block rewards, along with a few more comments about how this is a positive thing?

Hardforks without detailed and well considered information about the effects of that hardfork are simply worrying.


~260 blocks left until lotto fork.

[SuperClam]

Yes, indeed... my comments were based on my read-thru of the latest github commits and the OP in this thread.
The fact that the lottery is an exponential decay function is exactly what I am asking that you explain properly in the OP.  Most people can't be expected to read or test the code to understand this, and I suggest that your explanations have been a bit overly simple so far.  How about a nice graph/chart showing the odds of different block rewards, along with a few more comments about how this is a positive thing?
Hardforks without detailed and well considered information about the effects of that hardfork are simply worrying.
~260 blocks left until lotto fork.

Phzi,

I am on a tablet, and thus not able to reference my notes concerning your math, but it seems quite accurate.  The exponential decay is so..... exponential.... to attempt to keep yearly inflation in line with previous targets, while providing incentive to folks (in as even a manner as possible) to stake.  One of our primary concerns since launch has been the rate and consistency with which the network has been staking blocks.  This update was in large part designed to attempt to help in that respect by providing a larger pool of people who have an interest in staking.

Is anyone in the community good with graphs?  To be completely honest, I have never rendered a line graph or such, but it would be helpful in visualizing the reward structure.  If anyone has noticed, we aren't exactly skilled with the whole marketing and visual aspect of this

It was never our intention to 'thrust' this upon everyone or make it feel as though it was without warning.  We had been promising this update, and hinting at it via twitter from sometime; in addition in Poloniex trollbox.  The code was set with block heights initially with block time estimates placing it squarely in Sunday evening.  Since then, the network has continued to grow and even after pushing it back 500 blocks, it appears our targets just aren't accurate as the stake time seems to continue to change.  The difference between 10 minutes block times and 2 minute block times on fork estimates is, well, drastic.

Ironically, it is exactly that problem that drove the fork itself - an unhealthy crypto network is a vulnerable crypto network.  Any 'use' requires a stable, consistent stake time...  It was our hope that providing a decent incentive to smaller holders (which the majority of claimers are likely to be, and given their output age are likely to stake almost immediately upon importing) they would see the immediate 'reasonable' stake in their wallets and share some of our excitement for CLAMS -> hopefully, getting involved in the community instead of dumping their 'share' and moving onward.  The choice of an exponential decay function was quite simple, as we are not a fan of inflation.  We saw it as the only way to provide the opportunity and powerful incentive of large gains, which will hopefully get folks involved in the network, while at the same time maintaining a reasonable inflation rate.

One of our major problems right now is: How do we get friends who claim their CLAMS to stick around, get involved, participate in the network and increase security and consistency, instead of claiming their CLAMS, dumping them, and moving on.  We saw this lottery update as a step in the direction of solving that issue.

Will be back a bit later - I hope that helps a bit in framing some our thoughts behind the entire issue,

Yours Truly,
SuperCLAM.

[personOfUninterest]

I'm trying to stake, but the client says the coins aren't "mature".

8 hours, right?

Minimum Stake Age: 8 Hours

Mine took longer than 8 hours. From what I could tell maybe twice as long. If it tells you your stake reward is in 20 minutes, wait 20 minutes and it might say 15.

Then again, I'm not a CLAMillionaire. So I don't know if that's the reason. But it appears the averages could be optimized.

[xploited]

I'm trying to stake, but the client says the coins aren't "mature".

8 hours, right?

Minimum Stake Age: 8 Hours

Mine took longer than 8 hours. From what I could tell maybe twice as long. If it tells you your stake reward is in 20 minutes, wait 20 minutes and it might say 15.

Then again, I'm not a CLAMillionaire. So I don't know if that's the reason. But it appears the averages could be optimized.

8 hours is really just an estimate based on how long it takes to reach maturity. The block maturity is 500, so 510 (10 for confirmation) blocks after you put the Clams in your wallet the green light should come on and staking should begin. The block times have been slower then then should be which is why it would have taken more then 8 hours. 

Also, from my understanding the 'stake reward time' is just an estimation calculated from your weight and the network weight. It can be pretty inaccurate (from experience), especially with growing networks like Clam's

[yampi]

Is this normal?



All I tried to do was start the client. Was running fine last night.

Edit - Uninstalled and reinstalled - nothing. Copy CLAM data folder (appdata). Delete original, starts ok. Shut it down and replace blkxxx.dat and wallet.dat with backups.

And, success. Somewhat - it opens but looks like the wallet is frozen but still dealing with files. I guess the problem was my computer crashed in the middle of the night.

Well, I've left it on all day, but it's still frozen. The data files (logs, chain etc) are still being wrote to disk in realtime, it's just the damn thing's frozen (and will get an end program dialog if i click it's window). Wonder if I'm still staking.

Delete everything but wallet.dat
If it fails to start or freezes then your wallet.dat most likely is corrupted.
Make frequent backups.

[CryptoPromotions]

Too late to get some clams? I'm hungry.

 

[ymod123]

Too late to get some clams? I'm hungry.

 

right on time....

[almightyruler]

So, you have 2,335/1,000,000 odds (467/200,000) of hitting a lotto block.

Must have been my head that was the problem, then. I assumed (wrongly) that the reward for every block would vary. Thanks for the math to prove it.

I can now see some blocks that would have - if we were already on the lotto system - generated a reward higher than 0.1:

Code:

07/12/14 17:10:47 DebugProofOfStakeReward hash=989474017103111cb636 seed=17943395 random=2129073648 randCoefficient=0.991427176 nCoefficient=0.000000000 nSubsidy=0.10000001
07/12/14 19:04:53 DebugProofOfStakeReward hash=ad6472e8b0fa20a17657 seed=34215781 random=2143547323 randCoefficient=0.998167006 nCoefficient=0.004070347 nSubsidy=4.16993978
07/12/14 19:08:11 DebugProofOfStakeReward hash=22dd16b4b37f1493c1ec seed=21576734 random=2134171368 randCoefficient=0.993800987 nCoefficient=0.000000008 nSubsidy=0.10000792

I'll wait until the fork to confirm that I've properly matched hashes and blocks, but I'll repeat my concern: it appears to be possible to calculate the reward in advance, therefore it is simple to add a conditional to only try to mint PoS when it's worth it.

[SuperClam]

Too late to get some clams? I'm hungry.
 

right on time....

Indeed; right on time indeed

Must have been my head that was the problem, then. I assumed (wrongly) that the reward for every block would vary. Thanks for the math to prove it.
I can now see some blocks that would have - if we were already on the lotto system - generated a reward higher than 0.1:
I'll wait until the fork to confirm that I've properly matched hashes and blocks, but I'll repeat my concern: it appears to be possible to calculate the reward in advance, therefore it is simple to add a conditional to only try to mint PoS when it's worth it.

Likely a very reasonable concern, as I have previously mentioned.  
We never claimed to be perfect  

Remember though, lottery blocks are quite rare and the standard reward of 0.1 likely accounts for quite a decent percentage on most outputs considering it can be staked every 8 hours.  It wouldn't take many missed attempts to quickly erode the gains you might make from such a strategy.  We have been looking at ways to utilize a system where the current block's reward coinStake is signable by the previous block's creator - essentially requiring a double stake to have any influence.  There are concerns with using the current block, as 'choosing' not to stake could have similar repercussions in that situation as well.

In the meantime, we will continue to improve the CLAMClient; thank users like yourself for identifying possible concerns so that we know where we need to improve; and keep-on-clammin'.

We anticipate some type of improvement to the randomization system in the next update.  
You seem knowledgeable... Sure would be priceless to get the community involved in the project on git.

A better CLAMClient benefits us all,

SuperCLAM.

[SuperClam]

100 Blocks to the Lottery Update Fork.

Blocks are crawling....

This is precisely why we wanted to increase the incentive to consistently stake on the network....

[xploited]

So, you have 2,335/1,000,000 odds (467/200,000) of hitting a lotto block.

Must have been my head that was the problem, then. I assumed (wrongly) that the reward for every block would vary. Thanks for the math to prove it.

I can now see some blocks that would have - if we were already on the lotto system - generated a reward higher than 0.1:

Code:

07/12/14 17:10:47 DebugProofOfStakeReward hash=989474017103111cb636 seed=17943395 random=2129073648 randCoefficient=0.991427176 nCoefficient=0.000000000 nSubsidy=0.10000001
07/12/14 19:04:53 DebugProofOfStakeReward hash=ad6472e8b0fa20a17657 seed=34215781 random=2143547323 randCoefficient=0.998167006 nCoefficient=0.004070347 nSubsidy=4.16993978
07/12/14 19:08:11 DebugProofOfStakeReward hash=22dd16b4b37f1493c1ec seed=21576734 random=2134171368 randCoefficient=0.993800987 nCoefficient=0.000000008 nSubsidy=0.10000792

I'll wait until the fork to confirm that I've properly matched hashes and blocks, but I'll repeat my concern: it appears to be possible to calculate the reward in advance, therefore it is simple to add a conditional to only try to mint PoS when it's worth it.

I think you might be able to migrate the problem by setting a maxium stake time and resetting it once it reached the max. It would make staking more competitive (I think) and not really allow you to just sit around and not submit your blocks.  If you were to wait to long then the advantage of not submitting would be lost as you would be on the same level as everyone when the reward block came around, giving you no advantage.

Its just an ideaI had, might not work.

thoughts?

[istvandv]

block 33920 now

dont forget to update wallet and go clamming for pearls

[kbroadfoot]

block 33920 now

dont forget to update wallet and go clamming for pearls

Clams and pearls... is like krill and seals...

[SuperClam]

block 33920 now
dont forget to update wallet and go clamming for pearls

Clams and pearls... is like krill and seals...

Only 30 Blocks to the Update

[kidyubyub]

When I click the link for the Windows wallet update 1.4.2b, I get this as a file download: CLAMClient_1.4.2b_Windows.tar.gz. Is this incorrect, or am I doing something wrong?

[SuperClam]

When I click the link for the Windows wallet update 1.4.2b, I get this as a file download: CLAMClient_1.4.2b_Windows.tar.gz. Is this incorrect, or am I doing something wrong?

Not at all, it is compressed to make it download quicker.
Most standard decompression programs should work (7zip, etc.).

If you still can't figure it out, I am happy to package up a zip file for folks!