Author

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

legendary
Activity: 2940
Merit: 1333
I need some help please... my chain is already at block 170980 before I downloaded the new client
and after I ran the new version, instead of reorganizing & reconnecting to the correct fork it keeps continuing up to 171046 and stuck.
what should I do to go from this situation and back to the right fork without re-downloading the whole chain from 0
is there a way to force my client to start re-download from specified block height from 1-3 trusted hand picked nodes only?
would deleting peers.dat helps weeding out the bad nodes with wrong fork?

I don't know enought about how it works, but from what I know isn't the client meant to treat the longest chain as the best chain? If so, I don't see why it wouldn't "just work".

Anyone?
hero member
Activity: 1232
Merit: 738
Mixing reinvented for your privacy | chipmixer.com
I need some help please... my chain is already at block 170980 before I downloaded the new client
and after I ran the new version, instead of reorganizing & reconnecting to the correct fork it keeps continuing up to 171046 and stuck.
what should I do to go from this situation and back to the right fork without re-downloading the whole chain from 0
is there a way to force my client to start re-download from specified block height from 1-3 trusted hand picked nodes only?
would deleting peers.dat helps weeding out the bad nodes with wrong fork?
legendary
Activity: 2268
Merit: 1092
Code:
        int nLimit = 20;

Cheers for that. debug.log is still filling up with rapid repeated requests, but the excessive outbound bandwidth usage on port 31174 has disappeared.

Funny thing (not really) is that it only took 3 peers on the old fork to saturate my link.
member
Activity: 116
Merit: 10
Serious problem.

Clients on the old fork are repeatedly requesting the same set of blocks from me. They're stuck in an infinite loop.

My clams client is currently consuming the majority of my link's upstream bandwidth.

The base code doesn't seem to have any way of tracking blocks it has already requested, so there's no way to detect that it asked for the very same block only 10 seconds ago, and back off. Same for the client at my end, which should be refusing to send (or delaying sending) exactly the same data the 2nd, 3rd, 4th, nth time...

I'm either going to have to firewall and allow only IPs which I know are on the correct chain, or just stop the client completely. To be honest, since the lottery was disabled I don't really see much point in keeping the client open.  Embarrassed

I had this same issue on my DSL connection. The upstream was saturated.

The fix for me was to go into main.cpp Line 3274 or simply search for "getblocks", change:
Code:
        int nLimit = 500;

to
Code:
        int nLimit = 20;

As far as I can tell, this stops you from sending 500 'invalid' (to them not us =p) blocks to the other fork. This causes a little more TCP/local chatter but far less wasted bandwidth.

If you either can't compile, or are using Windows you might want to check out NetLimiter 3. I keep it running on my coins vm and it shapes the bandwidth for selected programs, making peers less likely to request more from you constantly.
legendary
Activity: 2268
Merit: 1092
Serious problem.

Clients on the old fork are repeatedly requesting the same set of blocks from me. They're stuck in an infinite loop.

My clams client is currently consuming the majority of my link's upstream bandwidth.

The base code doesn't seem to have any way of tracking blocks it has already requested, so there's no way to detect that it asked for the very same block only 10 seconds ago, and back off. Same for the client at my end, which should be refusing to send (or delaying sending) exactly the same data the 2nd, 3rd, 4th, nth time...

I'm either going to have to firewall and allow only IPs which I know are on the correct chain, or just stop the client completely. To be honest, since the lottery was disabled I don't really see much point in keeping the client open.  Embarrassed
full member
Activity: 155
Merit: 100
legendary
Activity: 2940
Merit: 1333
No wonder my client stuck resynching, I just realized we got a hard fork. I am downloading the new client now.
what should I do if my blockchain already at 170980? do I need to redownload the whole blockchain again (as in delete the %appdata% folder)
or the new client will take care of that and resynch, deletes blocks & reconnects the chain automatically? (would save me some bandwidth)

so I just need to overwrite my current CLAM directory by unzipping the new client to old directory, right?
no need to move away wallet.dat and other things?
sorry for the newbie questions... I've never done this before Embarrassed

I don't know if it will resync automatically without having to do a whole new blockchain download from scratch, but I expect it will. It's worth a try.

It's always worth making a backup of your wallet.dat somewhere safe occasionally, just in case.
hero member
Activity: 1232
Merit: 738
Mixing reinvented for your privacy | chipmixer.com
No wonder my client stuck resynching, I just realized we got a hard fork. I am downloading the new client now.
what should I do if my blockchain already at 170980? do I need to redownload the whole blockchain again (as in delete the %appdata% folder)
or the new client will take care of that and resynch, deletes blocks & reconnects the chain automatically? (would save me some bandwidth)

