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

[picolo]

if i have only 50 clams its very hard to stake now in my own wallet? is it better to move to just-dice to stake?

If you position the mouse cursor over the little blue ticket icon, a pop-up dialog will give you a precise calculation, e.g.:

Code:

>>> 626513 / 365
1716.4739726027397

So I shan't be holding my breath

I think those calculations are still bogus. When the devs changed network weights and the difficulty shot up to compensate the estimates went off with the fairies. According to my CLAM client, right now the next expected stake is about 25 years away... but I usually manage to stake every few days.

My balance is just over 100, so it's definitely possible, even with a modest balance. It is getting harder.

CLAM is at 0.003 so someone who bought at 0.003 when just-dice opened made a huge profit.

[dooglus]

If you position the mouse cursor over the little blue ticket icon, a pop-up dialog will give you a precise calculation, e.g.:

Code:

>>> 626513 / 365
1716.4739726027397

So I shan't be holding my breath

I think you must be running an old version of the client. The network weight is shown as a number with 8 decimal places in the current version, and is around 300k or so. The estimated time to stake a block is correct now too.

[dooglus]

Dooglus can you go public on how much CLAM you have,

I'd rather not, and don't see why it matters any more than how much anyone else has.

what portion of your commission you sell for BTC

I invest the commission in the JD bankroll. I buy and sell CLAM occasionally, but it isn't related to commission. I typically buy high and sell low, always getting market movements wrong.

and if you are invested in the just-dice CLAM bankroll?

I am.

[picolo]

Dooglus can you go public on how much CLAM you have,

I'd rather not, and don't see why it matters any more than how much anyone else has.

what portion of your commission you sell for BTC

I invest the commission in the JD bankroll. I buy and sell CLAM occasionally, but it isn't related to commission. I typically buy high and sell low, always getting market movements wrong.

and if you are invested in the just-dice CLAM bankroll?

I am.

OK fair enough; thanks for the answers.

[gjhiggins]

If you position the mouse cursor over the little blue ticket icon, a pop-up dialog will give you a precise calculation

Those calculations have been fixed in the newest client.

I think you must be running an old version of the client.

Ah, many thanks. I wasn't aware that I was behind the curve.

Updated.




Cheers

Graham

[seedtrue]

