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

[Quantum12]

thanx dooglus, I was stuck for ages , but your above method works great

so thanks again!

has staking been disabled now then ?

which method did you use? did you use the boostrap provided by dooglus? or did you make your own bootstrap using the client provided by dooglus with -makebootstrap?

i just renamed the old clam folder..

made a new one and put dooglus bootstrap.dat in there

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)

Q

[1714153334]

1714153334

[1714153334]

1714153334

[1714153334]

1714153334

[dooglus]

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.

[chilly2k]

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.   

[SuperClam]

1 clam..but how often?

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"

[Thirdspace]

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.dat
I thought at first this won't work because the blk0001.dat might be in different format than a bootstrap.dat should have
I 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 height
so I do some calculations and guess the size of the blockchain should be around 189,xxx,xxx bytes to be near block 170000
when 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" again
I 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 blockchain
strangely... 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 synched
why? because when it's fully synched, the client seems to still keep downloading data (high transfer rate) from nodes that are responding late
if 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 earlier
frankly 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

[dooglus]

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.dat
I thought at first this won't work because the blk0001.dat might be in different format than a bootstrap.dat should have
I 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 height
so I do some calculations and guess the size of the blockchain should be around 189,xxx,xxx bytes to be near block 170000
when 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.

[istvandv]

"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

they have staked 5 times in the month of october to generate 5 clams

5 / 18.3 = 27.32% interest for a month
or
27.32% * 12 = 327.84 interest a year (not compounded)


* 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

[dooglus]

"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

they have staked 5 times in the month of october to generate 5 clams

5 / 18.3 = 27.32% interest for a month
or
27.32% * 12 = 327.84 interest a year (not compounded)


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

Here's an example:

http://khashier.com:2750/address/xSeRBfdnw1vVtabmpZugCXKS8jGujKYXr5

That address started staking with 4.6 CLAMS in August, and now, almost 3 months later it has 8.8 CLAMS. So it hasn't quite doubled in 3 months.

[lakala]

So far my biggest stake block is Credit: 0.6888463 CLAM

[SuperClam]

So far my biggest stake block is Credit: 0.6888463 CLAM

Please check immediately that you are on the correct chain.
There was a recent mandatory update.

See:
https://bitcointalk.org/index.php?topic=623147.msg9314100#msg9314100

All block rewards are 1 CLAM each now.

[dooglus]

So far my biggest stake block is Credit: 0.6888463 CLAM

Please check immediately that you are the correct chain.
There was a recent mandatory update.

See:
https://bitcointalk.org/index.php?topic=623147.msg9314100#msg9314100

All block rewards are 1 CLAM each now.

Good catch. I assumed he wasn't staking very often, and that his last stake was before the upgrade.

[freedomsr40]

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

[Thirdspace]

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 usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,

getblocks 170613 to 00000000000000000000 limit 500
  getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
  getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
  getblocks stopping at limit 169612 09777d16b5cf14ad79ee

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

[ButtCrack]

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 usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,

getblocks 170613 to 00000000000000000000 limit 500
  getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
  getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
  getblocks stopping at limit 169612 09777d16b5cf14ad79ee

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.

[almightyruler]

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 usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,

getblocks 170613 to 00000000000000000000 limit 500
  getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
  getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
  getblocks stopping at limit 169612 09777d16b5cf14ad79ee

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:


listen=0
connect=109.195.211.62
connect=184.6.148.172
connect=203.20.114.252
connect=85.191.52.188
connect=72.10.216.54


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.

[dooglus]

listen=0
connect=109.195.211.62
connect=184.6.148.172
connect=203.20.114.252
connect=85.191.52.188
connect=72.10.216.54


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:

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

[SuperClam]

Indeed, we are aware of the issue.


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.

Thanks for being patient

[tryphe]

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 usual
I don't understand why this happening, because the outbound port on my side is blocked by firewall
I got multiple occurrences of these,

getblocks 170613 to 00000000000000000000 limit 500
  getblocks stopping at limit 171112 b31ce7156dffe7912335
getblocks 169613 to 00000000000000000000 limit 500
  getblocks stopping at limit 170112 cab452d5b579a4001875
getblocks 169113 to 831d2270c55e9d017514 limit 500
  getblocks stopping at limit 169612 09777d16b5cf14ad79ee

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.

[ymod123]

my wallet wont sync stuck at 9565 block remaining help?
im using the new update

[paulc010]

Have you tried the methods above? You can also try creating a clams.conf file in your clams data directory and use the addnode lines I specified. Been working for me no problem.

https://bitcointalk.org/index.php?topic=623147.msg9369794#msg9369794