so I just need to overwrite my current CLAM directory by unzipping the new client to old directory, right?
no need to move away wallet.dat and other things?
sorry for the newbie questions... I've never done this before Embarrassed
full member
Activity: 176
Merit: 100
Any way to get to know how many CLAMS are "active" in the wild
I know there are millions possibly, but it would be nice to determine how many are staking...



There's a bot in the CLAMS IRC channel that displays blockchain info. Go to: http://webchat.freenode.net/?channels=clams

Then type "&help" to list all the commands.

"&clamsupply" shows the following:

---------------------------------------------------------------------------------------------------------
[19:43]                                                                                              
[19:43]                           Current CLAMS in Circulation(estimate): 124019.35870633 Clams
[19:43]                                                                                              
[19:43] ---------------------------------------------------------------------------------------------------------
[19:43]    This information regardling currently claimed clams is an estimate based on moved piles of coins.
[19:43]    There is no way to determine if a clam has been claimed until it has been moved on the chain
[19:43]   -------------------------------------------------------------------------------------------------------
[19:43]   Lottery Winnings: 58934.84937575 Clams
[19:43]   Staking Earning: 10038.87704156 Clams
[19:43]   Amount Claimed: 50904.10229422 Clams, 11053 Addresses
full member
Activity: 155
Merit: 100
Any way to get to know how many CLAMS are "active" in the wild
I know there are millions possibly, but it would be nice to determine how many are staking...

legendary
Activity: 2940
Merit: 1333
You still get fees too which may account for it.

@dooglus I'm using mainly 2.5 CLAM piles now but not sure if it's staking any better/worse than it was at 5 CLAM piles. I have some remaining piles of 5 CLAMs that have a weight of  > 100 and there have been some 2.6 and 2.7 CLAM piles with much lower weight stake before them.....

I'm just going for lots of outputs = greater chance of getting a stake.

You're right, that will have been transaction fees from the transaction(s) included in the block.

On average your 5 CLAM outputs will stake twice as quickly as your 2.5 CLAM outputs, but you have half as many of them, so it balances out.

And while you're staking, you get a small chance of staking each second. The chance is bigger for bigger piles, and for older piles, but is still pretty tiny. It's possible you'll get lucky and stake very quickly, but it's also possible it will take much longer than expected. Your weighty 5 CLAM outputs can take longer to stake than your lower weight 2.6 CLAM piles in the same way that a guy who buys 1 lottery ticket per week can win the lottery before a guy who buys 10 tickets per week.
member
Activity: 92
Merit: 10
You still get fees too which may account for it.

@dooglus I'm using mainly 2.5 CLAM piles now but not sure if it's staking any better/worse than it was at 5 CLAM piles. I have some remaining piles of 5 CLAMs that have a weight of  > 100 and there have been some 2.6 and 2.7 CLAM piles with much lower weight stake before them.....

I'm just going for lots of outputs = greater chance of getting a stake.
hero member
Activity: 500
Merit: 500


