then just fired up the client Without the command line just as normal .. synced well and quick ( also looked for latest version of client on OP)

Right. I think that if the client sees that there is a bootstrap.dat file in the clam folder it will import all the blocks in that file before it even attempts to connect to any peers.

I specified the -connect= bit while testing my bootstrap file just to be certain that it really was using the bootstrap file rather than downloading from a particularly fast peer, but it was probably unnecessary to do so.

Can anyone explain how the Clams staking works. I have a basic to a little advanced understanding of staking, but this isn't making sense to me. How does the wallet decide which pile of coins to try to stake? Or is that something done on the block chain?

My question relates to the following.

I have 2 piles of clams I setup at exactly the same time. Both piles had 4 clams in them. One pile has already staked twice, the other has yet to stake. So I'm assuming something is random somewhere. I'm looking at coin control sorting on confirmations. I currently have a pile of 5 and a pile of 4 clams with almost 22K confirms. I also have a pile of 7.7 clams and that is 21K confirms. All other coins are smaller piles with 19K or less confirms. I'm assuming (and we all know where that can get me) that the weight is based on the time (confirms) and the size of the pile. But for some reason the last few stakes have been for piles in the lower portion of piles. IE less confirms and less size then the 7.7 clams at 19K confirms.

Can anyone explain how the Clams staking works. I have a basic to a little advanced understanding of staking, but this isn't making sense to me. How does the wallet decide which pile of coins to try to stake? Or is that something done on the block chain? My question relates to the following.I have 2 piles of clams I setup at exactly the same time. Both piles had 4 clams in them. One pile has already staked twice, the other has yet to stake. So I'm assuming something is random somewhere. I'm looking at coin control sorting on confirmations. I currently have a pile of 5 and a pile of 4 clams with almost 22K confirms. I also have a pile of 7.7 clams and that is 21K confirms. All other coins are smaller piles with 19K or less confirms. I'm assuming (and we all know where that can get me) that the weight is based on the time (confirms) and the size of the pile. But for some reason the last few stakes have been for piles in the lower portion of piles. IE less confirms and less size then the 7.7 clams at 19K confirms.

We already had this conversation on the freenode IRC channel #clams.But, I thought I would outline it here for other users.

CLAMS proof-of-stake functions much like proof-of-work. The primary difference being that your coin piles(outputs) are your mining rigs.The larger a coin pile(output) is, the higher the hash-rate of the mining rig.The older a coin pile(output) is, the higher the hash-rate of the mining rig.So! Age * Size = Hash Rate.

In actuality, it is the the difficulty that is altered by the age/size of the pile(output) but for our purposes hash rate is less technical and the result, I believe, is the same.

The 'Hash Rate' of a given pile decides how likely it is to stake. But, much like proof-of-work, finding a block is still random. The concept being that over time with a constant difficulty your piles become MORE likely to find a block.

When you find a block, no matter how large or small your pile is, you are rewarded with 1 CLAM, much like proof-of-work.

So! "How often do I get 1 CLAM?""How much interest do I get on CLAMS?"

How often does your video card mine a block of a given altcoin?It depends, on difficulty and your personal hash-rate.It varies, based on luck of finding a block.

The same applies to CLAMS. A primary, and we think great, difference being that the longer you DON'T find a block on CLAMS, the more likely it becomes that you WILL find a block.It is similar to if your video card or mining rig increased it's hash-power the longer it went without finding a block.

"I want numbers!"

Some users have reported their current percentage return as very similar to HYP.Though, in place of compound interest, you breed more tiny CLAM miners and increase your "hash rate"

thanks all for all the help... I finally back on the main chain. However I think I kinda cheated to get it to work instead of using bootstrap.dat from dooglus, I use my own... but without actually making bootstrap like dooglus said

I was just experimenting, so don't blame me if this doesn't work for you:I simply just deleted database & txleveldb directories, renamed blk0001.dat to bootstrap.datI thought at first this won't work because the blk0001.dat might be in different format than a bootstrap.dat should haveI ran it with "clam-qt.exe -listen=0" and it worked fine just took quite long time (maybe because my slow laptop)then the next step is not recommended, but I dont know what to do to make it stop at certain block heightso I do some calculations and guess the size of the blockchain should be around 189,xxx,xxx bytes to be near block 170000when I see blk0001.dat around that size... I forcefully kill the clam-qt process

next, I renamed bootstrap.dat to something else like x.bootstrap.dat and run "clam-qt.exe -listen=0" againI did this just to make sure everything is ok & not corrupted... then I use getblockcount (returns 170046) & getblockhash 170046 (returns 4bb124aeb6e80c2d7d2fdb995bf7fc7b8eba110f3c1877de49e55c671f773655)so I was off by a few blocks at height 170046 surprisingly "main chain" confirmed by comparing the hash to khash blockchainstrangely... eventhough my old chain was on the wrong fork, after I imported this way... the new chain turned out to be in the correct fork, main chain

so knowing all is good, then I restarted the client but this time without "-listen=0"and in about 30 minutes, I got my chain synched from 170046 to 179402 with only under 30MB bandwitdh (4MB real blockchain data)compare this to my last attempt of wasted 300MB & wrong chain... *facepalms* oh yeah and to save more bandwidth I exited/restarted my client once it's fully synchedwhy? because when it's fully synched, the client seems to still keep downloading data (high transfer rate) from nodes that are responding lateif I keep it up, it would just consume my bandwidth to download duplicate data from them late sender that my client was trying to connect earlierfrankly I'm not sure about that but that is what I think when I see I'm already synched but still downloading data heavily

this might not be the best way / method but it gets me back on the right track, so you should not try it if not so sure about this

