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

[SuperClam]

question guys...i deleted the clam software (i saved my .dat file before hand) and i opened and extracted the .2.2 update and opened it..but it still says .2.1  , why? any advice would be helpful,thanks

Further, if the archive was titled CLAMclient_1.4.2.2_MANDATORY_HOTFIX_Windows.zip (or Linux)

You are most certainly fine

[jd1959]

question guys...i deleted the clam software (i saved my .dat file before hand) and i opened and extracted the .2.2 update and opened it..but it still says .2.1  , why? any advice would be helpful,thanks

May be a stupid question did you run the setup file first or just the clam Qt? I had to run the setup file first to get the right version

Jon

[freedomsr40]

question guys...i deleted the clam software (i saved my .dat file before hand) and i opened and extracted the .2.2 update and opened it..but it still says .2.1  , why? any advice would be helpful,thanks

If you installed the version of CLAMClient listed in the OP post, reddit post, the above notice, or webpage - you should have the right version.  The compile and fix was rushed in only a few hours and it is quite possible the version # didn't get swapped out.

A low volume coin being exploited by a very popular dev. It looks like CLAMS poses some kind of threat to blackcoin. No wonder price keeps going down. 

We won't speculate on motives.
Though, we have noticed what is clearly a bot drip selling in the market.
The good news is the damage from the exploit is quite limited in that we caught it extremely quickly from what we can tell.

i got the windows link from your post above superclam so i guess im good, i deleted the entire %appdata% folder and its resyncing the chain...guess it just didnt get changed, thanks!

[dooglus]

Starting at block 170,000 of the CLAMS block chain, the CLAMS network will be moving away from the variable lottery based block reward and transitioning to a standard 1 CLAM per block reward.

Until then, almost all blocks will get a 0.1 CLAM reward and consume the accumulated age of the staked output.

Isn't it in my best interest to stop staking until block 170,000 is reached? Then I get 10 times as much value for each block I stake...

But what if everyone stops staking and waits for block 170k? Then we'll never reach it!

[phzi]

I think removing lotto rewards is a mistake.  Why not push the lotto block reward back 1 block, so that each block has minimum 2 txout? So, when a block is discovered, the miner pays themselves .1CLAM, and pays the previous block's first txout (the miner) a randomized lotto award (or 0).  Should be fairly simple to add block validation checks that would enforce this.

The problem with lotto rewards in every coin that has tried so far is that the reward is based on some data about the previous or current block.  By adding a second generate txout and calculating lotto rewards based on something unknown until the future, it seems like you could almost entitely avoid this abuse.  Someone with significant hashing (or here, staking) power could try to manipulate a string of blocks, but it would be significantly harder.

I think I have actually suggested this idea in this thread before.

[dooglus]

Why not push the lotto block reward back 1 block, so that each block has minimum 2 txout? So, when a block is discovered, the miner pays themselves .1CLAM, and pays the previous block's first txout (the miner) a randomized lotto award (or 0).

That's not a bad idea. I'd prefer it if the delay was longer, like 10 blocks or something - when I stake a block, the hash of the block I'm building on top of is used to determine whether the block 10 steps back won anything in the lotto...

That means that to cheat the system I have to withhold a chain of 10 blocks, while keeping up with the whole rest of the network.

It's still kind of exploitable though: when I see a block I staked is at depth 9, I take care to withhold any blocks which don't result in it winning a decent amount. But if I wait too long, someone else will stake a block, and that will probably mean my old block wins nothing.

Basically there's always going to be some point in time when I can make a decision to waste my coin weight earning a small reward, or hold off and wait for a chance to win a big lotto payout later. We have just shifted that decision point to 9 blocks after my initial block was staked.

[SuperClam]

I think removing lotto rewards is a mistake.  Why not push the lotto block reward back 1 block, so that each block has minimum 2 txout? So, when a block is discovered, the miner pays themselves .1CLAM, and pays the previous block's first txout (the miner) a randomized lotto award (or 0).  Should be fairly simple to add block validation checks that would enforce this.
The problem with lotto rewards in every coin that has tried so far is that the reward is based on some data about the previous or current block.  By adding a second generate txout and calculating lotto rewards based on something unknown until the future, it seems like you could almost entirely avoid this abuse.  Someone with significant hashing (or here, staking) power could try to manipulate a string of blocks, but it would be significantly harder.
I think I have actually suggested this idea in this thread before.