i mined a 1.0015 clams block reward  Huh (#172760 and i'm on the correct fork)
look like a smal loto reward but technically, that shouldn't be possible.
legendary
Activity: 2940
Merit: 1333
What is current recommended stack size and how long does it take to stake ?

I was intending to ask the same thing, re. optimal stack size.

The network difficulty target hovers around 200*2^224, meaning that on average it takes an output of weight N CLAM-days
2^256 / (N*200*2^224) = 2^32 / 200N = 21474836/N seconds = 248/N days to stake (assuming it never gets any weightier, which it of course will)

So a 5 CLAM output that is a week old (weight = 35) takes around 7 days to stake if it keeps that weight.

This looks like a dead end. Skip it if you like...

Quote
I guess the first thing to do is to find out how to calculate the expected time-to-stake taking the constant ageing into account:

Suppose we have an output with value V, and a network difficulty target of 200*2^224

For the first 1/V days it has a weight of 0 (weights are rounded down to an integer number of CLAM-days), so it can't stake.
ie. the probability of it staking in the first 1/V days is 0.

For the 2nd 1/V days it has a weight of 1, and has a 200*2^224/2^256 = 200/2^32 probability of staking each second.
The probability of it staking in the 2nd 1/V days is 1-(probability of it not staking in that period)
1/V days is 86400/V seconds, so that's:
= 1 - ((1-(200/2^32))^(86400/V))

For the 3rd 1/V days, weight = 2, probability of staking in any given second is 2*200/2^32,
and so the probability of it staking in the 3rd 1/V days is (1 - ((1-(400/2^32))^(86400/V)))

... and this feels like it's going nowhere.

Can someone with a clue help me out please?

The big picture:

No output gains any "weight" for the first 4 hours - it has 4 hours taken off its age before the weight calculation is done.

No output can stake until it is 'mature'. Staking makes it immature. It needs 500 confirmations after staking before it can stake again. 500 confirmations should take over 8 hours, so the 4 hours in the previous point should never be the limiting factor other than for recently moved (as opposed to staked) outputs. This probably puts an upper limit on the optimal output size. If I put all my CLAMs into a single large output, it will probably stake not long after it has its 500 confirmations, but then I have to wait another 8 hours for it to get another 500 confirmations, so I'm limited to staking a few times per day.

Weights are rounded down to the next integer CLAM-day. So if you split your outputs into 0.001 CLAM pieces, each one will take 1000 days before it reaches a weight of 1, and so won't be able to stake for a few years. This puts a lower limit on the optimal output size.

Perhaps this means that the optimal size is that which reaches 1 CLAM-day of weight just as the 500 confirmations are reached? 500 confirmation is meant to take 8.3333 hours, and 4 hours are taken off the age, so I want my output to have a weight of 1 when its effective age is 4.3333 hours. So its value needs to be 24/4.33333 = 5.54 CLAMs.

Thoughts?

Edit: of course, as they stake, the outputs will grow in size. We can't set them all to 5.54 CLAMs and expect them to stay at that size. Perhaps it's best to set them to 4 CLAMs, leave them to grow to 7 CLAMs, then when they reach 8, split them into two 4's and let them start over?
sr. member
Activity: 432
Merit: 250
Has the block explorer been updated? I'm not sure if my updated client has managed to resolve the fork and hop onto the correct chain, or both the block explorer and my client are on the "old" fork.
./clamd getblockhash 170571
e0d490a9b1e46a369b8344781f280119636ae48b718568dc1542c54968f3bde5


Block #170571
hash: e0d490a9b1e46a369b8344781f280119636ae48b718568dc1542c54968f3bde5

Looks good Grin
Can you post url of block exporer on OP ?
khashier.com:2750/chain/Clams
What is current recommended stack size and how long does it take to stake ?

Thanks !
sr. member
Activity: 434
Merit: 250
"The mass of men lead lives of quiet desperation."
Crap just updated, sorry to find out about the exploit. Good job catching it so fast
legendary
Activity: 2940
Merit: 1333
I mined about 12 blocks on the old chain before I swapped over, although the network weight was still about 300k when I switched.

It was just main.cpp that changed wasn't it?

Yes, I believe so.

Here: https://github.com/nochowderforyou/clams/commit/ecef9cee2e8fd7a4c47de8809e9d4cccd231f00f
member
Activity: 92
Merit: 10
I mined about 12 blocks on the old chain before I swapped over, although the network weight was still about 300k when I switched.

It was just main.cpp that changed wasn't it?
legendary
Activity: 2940
Merit: 1333
I'm seeing a LOT of orphan blocks in my debug.log:

Quote
received block bbd08b69888d5911f1d8
ProcessBlock: ORPHAN BLOCK, prev=d71bb0f13f3e2b7cd660
received block d71bb0f13f3e2b7cd660
ProcessBlock: ORPHAN BLOCK, prev=f195e50052dd11534ad7
received block f195e50052dd11534ad7
ProcessBlock: ORPHAN BLOCK, prev=f16a05c3f9b0a161146d
received block f16a05c3f9b0a161146d
ProcessBlock: ORPHAN BLOCK, prev=2c7ef5a2a52b11156f08
received block 2c7ef5a2a52b11156f08
ProcessBlock: ORPHAN BLOCK, prev=9de82b7d4692326d374a
received block 9de82b7d4692326d374a
ProcessBlock: ORPHAN BLOCK, prev=8aa7b6dd87ae1598585a
received block 8aa7b6dd87ae1598585a
ProcessBlock: ORPHAN BLOCK, prev=2bd912c37d4d31ef351d
received block 2bd912c37d4d31ef351d
ProcessBlock: ORPHAN BLOCK, prev=c80684c39b4f841a903f

I guess that's just someone staking on the wrong fork, right?

I'm on the same fork as poloniex and khashier - but it seems some big stakeholder didn't switch forks yet.
member
Activity: 92
Merit: 10
Mine re-synced. I came looking here because I was hitting lots of blocks and my balance was going up too fast...... now I know why, it was 10 times too fast Cheesy
Jump to: