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

[BayAreaCoins]

Long Live the Great Clam.

Sometimes people complain that they've been staking for a long time and not got any stakes yet.

Since I made the new Just-Dice staking wallet I've been watching to see how it performs, staking wise.

I found there's huge variance. I made around 13000 outputs of size 100 CLAMs, and set them to split into 25 CLAM outputs when they stake.

Some outputs have staked incredibly well. This one staked 5 times in 8 days, despite only being worth 26 to 30 CLAMs for most of that time:

84d121      -> 100 CLAM   1044120 (2016-06-21 22:14:24)
cbdfb7  100 ->  26 CLAM   1045413 (2016-06-22 18:53:20)
a799ea   26 ->  27 CLAM   1050053 (2016-06-26 00:42:40)
c6709f   27 ->  28 CLAM   1050991 (2016-06-26 16:32:00)
00d648   28 ->  29 CLAM   1052089 (2016-06-27 11:02:40)
e58636   29 ->  30 CLAM   1054628 (2016-06-29 05:42:24)

Whereas none of the 146 inputs to 462d2e worth a total of 14600 CLAMs staked at all in 9 days. I sent them all back to the hot wallet to top it up after a few large withdrawals.

Could it be the lottery all over again with developers gaming the system?

Seems strange and a possible red flag again.

[1713529448]

1713529448

[1713529448]

1713529448

[1713529448]

1713529448

[presstab]

I remember last time the chart looked similarly weird, and presstab commented saying he should fix it.

Alright alright, enough reminders finally prompted me to patch that up for you.

[rocoro]

Long Live the Great Clam.

Sometimes people complain that they've been staking for a long time and not got any stakes yet.

I've noticed when staking, some days in a row I get none.  Other days I get more, and seems to make up for the days I got none.

I think its just variance.

[presstab]

Long Live the Great Clam.

Sometimes people complain that they've been staking for a long time and not got any stakes yet.

I've noticed when staking, some days in a row I get none.  Other days I get more, and seems to make up for the days I got none.

I think its just variance.

I always think of long term staking in terms of the law of large numbers.

[jpcfan]

Can't believe a coin called Clams held it together this long. 

clam will be the next ETH

[jpcfan]

JD site is down. please call 911 and fix ASAP please

[marilyn4325]

Can't believe a coin called Clams held it together this long. 

clam will be the next ETH

Needs more features, like the ability to create your own coin ( https://www.ethereum.org/token the site is a bit outdated, it is possible with a mouse click in the latest GUI) and of course, smart contracts.

[rocoro]

Needs more features, like the ability to create your own coin ( https://www.ethereum.org/token the site is a bit outdated, it is possible with a mouse click in the latest GUI) and of course, smart contracts.

Too much bloat,  a currency should just be a currency.  And we don't need everyone making "teletubby" / chucky cheese coins, tokens.

[neogen1]

where can i find a new bootstrap, because my wallet stopped sync at block 1047837

thx for help :-)

[dooglus]

where can i find a new bootstrap, because my wallet stopped sync at block 1047837

thx for help :-)

You can probably fix it by shutting down the wallet and restarting it.

But I've updated the bootstrap too, at the usual URL.

[dooglus]

Since I made the new Just-Dice staking wallet I've been watching to see how it performs, staking wise.

I found there's huge variance.

Could it be the lottery all over again with developers gaming the system?

Seems strange and a possible red flag again.

No, it can't be the developers. The behavior I'm seeing is entirely on the JD staking wallet, which the developers don't have access to.

All we're seeing is variance in action. I have thousands of outputs staking. Each output expects to stake about once every 40 days. Of those thousands, some are bound to be unusually lucky.

As it happens, I now have 4 outputs that have staked 5 times each, not just one of them as before, but none that has staked 6 times yet:

  54f0aa
  55e31f
  debed8
  e58636

[SuperClam]

where can i find a new bootstrap, because my wallet stopped sync at block 1047837
thx for help :-)

You can probably fix it by shutting down the wallet and restarting it.
But I've updated the bootstrap too, at the usual URL.

 
 
You are likely best served with a restart, as dooglus has suggested. 
 
For those with initial-sync problems, the bootstrap is likely still the best solution. 
 
In the very near future there will be an update coming dealing specifically with the network. 
 
The code is currently pulling data via requests in a duplicitous manner as well as improperly handling inv messages from older code. 
Combine that with our 'jump backwards' misbehavior code and the client is Long overdue for better net code.

[kito]

