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

mo

legendary

Activity: 1484

Merit: 1001

dooglus,Where can I see rich list? Thank you!!

lovewiki

sr. member

Activity: 271

Merit: 250

Share Love

Quote from: dooglus on July 11, 2016, 02:19:51 PM

Checking the staking wallet logs I do see that it continues to search its own outputs even if it accepts a block from a peer while searching. Here's an example:

Quote

starting stake
CWallet::CreateCoinStake() iteration 0
CWallet::CreateCoinStake() iteration 15000
CWallet::CreateCoinStake() iteration 30000
CWallet::CreateCoinStake() iteration 45000
CWallet::CreateCoinStake() found no stake
stake took 4s

starting stake
CWallet::CreateCoinStake() iteration 0
CWallet::CreateCoinStake() iteration 15000
stake 1.00 for xB2ecbVboyD513HJfvzvxw3tuNfRcUVUXv; not mine
SetBestChain: new best=5b2e7337902bc3e230541d1c47f135cd23efb2b984bc744aac54a5f14161691e height=1070779 trust=255420176884548245025 blocktrust=523267355223939 date=07/10/16 13:24:16
ProcessBlock: ACCEPTED
CWallet::CreateCoinStake() iteration 30000
CWallet::CreateCoinStake() iteration 45000
CWallet::CreateCoinStake() found no stake
stake took 2s

starting stake
CWallet::CreateCoinStake() iteration 0
CWallet::CreateCoinStake() iteration 15000
CWallet::CreateCoinStake() iteration 30000
CWallet::CreateCoinStake() iteration 45000
CWallet::CreateCoinStake() found no stake
stake took 3s

In this case we didn't find a block, so the peer's block won. I'll see if I can find an example where JD found a block after hearing about one from a peer.

Edit: I can't find any. I suspect that although it continues looping through all the unspent outputs, accepting the peer's block has somehow made it such that no local stake will be accepted and so it's a waste of time to even continue searching in the current time slot.

My understanding is that if a new block is accepted then the client should try to find the next block based on this child, not based on the old child. Is CLAM not working like this?

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: whenwhatwherewhyhow on July 22, 2016, 09:28:19 AM

What is the max supply cap of CLAMS?

There's one born every minute. What's the max supply cap of minutes?

Also, khashier.com seems to be down.

xploited?

whenwhatwherewhyhow

newbie

Activity: 45

Merit: 0

What is the max supply cap of CLAMS?

tryphe

member

Activity: 116

Merit: 10

Sweet!

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: dooglus on July 08, 2016, 03:54:47 PM

Quote from: dooglus on July 01, 2016, 12:14:36 AM

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!)

Quote

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)

I'm still monitoring the JD staking wallet. It started out with 13k outputs of size 100 CLAMs each, and I set it to split to 25 CLAM outputs when it stakes. I counted the number of outputs of each size each morning, and plotted those counts on a log scale:

I'm not sure this is of interest to anyone other than myself but it's kind of pretty so I thought I'd post it anyway.

kito

newbie

Activity: 13

Merit: 0

>stake took 4s ... stake took 2s ...stake took 3s

Interesting that the stake times can vary this much. I would assume on a fast PC this would be more consistent.

Maybe consolidating the outputs to reduce hashing would help.

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: kito on July 11, 2016, 01:42:12 PM

I do not have the knowledge to read code to know how clam works.

The code is multi-threaded. So the part which loops through your own outputs checking whether they can stake runs in parallel with the part which accepts new blocks from peers.

Checking the staking wallet logs I do see that it continues to search its own outputs even if it accepts a block from a peer while searching. Here's an example:

Quote

starting stake
CWallet::CreateCoinStake() iteration 0
CWallet::CreateCoinStake() iteration 15000
CWallet::CreateCoinStake() iteration 30000
CWallet::CreateCoinStake() iteration 45000
CWallet::CreateCoinStake() found no stake
stake took 4s

starting stake
CWallet::CreateCoinStake() iteration 0
CWallet::CreateCoinStake() iteration 15000
stake 1.00 for xB2ecbVboyD513HJfvzvxw3tuNfRcUVUXv; not mine
SetBestChain: new best=5b2e7337902bc3e230541d1c47f135cd23efb2b984bc744aac54a5f14161691e height=1070779 trust=255420176884548245025 blocktrust=523267355223939 date=07/10/16 13:24:16
ProcessBlock: ACCEPTED
CWallet::CreateCoinStake() iteration 30000
CWallet::CreateCoinStake() iteration 45000
CWallet::CreateCoinStake() found no stake
stake took 2s

starting stake
CWallet::CreateCoinStake() iteration 0
CWallet::CreateCoinStake() iteration 15000
CWallet::CreateCoinStake() iteration 30000
CWallet::CreateCoinStake() iteration 45000
CWallet::CreateCoinStake() found no stake
stake took 3s

In this case we didn't find a block, so the peer's block won. I'll see if I can find an example where JD found a block after hearing about one from a peer.

Edit: I can't find any. I suspect that although it continues looping through all the unspent outputs, accepting the peer's block has somehow made it such that no local stake will be accepted and so it's a waste of time to even continue searching in the current time slot.

kito

newbie

Activity: 13

Merit: 0

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

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: kito on July 08, 2016, 08:53:11 PM

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

andulolika

legendary

Activity: 2338

Merit: 1047

Quote from: Timetwister on July 09, 2016, 05:17:05 AM

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

Timetwister

legendary

Activity: 1199

Merit: 1047

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

mastertrader777

legendary

Activity: 1092

Merit: 1000

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

kito

newbie

Activity: 13

Merit: 0

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

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: kito on July 07, 2016, 05:13:26 PM

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.

Quote from: dooglus on July 01, 2016, 12:14:36 AM

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!)

Quote

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:

Quote

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

newbie

Activity: 13

Merit: 0

Quote from: dooglus on July 07, 2016, 01:39:16 AM

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.

SuperClam

hero member

Activity: 784

Merit: 1002

CLAM Developer

Quote from: dooglus on July 07, 2016, 01:25:16 AM

Quote from: neogen1 on July 06, 2016, 12:36:51 PM

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.

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: BayAreaCoins on July 01, 2016, 11:26:13 AM

Quote from: dooglus on July 01, 2016, 12:14:36 AM

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

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: neogen1 on July 06, 2016, 12:36:51 PM

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.

neogen1

sr. member

Activity: 458

Merit: 250

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

thx for help :-)

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