Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 442. (Read 1151252 times)

Block #170571
hash: e0d490a9b1e46a369b8344781f280119636ae48b718568dc1542c54968f3bde5

Looks good

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?


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.

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

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.

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

Roughly 5 blocks to the hard-fork.

If you haven't updated please update immediately.

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

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.

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.

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.

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!

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!

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

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

You are most certainly fine

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.

---

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.

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. 

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

Thanks for heads up.

Jon 

To the CLAMS community:

Yesterday, it came to the attention of the CLAMS development team that there is an exploit in the CLAM lottery system.  Thankfully, due to some phenomenal detective work and a watchful eye by tryphe and dooglus, we caught the exploit extremely quickly.  Additional investigation conducted by dooglus, revealed that the exploit was being undertaken by a well known developer in the community that goes by the name 'rat4'.  rat4 is the chief developer of the crypto-currency Blackcoin. 

The team immediately contacted rat4 via IRC.  rat4 acknowledged discovering CLAMS recently and the use of the exploit.  Though after-the-fact, rat4 agreed to speak with the development team and provided additional insight and information concerning the exploit.  Despite being a bit bitter, the additional insight was greatly appreciated and helpful in considering the alternatives moving forward. 

In short, the exploit was executed via withholding/solving/staking sets of blocks and involved brute forcing the block which decides the block reward prior to submission.  To our great disappointment, no purely reliable, readily available and tested solution to the exploit existed that satisfied our requirements of security and fairness.  After reviewing the options available for the CLAMS network, it was decided by the development team to conduct a near immediate hard-fork of the CLAMS block chain to remove the threat.

---

The Hard-Fork:

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.  This 1 CLAM block reward maintains a projected inflation target extremely close to the original target of the lottery update; the primary difference being that the reward is balanced between blocks instead of accrued into larger "lucky" blocks.  The CLAM lottery has been greatly enjoyed by users and if a strong solution to the exploit presents itself in the coming days, there is intention to re-instate the lottery.  Unfortunately, such a solution is not readily available at the moment and in a prudent time-frame.

At the time of this posting the CLAMS network is at block #168853.  That places the hard-fork and block 170,000 at roughly 1,150 blocks from now: a bit under a day.  Poloniex has been contacted and is prepared and ready to update the exchange client(s) in preparation for the fork.  The new source has also already been pulled into the master repository.  It is anticipated that the hard-fork will proceed with little disruption as it is quite simple in scope.

ALL USERS SHOULD UPDATE THEIR CLIENT IMMEDIATELY.

---

Updated Windows Client: https://mega.co.nz/#!0U0GTADT!80mk1ETxo_2JwcfsSVHnkyqu4H_9s8KM9Ril-MaPey4


Updated Linux Client: https://mega.co.nz/#!MEkiVKID!bmjd8FQkDoHh2LeT6jg138lLLupZgZ3fuwP271gYRYM


Updated Source: https://github.com/nochowderforyou/clams

Hey Jon.

Glad to hear at least someone isn't bored by my overly dry posts.

So without further ado, here's more tedious detail!

I made a new wallet, sent myself a single output, and fudged the client code so that the output would age 1 CLAM-day every 3 minutes. I also modified it to show the current weight (in CLAM-days), the current network difficulty (right-shifted 224 bits to make it readable - lower numbers represent harder difficulty), the odds against mining a block in any given second, and the client's displayed "expected time" value:


As the weight goes up, the estimate goes down, roughly speaking. It also varies with the 'target' (difficulty) but that stays around 150-250 for the most part (for now).