No, it can't be the developers. The behavior I'm seeing is entirely on the JD staking wallet, which the developers don't have access to.

I wonder if the size of the staking wallet affects the probability of staking.  Although POS doesn't require as much work as POW, there is still hashing going on for each input.  For smaller wallets this time is small . However for a large wallet or wallets with lots of tiny inputs, then I assume clam client does the hashes in a serial fashion which cause the 1st inputs to have a higher probability to stake vs ones which happen later in time.

[dooglus]

I wonder if the size of the staking wallet affects the probability of staking.  Although POS doesn't require as much work as POW, there is still hashing going on for each input.  For smaller wallets this time is small . However for a large wallet or wallets with lots of tiny inputs, then I assume clam client does the hashes in a serial fashion which cause the 1st inputs to have a higher probability to stake vs ones which happen later in time.

The JD staking wallet does often have two outputs which are able to stake at the same time, and so only the first of them gets to stake.

This one staked 5 times in 8 days, despite only being worth 26 to 30 CLAMs for most of that time:

That one recently staked again, for 6 stakes in 17 days: (edit: 7 stakes in 19 days!)

84d121      -> 100 CLAM   1044120 (2016-06-21 22:14:24)
cbdfb7  100 ->  26 CLAM   1045413 (2016-06-22 18:53:20)
a799ea   26 ->  27 CLAM   1050053 (2016-06-26 00:42:40)
c6709f   27 ->  28 CLAM   1050991 (2016-06-26 16:32:00)
00d648   28 ->  29 CLAM   1052089 (2016-06-27 11:02:40)
e58636   29 ->  30 CLAM   1054628 (2016-06-29 05:42:24)
4170b5   30 ->  31 CLAM   1067683 (2016-07-08 09:20:16)
60ca71   31 ->  32 CLAM   1070634 (2016-07-10 10:57:52)

Whereas previously we would expect one of the thousands of outputs to be lucky, it's kind of surprising that the one which was previously the luckiest staked again in just 9 days when we would expect it to take around 33 days (edit: and then it staked again, just 2 days later!).

I added some code to spit out the txid and value of every 1000th output as it's checking for staking to see what order it checks in:

CWallet::CreateCoinStake() iteration 0
txid 9b85808e67aee6e2c6873a1ec1ad41a49050683506d1154714602f6be030f504 value 100.00
txid 9c289f367372d4f070bb67a49b1886532da0d19113a47fbeee17f2b682a2b909 value 25.00
txid c63ec1be3e4fb7dd0b8cac27aa407449160ecf1147c320cd0e86de630789ab0f value 25.00
txid 380d0d52ec8bd8bdc383c2a1317b77d9292fc4d7680eebc4b3c4ea9f457bfe14 value 26.00
txid c49f9e7812f309cb723fa55a78400c5f5ddf55891c837f9f17125873fedf941a value 25.00
txid b652f5dcc4da57683d12142e6e76d1d2022e78da0ab12e4de0f3d6f042f85220 value 25.00
txid cdb02cd119f8c2fb32792ce9770acf95e27b9c7c00b5d58452c63929ecb78026 value 26.0001
txid 98aa0297c835e372424957c4b0a58181ee223d95fed7d02ec2c849dcf1752c2c value 27.00
txid 7975bca559eee9b09d89d7a4e38faa47fdd99172d736c7bd81e343606907f231 value 25.00
txid 3a1951620a08d2a2591d947f2e5f6380829b544f051bff9c0225760ce86b3037 value 25.00
txid 7f3a568871c79cd361ec4f2a41d2493f4fa041b39458673c22f29ec45d54773c value 25.00
txid 1f49fb96685c2622a7487553dea48eced365704e83005cbbb56d17330acf4641 value 26.00
txid 3e5542b64c4fe1b57f69e588a86706843f396c930666a2ae4938941a38393946 value 28.0002
txid 9adeffdd5736b070872462f7b5e41053edbeacbda6322cc7ca7a983e64c1814c value 25.00
txid 9bb6a0b9bf8a299bd01c0234c6acaf69f5604b028d3f1a7f36463a513192bc51 value 25.00
CWallet::CreateCoinStake() iteration 15000
txid f02005c4188851983e3fb00cb712e109e243f112c09333331e85911153309c56 value 25.00
txid c9232307df0c5c66c81b6b312d8c14507f7fb0be84ffb32a2f6df26e9433b15b value 25.00
txid 028a55a175e3581e2520241989de310c91d5b9e915960ee7001923a8cc3bc661 value 25.00
txid 1fff98a5e28678325cce78b9b43feecc8c1cf3d63bc7f1888f5ed72150a86267 value 25.00
txid 1b998d7b47d236c907f1fb4235fad9efb7a2032c257063f792a365270d0eb96d value 25.00
txid aaba3fcbd7df14974f491253f3142bc2c984a46fa39a14511cba8b61e7e76473 value 25.00
txid aa7614f556a41fced204ba11821d3cd07324c18b2d0ac489237f09d787b30e79 value 26.00
txid fdd26dccb3ef7197cfffae0a859bece6e55c2ba81bf2ac99f8258c043c8a9f7e value 25.00
txid 1f92ef18964027cd356d0025302fa7e2b257911efc353eb377570a8824117d83 value 26.00
txid 4b85edb826508142db9af391888dd656b724db06b8d91716fa00c2759b5e0989 value 25.00
txid c1d837611f12d402460918e95a77525af840954b36d69b497f9d0488e2f89e8f value 26.00
txid d85223cf502c00371dbb325ac9ffebe2fdaebdc3d3d1332ccaa94e9856b2b495 value 25.00
txid 97dcb886be8e55871befab8bfa49361b68806ce64ce1a067371867dd2201e59b value 26.00
txid 702744a0c84026f60ff2e2be867a6e4289c80d5066fe24f5b2e14c615a2f4ca1 value 25.00
txid f8236b917599b1be1fa4b664347e860bab45f87c02a3c777ee45333fa5cdd7a7 value 27.00

