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

[picolo]

You can check the value of your clams and find some other useful links and information on Claams.com

That is an good option to check it.

Good option, maybe add the value in $.

[dooglus]

Good option, maybe add the value in $.

I was looking at Poloniex, trying to figure out how to ask its API for the most recently traded CLAM/BTC price.

It turns out there wasn't a way without either asking for the most recently traded price of all their currency pairs, or getting a list the most recent 200 CLAM trades. But now there is:

Just GET:

  https://poloniex.com/public?command=returnTradeHistory&currencyPair=BTC_CLAM&limit=1

It returns:

  [{"tradeID":188881,"date":"2015-01-26 21:44:26","type":"buy","rate":"0.00555597","amount":"0.20668765","total":"0.00114835"}]

which is a lot less data than the previous best way of doing it.

[jd1959]

Hi guys

I'm running both 64 bit and 32 bit wallets on different Windows 7 computers the 64 bit shows a block 309812 and thinks it's up to date. The 32 bit  shows block 313277. I am running latest versions downloaded 24/01/2015.

When I look at file dates in package it shows 31/05/2013 in both packages 64 and 32 bit, the previous version showed file dates of 16/12/2014. I might be out of line but it looks wrong to me me...Any ideas?

Jon

Edit I've rolled back to previous version on 64 bit computer and it's sorted, so i would recommend not installing latest 64 bit

[binmon]

I'm seeing something very similar with my 64 bit win 7 version 1.4.4 wallet...  when i first start it, it will sync.  and sit there.  after 4 hours, it hasn't updated.  To get it to update, i have to close and re-start the client.  definitely not keeping up with things.

[Trent Russell]

@Baljourn @jd1959 @binmon

I had similar problems with version 1.4.4 on linux (32 bit) over the weekend and posted on this thread.

User shawn2025 reported problems last week and posted on this thread.

In my case I first restarted version 1.4.4 (newly downloading the blockchain) but it got stuck again. Then I downgraded to 1.4.3 and it's been working properly now for a few days.

I also recommend downgrading to 1.4.3. In general it's good to stay close to the version Just Dice (dooglus) is using since it's the majority staker. Currently JD is running a variant of 1.4.2.1.

Additional note: You can use "getinfo" to find out the latest block you have and use khashier.com to see if you've fallen behind. If your node has fallen behind, you won't stake.

[dooglus]

I had similar problems with version 1.4.4 on linux (32 bit) over the weekend and posted on this thread.

I just saw your post and remembered that I rebooted my laptop last night and didn't restart my local CLAM client.

I'm running 1.4.4 64 bit locally, on linux.