I am not the most technical member of the team, but I will do my best to explain.  If I am mistaken on a specific detail, I am sure xploited, dooglus or tryphe will correct me

There are really two problems: choosing a deterministic BUT non-brute-forceable seed for the random number generator, and preventing the withholding of blocks, or 'nothing at stake' problem.  There are a few candidates that might be useful and suitable to seed the 'rng', such as the proofHash, but the problem of withholding blocks remains an unsolved issue.  Unfortunately, simply changing the txOut for the reward to a prior block's finder does not solve the problem (though it had been discussed both in the thread and in private discussion).  

I am one of the largest proponents of the CLAM lottery, after all it was my idea.  If I had seen an easy and certain way to salvage the lottery with a fix in the time-frame set before us: have no doubt it would have been implemented instead of this fix.  Thanks to the speed with which some great CLAMS recognized and reacted to this threat, this fork will protect the chain and money supply from abuse in the short-term.  What could have been a significant dilution/inflation in the CLAM network should at the end of the day have very little impact due to these efforts.

That said, I agree and still prefer a lottery-based reward.  There is something about waking up in the morning with bated breath and checking your CLAMclient to see your over-night "wins" that is simply captivating.  If you believe you have a solid, reliable, un-cheatable way to implement the lottery-based reward, that is not susceptible to withholding or brute-force attacks I encourage you to please submit a pull request against the master repo with your changes.  I can ensure you they would be reviewed most carefully.  In the meantime, the chain should be safe and preserved to give us time to review the code ourselves and brainstorm a better implementation.


We intend to continue working on CLAMS with a perspective on far in to the future.  We aren't going anywhere and we hope you choose to stay around as well

The essence of an anti-fragile system REQUIRES coming under attack. 
Without attack, resilience can never be built and polished.

[tryphe]

Just to drill to the point here for the skeptics, fudders, and for clarity for our old-timers:

I don't like using other coin codebases, especially Bitcoin and our altcoins that we hold so dearly. (dumb right?) =p

I was on to this exploit, among testing hundreds of other tests unique to this codebase for almost a month to try and find any discrepancies; but digging through the code of five coins chopped down at a given commit is very hard. You have to get into the mindset of the developers to understand it completely. To go even further, you have to understand all of these things way out of the box to think of an exploit (blackcoin dev cough cough). Regardless, I was very close, and knew something was up, saw it happen IMMEDIATELY, and raised red flags. This could have gone on easily for days or a week longer, this is why we were so diligent to remove the lottery. Things will be static until we find a certain path for lottery security.

As bad as this sounds, or as long of a postponement of the lottery that this MIGHT be; it's not as far off as people think, and there's a lot more than a lottery to look forward to.

The sole problem here is that the Bitcoin codebase is based on the combined collective thoughts of hundreds (maybe thousands) of people over 6 years. While this makes for an interesting piece of software, this quickly becomes a very bad thing. There's major library overlap and implementations across the board that CLAMS simply does not need. I plan to make a codebase of our own. Not by copying code, or by starting from the Bitcoin code and adding some interesting commits from some random coins. But from SCRATCH. Yes, I'm crazy, but this can be done a whole lot better. Worlds better. This is the nature of open source. This community is home for all of us, and we won't stop, for our sake or for yours. For now, this is what I am focused on, as well as a different UI. (No, not the UI you see right now, that was a hurry up fix build, haha)

While this is a ways off, we are planning on reintroducing the lottery with a much more robust way to seed the stake (i.e. not using the last block hash for the seed). While this seems like a simple issue, there's a lot more to take into consideration that isn't obvious in any way before we're going risk our users possibly losing coin, or the coin degrading. This is why the lottery is disabled.

TLDR: We are not standing by the wayside here.

I hope this clears things up on a whole for now.
Please don't hesitate to stop in or hang around with us in #clams on freenode IRC.

Best regards,
Tryphe

[SuperClam]

Roughly 5 blocks to the hard-fork.

If you haven't updated please update immediately.

[paulc010]

Damn I missed this....... updating now :/

[almightyruler]

Damn I missed this....... updating now :/

I missed it too. Perhaps this thread topic can be updated so that it displays more prominently when people view "new replies"

Hopefully I can use an earlier snapshot of the blockchain so I don't need to delete and sync from scratch.

On that note. @tryphe, if the code is being rewritten, please considering making recovering from forks easier. Perhaps in the -qt client, when a fork goes beyond a few PoS bocks fighting it out over a couple of minutes, show a dialog warning that the local blockchain does not match the preferred blockchain, and ask if the user wants to roll back to the most recent hardened checkpoint, and sync from there.

