OK, so I imported my keys and wallet is fully sync now. But the balance is still zero.
How much time does it take to receive CALM on my imported keys?
Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 401. (Read 1151252 times)
January 03, 2015, 03:48:34 PM
January 03, 2015, 02:17:23 PM
No Mac wallet, not worth my time.
Want to sell me your old empty keys?
January 03, 2015, 02:05:53 PM
No Mac wallet, not worth my time.
January 03, 2015, 11:47:07 AM
With the max of 16 connections it shouldn't take more than half an hour.
I think it only uses one connection to sync, and it picks it randomly. Recent changes to Bitcoin improve that behaviour but I don't think the CLAM client has them yet.
See https://bitcointalksearch.org/topic/m.9772191 for a bootstrap.dat file that speeds up the initial sync process.
January 03, 2015, 09:15:14 AM
I wish there was a way to import individual private keys to CLAM wallet.
i believe you can, using "importprivkey
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...
January 03, 2015, 05:05:02 AM
I wish there was a way to import individual private keys to CLAM wallet.
i believe you can, using "importprivkey
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...
January 03, 2015, 04:38:43 AM
I wish there was a way to import individual private keys to CLAM wallet.
i believe you can, using "importprivkey
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.
January 03, 2015, 04:29:13 AM
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
January 03, 2015, 04:00:47 AM
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.
January 02, 2015, 09:11:56 PM
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).
January 02, 2015, 03:57:42 PM
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).
January 02, 2015, 12:56:59 PM
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...
January 02, 2015, 11:32:57 AM
How do I claim my CLAM for my old BTC addresses?
January 02, 2015, 10:11:46 AM
My wallet keeps crashing at 8 days behind.
Is there a reason for that?
Is there a reason for that?
January 02, 2015, 01:30:38 AM
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.
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.
January 02, 2015, 12:10:18 AM
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: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.
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?
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?
January 01, 2015, 11:39:35 PM
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.
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.
January 01, 2015, 11:35:49 PM
Awesome
Added to OP post.
January 01, 2015, 11:23:05 PM
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.Edit:
https://i.imgur.com/wFZqDYL.png
Should clock be ok now?
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?
January 01, 2015, 09:41:50 PM
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 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.
Jump to: