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

That's how long it takes to search for staking opportunities each 16 seconds. Most times you check you find that there isn't any such opportunity. There's only one per minute globally, so even with 100% of the staking weight you'd have around a 1 in 4 chance of any particular search being successful. When we do find a block, it will be at a random point through that 4 second search, and so on average a successful search takes 2 seconds ((0 + 4) / 2).


I don't think you're understanding still. "Difficulty leading to 16 seconds" isn't what's happening. The difficulty adjusts how hard it is to stake a block. It adjusts such that we find around one block per minute. But blocks can only be found when the time (in seconds since some date in 1970) is a multiple of 16. That only happens every 16 seconds. That's fixed by the protocol (until the developers change the protocol again, of course), and isn't related to the difficulty.


It's a real 4 seconds. 4 seconds out of every 16 seconds the CPU on one core of JD's staking wallet server is pegged at 100%. They're outputs of the transactions that created them. They're not the inputs of any transactions yet, or they wouldn't be unspent. They're potential inputs, if you like, but actual outputs. When they stake they become inputs of the staking transaction.

The rounding down to an integer was related to how the age of an output affected its staking power in an older version of CLAM. I think it used to multiply the value by the age and round down to an integer. I don't think it does that rounding any more, or the multiplication by the age. These days the staking power (called the "weight") is just the same as the value in CLAMs. Each output is considered separately. It doesn't matter if you have lots of 1 CLAMs outputs on a single address, or in lots of different addresses. They each get their own individual chance of staking, with a probability proportional to their own individual value in CLAMs.

There is a benefit to splitting your outputs up into several smaller outputs. Suppose you have 1000 CLAMs. It will stake very quickly, and become 1001 CLAMs. But then it will take 8 hours to mature before it can stake again. The best you could hope for it that it will stake 3 times per day (since that's how many 8 hour maturation periods you can fit into a day).

If instead you split it into 1000 outputs of size 1, each one tries to stake independently. Each one has a 1000 times lower chance of staking than the 1000 CLAM output did, but there are 1000 of them, so it takes roughly the same time for one of them to stake, and turn from 1 CLAM to 2 CLAMs. Then, however, only the 2 CLAM output is frozen for 8 hours while it matures. The other 999 CLAMs continue trying to stake. So you have saved yourself an 8 hour wait for 99.9% of your value.

If you split your value up into *too* many outputs, you'll have too much hashing to do every 16 seconds that you won't be able to get through it all. And if you ever want to spent your outputs, having them split up into millions of tiny pieces makes the transaction which spends them very big (and so very expensive in tx fees).

So there's a tradeoff - split enough, but not too much.

Deb calls it "the clamily".

I don't understand what you're asking, sorry.

The CLAM protocol has a time granularity of 16 seconds. Every 16 seconds it checks each of its unspent outputs to see if it can stake, then sleeps until then next 16-second "tick" of the clock.

If it takes you more than 16 seconds to check all your unspent outputs then you'll be missing out on staking opportunities, because you'll be falling further and further behind. JD is able to do all its staking work in 4 seconds and have a 12 second snooze before the next opportunity comes up.

I don't understand the bit about "missing 3 variations of hashes". There's only one hash per output per 16 seconds.

Now if JD was able to check all of its outputs in 0.001 seconds then it would probably have a lower orphan rate, since it is kind of a race. Maybe that's what you're referring to?

I believe this means that you are missing 3 variations of hashes for each output per every 4 seconds?

Awesome work with the stake data chilly2k - we're happy to have you as part of the family

     Today is my 1 year Clammaversary.  One year ago today I got my first Clam stake.    This was pre-lottery and pre-fixed reward.  It was for a whopping 0.00657097 clams.  

      Thanks to all for make the past year an enjoyable one, and wishing all the best for the next year.  

Try this again. 

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


   I'll try to keep this up for another 2 weeks, to see how variability comes into play.   My stakes have been all over the board from a low of 2 per day to 8 per day.  So over times we should see how it levels out. 

Oh, that makes more sense then.


4 Seconds? Is that needed for finding a block each time? Given a difficulty leading to 16 seconds these 4 seconds would be huge. I mean the difference to orphan blocks or get block orphaned. Or isnt it needed to calculate a block?


Then i misunderstood your sentence.

So the 4 seconds are real and you meant it goes through each of that outputs (shouldnt it be inputs as long as they arent sent out?) and checks if it finds a hash? Does the output amount matter here? I mean you described rounding the amount of clams down to an integer. Does this apply to the address these outputs are on, so a big amount of clams or only to the single output? If the latter then one could get an advantage by sending the clams in amounts of 1 to a new address. The chance to find a block would be maximized?

Maybe you misunderstood. Staking destroyed age, setting it back to zero. So it's not like old coins keep getting old and staking at the same time. You choose: stake, or gather age. The idea seemed to be that you could load up your wallet once a month and collect all the built up staking that had accumulated due to the age. But when staking is meant to secure the network surely you don't want people only doing it once a month. Hence the abolishment of 'age'...


All the inputs are fixed. You can't increase your chances of finding a 'good' hash by throwing more CPU at it. You could calculate hashes somewhat in advance (though I think some of the inputs depend on recent blocks, so not too far in advance) but hashing doesn't take long anyway. The JD staking wallet checks something like 30k outputs in 4 seconds.

src/kernel.cpp says this:


and this:


I've never tried to understand it fully, but it looks like the author went to some lengths to make it hard or impossible to game.


I did? I didn't mean to. It checks each *output*. You can have multiple unspent outputs per address. JD keeps most of its value split into 30k separate outputs at a single address. The wallet loops through all the unspent outputs it controls, does a hash for each of them, trying to find one that hashes low enough to stake a block.

*lol* Sounds like a currency that rewards you for NOT using it as a currency. If i would have read it without knowing clams i would think this is a scamcoin and the creators did this to become rich.


Thanks for the explaination. So the sets of parameters for each second are fixed. You cant try different hashes in one second. Or 16 seconds, now. Would one have an advantage when calculating hashes in advance? I guess so since finding hashes for the same second should be hard. I mean where do you take the second from? Your second can be some seconds after the seconds of other miners, so you would be late all time, not finding a block ever.

And you said the wallet checks each of your addresses. Does this mean you can have different addresses in your wallet and you could try out each one if it creates a correct hash?

Yeah, you don't just leave dead links like that. I'm sure it's just an oversight.

Confirmation on my suspicion.

https://twitter.com/BayAreaCoins/status/617480509359132672