When I started the CLAM client it quickly caught up most of the way (the network was at block 314498, my local client started at 313818, and it very quickly synced to block 314318, then paused for almost a minute before continuing:

2015-01-27 19:14:51 height=314316 date=01/27/15 16:00:48
2015-01-27 19:14:51 height=314317 date=01/27/15 16:02:08
2015-01-27 19:14:51 height=314318 date=01/27/15 16:02:24
2015-01-27 19:15:37 height=314319 date=01/27/15 16:02:56
2015-01-27 19:15:37 height=314320 date=01/27/15 16:04:00
2015-01-27 19:15:37 height=314321 date=01/27/15 16:04:48

Then things got really weird. The syncing carried on going really fast until I was about 5 blocks behind the newest and then it stopped. It turns out that I was getting each block pretty much exactly 2 minutes late. This carried on for 18 blocks, and then I started seeing blocks in real time.

It looks like there's a peer out there that is deliberately withholding blocks for 2 minutes before relaying them. Possibly to reduce the chance of its own blocks being orphaned? Or is there an explanation for this which doesn't involve some kind of cheating?

Here are the logs from JD and my laptop side by side:

                    Just-Dice                                                  Local
--------------------------------------------------------   --------------------------------------------------------
2015-01-27 19:07:28 height=314495 date=01/27/15 19:07:28   2015-01-27 19:16:00 height=314495 date=01/27/15 19:07:28   catching up
2015-01-27 19:08:34 height=314496 date=01/27/15 19:08:32   2015-01-27 19:16:01 height=314496 date=01/27/15 19:08:32
2015-01-27 19:09:21 height=314497 date=01/27/15 19:09:20   2015-01-27 19:16:01 height=314497 date=01/27/15 19:09:20

2015-01-27 19:11:47 height=314498 date=01/27/15 19:11:44   2015-01-27 19:16:51 height=314498 date=01/27/15 19:11:44   5 minute delay

2015-01-27 19:15:33 height=314499 date=01/27/15 19:15:28   2015-01-27 19:17:33 height=314499 date=01/27/15 19:15:28   2 minute delay
2015-01-27 19:15:47 height=314500 date=01/27/15 19:15:44   2015-01-27 19:17:49 height=314500 date=01/27/15 19:15:44
2015-01-27 19:16:28 height=314501 date=01/27/15 19:16:16   2015-01-27 19:18:30 height=314501 date=01/27/15 19:16:16
2015-01-27 19:17:39 height=314502 date=01/27/15 19:17:36   2015-01-27 19:19:40 height=314502 date=01/27/15 19:17:36
2015-01-27 19:18:23 height=314503 date=01/27/15 19:18:24   2015-01-27 19:20:24 height=314503 date=01/27/15 19:18:24
2015-01-27 19:19:11 height=314504 date=01/27/15 19:19:12   2015-01-27 19:21:12 height=314504 date=01/27/15 19:19:12
2015-01-27 19:20:01 height=314505 date=01/27/15 19:20:00   2015-01-27 19:22:03 height=314505 date=01/27/15 19:20:00
2015-01-27 19:20:33 height=314506 date=01/27/15 19:20:32   2015-01-27 19:22:34 height=314506 date=01/27/15 19:20:32
2015-01-27 19:21:21 height=314507 date=01/27/15 19:21:20   2015-01-27 19:23:22 height=314507 date=01/27/15 19:21:20
2015-01-27 19:21:35 height=314508 date=01/27/15 19:21:36   2015-01-27 19:23:37 height=314508 date=01/27/15 19:21:36
2015-01-27 19:22:11 height=314509 date=01/27/15 19:22:08   2015-01-27 19:24:12 height=314509 date=01/27/15 19:22:08
2015-01-27 19:23:11 height=314510 date=01/27/15 19:23:12   2015-01-27 19:25:12 height=314510 date=01/27/15 19:23:12
2015-01-27 19:24:17 height=314511 date=01/27/15 19:24:16   2015-01-27 19:26:19 height=314511 date=01/27/15 19:24:16
2015-01-27 19:24:54 height=314512 date=01/27/15 19:24:48   2015-01-27 19:26:56 height=314512 date=01/27/15 19:24:48
2015-01-27 19:25:19 height=314513 date=01/27/15 19:25:20   2015-01-27 19:27:20 height=314513 date=01/27/15 19:25:20
2015-01-27 19:25:37 height=314514 date=01/27/15 19:25:36   2015-01-27 19:27:38 height=314514 date=01/27/15 19:25:36
2015-01-27 19:26:43 height=314515 date=01/27/15 19:26:40   2015-01-27 19:28:43 height=314515 date=01/27/15 19:26:40
2015-01-27 19:27:10 height=314516 date=01/27/15 19:27:12   2015-01-27 19:29:11 height=314516 date=01/27/15 19:27:12

2015-01-27 19:29:54 height=314517 date=01/27/15 19:29:52   2015-01-27 19:29:56 height=314517 date=01/27/15 19:29:52   real time
2015-01-27 19:30:13 height=314518 date=01/27/15 19:30:08   2015-01-27 19:30:15 height=314518 date=01/27/15 19:30:08
2015-01-27 19:30:27 height=314519 date=01/27/15 19:30:24   2015-01-27 19:30:29 height=314519 date=01/27/15 19:30:24

I remember seeing a post a few days ago to the effect of "how are we meant to stake when all the blocks are 5 minutes late". I didn't understand what he was getting at, but now I do...

Edit: this:

Hard to stake if block explorer always 7 blocks ahead.

[rocoro]

I had similar problems with version 1.4.4 on linux (32 bit) over the weekend and posted on this thread.

I just saw your post and remembered that I rebooted my laptop last night and didn't restart my local CLAM client.

I'm running 1.4.4 64 bit locally, on linux.

When I started the CLAM client it quickly caught up most of the way (the network was at block 314498, my local client started at 313818, and it very quickly synced to block 314318, then paused for almost a minute before continuing:

2015-01-27 19:14:51 height=314316 date=01/27/15 16:00:48
2015-01-27 19:14:51 height=314317 date=01/27/15 16:02:08
2015-01-27 19:14:51 height=314318 date=01/27/15 16:02:24
2015-01-27 19:15:37 height=314319 date=01/27/15 16:02:56
2015-01-27 19:15:37 height=314320 date=01/27/15 16:04:00
2015-01-27 19:15:37 height=314321 date=01/27/15 16:04:48

Then things got really weird. The syncing carried on going really fast until I was about 5 blocks behind the newest and then it stopped. It turns out that I was getting each block pretty much exactly 2 minutes late. This carried on for 18 blocks, and then I started seeing blocks in real time.

It looks like there's a peer out there that is deliberately withholding blocks for 2 minutes before relaying them. Possibly to reduce the chance of its own blocks being orphaned? Or is there an explanation for this which doesn't involve some kind of cheating?

Here are the logs from JD and my laptop side by side:

                    Just-Dice                                                  Local
--------------------------------------------------------   --------------------------------------------------------
2015-01-27 19:07:28 height=314495 date=01/27/15 19:07:28   2015-01-27 19:16:00 height=314495 date=01/27/15 19:07:28   catching up
2015-01-27 19:08:34 height=314496 date=01/27/15 19:08:32   2015-01-27 19:16:01 height=314496 date=01/27/15 19:08:32
2015-01-27 19:09:21 height=314497 date=01/27/15 19:09:20   2015-01-27 19:16:01 height=314497 date=01/27/15 19:09:20

2015-01-27 19:11:47 height=314498 date=01/27/15 19:11:44   2015-01-27 19:16:51 height=314498 date=01/27/15 19:11:44   5 minute delay

2015-01-27 19:15:33 height=314499 date=01/27/15 19:15:28   2015-01-27 19:17:33 height=314499 date=01/27/15 19:15:28   2 minute delay
2015-01-27 19:15:47 height=314500 date=01/27/15 19:15:44   2015-01-27 19:17:49 height=314500 date=01/27/15 19:15:44
2015-01-27 19:16:28 height=314501 date=01/27/15 19:16:16   2015-01-27 19:18:30 height=314501 date=01/27/15 19:16:16
2015-01-27 19:17:39 height=314502 date=01/27/15 19:17:36   2015-01-27 19:19:40 height=314502 date=01/27/15 19:17:36
2015-01-27 19:18:23 height=314503 date=01/27/15 19:18:24   2015-01-27 19:20:24 height=314503 date=01/27/15 19:18:24
2015-01-27 19:19:11 height=314504 date=01/27/15 19:19:12   2015-01-27 19:21:12 height=314504 date=01/27/15 19:19:12
2015-01-27 19:20:01 height=314505 date=01/27/15 19:20:00   2015-01-27 19:22:03 height=314505 date=01/27/15 19:20:00
2015-01-27 19:20:33 height=314506 date=01/27/15 19:20:32   2015-01-27 19:22:34 height=314506 date=01/27/15 19:20:32
2015-01-27 19:21:21 height=314507 date=01/27/15 19:21:20   2015-01-27 19:23:22 height=314507 date=01/27/15 19:21:20
2015-01-27 19:21:35 height=314508 date=01/27/15 19:21:36   2015-01-27 19:23:37 height=314508 date=01/27/15 19:21:36
2015-01-27 19:22:11 height=314509 date=01/27/15 19:22:08   2015-01-27 19:24:12 height=314509 date=01/27/15 19:22:08
2015-01-27 19:23:11 height=314510 date=01/27/15 19:23:12   2015-01-27 19:25:12 height=314510 date=01/27/15 19:23:12
2015-01-27 19:24:17 height=314511 date=01/27/15 19:24:16   2015-01-27 19:26:19 height=314511 date=01/27/15 19:24:16
2015-01-27 19:24:54 height=314512 date=01/27/15 19:24:48   2015-01-27 19:26:56 height=314512 date=01/27/15 19:24:48
2015-01-27 19:25:19 height=314513 date=01/27/15 19:25:20   2015-01-27 19:27:20 height=314513 date=01/27/15 19:25:20
2015-01-27 19:25:37 height=314514 date=01/27/15 19:25:36   2015-01-27 19:27:38 height=314514 date=01/27/15 19:25:36
2015-01-27 19:26:43 height=314515 date=01/27/15 19:26:40   2015-01-27 19:28:43 height=314515 date=01/27/15 19:26:40
2015-01-27 19:27:10 height=314516 date=01/27/15 19:27:12   2015-01-27 19:29:11 height=314516 date=01/27/15 19:27:12

2015-01-27 19:29:54 height=314517 date=01/27/15 19:29:52   2015-01-27 19:29:56 height=314517 date=01/27/15 19:29:52   real time
2015-01-27 19:30:13 height=314518 date=01/27/15 19:30:08   2015-01-27 19:30:15 height=314518 date=01/27/15 19:30:08
2015-01-27 19:30:27 height=314519 date=01/27/15 19:30:24   2015-01-27 19:30:29 height=314519 date=01/27/15 19:30:24

I remember seeing a post a few days ago to the effect of "how are we meant to stake when all the blocks are 5 minutes late". I didn't understand what he was getting at, but now I do...

Edit: this:

Hard to stake if block explorer always 7 blocks ahead.

Wow sounds like some problems....

[picolo]

Good option, maybe add the value in $.

I was looking at Poloniex, trying to figure out how to ask its API for the most recently traded CLAM/BTC price.

It turns out there wasn't a way without either asking for the most recently traded price of all their currency pairs, or getting a list the most recent 200 CLAM trades. But now there is:

Just GET:

  https://poloniex.com/public?command=returnTradeHistory&currencyPair=BTC_CLAM&limit=1

It returns:

  [{"tradeID":188881,"date":"2015-01-26 21:44:26","type":"buy","rate":"0.00555597","amount":"0.20668765","total":"0.00114835"}]

which is a lot less data than the previous best way of doing it.

Nice way to get the information

Today it returns

[{"tradeID":189520,"date":"2015-01-28 11:18:46","type":"buy","rate":"0.00547257","amount":"2.74642444","total":"0.01502999"}]

[dooglus]

I received an email to the Just-Dice support address saying the following:

date: 2015-01-28 6:36pm
subject: Missing Clam

I have around 1480 Clam in my wallet, the other day it staked 10 times for 1x clam each time.

I had staked 12 but 2 wound up being an Orphan.

Most of the clams staked had 60 + confirmations before I closed my wallet.

Loaded it the next day, it wouldn't leave 12 hours behind. So I rebuilt my wallet and everything loaded fine, my deposit from poloniex finally came in.

What was odd though, is that now all 12 clam I had staked are no orphans, losing me all 12 staked.

Why is the reason for this?

I could understand one or two, but all 12 even when many had over 50 confirmations when I closed my wallet.

I figure it's not a Just-Dice issue, so have reposted it here.

My guess is that he was on a fork, possibly caused by the de-syncing that lots of people have been reporting recently, and that the wallet only realised it was on a losing fork when he resynced it.

Is anyone looking into the issue of the client losing sync? It seems to be a pretty common problem. I wonder if it is being triggered on purpose by somebody looking to disrupt the network.

The crux of the issue appears to be the following code in main.cpp:

Code:

   // ppcoin: check proof-of-stake
    // Limited duplicity on stake: prevents block flood attack
    // Duplicate stake allowed only when there is orphan child block
    if (pblock->IsProofOfStake() && setStakeSeen.count(pblock->GetProofOfStake()) && !mapOrphanBlocksByPrev.count(hash) && !Checkpoints::WantedByPendingSyncCheckpoint(hash))
        return error("ProcessBlock() : duplicate proof-of-stake (%s, %d) for block %s", pblock->GetProofOfStake().first.ToString(), pblock->GetProofOfStake().second, hash.ToString());

which discards blocks if two or more stake the same output at the same time. It seems to be easy enough to publish multiple different blocks whenever you get a chance to stake. If peers disagree on which one was seen first, this could cause some of them to desync.

[bobboooiie]

SuperClam any response or progress on this ? This seems rather problematic

[allejuppa]

Dooglus:
Look at my comment on
https://github.com/nochowderforyou/clams/commit/66493570358a53f65b209590c38459cef92a0112

[dooglus]

Dooglus:
Look at my comment on
https://github.com/nochowderforyou/clams/commit/66493570358a53f65b209590c38459cef92a0112

I'm not familiar enough with this part of the client to know whether you're right about that commit causing the problem.

Can you explain what that commit does, and why it's a problem?

I see the code that rejects duplicate proofs of stake existed before that chance. What was the mechanism for recovering from the network building on top of a rejected block before this commit? Does this commit break that mechanism?

[SuperClam]

SuperClam any response or progress on this ? This seems rather problematic

Indeed. 
This is an ongoing issue that has, up until recently, been difficult to reliably reproduce and most often solved by a simple restart of the client.

A recent update seems to have possibly aggravated the issue.
Not a horrible situation, as aggravation often breeds incentive and motivation.


I am by no means the most technically savvy of those involved in the project; so I will defer to xploited, dooglus, allejuppa, and others concerning the technical details.

To my knowledge, there has never been any issue of forking or core service separation on the chain.
Rest assured it is being looked at - as always, anyone with expertise is invited to take part at the project repository.

This is, after all, an open source volunteer project.
We rise or fall together

[dooglus]

To my knowledge, there has never been any issue of forking or core service separation on the chain.
Rest assured it is being looked at - as always, anyone with expertise is invited to take part at the project repository.

This is, after all, an open source volunteer project.
We rise or fall together

I made an issue in the github repository so we can have all the discussion in one place:

https://github.com/nochowderforyou/clams/issues/133

With allejuppa's help I seem to have discovered the cause of the problem. It's in the handling (or lack of handling) of orphan blocks in v1.4.4.

This does look like a pretty serious problem with v1.4.4. It would be easy for a service to get stuck on the wrong side of a fork. The bug appears to make it relatively simple to hobble peers running v1.4.4. Until it is fixed it's not a good idea to run v1.4.4.

Are there any issues with downgrading to the previous release?

Edit: this seems to fix the problem

[ju34400]

hi i have 1 adress on blockchaininfo wallet
with transaction before may 2014
but justdice say me  BTC address [1BV2Eupx] was not funded on 12th May 2014;

however i can see transaction before may

https://blockchain.info/address/1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE

I tried importing the private key and also by importing the wallet on bitcoin-qt for get a .dat, nothing worked

if someone had an idea it would be nice

[istvandv]

hi i have 1 adress on blockchaininfo wallet
with transaction before may 2014
but justdice say me  BTC address [1BV2Eupx] was not funded on 12th May 2014;

however i can see transaction before may

https://blockchain.info/address/1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE

I tried importing the private key and also by importing the wallet on bitcoin-qt for get a .dat, nothing worked

if someone had an idea it would be nice

your balance during the distribution was 0.00000543
http://bitref.com/1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE

clams were distributed to btc with balances > 0.0001

[dooglus]

hi i have 1 adress on blockchaininfo wallet
with transaction before may 2014
but justdice say me  BTC address [1BV2Eupx] was not funded on 12th May 2014;

however i can see transaction before may

https://blockchain.info/address/1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE

I tried importing the private key and also by importing the wallet on bitcoin-qt for get a .dat, nothing worked

if someone had an idea it would be nice

You can get a list of the balances at various dates here:

https://blockchain.info/charts/balance?showDataPoints=true&timespan=&show_header=true&daysAverageString=1&scale=0&format=csv&address=1BV2Eupx1zNwqfFGnZHMWJPq6Qtjp4FciE

Specifically it was 0.00000543 BTC on 30/04/2014 and stayed at that until 18/06/2014. So on 12th May the balance was pretty much zero. It needed to be over 0.0001 BTC to be funded with CLAM I think.

[SuperClam]

CLAM client v1.4.5 TEST-build


Windows 32bit
Windows 64bit
Linux 64bit
OSX

[jd1959]

CLAM client v1.4.5 TEST-build


Windows 32bit
Windows 64bit
Linux 64bit
OSX

Hi SuperClam

I've downloaded and installed  Windows 64bit

All synced up seems to work quite nicely thank you

Jon  

[SuperClam]

CLAM client v1.4.5 TEST-build


Windows 32bit
Windows 64bit
Linux 64bit
OSX

Hi SuperClam

I've downloaded and installed  Windows 64bit

All synced up seems to work quite nicely thank you

Jon  

Great to hear!

Please keep an eye on it, and let us of know of any abnormalities or problems!