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

[dooglus]

dooglus,

You are rarely wrong

Speaking of which, don't be a stranger in the irc channel.
Would like to make sure that we don't miss any of your fixes when we do this upcoming update.

I remember the client used to be treating all transactions as if the coins were newly mined, and would wait 120 (?) confirmations before starting to try to stake them, but upon receiving a block from a peer it wouldn't apply the same rule. So I modified my client to try to start staking ASAP, and found the network would accept outputs that staked before they had the 120 confirmations.

I believe I made a pull request for the change, and that it was accepted. That's the bit I may be wrong about. I know that the rest of it is right.

[1713505303]

1713505303

[1713505303]

1713505303

[1713505303]

1713505303

[freedomsr40]

is the "Expected time to earn reward" thing in the wallet accurate at all?

[dooglus]

is the "Expected time to earn reward" thing in the wallet accurate at all?

I think it's about right, but it assumes that blocks will continue to be found at the rate they have recently been found I think. The network rate has been pretty stable recently, so that's a reasonable assumption.

Edit: I looked into it and did some experimentation. It doesn't look at the recent history at all. It just looks at the weight (age times size) of your outputs and the current network difficulty, and calculates the expected time from that.

I think it's accurate.



Note: the "expected time" it shows is based on the current weight of your outputs. As they get older, the estimate will reduce significantly. My 5 CLAM, 1 CLAM-day output which has an "expected time" of 264 days right now will have a weight of 6 CLAM-days this time tomorrow, and so will have an expected time to stake of 6 times less than 264 days, or around 44 days. 24 hours after that, it will have a weight of 11 CLAM-days, and an expected time to stake of 264/11 = 24 days. (Assuming the network difficulty doesn't change, and also assuming it doesn't get lucky and stake before then, which it probably won't, but could).

[dooglus]

oh...i see it takes about 8.5 hours before the lottery thing starts and the coins are mature enough...right?

I think maybe only 4 hours. The maturing thing is only for newly mined (or staked) coins. If you bought some on an exchange and withdrew to your wallet, I think they are ready to stake after 4 hours - but I could be wrong.

The other thing I had forgotten is that the "weight" of your coins has to be greater than zero to be considered fit for staking.

The weight of each output is calculated as ((the age of the output minus 4 hours in days) times (the value of the output in CLAMs)) rounded down to an integer number of "CLAM-days".

So if you're trying to stake a 2-CLAM output, it will need to be at least 16 hours old before it is considered "mature" for staking purposes
(because ((16-4)/24) * 2 == 1)

In general it takes (24/value + 4) hours for an output to mature for staking.

I'm running a test to see if that's what actually happens - I guess I'll report back in (24/value+4) hours!

Edit: I cheated, and reduced a bunch of numbers to make it go quicker. It looks like the above is correct.

[jd1959]

Hi dooglus

I don't say a lot here but I'm a chronic thread follower, tragic almost. I must say I look forward to reading your posts. I find them insightful and technically informative. Keep up the good work

Jon 

PS should have included SuperClam in thank you as well

[dooglus]

Hi dooglus

I don't say a lot here but I'm a chronic thread follower, tragic almost. I must say I look forward to reading your posts. I find them insightful and technically informative. Keep up the good work

Jon  

PS should have included SuperClam in thank you as well

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:

weight: 1, target: 221, tries: 19348061 <-- 223 days
weight: 2, target: 221, tries: 9674030 <-- 111 days
weight: 2, target: 230, tries: 9326589 <-- 107 days
weight: 2, target: 241, tries: 8874185 <-- 102 days
weight: 3, target: 241, tries: 5916123 <-- 68 days
weight: 3, target: 244, tries: 5847408 <-- 67 days
weight: 3, target: 196, tries: 7268585 <-- 84 days
weight: 4, target: 196, tries: 5451438 <-- 63 days
weight: 4, target: 226, tries: 4736416 <-- 54 days
weight: 4, target: 216, tries: 4960172 <-- 57 days
weight: 4, target: 202, tries: 5314525 <-- 61 days
weight: 4, target: 191, tries: 5611700 <-- 64 days
weight: 5, target: 194, tries: 4411545 <-- 51 days
weight: 5, target: 189, tries: 4526974 <-- 52 days
weight: 6, target: 189, tries: 3772478 <-- 43 days
weight: 6, target: 244, tries: 2923984 <-- 33 days
weight: 6, target: 238, tries: 3000490 <-- 34 days
weight: 6, target: 234, tries: 3054402 <-- 35 days
weight: 7, target: 234, tries: 2618059 <-- 30 days
weight: 7, target: 229, tries: 2670448 <-- 30 days
weight: 7, target: 230, tries: 2665237 <-- 30 days
weight: 7, target: 207, tries: 2961408 <-- 34 days
weight: 7, target: 197, tries: 3114058 <-- 36 days
weight: 8, target: 197, tries: 2724800 <-- 31 days
weight: 8, target: 187, tries: 2865281 <-- 33 days
weight: 8, target: 189, tries: 2831982 <-- 32 days
weight: 9, target: 189, tries: 2517317 <-- 29 days
[...]
weight: 31, target: 147, tries: 936996 <-- 10 days
[...]
weight: 498, target: 131, tries: 65352 <-- 18 hours
weight: 498, target: 153, tries: 56110 <-- 15 hours

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).

[SuperClam]

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

[jd1959]

Thanks for heads up.

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

[vhong]

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. 

[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

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.

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