Make CLAM great again - create an edge vs. all the other altcoins out there!

[chris106]

Hello there - have an idea to improve CLAM and thought I would place it here - though not much recent activity:

CLAM basically is cool for two reasons - 1) the uniquely fair distribution model 2) the access it gives you to dooglus' highly trusted dice site

However, these two features alone are not really attracting much attention anymore And the price development has been a bit disappointing. My proposal would be to position CLAM as a true gambling coin, with some built-in on-chain gambling options. This would also solve the problem of massive over-concentration in dooglus' JD wallets.

My idea would be the following: Is it possible to add into the code a function like "cointoss 100" where the next block's "entropy bit" of "1" or "0" would determine if that user loses the 100 from his balance or gains an additional 100 CLAM to his address - with a true 50/50 chance either way? The new 100 CLAM would not come from any other user (thus no bankroll required) rather the new 100 CLAM would just be newly created. Since the probability is truly 50/50, over time and on average no change to overall money supply would be expected. Of course you would need to pay the 0.001 CLAM for the transaction just like any transfer, but you would still be nearly even odds...

If this function were integrated into CLAM it would create huge demand for the crypto-currency again as it could offer even better odds than JD's 1% house edge, and it would alleviate the problem of over-concentration at JD... But it would not be a threat to JD either since people playing this "cointoss" would be willing to wait for tosses to be confirmed, but they would put up with the wait since they have better odds (roullete takes about 1 minute per game but people still do it - even with far worse odds)

People craving immediate gratification or martingale games would still rely on JD. Would be super interested if any coders have an idea if this is doable - and if so how difficult to implement (quick add-on or whole new architecture???) I am just an investor and have no coding experience/knowledge.

Thanks!

[creativecuriosity]

The problem is that the above idea isn't a 'true 50/50' odds scenario.
The staker of the next block, with enough at stake, could refuse to post the found block unless it would end in a positive betting result.
The only way I am familiar with to accomplish this is through a Proof-of-work-ish delay on the resolution of the bet.
Such that the work to discover the winner takes too long to reasonably complete prior to the block being cemented in the chain.

[chris106]

Thanks a lot for your quick response! Do you see any practical work-around to integrate into CLAM? Also for my understanding - if the staker of the next block refuses to publish the found block, does that really matter? Wouldn't someone else take his place in the meantime and post - resulting in the 50/50 odds?

[haraldg]

No, its a fundamental problem. Even if you made the result of the bet dependent on a block quite far in the future it won't be 50/50 odds if some stakers suppress blocks. This becomes worse the more centralised the currency is.

I'm sure activity and market cap will rise again once there is a software release that actually can download the blockchain on its own and generally is healthy.

[chris106]

ok thanks. so even if one staker or even several in a row suppress a "heads" block and the probability of the next unsupressed block being "heads" remains 50/50 there is still a chance for a large staker to manipulate the outcome? is this because the large staker can suppress one block and still stake the next one? is there no workaround such that suppression leads to forfeiting staking for the next block? or is there no other workaround you can think of (like the proof of work element previous poster referred to)? integrating a cointoss type function into CLAM would be a first and I think would be a huge hit.

on your second comment, do you expect a new software release any time soon?

thanks

[tryphe]

Hey Chris,

To emphasize a bit on cc's comments: The CLAM chain used to use, more or less, your suggested method for an on-chain lottery (1-1000 CLAM reward per block). However, since the value of a CLAM block is equal to the output, people are subject to choosing the blocks themselves and "trashcanning" the blocks that don't give them the best result. I could go on, but that's not getting to the point.

The point I'm trying to make is this: It would be wise to take a future proof of something more valuable than the bet itself, ie., a bitcoin block. Subsequently, if you wanted to "cheat", you'd have to bribe the majority of Bitcoin miners to withhold blocks, which is not really feasible. Thusly, the security will be much better in this model, but only in that it's severely discouraging, and not that it's completely secure.