Just an awesome thought garthkiser had, but if the facets held onto a perpetual amount of coins the staking they can do could provide the the clams needed to fund the faucets! 
It would likely take 100-200 coins at this point and the pool would have a constant (albeit up to variance) supply of clams. Maybe do like doogus does and keep 5-10% of the staked rewards (that's just a thought I had).
You guys should both pop into our irc channel over the next day or two, we would likely be willing to help fund it out of some bounty funds we have!

I wish I could take the credit, but it was tryphe's awesome idea I can lend 100CLAMs to the cause, though, if the faucet operator will agree to return them in the event that the faucet is permanently stopped.

My faucet is completely funded atm by coins I earn from staking, only on just-dice, not the faucets server. You do have a good idea though.

However, I would much rather store larger amounts of coins on just-dice for security reasons.

[SuperClam]

Thanks, I'll try to check my clock too!
Edit:
https://i.imgur.com/wFZqDYL.png
Should clock be ok now?

Yes, but it's best to leave ntpd running all the time. Then your clock will stay right.
I'm not sure what units ntpq is using, but if it was saying your clock was off by 46 seconds then that could well explain the high orphan rate you were seeing. A hardfork about a month ago really tightened things up re. clock errors.

Interested to hear you opinion on this dooglus:

It is my personal experience that any changes to the system clock should be accompanied by a restart of the client and possibly also deleting the peers.dat file.  The logic being, the client stores "offsets" to automatically adjust the clock.  During debug work with various users, it appears that changing the system clock can cause (possibly temporary) problems.  The client continues to use the previously calculated offset parameters despite the system clock having recently changed.

Thoughts?

[SuperClam]

First CLAM Faucet is up and running!
Here is the link!

I just set up a faucet as well. http://myfreeclams.com/
come get some free clams.

Awesome

Added to OP post.

[dooglus]

Yes, but it's best to leave ntpd running all the time. Then your clock will stay right.
I'm not sure what units ntpq is using, but if it was saying your clock was off by 46 seconds then that could well explain the high orphan rate you were seeing. A hardfork about a month ago really tightened things up re. clock errors.

Interested to hear you opinion on this dooglus:

It is my personal experience that any changes to the system clock should be accompanied by a restart of the client and possibly also deleting the peers.dat file.  The logic being, the client stores "offsets" to automatically adjust the clock.  During debug work with various users, it appears that changing the system clock can cause (possibly temporary) problems.  The client continues to use the previously calculated offset parameters despite the system clock having recently changed.

Thoughts?

peers.dat doesn't store any offset info; it's a list of peer IP addresses and how recently we were able to connect to them, so I don't think there's any need to delete it after fixing your clock.

When you start the client, it starts building a list of time offsets. Each peer it connects to tells it what it thinks the time is, and the client records how different each client's idea of the time is from its own clock. So if you adjust the system clock after connecting to a bunch of peers, those stored offsets will be wrong, and you'll need to restart.

My point was that by running ntpd constantly, it will be constantly correcting the clock whenever it drifts by a fraction of a second, and so your clock will always be right. You won't see your system clock being adjusted - you'll just see that it is always right. This kind of automatic adjustment doesn't require a client restart, since each adjustment is tiny and invisible.

[SuperClam]

Yes, but it's best to leave ntpd running all the time. Then your clock will stay right.
I'm not sure what units ntpq is using, but if it was saying your clock was off by 46 seconds then that could well explain the high orphan rate you were seeing. A hardfork about a month ago really tightened things up re. clock errors.

Interested to hear you opinion on this dooglus:
It is my personal experience that any changes to the system clock should be accompanied by a restart of the client and possibly also deleting the peers.dat file.  The logic being, the client stores "offsets" to automatically adjust the clock.  During debug work with various users, it appears that changing the system clock can cause (possibly temporary) problems.  The client continues to use the previously calculated offset parameters despite the system clock having recently changed.
Thoughts?

peers.dat doesn't store any offset info; it's a list of peer IP addresses and how recently we were able to connect to them, so I don't think there's any need to delete it after fixing your clock.
When you start the client, it starts building a list of time offsets. Each peer it connects to tells it what it thinks the time is, and the client records how different each client's idea of the time is from its own clock. So if you adjust the system clock after connecting to a bunch of peers, those stored offsets will be wrong, and you'll need to restart.
My point was that by running ntpd constantly, it will be constantly correcting the clock whenever it drifts by a fraction of a second, and so your clock will always be right. You won't see your system clock being adjusted - you'll just see that it is always right. This kind of automatic adjustment doesn't require a client restart, since each adjustment is tiny and invisible.

Good point; so it makes sense to restart after an initial sync (to update offsets) - no need to fiddle with the peers.dat file.

The code currently only figures offset on connect, and not periodically for long-standing connections, correct?

[almightyruler]

I think what dooglas is saying is that no restart should be needed UNLESS you make a significant adjustment to your time (eg via ntpdate, or setting the time manually)

ntpd is designed to figure out the drift of your local clock, and make regular, tiny adjustments (small fractions of a second), to keep it on track with the rest of the world. The only time I could see this being a problem is if your clock is out by several tens of seconds - I believe that in this case, ntpd will gradually adjust it to the correct time, which may cause problems with a coin client. With stored offsets of peers, and the client being blind to time shifts, a gradual change towards correct time would essentially be the same as a one-off major adjustment.

All this is pretty much moot anyway - just run ntpdate at startup to yank your clock into submission, then ntpd immediately afterwards to keep it there.

[S4VV4S]

My wallet keeps crashing at 8 days behind.

Is there a reason for that?

[sgk]

How do I claim my CLAM for my old BTC addresses?

[dooglus]

The code currently only figures offset on connect, and not periodically for long-standing connections, correct?

Right. And that's OK so long as everyone's clock is always wrong by the same amount. But we've seen at least one example of a clock that loses over 1 second per minute. There's nothing much we can do to help him other than have him run something that fixes his clock regularly.

The only time I could see this being a problem is if your clock is out by several tens of seconds - I believe that in this case, ntpd will gradually adjust it to the correct time, which may cause problems with a coin client.

I think you have that backwards. The ntpd manpage says:

          Normally, the time is slewed if the offset is less than
          the step  threshold, which  is 128  ms by  default, and
          stepped if  above the threshold.

The gradual adjustment thing happens for small (sub 128 ms) errors - otherwise it's stepped. "ntpd -x" increases that threshold to 600s - so don't use that...

[S4VV4S]

How do I claim my CLAM for my old BTC addresses?

File/Import wallet  and locate your wallet.dat

Make sure you move your coins to another wallet first (not address in the same wallet).

[Vortex20000]

How do I claim my CLAM for my old BTC addresses?

File/Import wallet  and locate your wallet.dat

Make sure you move your coins to another wallet first (not address in the same wallet).

Although you don't have to if you trust the clam devs...

[sgk]

How do I claim my CLAM for my old BTC addresses?

File/Import wallet  and locate your wallet.dat

Make sure you move your coins to another wallet first (not address in the same wallet).

Thanks, I should have read the OP carefully; it was already mentioned there.

I'll make sure to use only zero-balance addresses. I wish there was a way to import individual private keys to CLAM wallet.

[istvandv]

How do I claim my CLAM for my old BTC addresses?

File/Import wallet  and locate your wallet.dat

Make sure you move your coins to another wallet first (not address in the same wallet).

Thanks, I should have read the OP carefully; it was already mentioned there.

I'll make sure to use only zero-balance addresses. I wish there was a way to import individual private keys to CLAM wallet.

i believe you can, using "importprivkey <privkey>" in the console

[dooglus]

I wish there was a way to import individual private keys to CLAM wallet.

i believe you can, using "importprivkey <privkey>" in the console

True.

It's quite slow unless you tell it not to rescan until the last import:

importprivkey PRIVKEY '' false

The false means 'don't rescan'. The default is true. The '' is the label for the imported address.

You can also 'dig' individual private keys using the chat box at Just-Dice.com - see the FAQ tab there, and type /dig in the chat tab for more info.

[sgk]

I wish there was a way to import individual private keys to CLAM wallet.

i believe you can, using "importprivkey <privkey>" in the console

True.

It's quite slow unless you tell it not to rescan until the last import:

importprivkey PRIVKEY '' false

The false means 'don't rescan'. The default is true. The '' is the label for the imported address.

You can also 'dig' individual private keys using the chat box at Just-Dice.com - see the FAQ tab there, and type /dig in the chat tab for more info.

This is a great idea, thanks for the advice. I have imported the keys successflly and now I'm just waiting for wallet to sync.

13 weeks behind...