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

[BayAreaCoins]

FreeBitcoins.com CLAM faucet is back online.

We are strictly doing offchain transactions for our faucet in order not to shit up the CLAM blockchain any more than necessary.

Our CLAM faucet currently connects to Freebitcoins.com and Just-dice.com... we will be adding more site though!

Would be awesome to have our site added to the list

I'll message you on skype when I wake up and see if we can work something out <3!

[bolo1970]

  The doge blockchain has become so big that someone invented multidoge, similar to multibit for bitcoin. What happens to all the multibit and multidoge users? They do not have wallet.dat files and will probably lack the technical skills to export keys.  Another question is if I need my BTC/LTC/DOGE wallet update to the latest block before I copy it to the appdata/Roaming/CLAM/?

[Faust Roland]

All nodes I connect has odd timeoffset - between -100 to -60. Also I am pretty sure, that I have correct time at my node. Is there something I can do with that?

$ cli getpeerinfo | grep "addr\|timeoffset" | grep -v local
    "addr" : "151.226.102.252:31174",
    "timeoffset" : -94,
    "addr" : "46.4.113.143:31174",
    "timeoffset" : -97,
    "addr" : "165.227.93.150:31174",
    "timeoffset" : -94,
    "addr" : "95.87.207.152:31174",
    "timeoffset" : -95,
    "addr" : "67.205.153.62:31174",
    "timeoffset" : -88,
    "addr" : "94.23.58.222:31174",
    "timeoffset" : -95,
    "addr" : "124.191.213.74:31174",
    "timeoffset" : -109,
    "addr" : "97.83.177.95:31174",
    "timeoffset" : -95,
    "addr" : "69.121.201.75:31174",
    "timeoffset" : -96,
    "addr" : "82.21.202.185:31174",
    "timeoffset" : -101,
    "addr" : "67.191.63.234:31174",
    "timeoffset" : -92,
    "addr" : "176.58.119.91:31174",
    "timeoffset" : -88,
    "addr" : "193.111.198.69:31174",
    "timeoffset" : -86,
    "addr" : "188.40.206.114:31174",
    "timeoffset" : -79,
    "addr" : "158.129.212.236:31174",
    "timeoffset" : -72,
    "addr" : "178.62.8.78:31174",
    "timeoffset" : -66,

[criptocambio]

All nodes I connect has odd timeoffset - between -100 to -60. Also I am pretty sure, that I have correct time at my node. Is there something I can do with that?

$ cli getpeerinfo | grep "addr\|timeoffset" | grep -v local
    "addr" : "151.226.102.252:31174",
    "timeoffset" : -94,
    "addr" : "46.4.113.143:31174",
    "timeoffset" : -97,
    "addr" : "165.227.93.150:31174",
    "timeoffset" : -94,
    "addr" : "95.87.207.152:31174",
    "timeoffset" : -95,
    "addr" : "67.205.153.62:31174",
    "timeoffset" : -88,
    "addr" : "94.23.58.222:31174",
    "timeoffset" : -95,
    "addr" : "124.191.213.74:31174",
    "timeoffset" : -109,
    "addr" : "97.83.177.95:31174",
    "timeoffset" : -95,
    "addr" : "69.121.201.75:31174",
    "timeoffset" : -96,
    "addr" : "82.21.202.185:31174",
    "timeoffset" : -101,
    "addr" : "67.191.63.234:31174",
    "timeoffset" : -92,
    "addr" : "176.58.119.91:31174",
    "timeoffset" : -88,
    "addr" : "193.111.198.69:31174",
    "timeoffset" : -86,
    "addr" : "188.40.206.114:31174",
    "timeoffset" : -79,
    "addr" : "158.129.212.236:31174",
    "timeoffset" : -72,
    "addr" : "178.62.8.78:31174",
    "timeoffset" : -66,

Either you need to update your clock, or everyone does. This can be caused because of clock drifting, or some other issues. Please sync your computer with an NTP server to be sure your clock is right: Google have a huge NTP server and a nice tutorial here https://developers.google.com/time/guides