thanks all for all the help... I finally back on the main chain. However I think I kinda cheated to get it to work instead of using bootstrap.dat from dooglus, I use my own... but without actually making bootstrap like dooglus said

I was just experimenting, so don't blame me if this doesn't work for you:I simply just deleted database & txleveldb directories, renamed blk0001.dat to bootstrap.datI thought at first this won't work because the blk0001.dat might be in different format than a bootstrap.dat should haveI ran it with "clam-qt.exe -listen=0" and it worked fine just took quite long time (maybe because my slow laptop)then the next step is not recommended, but I dont know what to do to make it stop at certain block heightso I do some calculations and guess the size of the blockchain should be around 189,xxx,xxx bytes to be near block 170000when I see blk0001.dat around that size... I forcefully kill the clam-qt process

That sounds like a reasonable method. I guess the blk* file is the same format as bootstrap.dat. It probably imported all the blocks up to 170000 and then was trying to import the later ones but was finding none of them were acceptable (since they were all on the wrong fork). It would have finished on its own in the end, and when it finishes it renames bootstrap.dat to something similar but different, so it doesn't see it again next time you run the client.

That would have been safer than forcibly killing it. Just wait for it to finish the import.

"How often do I get 1 CLAM?""How much interest do I get on CLAMS?""I want numbers!"Some users have reported their current percentage return as very similar to HYP.Though, in place of compound interest, you breed more tiny CLAM miners and increase your "hash rate"

to provide sample data, can be very different to others depending on how many clams you have and how many clams per pile you set them up

i have a sample 18.3 clams divided into 3 piles of about ~6 clams per pile

"How often do I get 1 CLAM?""How much interest do I get on CLAMS?""I want numbers!"Some users have reported their current percentage return as very similar to HYP.Though, in place of compound interest, you breed more tiny CLAM miners and increase your "hash rate"

to provide sample data, can be very different to others depending on how many clams you have and how many clams per pile you set them up

i have a sample 18.3 clams divided into 3 piles of about ~6 clams per pile

* ok ok, i cheated a bit, 4 other stakes where during lotto so really .1 stake but i just imagined they were already after the fork and giving out 1 clam just for sampling

Staking is random. Every second you have a small chance of being able to stake, which is proportional to the size of your output and its age, and inversely proportional to the current network difficulty.

hey guys i know i posted alot on here earlier, i talked to creative in the IRC..all is going well over here and CLAMS seems to be doing great. EVEN WITHOUT THE LOTTERY! i dont own a ton of clams but i still have a decent pile to start, good work DEV's you guys are doing great i cant wait to hear the new news

sorry to bother you guys again, I have another small question (problem)I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usualI don't understand why this happening, because the outbound port on my side is blocked by firewallI got multiple occurrences of these,

is this my client requesting blocks or other node requesting blocks from me?is this the same problem as almightyruler said couple days ago? if it is how could it be, coz my firewall blocks incoming requests

sorry to bother you guys again, I have another small question (problem)I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usualI don't understand why this happening, because the outbound port on my side is blocked by firewallI got multiple occurrences of these,

is this my client requesting blocks or other node requesting blocks from me?is this the same problem as almightyruler said couple days ago? if it is how could it be, coz my firewall blocks incoming requests

Try to add "listen=0" in config, it means "do not accept incoming connections".I do not think it will work but worth to give it a try.Problem is that "outgoing connections only" still alows uploading.When you upload a lot it means the swarm likes you and have many clients updating using your connection.Once swarn has updated most clients and are in sync it should normalise.

sorry to bother you guys again, I have another small question (problem)I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usualI don't understand why this happening, because the outbound port on my side is blocked by firewallI got multiple occurrences of these,

is this my client requesting blocks or other node requesting blocks from me?is this the same problem as almightyruler said couple days ago? if it is how could it be, coz my firewall blocks incoming requests

This is most likely the same problem I mentioned. Clients on the wrong fork are going crazy trying to resolve your view of the world versus theirs.

It's a peer to peer network that needs to share data, so even if you block incoming connections, any peer you are connected to (eg via outbound connect) will still request blocks.

One possible temporary workaround (not tested) is to force a connect to only nodes you know are on the correct chain. In your clam.conf you'd have something like this:

This disables inbound connections, and forces a connect to the configured peers. I can't remember if it will also still try to connect to other peers it becomes aware of (which will defeat the purpose of this workaround)

Note that if this does work it would only be a temporary workaround, as it ties you to these specific nodes, which are just 5 random IPs I've happened to note are on the right chain.

This disables inbound connections, and forces a connect to the configured peers. I can't remember if it will also still try to connect to other peers it becomes aware of (which will defeat the purpose of this workaround)

If you specify any connect= at all, the addresses you list will be the only addresses you connect to. You don't need to specify listen=0 as well.

clamd --help tells us:

Quote

-connect=<ip> Connect only to the specified node(s) -listen Accept connections from outside (default: 1 if no -proxy or -connect)

In the last couple days, we have merged well over 100 upstream commits.The intention is to release a new feature designed to make us more resilient to censorship, a fix to tame misbehaving forked clients, and a ton of house-cleaning.

sorry to bother you guys again, I have another small question (problem)I just noticed that since I got back on the main chain, my upload data transfer is MUCH higher than usualI don't understand why this happening, because the outbound port on my side is blocked by firewallI got multiple occurrences of these,

is this my client requesting blocks or other node requesting blocks from me?is this the same problem as almightyruler said couple days ago? if it is how could it be, coz my firewall blocks incoming requests

Yes, it doesn't matter if you are listening on a port or not, you're still essentially a "server" to the people you connect *to* even if you connected to them.