[almightyruler]

Has the block explorer been updated? I'm not sure if my updated client has managed to resolve the fork and hop onto the correct chain, or both the block explorer and my client are on the "old" fork.

./clamd getblockhash 170571
e0d490a9b1e46a369b8344781f280119636ae48b718568dc1542c54968f3bde5

[SuperClam]

Damn I missed this....... updating now :/

I missed it too. Perhaps this thread topic can be updated so that it displays more prominently when people view "new replies"
Hopefully I can use an earlier snapshot of the blockchain so I don't need to delete and sync from scratch.

Sorry, with this being a time-sensitive update and between Twitter, Reddit, Bitcointalk.org, the website, etc. we tried to get the information out there as much as possible.  I appended 'Mandatory Update' to the post topic; I assume that was the suggestion?

Has the block explorer been updated? I'm not sure if my updated client has managed to resolve the fork and hop onto the correct chain, or both the block explorer and my client are on the "old" fork.
./clamd getblockhash 170571
e0d490a9b1e46a369b8344781f280119636ae48b718568dc1542c54968f3bde5

Poloniex and the block explorer were both verified as being on the right chain immediately after the forking block @ 170,000.  Just checked again now, and khashier.com:2750/chain/Clams does indeed appear to still be correct.

[SuperClam]

Has the block explorer been updated? I'm not sure if my updated client has managed to resolve the fork and hop onto the correct chain, or both the block explorer and my client are on the "old" fork.
./clamd getblockhash 170571
e0d490a9b1e46a369b8344781f280119636ae48b718568dc1542c54968f3bde5

Block #170571
hash: e0d490a9b1e46a369b8344781f280119636ae48b718568dc1542c54968f3bde5

Looks good

[paulc010]

Mine re-synced. I came looking here because I was hitting lots of blocks and my balance was going up too fast...... now I know why, it was 10 times too fast

[dooglus]

I'm seeing a LOT of orphan blocks in my debug.log:

received block bbd08b69888d5911f1d8
ProcessBlock: ORPHAN BLOCK, prev=d71bb0f13f3e2b7cd660
received block d71bb0f13f3e2b7cd660
ProcessBlock: ORPHAN BLOCK, prev=f195e50052dd11534ad7
received block f195e50052dd11534ad7
ProcessBlock: ORPHAN BLOCK, prev=f16a05c3f9b0a161146d
received block f16a05c3f9b0a161146d
ProcessBlock: ORPHAN BLOCK, prev=2c7ef5a2a52b11156f08
received block 2c7ef5a2a52b11156f08
ProcessBlock: ORPHAN BLOCK, prev=9de82b7d4692326d374a
received block 9de82b7d4692326d374a
ProcessBlock: ORPHAN BLOCK, prev=8aa7b6dd87ae1598585a
received block 8aa7b6dd87ae1598585a
ProcessBlock: ORPHAN BLOCK, prev=2bd912c37d4d31ef351d
received block 2bd912c37d4d31ef351d
ProcessBlock: ORPHAN BLOCK, prev=c80684c39b4f841a903f

I guess that's just someone staking on the wrong fork, right?

I'm on the same fork as poloniex and khashier - but it seems some big stakeholder didn't switch forks yet.

[paulc010]

I mined about 12 blocks on the old chain before I swapped over, although the network weight was still about 300k when I switched.

It was just main.cpp that changed wasn't it?

[dooglus]

I mined about 12 blocks on the old chain before I swapped over, although the network weight was still about 300k when I switched.

It was just main.cpp that changed wasn't it?

Yes, I believe so.

Here: https://github.com/nochowderforyou/clams/commit/ecef9cee2e8fd7a4c47de8809e9d4cccd231f00f

[Karn]

Crap just updated, sorry to find out about the exploit. Good job catching it so fast

[ButtCrack]

Has the block explorer been updated? I'm not sure if my updated client has managed to resolve the fork and hop onto the correct chain, or both the block explorer and my client are on the "old" fork.
./clamd getblockhash 170571
e0d490a9b1e46a369b8344781f280119636ae48b718568dc1542c54968f3bde5

Block #170571
hash: e0d490a9b1e46a369b8344781f280119636ae48b718568dc1542c54968f3bde5

Looks good

Can you post url of block exporer on OP ?
khashier.com:2750/chain/Clams
What is current recommended stack size and how long does it take to stake ?

Thanks !