The doge blockchain has become so big that someone invented multidoge, similar to multibit for bitcoin. What happens to all the multibit and multidoge users? They do not have wallet.dat files and will probably lack the technical skills to export keys. 

All softwares that tries to manage a criptocurrency portfolio have some sort of way to export private keys. Multibit, for example, have this tutorial:
https://multibit.org/help/v0.5/help_exportingPrivateKeys.html

Access to a wallet.dat is not necessary, as you can import these private keys to any other compatible software. The lack of technical skills, however, can really be a problem for some people: But the wallet technology is quickly getting easier to use. We already have some wallets that you just need to write down some words instead of exporting keys, for example.

Another question is if I need my BTC/LTC/DOGE wallet update to the latest block before I copy it to the appdata/Roaming/CLAM/?

Please do not copy files from other coins inside the CLAM client. They are different, and are not compatible between them. If you need to update your CLAM client, please let it update by itself or use a bootstrap.dat made by dooglus.

[Faust Roland]

All nodes I connect has odd timeoffset - between -100 to -60. Also I am pretty sure, that I have correct time at my node. Is there something I can do with that?

Either you need to update your clock, or everyone does. This can be caused because of clock drifting, or some other issues. Please sync your computer with an NTP server to be sure your clock is right: Google have a huge NTP server and a nice tutorial here https://developers.google.com/time/guides

The Raspberry has the time correctly synchronized. I started the clam node on my work PC (also synced)
Both nodes are connected to the same peer 69.121.201.75:31174, but Raspberry says "timeoffset" : -185, WorkPC says "timeoffset" : 0,
I have no idea whats wrong...


Raspberry

ntpdate -d time1.google.com | sed -n '$s/.*offset //p'
-0.008269 sec

cli getpeerinfo | grep timeoffset
    "addr" : "67.191.63.234:31174",
    "timeoffset" : -182,
    "addr" : "69.121.201.75:31174",
    "timeoffset" : -185,
    "addr" : "94.23.58.222:31174",
    "timeoffset" : -186,
    "addr" : "178.62.8.78:31174",
    "timeoffset" : -137,
    "addr" : "67.205.153.62:31174",
    "timeoffset" : -138,
    "addr" : "82.21.202.185:31174",
    "timeoffset" : -140,
    "addr" : "176.58.119.91:31174",
    "timeoffset" : -113,
    "addr" : "158.129.212.236:31174",
    "timeoffset" : -120,
    "addr" : "74.82.244.243:31174",
    "timeoffset" : -99,
    "addr" : "89.115.82.116:31174",
    "timeoffset" : -98,
    "addr" : "193.111.198.69:31174",
    "timeoffset" : -59,
    "addr" : "151.226.102.252:31174",
    "timeoffset" : -12,
    "addr" : "165.227.93.150:31174",
    "timeoffset" : -12,
    "addr" : "46.4.113.143:31174",
    "timeoffset" : -7,
    "addr" : "95.87.207.152:31174",
    "timeoffset" : -22,
    "addr" : "70.77.101.45:31174",
    "timeoffset" : -1,

Work PC (currently syncing)
ntpdate -d time1.google.com | sed -n '$s/.*offset //p'
host found : time1.google.com
0.000309 sec

        "addr" : "178.62.8.78:31174",
        "timeoffset" : 0,
        "addr" : "67.191.63.234:31174",
        "timeoffset" : -1,
        "addr" : "158.69.32.10:31174",
        "timeoffset" : 0,
        "addr" : "47.214.177.20:31174",
        "timeoffset" : -1,
        "addr" : "89.142.71.41:31174",
        "timeoffset" : -1,
        "addr" : "159.203.5.220:31174",
        "timeoffset" : -1,
        "addr" : "176.58.119.91:31174",
        "timeoffset" : -1,
        "addr" : "95.87.207.152:31174",
        "timeoffset" : 0,
        "addr" : "89.115.82.116:31174",
        "timeoffset" : 0,
        "addr" : "78.46.108.202:31174",
        "timeoffset" : -1,
        "addr" : "69.121.201.75:31174",
        "timeoffset" : 0,
        "addr" : "45.58.115.206:31174",
        "timeoffset" : -2,
        "addr" : "46.4.113.143:31174",
        "timeoffset" : -2,
        "addr" : "185.52.2.48:31174",
        "timeoffset" : 0,
        "addr" : "97.83.177.95:31174",
        "timeoffset" : -1,
        "addr" : "73.170.212.102:31174",
        "timeoffset" : 0,

