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

[chilly2k]

Each CLAM has a certain chance of staking each 16 seconds. If you only try to stake half the time, you will stake about half as often. In that sense it's like proof-of-work. If age mattered then you could shut down your wallet most of the time, let the age build up, then once a week run it and let all your outputs stake, collecting the potential built up during the downtime. That's no longer how it works.

   Excellent explanation Doog.  I knew age was no longer a factor, but not the why piece. 

It's to bad we can't somehow track the time actually staking and make that part of the factor.  Now it's all random, each block of clams has the same chance as all the others.  I believe this is hurting the smaller stakers.  I know eventually it will all even out, but in the shorter term they are not seeing a benefit to staking on their own.
So if you had the weight increase and then reset once a block is staked, more smaller investors might buy into staking.  It wouldn't cause them to get more shares, just more regularity.   

   I don't profess to really understanding how clams actually stake.  But if there was some way to factor in the weight while still keeping it somewhat random, that would be cool.
Maybe have a way to know when the client first connects to the network, and use that as the basis for the stake time weight.  Each time it connected it would reset to 0.   

 This doesn't really affect me, I've just changed my mindset from staking X per day to staking Y per week.  Since Just-Dice started I can no longer expect to stake a somewhat constant amount a day (+/- 30%). but for a week it's pretty regular (+/- 30%). 
     

[inkha]

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.

Thanks I can improve upon CLAAMS.com also if you have any feature request cheers

[aukusti]

I'm trying to claim some clam from my old doge wallet and nothing seems to happen when I import the wallet.dat and enter the password for it. Am I doing something wrong here or am I just too impatient? There definitely were some doge in that wallet on 12th of May

[SuperClam]

I'm trying to claim some clam from my old doge wallet and nothing seems to happen when I import the wallet.dat and enter the password for it. Am I doing something wrong here or am I just too impatient? There definitely were some doge in that wallet on 12th of May

If you are certain that the given wallet.dat file contains keys corresponding to unspent outputs on May 12th:

The debug.log file should contain a short report concerning the import.  Please ensure no keys were "skipped".
If the keys were imported successfully, try restarting the client with the rescan flag.

If you are still having problems, please stop in to #clams on freenode IRC; haven't had a single claim we haven't been able to figure out yet

[Vortex20000]

https://m.youtube.com/watch?v=3gfntBEI3Aw

Made me thi k of you twats

Well, thanks for the laugh, uglyvagina.

[dooglus]

   Excellent explanation Doog.  I knew age was no longer a factor, but not the why piece. 

I'm not exactly sure about the 'why' myself. The previous way was being abused by some kind of block-withholding and timewarp attacks, and a whole bunch of upstream changes were merged in to the CLAM client. It's hard to know which of them were brought in because they were a good idea, and which were just merged because they were there.

It's to bad we can't somehow track the time actually staking and make that part of the factor.  Now it's all random, each block of clams has the same chance as all the others.  I believe this is hurting the smaller stakers.  I know eventually it will all even out, but in the shorter term they are not seeing a benefit to staking on their own.
So if you had the weight increase and then reset once a block is staked, more smaller investors might buy into staking.  It wouldn't cause them to get more shares, just more regularity.   

A block's chance is proportional to its size. It's not true that "each block of clams has the same chance as all the others". If it did, everyone would do best by splitting their 1 CLAM into a million tiny blocks and the blockchain would get very bloated as a result.

If weight increased with age, it might well become not worth staking most of the time. Why waste all that CPU time checking for staking opportunities every 16 seconds if you can just shut staking down and check for staking opportunities once per day? It seems like it's best for the network to have as many people staking as possible, but maybe it doesn't make a difference.

   I don't profess to really understanding how clams actually stake.  But if there was some way to factor in the weight while still keeping it somewhat random, that would be cool.
Maybe have a way to know when the client first connects to the network, and use that as the basis for the stake time weight.  Each time it connected it would reset to 0.   

Bear in mind that the whole thing has to work without trust on a decentralised network. How am I to know when your client connected to the network and that you didn't just write a program that fakes it?

[dooglus]

https://m.youtube.com/watch?v=3gfntBEI3Aw

Funny video. Overweight middle-aged men acting dumb always make me laugh (do you see what I did there?)

[Baljourn]

Is there anyone else having problems with wallet v. 1.4.4 not staking?  I was doing fine until two days ago, which is the last time the wallet has staked.  Could it be that I just am that unlucky or is there something I'm missing?

[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?