So it's not sorted by txid or value, but it does seem to always be in the same order.

[kito]

>The JD staking wallet does often have two outputs which are able to stake at the same time, and so only the first of them gets to stake.

It may be so, but I was more curious about the the actual hashing events being serialized.  Lets say a a wallet had 1 million inputs, then how long would it take hash all 1 million inputs? My guess is the first 1/2 million would have a greater probability to stake and not orphaned then then last 1/2 million just due to the time it takes to do hashing. 

Doesn't the 1st person who has a valid stake and propagates over the network win? 

[mastertrader777]

Hello Clam Community,

Would any of you guys be interested in some Clam apparel?

I would love to host an outlet for this apparel but I would like to see if you all are interested?

Anyone have some Clam high rez logos?

www.CryptosCloset.com - Your #1 Online Crypto Apparel Boutique accepting many different crypto currencies.

Let me know what you all think!

Thanks,

Rich

www.CryptosCloset.com

[Timetwister]

What percentage of the total "redeemable" CLAM coins have been claimed?

[andulolika]

What percentage of the total "redeemable" CLAM coins have been claimed?

12:37:40 INFO: 182,404 of 3,208,032 sets of 4.60545574 CLAM were dug up so far from the initial distribution
12:37:40 INFO: 840,054 CLAM were dug up and 964,844 CLAM were staked for a total of 1,804,897 CLAM

[dooglus]

>The JD staking wallet does often have two outputs which are able to stake at the same time, and so only the first of them gets to stake.

It may be so, but I was more curious about the the actual hashing events being serialized.  Lets say a a wallet had 1 million inputs, then how long would it take hash all 1 million inputs? My guess is the first 1/2 million would have a greater probability to stake and not orphaned then then last 1/2 million just due to the time it takes to do hashing. 

Doesn't the 1st person who has a valid stake and propagates over the network win? 

Oh, yes. If it takes you more than 16 seconds to check all your outputs then you're going to be missing out of some stakes. I am able to check about 15k outputs per second, and have around 46k outputs attempting to stake at any given time, so it takes 3 or 4 seconds to check for stakes. You wouldn't want to have a million outputs unless you had a significantly faster staking machine. You would want to combine some of those outputs into a more manageable set.

I'm not sure what happens if one of your peers sends you a block while you are working through your outputs. Maybe you stop working and use the peer's block, or maybe you keep working hoping to find an output of your own which can compete with the peer's block.

[kito]

>I'm not sure what happens if one of your peers sends you a block while you are working through your outputs. Maybe you stop working and use the peer's block, or maybe you keep working hoping to find an output of your own which can compete with the peer's block.

This to me is the difference.  A single user may finish hashing their wallet in under a millisecond vs JD jumbo wallet which takes 3-4 secs.  A 4 second head start would allow a valid stake to completely update the entire network me thinks.  It might make sense for client continues to look for valid stakes for a few 100 milliseconds because the time to propagating a valid stake is kind of variable, but after that it seems like it would be a wasted effort.  I do not have the knowledge to read code to know how clam works.