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

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

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"

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.   

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.

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

Caritas, Libertas, Aequitas, Monetas

if Im not mistaken

target block time is 1 minute

so 60 blocks/clams per hour
1,440 blocks/clams per day

POC OR POP,WHICH ONE DO YOU WANT?
btw,what does"CLAMS"mean?

1 clam..but how often?

all stakes are now 1 clam, there is no percent, thats as simple as it is

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?

so with no lotto how does this work? whats the %? or how does the 1 clam payouts work?

Seem's like a good time to be buying, price is dropping almost daily but wont take much to shoot back up  

try to download new update fix Google browser blocking it...

You're welcome.

The lottery has been disabled. It used to be that you got 0.1 CLAM almost every time you staked, but occasionally you got a much bigger reward, up to 1000 CLAM. The long-term average was meant to be 1 CLAM per stake.

It turns out the lottery was exploitable and so now everyone gets 1 CLAM per stake (plus any transaction fees for transactions you include in the staked block).

Some block rewards before the lottery was suspended:



And after:

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

so thanks again!

has staking been disabled now then ?

Using the -makebootstrap RPC command I wrote yesterday you could make a bootstrap.dat containing blocks up to 170000, then make a new clam folder and initialise it from the bootstrap file you made.

That would save you having to download the blockchain over again, but would require you to build the CLAM client yourself.

try the bootstrap provided by dooglus

download:
https://s3.amazonaws.com/dooglus/bootstrap.dat

rename clam folder so no blockchain, make a new clam folder, put the bootstrap.dat in it, and run "clam-qt.exe -connect=127.0.0.1" to prevent it from being able to connect to any peers

I have these in my clam.conf file (from previous sync. issues these were posted in here):

need help really bad here... wasted so much bandwith on the last attempt to resynch
the block still stuck @171046 wrong fork and won't fixes itself eventhough I let it run and consumed 300 MB bandwith
my logfile spammed by hundreds of this same errors:
that block 433bcff is block 170622 on correct chain, but why my client is spouting those error messages?
what makes my client downloads so much data & not resync the correct chain?
are there some nodes out there running wrong fork deliberately just to screw us up?
sorry guys... I'm a bit frustrated trying to get my CLAM back on the main chain

is there a way for me to remove a few blocks (something like rollback) from my chain?
if possible I want to try disconnect all blocks starting from 170000+ and try to resynch again
or is it possible to use my own blk0001.dat (maybe rename it first) & import only up to block 170000, then go online and resynch the rest?
something like "-loadblock=oldblk0001.dat" but how do I set it just to import up to 170000?