If you wanted relative complete security, you could use multiple oracles (such as several nodes within a service) that post a hash on CLAMspeech of a future "proof hash" (a hash of the actual result). Given that one these nodes is compromised, all nodes will not post the same "proof hash", and the network will know that something is up. Once the bet takes place, the "proof" is posted, and everyone knows that the "proof hash" was secure in the meantime (with respect to the owner of the nodes, because there could be internal collusion) to determine the result of their wager. This is more or less what JD does, but without the node part, since it's all done on-site. A fundamental thing that JD does, is allow the player to supply their own seed, to thwart collusion within JD itself, unless you were able to completely control the entropy and seeding mechanism. There's even user choice of choosing high/low after the fact to even thwart collusion at that depth.

I hope this helps a bit. Cheers!

[dooglus]

The only way I am familiar with to accomplish this is through a Proof-of-work-ish delay on the resolution of the bet.

Yes, me too. Allowing the result of a bet to be decided by the hash of the block containing that block opens the whole process up to attack from the stakers. It would be trivially easy for a large staker to tip the odds in his own favor by refusing to publish blocks which cause his own bets to lose, or even deliberately orphaning blocks found by others which cause his own bets to lose.

As @creativecuriosity says, the only good workaround is to make it take a long time to figure out whether a bet has won or lost once we know the block hash, such that the block is reasonably well buried by the time the result is known.

Ideally we would find a function which is:

