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

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

Indeed; right on time indeed

---

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.

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.

right on time....

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

 

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

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

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.

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.

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.

---

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.

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

8 hours, right?

Minimum Stake Age: 8 Hours

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:


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:


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:

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

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.

First, and foremost, you have indeed been involved in this thread for some time; and CLAMS in general -> thank you.
It is always your ability and prerogative to publish an alternative wallet.  Personally, I would much rather you apply that effort and skill towards helping us improve the CLAMClient - starting with the random block issue you are so extremely worried about.  We are a new and yet small network; forks are not impossible by any means.  We have never claimed to be Jedi-Developers.  In fact, we have repeatedly suggested folks post issues, and get involved - you would be welcomed to the team, just as anyone else here.

---

Your argument that you will stake each the same regardless of the contents only holds sway in an immature network with low stake weight. 
In a higher stake weight network, those small outputs would struggle to stake at all.

---

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?

---

The reasoning is simple; one of the primary goals of CLAMS is Aequitas, as listed on the main image in the OP Post.

This takes away at least some of the advantage that massively rich holders have in a proof-of-stake system.

We don't believe that having a large pile of CLAMS (output) entitles a person to stake at will with a lower difficulty, earning the same amount of coins regardless of how often they stake their wallet (as coin age accrues).  As all things, we expect this to find a balance.  How large must the output/pile be to reliably stake often.  Users will then divide their coins into piles of that size (much as is the case with standard PoS where there is a "sweet spot" concerning compound interest and stake pile size).

In addition, staking your wallet only occasionally has security implications for the network. This has been a major problem for CLAMS just as it has been a problem for many other Proof-Of-Stake coins.  We have had sluggish and un-even blocks which affect users.  We much prefer a secure network where folks are rewarded for staking their wallets, and competing for blocks, continuously.

---

In short, this update is not rolling-back, as we don't believe it will allow folks to stake whatever size block they want at will.  We would much rather you apply yourself to getting involved and helping out with CLAMS, rather than developing software to attempt to subvert it -> but we can't force you to do so.  Regardless, your time spent in the thread is appreciated, and your concerns are listened to more than you might know.  Work has already begun to include adjustments to how the lottery system will work in the next update (which isn't very far in the future as it is).  You are personally invited to take part,

SuperCLAM

AKA block rewards waiting to be manipulated?  Simply put: revert this change NOW, or explain it in detail ASAP.

"Lotto" (pseudo-random/predictable) block rewards worked out horribly for every blockchain that has implemented this scheme of block reward determination for PoW blocks (Doge, the original implementation, eventually reverted their pseudo-random block rewards due to abuse)....

Why exactly do you think this is going to be different for PoS blocks? (hint: it won't...)

---

Until this is resolved to sufficient satisfaction, I strongly advise that nobody invest in CLAMs, and sell anything you have...

I have been in this thread and a supporter of this idea since close to the beginning, but this change is COMPLETELY UNACCEPTABLE WITHOUT FULL PRIOR EXPLANATION.

If the community does not receive a detailed overview of all changes in this hardfork, along with a precise overview of how this will affect the network in the future, plus detailed information about why this is secure, this coin is now dead in the water...

@SuperClam:  you are killing a great idea - the only possible reason I can imagine for such an unexplained fork is that you're trying to generate large lotto blocks for you/your-team though PoS reward manipulation....

Create some damn GUI elements if you are a competent enough dev to do so... stop changing things that were working fine and didn't need changing.

---

If SuperClam does not revert this fork, I will be publishing a wallet branch that ONLY stakes high-value lotto blocks....

Further point of consideration for everyone:  the way the new code is implemented, you're best splitting your clams into as many addresses as possible.  You will stake each the same, irrelevant of the age or contents.  Funny.... this sort of spreading coins between addresses is exactly how the CLAM devs could have rewarded themselves with an absurd amount of clams from the get-go, without anyone being the wiser (this has been brought up in this thread before, more then once).

Concerning "rarity" the answer should be, over the long-term -> no.

Running years worth of blocks through our scripts, the yearly inflation works out to very close to the same depending on luck, ~1-2%

It is quite "exponential" in that larger reward blocks are quite rare, much like a lottery.

If there are any adult ladies who are fans of CLAMS, there is a new NSFW Sub-Reddit ready for tip-posting:
CLAMS 4 CLAMS

---

Quite possibly a valid argument, though made MUCH less extreme due to the lack of multi-pools and such in a Proof-Of-Stake situation.
Age may still be able to be accrued waiting for better blocks, however.

Update #2 is coming fast down the pike, and though it wasn't intended to be a fork; there is no reason improvements that cause a fork can't be included.

Please create an 'issue' on the github page; the hash should likely be passed in from CreateCoinStake() when creating a stake block.
Passing your concern on to those more intelligent.

---

No rush, in fact it was planned for this weekend and the code has been complete for some time.

Someone started staking recently with quite a large pile; moved us from ~7-10 minute stake blocks to ~2 minute stake blocks which threw our previous estimates off by almost an order of magnitude.

All the more reason to incentiv-ize staking, as a healthier, more staked network wouldn't have such a range of stake times.

BTW SuperClam, you should post an update to the end of the thread, as well as updating the OP. If it wasn't for the discussion by others I would have never known about the upcoming fork.

Needs more notice, too. At the current minting rate the fork will happen in less than 24 hours. You're going to have a bunch of people this time tomorrow who have no idea the network has forked. What's the rush?

I've just had a quick look at the code, and it appears that the seed is based on the previous block's hash, therefore the reward can be calculated in advance.

It's going to be relatively simple (probably just one conditional statement) to modify the client to only try to stake if the reward for that block is above a certain amount. You don't even need special software like you would if doing selective PoW mining to take advantage of superblocks.

This means a client can choose not to stake unless the reward is (say) tier 3 or better. This allows someone with a smaller balance (who may not be able to stake much) to win more than they normally would. I consider this a serious flaw.

I don't understand why the reward system is being changed so soon after launch. Won't this completely change the 'rarity' of this coin?