[Broko82]

I have some difficulties staking recently. I should obtain one coin every ~30 hours, but my last stake dates back to 2 of January 2019.
I am wondering, if something is wrong with my configuration. The wallet seems to be fine.
Just a few minutes ago I got an orphaned block... :-(

Is it normal, to wait such a long time?

[criptocambio]

All nodes I connect has odd timeoffset - between -100 to -60. Also I am pretty sure, that I have correct time at my node. Is there something I can do with that?

Either you need to update your clock, or everyone does. This can be caused because of clock drifting, or some other issues. Please sync your computer with an NTP server to be sure your clock is right: Google have a huge NTP server and a nice tutorial here https://developers.google.com/time/guides

The Raspberry has the time correctly synchronized. I started the clam node on my work PC (also synced)
Both nodes are connected to the same peer 69.121.201.75:31174, but Raspberry says "timeoffset" : -185, WorkPC says "timeoffset" : 0,
I have no idea whats wrong...


Raspberry

ntpdate -d time1.google.com | sed -n '$s/.*offset //p'
-0.008269 sec

cli getpeerinfo | grep timeoffset
    "addr" : "67.191.63.234:31174",
    "timeoffset" : -182,
   (...)
Work PC (currently syncing)
ntpdate -d time1.google.com | sed -n '$s/.*offset //p'
host found : time1.google.com
0.000309 sec

        "addr" : "178.62.8.78:31174",
        "timeoffset" : 0,
        "addr" : "67.191.63.234:31174",
        "timeoffset" : -1,
        "addr" : "158.69.32.10:31174",
(...)

This does not seem to be a bug in CLAM client, but a misconfiguration on your raspberry pi. Here is a link to get you started, but that's the best i can offer you as i don't have one to debug by myself:

https://stackoverflow.com/questions/41848227/debian-linux-raspbian-raspberry-pi-time-offset-is-65s-ahead-of-utc

I have some difficulties staking recently. I should obtain one coin every ~30 hours, but my last stake dates back to 2 of January 2019.
I am wondering, if something is wrong with my configuration. The wallet seems to be fine.
Just a few minutes ago I got an orphaned block... :-(

Is it normal, to wait such a long time?

Looks like you got forked from the network. To be sure, please verify the output of the command

Code:

clamd getblockcount

and take a look at https://csexplorer.criptocambio.com.br/ or http://khashier.com/ to see if the number of the last block indexed is similar. A difference of 1 is acceptable, as the network can take a time to propagate blocks. But if the difference is bigger, then you got forked and need to resync

[Broko82]

I have some difficulties staking recently. I should obtain one coin every ~30 hours, but my last stake dates back to 2 of January 2019.
I am wondering, if something is wrong with my configuration. The wallet seems to be fine.
Just a few minutes ago I got an orphaned block... :-(

Is it normal, to wait such a long time?

Looks like you got forked from the network. To be sure, please verify the output of the command

Code:

clamd getblockcount

and take a look at https://csexplorer.criptocambio.com.br/ or http://khashier.com/ to see if the number of the last block indexed is similar. A difference of 1 is acceptable, as the network can take a time to propagate blocks. But if the difference is bigger, then you got forked and need to resync

Thank you. Today, I checked the output of the command and it matches the actual number of blocks on the website. However, I restarted the client yesterday and I also synced my PC clock with internet time (the deviation was less than 2s, so I don't think this is an issue).
I can't tell now if I was on the wrong chain prior to restarting.
The good news is that I staked 1 CLAM today in the morning, transaction is already validated.

[almightyruler]

This does not seem to be a bug in CLAM client, but a misconfiguration on your raspberry pi. Here is a link to get you started, but that's the best i can offer you as i don't have one to debug by myself:

https://stackoverflow.com/questions/41848227/debian-linux-raspbian-raspberry-pi-time-offset-is-65s-ahead-of-utc

NTP can be inaccurate if you get the wrong mix of peers. My main router has 5 external peers, and all are at least 500ms off (both +ve and -ve) my computed time. One is at +2.3 seconds offset. These are all supposedly stratum 2 servers, learned from pool.ntp.org.

[Faust Roland]

This does not seem to be a bug in CLAM client, but a misconfiguration on your raspberry pi. Here is a link to get you started, but that's the best i can offer you as i don't have one to debug by myself:

https://stackoverflow.com/questions/41848227/debian-linux-raspbian-raspberry-pi-time-offset-is-65s-ahead-of-utc

NTP can be inaccurate if you get the wrong mix of peers. My main router has 5 external peers, and all are at least 500ms off (both +ve and -ve) my computed time. One is at +2.3 seconds offset. These are all supposedly stratum 2 servers, learned from pool.ntp.org.

My PI has correct time - same time I have on my Main PC and on the Phone (I am using time-based 2FA, so my time has to be correct)
Bud I tried to:
Stop clamd
move .clam to .clam_backup
create new .clam/clam.conf
start clamd with no blockchain from scratch

Then I got peers with +-1s timeoffset.

Then I switched back to the full synced chain and again +-85s timeoffset.
I tried to delete peers.dat, no change


See below
at the 10:21:21 I got new block with error  block timestamp too far in the future
at the 10:25:20 The Block with timestamp 10:21:20 is officially accepted but is considered as "already have"

So I don't know if I can start staking, as I got forked in December (after 2 years of smoothness stakig) and I don't want to repeat the same issue...

Also I am considering, that the size of the clam overgrew what RPi can handle - are there other RPi stakers here?

Code:

free -h
             total       used       free     shared    buffers     cached
Mem:          973M       942M        31M       568K       1.8M       6.3M
-/+ buffers/cache:       933M        39M
Swap:         1.0G       509M       514M

2019-01-12 10:21:21 ERROR: CheckBlock() : block timestamp too far in the future
2019-01-12 10:21:21 ERROR: ProcessBlock() : CheckBlock FAILED
2019-01-12 10:21:47 CheckStakeKernelHash() : using modifier 0x5519ccb791de9d5c at height=2378211 timestamp=2019-01-12 10:17:20 UTC for block from timestamp=2018-12-26 15:50:24 UTC
2019-01-12 10:21:47 CheckStakeKernelHash() : check modifier=0x5519ccb791de9d5c nTimeBlockFrom=1545839424 nTimeTxPrev=1545839395 nPrevout=108 nTimeTx=1547288272 hashProof=0000e6800376214e9c9a5a94d73c2c8680523dd565a4b06b98433386c43d95ae
2019-01-12 10:21:47 CheckStakeKernelHash() : using modifier 0x5519ccb791de9d5c at height=2378211 timestamp=2019-01-12 10:17:20 UTC for block from timestamp=2018-12-26 15:50:24 UTC
2019-01-12 10:21:47 CheckStakeKernelHash() : check modifier=0x5519ccb791de9d5c nTimeBlockFrom=1545839424 nTimeTxPrev=1545839395 nPrevout=108 nTimeTx=1547288272 hashProof=0000e6800376214e9c9a5a94d73c2c8680523dd565a4b06b98433386c43d95ae
2019-01-12 10:21:48 SetBestChain: new best=40e955aeab8f05a5dba5d6f569f99a236d1318d74a63fa0063f5f6282755703f  height=2378212  trust=886542851187320957639  blocktrust=664485070067994  date=01/12/19 10:17:52
2019-01-12 10:21:48 ProcessBlock: ACCEPTED
2019-01-12 10:21:48 ERROR: ProcessBlock() : already have block 2378212 40e955aeab8f05a5dba5d6f569f99a236d1318d74a63fa0063f5f6282755703f
2019-01-12 10:21:59 peer 188.40.206.114:31174: leap backwards in height request, from max 2311199 to current 275001. penalty=1/100
2019-01-12 10:22:11 force request: block 258ce97be5f2dabfa7e12d5bc41377f7f183f76874de6a770d6e80ef62bcb2d7
2019-01-12 10:22:14 ERROR: CheckBlock() : block timestamp too far in the future
2019-01-12 10:22:14 ERROR: ProcessBlock() : CheckBlock FAILED
2019-01-12 10:22:23 CheckStakeKernelHash() : using modifier 0x5519ccb791de9d5c at height=2378212 timestamp=2019-01-12 10:17:52 UTC for block from timestamp=2018-10-13 10:28:16 UTC
2019-01-12 10:22:23 CheckStakeKernelHash() : check modifier=0x5519ccb791de9d5c nTimeBlockFrom=1539426496 nTimeTxPrev=1539426496 nPrevout=1 nTimeTx=1547288304 hashProof=0000145d97e32a4144ef8f773b2f4fcfd5eb45a5bd863d95d0135fef207b095f
2019-01-12 10:22:23 CheckStakeKernelHash() : using modifier 0x5519ccb791de9d5c at height=2378212 timestamp=2019-01-12 10:17:52 UTC for block from timestamp=2018-10-13 10:28:16 UTC
2019-01-12 10:22:23 CheckStakeKernelHash() : check modifier=0x5519ccb791de9d5c nTimeBlockFrom=1539426496 nTimeTxPrev=1539426496 nPrevout=1 nTimeTx=1547288304 hashProof=0000145d97e32a4144ef8f773b2f4fcfd5eb45a5bd863d95d0135fef207b095f
2019-01-12 10:22:23 SetBestChain: new best=4a0bec133723366a1e5989948094f0f938b1049d88a833c759a84416f147aadf  height=2378213  trust=886543514991569125486  blocktrust=663804248167847  date=01/12/19 10:18:24
2019-01-12 10:22:23 ProcessBlock: ACCEPTED
2019-01-12 10:22:23 ERROR: ProcessBlock() : already have block 2378213 4a0bec133723366a1e5989948094f0f938b1049d88a833c759a84416f147aadf
2019-01-12 10:22:39 ERROR: CheckBlock() : block timestamp too far in the future
2019-01-12 10:22:39 ERROR: ProcessBlock() : CheckBlock FAILED
2019-01-12 10:23:11 CheckStakeKernelHash() : using modifier 0x5519ccb791de9d5c at height=2378213 timestamp=2019-01-12 10:18:24 UTC for block from timestamp=2018-12-19 14:34:08 UTC
2019-01-12 10:23:11 CheckStakeKernelHash() : check modifier=0x5519ccb791de9d5c nTimeBlockFrom=1545230048 nTimeTxPrev=1545230048 nPrevout=1 nTimeTx=1547288352 hashProof=00003186d2858ece5df2cfaafe08616b305556a5bedafe0e18f301b12d9bbeb6
2019-01-12 10:23:11 CheckStakeKernelHash() : using modifier 0x5519ccb791de9d5c at height=2378213 timestamp=2019-01-12 10:18:24 UTC for block from timestamp=2018-12-19 14:34:08 UTC
2019-01-12 10:23:11 CheckStakeKernelHash() : check modifier=0x5519ccb791de9d5c nTimeBlockFrom=1545230048 nTimeTxPrev=1545230048 nPrevout=1 nTimeTx=1547288352 hashProof=00003186d2858ece5df2cfaafe08616b305556a5bedafe0e18f301b12d9bbeb6
2019-01-12 10:23:11 SetBestChain: new best=c60d28f4ccdf3fee4634c78ce48ffe27b4c543bd41cd02e70eea994e9da2978d  height=2378214  trust=886544178455603001062  blocktrust=663464033875576  date=01/12/19 10:19:12
2019-01-12 10:23:11 ProcessBlock: ACCEPTED
2019-01-12 10:23:11 ERROR: ProcessBlock() : already have block 2378214 c60d28f4ccdf3fee4634c78ce48ffe27b4c543bd41cd02e70eea994e9da2978d
2019-01-12 10:23:20 ERROR: CheckBlock() : block timestamp too far in the future
2019-01-12 10:23:20 ERROR: ProcessBlock() : CheckBlock FAILED
2019-01-12 10:23:43 ERROR: CheckBlock() : block timestamp too far in the future
2019-01-12 10:23:43 ERROR: ProcessBlock() : CheckBlock FAILED
2019-01-12 10:24:14 CheckStakeKernelHash() : using modifier 0x5519ccb791de9d5c at height=2378214 timestamp=2019-01-12 10:19:12 UTC for block from timestamp=2018-11-07 03:15:28 UTC
2019-01-12 10:24:14 CheckStakeKernelHash() : check modifier=0x5519ccb791de9d5c nTimeBlockFrom=1541560528 nTimeTxPrev=1541560528 nPrevout=2 nTimeTx=1547288416 hashProof=0000262bef905f7f0317001f41c80c6a8d3a939a969be45f1e4a774a988799a5
2019-01-12 10:24:14 CheckStakeKernelHash() : using modifier 0x5519ccb791de9d5c at height=2378214 timestamp=2019-01-12 10:19:12 UTC for block from timestamp=2018-11-07 03:15:28 UTC
2019-01-12 10:24:14 CheckStakeKernelHash() : check modifier=0x5519ccb791de9d5c nTimeBlockFrom=1541560528 nTimeTxPrev=1541560528 nPrevout=2 nTimeTx=1547288416 hashProof=0000262bef905f7f0317001f41c80c6a8d3a939a969be45f1e4a774a988799a5
2019-01-12 10:24:15 SetBestChain: new best=11f8931146069a41be5be689d453702e6654a1efb322dcdba878bdd9c81a3f8f  height=2378215  trust=886544841579584905956  blocktrust=663123981904894  date=01/12/19 10:20:16
2019-01-12 10:24:15 ProcessBlock: ACCEPTED
2019-01-12 10:24:15 ERROR: ProcessBlock() : already have block 2378215 11f8931146069a41be5be689d453702e6654a1efb322dcdba878bdd9c81a3f8f
2019-01-12 10:24:31 ERROR: CheckBlock() : block timestamp too far in the future
2019-01-12 10:24:31 ERROR: ProcessBlock() : CheckBlock FAILED
2019-01-12 10:24:39 ERROR: CheckBlock() : block timestamp too far in the future
2019-01-12 10:24:39 ERROR: ProcessBlock() : CheckBlock FAILED
2019-01-12 10:25:05 ping timeout: 1200.010178s
2019-01-12 10:25:20 CheckStakeKernelHash() : using modifier 0x5519ccb791de9d5c at height=2378215 timestamp=2019-01-12 10:20:16 UTC for block from timestamp=2019-01-07 19:29:36 UTC
2019-01-12 10:25:20 CheckStakeKernelHash() : check modifier=0x5519ccb791de9d5c nTimeBlockFrom=1546889376 nTimeTxPrev=1546889376 nPrevout=2 nTimeTx=1547288480 hashProof=00000712539b11721c548a48f699512ed023ce4ddfbbd9b10611124ebcaee86b
2019-01-12 10:25:20 CheckStakeKernelHash() : using modifier 0x5519ccb791de9d5c at height=2378215 timestamp=2019-01-12 10:20:16 UTC for block from timestamp=2019-01-07 19:29:36 UTC
2019-01-12 10:25:20 CheckStakeKernelHash() : check modifier=0x5519ccb791de9d5c nTimeBlockFrom=1546889376 nTimeTxPrev=1546889376 nPrevout=2 nTimeTx=1547288480 hashProof=00000712539b11721c548a48f699512ed023ce4ddfbbd9b10611124ebcaee86b
2019-01-12 10:25:20 SetBestChain: new best=702f7d9d7bb53884f53e0f7f07000d3cdab9cd55d08fa3b2f35d340a2e5c682f  height=2378216  trust=886545504363770220410  blocktrust=662784185314454  date=01/12/19 10:21:20
2019-01-12 10:25:20 ProcessBlock: ACCEPTED
2019-01-12 10:25:20 ERROR: ProcessBlock() : already have block 2378216 702f7d9d7bb53884f53e0f7f07000d3cdab9cd55d08fa3b2f35d340a2e5c682f

[smooth]

Also I am considering, that the size of the clam overgrew what RPi can handle - are there other RPi stakers here?

That seems possible. RPi is 32 bit right? My clam client (linux command line) after it has been running a while is using about 3.4 GB of address space though not quite that much actual memory. Seems close to a 32 bit limit. I'm on 64 bit system with plenty of RAM so it doesn't matter at all in my case but it may in yours.

[Dimon777]

when will the new wallet come out?

[BayAreaCoins]

when will the new wallet come out?

It's still being worked on: https://github.com/nochowderforyou/clams/tree/2.1.0

[huu78]

I used to play my favorite clam coin at just-dice.com. until now still playing there. although only with a little clam.

[Faust Roland]

Also I am considering, that the size of the clam overgrew what RPi can handle - are there other RPi stakers here?

That seems possible. RPi is 32 bit right? My clam client (linux command line) after it has been running a while is using about 3.4 GB of address space though not quite that much actual memory. Seems close to a 32 bit limit. I'm on 64 bit system with plenty of RAM so it doesn't matter at all in my case but it may in yours.

To add more into my story.

I configured my RPi node to maintain only one connection.
I got connected to the node with timeoffset -140, BUT the timeoffset in the getinfo is "0" and the complain "block timestamp too far in the future" is not appearing in the log anymore

The block really seems to get accepted much quicker (8s compared to 2 minutes previously)

2019-01-14 17:13:28 SetBestChain: new best=888094194c94f66b793783d1b13e11268b86a2a94f3d2c69246ea649a6130d7b  height=2381492  trust=888852073952277551647  blocktrust=841655184282631  date=01/14/19 17:13:20
2019-01-14 17:13:28 ProcessBlock: ACCEPTED

I allowed staking and I'll see whats happen.

[almightyruler]

Any update on the new client, specifically the syncing issue?

Mine was 18 days behind and after 8 hours it's still struggling to sync: ORPHAN BLOCK 751

For those who run the client 24/7 this is never a problem, but for everyone else.....

[BayAreaCoins]

Any update on the new client, specifically the syncing issue?

Mine was 18 days behind and after 8 hours it's still struggling to sync: ORPHAN BLOCK 751

For those who run the client 24/7 this is never a problem, but for everyone else.....

The new wallet syncing MUCH faster.

It's still being worked on day by day.

We need more people contributing and helping.  The github link is somewhere above and for people that are serious about helping... dooglus has a discord for developers and contributors we can invite folks into.

[BayAreaCoins]

My new CLAM trading tool Swap is starting to get a decent bankroll.

This allows users to buy and sell CLAMS for Bitcoin and other altcoins.

We've completed over 420 trades today!  

I think our "checkout" process is the best in the game... it's even better than Dominos Pizza's checkout.  (here is a 1.5 minute video if you want to watch before trying: https://www.youtube.com/watch?v=5AJ2wNgfkR0)

[four3200]

is pow still producing?

[Bit-Exo.com]

Any idea why I can no longer see stake tx's when i search my wallet using the listsinceblock function?

A few weeks ago I added:
splitsize=50
combinelimit=40
mininput=0.01

to the clam.conf file and i can see that the wallet has staked some blocks, the balance has gone up and I can see the new outputs on khasier when i look at the staking address but my function to look for new stakes now only shows regular send and receive tx's and no more generated.

Just in case it was the splitsize or combinelimit i just commented those lines out but I was hoping someone with a bit more experience with the wallet might be able to chime in.