1) hard: takes a long time to figure out the result of a bet (to prevent block withholding attacks) 2) verifiable: is very quick to verify once the result is known (so the bettor himself can do the hard work, publish the result, and the rest of the network can quickly verify that his result is correct) 3) unique: has a unique result (we don't want multiple possible results to a bet; the bet should either be definitely won or definitely lost)

I don't think anyone has come up with a suitable function. I'm not sure it is possible.

There was an interesting thread on the bitcointalk forums when a site called pevpot.com was trying to come up with a provably fair lottery game. They faced the same issues: they wanted the result of the lottery to be decided by a block hash, but didn't want the miner to be able to cheat by withholding a block he found that made his own tickets all lose. So they used a very slow function (hash the block hash iteratively a billion times, or some such) to determine the winning ticket. That met conditions 1 and 3, but not 2. Anyone who wanted to verify the result of the lottery had to run the same slow CPU-intensive function. That's OK for a lottery, but not OK if every full node in the CLAM network has to run a slow function for every bet that happens.

We can find a function that meets conditions 1 and 2 by having the player find a nonce such that hash(nonce + bet_txid) starts with a certain number of zeroes. It's trivially easy to verify that their nonce satisfies the condition, but condition 3 fails: the solution isn't unique. If the player finds a nonce that makes them lose, they can keep searching in the hope of finding one that makes them win.

And of course it's easy to find a function satisfying 2 and 3, but without 1 it's useless.

Can you find a function satisfying all three conditions?

Edit: I found and linked to the pevpot thread, and it turns out I had misremembered the three conditions. It's important that the slow function can't be parallelized too. If you can simply put a million machines to work in parallel to decide if your new block makes you win or lose then people are going to be able to cheat it still.

[chris106]

Thanks for the posts guys!

While I wait for someone who actually knows what he's talking about to respond to dooglus and kwentzell - hopefully with a function that satisfies those 3 requirements ;) - or perhaps with another work-around, I'll just throw this out there: From the perspective of an altcoin enthusiast, CLAM has been a bit of a disappointment because it has not been able to generate enough demand to compensate for inflation. I think this is because the only true source of demand is access to JD.

In fact, to confirm this I created a supply and demand model to compare CLAM's "fair value" with its market price, and the result was that CLAMs invested on-site at JD ended up being the best proxy for demand (resulting in a "fair value" with the highest correlation to market price - with a few overshooting exceptions) - see attached graph.

My point is - to really make CLAM a success and boost demand, it would be cool to add truly unique features - that would also fit to the community and not take away from JD but rather add another source of demand (such as some kind of secure, blockchain-based betting as mentioned above - if it's possible). Otherwise, my model is showing that fair value probably tops out at around $1.20. And longer-term it doesn't really make sense for a decentralized crypto-currency's value to be so strongly tied to a single external site - however cool it may be!

[creativecuriosity]

@chris106
Fair observations.

@haraldg
I was looking into the network issues; there appears to be a fair bit of repetition in GetBlock pushes - which isn't aided by some wacky inventory messages that nodes are sending syncing nodes.

I didn't release my work or fiddling as I'm not personally particularly proficient in c++.
I believe it is a rather simple fix, if I had someone proficient who was willing to 'hash' it out with me, pardon the pun. A matter of identifying and ignoring the stray inventories, removing a bit of duplication, implementing a wiser orphan culling method, and ensuring future versions don't trigger requesting them in the first place.
You can find the majority of the code involved with some simple 'finds' in main.cpp:
'PushGetBlocks(', 'AskFor(', 'hashHighBlock', 'PruneOrphanBlocks'.

@dooglus
Maybe some type of ZKP; but, it's beyond me.
Such that a bettor could recursively hash to a specified high nonce hash with a high memory requirement hashing algo and prove it without verifiers needing to recursively hash.
Again, beyond me.

[dooglus]

I was looking into the network issues

I think xploited's "reindex" branch is a lot better at syncing. I don't know what needs doing before it can be released. Knowing there is so much work on an unreleased branch has pretty much stopped me working on the master branch, since merging between the two is hard.

Maybe some type of ZKP; but, it's beyond me.

Yeah, me too. I'll see what I can learn about it. It strikes me though that if the player has to do a lot of work for each bet to figure out whether they won or not then it's probably not going to be very popular. While the difference between 0% and 1% edge should be a big deal I don't think most gamblers actually care. 1% is small enough. I don't think a 0% edge service which takes 10 minutes of 100% CPU computation per bet would be very popular.

[tryphe]

@chris106

One thing to note about the huge price drop is that the digsupply was essentially doubled last year. This is what caused the price drop, not inflation (stakesupply). Although these two things are quite relativistic in terms of price, I'm not sure you could call them the same thing. If more of the digsupply were dumped on the market even further, you'd see a nearer approach to zero. This stifles short-term growth, but I'm highly doubtful it has any effect on long-term growth in terms of market cap. Of course, it all depends on the rate of dumping, which was extremely high, and how much people give in to the FUD (also extremely high). I like to refer to this as "Building sand castles at low tide". Similar to a short squeeze, you can only suppress things to a near-zero value for so long before equilibrium is met and growth becomes parabolic. In this case, we have both scenarios, which makes things great for anyone who is holding a leveraged short position from last year. The effect is also compounded when you bring the 50% consensus issue into the mix. Not only does this entice these positions even further, it suppresses any confidence in positive(long) positions until such conditions are diminished. This is why I think the price is low.

Provably fair systems are an absolute novel concept in contrast to how a modern casino works, in terms of offering great transparency and provability. Based on how much capital is in these areas of outdated, real life examples, I'm confident that there will be a spectrum shift into our ecosystem or other cryptocurrencies. However, such security-centric systems take time to get right and the learning curve is extremely high. Not only that, but the consequences of getting even a simple implementation detail wrong on top of a perfectly working function is grave. But I can assure you, there are people that are not ignoring this opportunity.

[chris106]

@kwentzell

Yes, that's a good point about the digging. Certainly the price collapse from Aug. 19 to Nov. 27 2015 (see price chart above) can be fully explained by the "Big Dig". Below the dig supply showing this. However, since Nov. 27 2015 until today there has been extremely little digging - on avg. 81 CLAM per day, which is much less than the pre-"Big Dig" norm of 438 CLAM per day (from Jan 4. 2015 onwards). In fact, at the current rate, the digging is not even inflationary to someone fully staking (because not all nodes are actively staking, as long as digging is less than 200 CLAM per day, if you stake your total share of of the money supply actually rises (negative dilution). But anyway, point is that digging cannot explain the price collapse from $1.50 after the Big Dig to less than half that today - this can only be explained by lack of demand strong enough to compensate staking (though my fair value estimate shows the recent drop is overshooting):

@dooglus

Thanks so much for looking into a possible new release and the idea of a betting function (that would certainly justify a new release)!

You wrote: While the difference between 0% and 1% edge should be a big deal I don't think most gamblers actually care. 1% is small enough. I don't think a 0% edge service which takes 10 minutes of 100% CPU computation per bet would be very popular.

I think you're right that JD users will not be much interested in 0% edge betting, since they are after instant gratification and tend towards martingale strategies - for which they want fast doubling action.

However, I wouldn't underestimate the demand out there for "zero-take" gambling. I think there is a huge portion of the population that enjoys the thrill of gambling but knows that it is a very foolish proposition when the odds are against you. Having fair, even odds would be truly revolutionary. Suddenly anyone could gamble for fun without fear of loss on average over time (if betting remains small enough percentage of your bankroll). This would be a world's first, and I think would breathe serious new life and demand into CLAM. Also it would be a very elegant application of blockchain, since zero-edge betting is really only possible when costs are born by decentralized, incentivized full nodes, so that the house does not need to pay for an external website, server space, etc. etc.

I'm very confident it would give CLAM a feature edge that would be pretty exciting. The question is whether it is possible, easily implementable, and without causing a 10 minute delay. A couple minutes would still work - as many casino games take that long, but 10 minutes might be a stretch. Possibly people could build a cool interface into the client that shows some kind of graphic display like coins being tossed with lots of colors or something until the result is there.

[chris106]

Hey guys,

Did some research and I think I found a way to introduce a zero-house-edge, secure, guaranteed fair coin toss function into the next CLAM release. Instead of relying on an external source of randomness or next block generation, this method involves two (or more) parties who both want to bet a sum of CLAM x against each other. Both parties need to "deposit" 2x as security through a time lock which will be returned if the game was fair but paid to the other automatically if there was any manipulation of the game. If there is no manipulation, then the loser of the coin toss sends x CLAM to the winner.

The academics proved the method guaranteed fairness (not only "provably fair" after the fact) and implemented it via Bitcoin, and their research was peer reviewed. See the paper here: http://ieeexplore.ieee.org/ielx7/6954656/6956545/06956580.pdf?tp=&arnumber=6956580&isnumber=6956545

Section IV is the relevant part.

In order to realize the crypto worlds first edge-free gambling use case via the next release of CLAM, and hopefully help CLAM recover from its slump (still at less than $0.60 per CLAM as I write this) the community would have to do the following:

1) integrate into next client release a way for gamblers to communicate to each other that they (or their public key) would be interested in betting x CLAM on an N-player lottery. Because the deposit required is N(N-1) times the amount bet x, probably only 2-player lotteries (coin toss) will be popular.

2) add a new command "cointoss" (eg: cointoss x public_key_of_counterparty) that automates the whole deposit commit etc process described in detail in section IV of paper above.

3) ideally add graphical interface into the CLAM client for gamblers to find counter parties, click on amounts to gamble and watch some kind of graphical coin toss or something to make it fun.

4) probably make transaction fees optional so that patient gamblers can really get pure edge free take-free gambling, while less patient gamblers can add transaction fee to ensure quick results.

The cool thing about this method is that the coin toss would be almost as fast as a normal send transaction, so no long wait for some kind of prof of work. The need for 2x deposits is kind of annoying, but shouldn't be too much of a problem - I mean even now with CLAM staking leads to large amounts of the balance being locked up at any given moment and it doesn't bother anyone.

So what do you guys think?!