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

[dooglus]

It seems I've been neglecting the forum for a day or two. We've had a big player beating us senseless at JD which has left me distracted.

Ah, Doog. You never cease to amaze me. You're one of the few people here that doesn't just throw out assumptions, and instead gives actual information that substantiates your views. Huge +1 with this.

I never really got the point of arguing from emotion. But I'm kind of autistic, so whatever.

Now, I think the idea of orphaning blocks should be ignored in relation to JD vs. elsewhere.

[... diagram and argument omitted ...]

So barring JD doing something nefarious (like attacking the network), it shouldn't really matter how many blocks the site is staking. This, of course, ignores the principle that states nobody should have 51%+ regardless of their intentions (as that makes it a centralized system, whether they want to abuse the power or not).

The problem is that as far as the CLAM network is concerned, the clock only 'ticks' once every 16 seconds. All block timestamps are exact multiples of 16 seconds. And so it's very possible that JD and OTHER both find blocks at the same 'time' (given such a grainy version of time). When that happens, JD will accept the block it found, and attempt to build on top of it. The rest of the network will accept whichever block they saw first. Since JD has 75% of the weight, the most likely outcome is that JD finds the next block, orphaning the OTHER's block.

And the solution that I discussed with xploited is to make the clock tick more often, reducing the chance of two blocks having the same timestamp.

2.  People trust digging on JD way more than some strange client that magically shifts through your wallets for coins or whatever else.  CLAM CLIENT sketchs me out personally and many many others. (I do think it is safe though, but honestly I personally do not have it downloaded and probably will not download it.)

I hope this doesn't sketch you out too much, but I have a newsflash for you...

When you type "/dig <addr> <privkey>" in the JD chat box, guess what JD does with that information. It makes an RPC call *to the official client* asking it to sign a raw transaction *with your private key*. ie. JD takes your private key, and gives it to the CLAM client. The CLAM client doesn't do anything with it other than using it to sign a transaction, and your key isn't stored anywhere, but it's important to realise that you are trusting the official client whether you use JD or not.

[mindless drivel]

Would you just fuck off already? Thanks.

It's odd that you would trust a third party website over a client that has source available, which you can even compile yourself, and that additionally, by trusting this third party website, you're opening the entire network up to a potential 51% attack.

I don't like third party sites either, but until we have "smart contracts" readily available and accepted, I don't see a way around it. People like the idea of having their coins "work for them" like they can at JD (in theory at least - we've been losing more than winning recently) and I don't see how we can achieve that without the third party holding their coins. Although, that reminds me:

About a year ago the idea was floated of allowing JD 'investors' to only actually deposit a fraction of their bankroll to the site while declaring the size of their total bankroll. The site would then act as if they had deposited the whole amount, using the actual deposit as collateral in the event that they lose. This would allow people to stake the majority of their own coins in their own wallet, while still having them "work" as if they were in the JD bankroll. I hope to finally implement such a system "soon".

The client is significantly safer then a website you send your private keys to.

Exactly. The client is used by the website to hold the coins. Any badness in the client is automatically also in the site, since the client is a component of the site.

I'm going to try to be nice, but your making it difficult.

Bay's a bigger fan of JD than I am. I see you guys looking out for the best interests of CLAM as a whole. He sees you attacking JD, and so is springing to its defence. I'm sure that's unnecessary, and we'll work it out reasonably. Adding 'age' to staking weight doesn't disadvantage JD unreasonably. If anything it makes things fairer. I suspect that JD is currently staking more than its fair share of the blocks (due to the way orphaning works when there's a race), which isn't how I want things to be.

You say you think its safe but it sketches you out?

I think I know where he's coming from. You must have heard a hundred times "why do you guys want my BTC keys?" and other such misunderstandings. People have been told to keep their wallets private, then you guys come along asking them to "import" their most precious file. People are suspicious. "Sketched out". Yes, we can say "review the code", or "we only use the keys to sign transactions", but most people don't have the skills to review the code or the understand to know what private keys even really are let alone how they're used. We're lucky if they know to keep their wallet safe in a lot of cases and there is a conflict when you then ask them to share their BTC wallet with the CLAM client.

[We] discussed the situation just last night and came to the conclusion its too early to decided if JD having the coins and the hold over the network that comes with it is temporary or something that will get worse over time

I didn't think of it at the time, but I think adding the ability for people to hold the majority of their coins locally (in their own copy of the client, as I described a few responses up) will help with this. I'll encourage the bigger investors to do just that. It's in their best interest, as well as the interest of the network as a whole.

Crypto currency should not be based on trust.

Absolutely laughable.

[...]

It is honestly hilarious that you think it is strange that normal people aren't rushing to download a thing that goes through all of their computers crypto wallets by a person who is named Xploited.

Oh dear. I'm answering this thread as I catch up on it. Things are getting unnecessarily messy here. Can't we all just get along?

The Clam Client only opens the wallets you explicitly ask it to. You make a good point that at JD you can 'dig' individual addresses rather than having to do it on a per-wallet level, but for people willing to 'dumpprivkey' in BTC and 'importprivkey' in CLAM, they can do the same too. And as Creative always points out, people who import their keys one by one are likely going to miss some, because they likely don't know about change addresses in enough detail.

So in summary:

* JD has an unfair advantage, and is staking too much
* JD threatens the network by being a single point of failure
* I support any reasonable attempt by the CLAM developers to help resolve these issues
* I will attempt to implement a system at JD that will allow investors to hold the majority of their coins locally, which I'm sure will at least partially fix the issues
* CLAM developers and JD aren't at war, and will work together to fix things!

Yeah?

[BayAreaCoins]

Yeah?

Okie dokie  

[picolo]

What remains to be seen is how the price and amount of CLAM wagered will move overtime when JD will return 140% in a year at the current pace. Can a website be such a portion of the market?

[SuperClam]

Complete agreement, with the sole exception of:

Oh dear.

You are stealing my "line"

Yeah?

Yeah

[chilly2k]

About a year ago the idea was floated of allowing JD 'investors' to only actually deposit a fraction of their bankroll to the site while declaring the size of their total bankroll. The site would then act as if they had deposited the whole amount, using the actual deposit as collateral in the event that they lose. This would allow people to stake the majority of their own coins in their own wallet, while still having them "work" as if they were in the JD bankroll. I hope to finally implement such a system "soon".


Yeah?

   I think this is a great idea, but implementing it sounds like a nightmare.  As a quick fix, have you thought about running multiple copies of the client?  You would still have control of over 51% of the network, but no one client would have that power.  I have not looked at this any more then writing these words.  But I read a lot and haven't seen a technical reason you couldn't do it. 

    Good Luck, and thanks for JD.   

[picolo]

Very thin sell order on poloniex for CLAM. Bull market ahead?

[J. J. Phillips]

Thanks for your reply. I can't respond to everything and the thread has moved on anyway. It's OK to assume I agree with everything I didn't reply to.

The concern at hand is the concentration and centralization of the CLAM network.  
Your suggested solution appears to be that there should be an alternative which does not require users to download the client.


There are multiple reasons it is desirable that users download the client.

I agree it's desirable if people who realize they have clams from the initial distribution download the client and become part of the network. I encourage people to do so.

I suspect given a choice between doing that and using the kind of quick method Just Dice allows, most people will use the quick method and probably convert to BTC as quickly as possible. If there were an alternative quick method run by someone other than dooglus, then there would be at least two independent people staking in the network and collecting lots of the clams from the initial distribution. (Three or four would be much better.) I think the concentration is partly due to Just Dice being the only quick, easy way to claim those clams.

Third, your solution appears to suggest that third-party services, in which the private key is transferred to a web-server over the wire through a browser into an opaque code system is preferable, from a security stand-point, to importing directly into the client.

Actually, I was suggesting people could sign a transaction (even offline) and never give up their private key. I probably didn't make that clear. For example, someone (Alice) could just make a big list of all the bitcoin addresses that still have clams and publish them with codes for transactions spending those clams to Alice's own clam address. Then Alice could say: "If you use some little piece of code that is only doing digital signatures to sign this transaction to my clams address, then I will send 3 mbits to your bitcoin address." Alice only needs the signed transaction to get the clams, not the private key.

Of course, the entire issue of security is nearly moot, considering that the recommended claim process, for Just-Dice OR the client, both involve emptying the private key before claiming regardless.  Empty keys have no more value than any random string of characters.

I'm guessing you've had to explain this hundreds of times. You're correct, of course, and that's what I did myself just to be on the safe side. I'm trying to suggest an alternative answer: "You don't have to give up your private key, you just have to sign one thing with it." Realistically, most people don't understand and are scared as a consequence. I'm not sure much can be done about that, but I suspect it means most people who have clams from the initial distribution will never claim them.

By the way, there is a problematic corner case with emptying addresses before claiming clams. Some bitcoins (well, tx outs) are really tokens standing for some meta-protocol (e.g., colored coins, master coin, counterparty). Care would need to be taken to move these, or they could lose their intended meaning and lose significant value as a result.

Concerning age:

The re-implementation of age would reduce the occurrence of orphans caused by "race conditions".  For that reason alone, it is likely a sensible option.  

Yes, it should reduce occurrences of "race conditions" -- as should switching 16s to 1s. How many such race conditions occur in an average day at the moment?

The only argument I have heard against the re-implementation of age concerns the incentive structure and desire to have clients staking continuously for network security.  

CLAMS already has the most sensible incentive structure is this regard, even if EXPONENTIAL age was implemented.

The fact is, we are the only proof-of-stake crypto with a reward structure that doesn't allow users to accrue reward "interest" via accruing age.  That alone is incentive to not "store" age.  Time not spent hashing, is time not spent rolling hashes for nBits.  Making CLAMS easily the crypto with the most well-aligned incentive structure regardless of age.

Ah, because the reward is fixed at 1 clam? You're right. I hadn't thought about that. With a fixed reward staking all the time provides optimal rewards. Eh, I'm OK with putting age back in.

To some extent, "age" is still in the staking algorithm now since minted coins take 510 blocks to mature (so the age goes from 0 to 1 and stays at 1). I noticed Just Dice mostly gets around this (completely legitimately) by keeping lots of transactions with approximately 4 clams as an output. (I might be doing the same thing, but I'm not telling.) This way there is the same chance of staking as if there were one big txout, but when one of the small ones stakes there are only 5 clams waiting to mature leaving the other small txouts still staking. (I'm not sure if 4 clams is optimal for this strategy. Someone should do the maths.)

Keep in mind that however age is included, stakers will (legitimately) split their clams to optimize their rewards.

I don't know the real numbers, but suppose JD has 25,000 transaction outputs staking with 4 clams on each. No matter how many of these have recently staked, most of them necessarily haven't staked recently and will have some age saved up.

I doubt there is a modification that would cause JD to stake fewer blocks. There could simply be a modification that the same *address* cannot stake twice in a row, but this has the obvious workaround that JD (and everyone else) would use different addresses for each staking output.

[dooglus]

Keep in mind that however age is included, stakers will (legitimately) split their clams to optimize their rewards.

I don't know the real numbers, but suppose JD has 25,000 transaction outputs staking with 4 clams on each. No matter how many of these have recently staked, most of them necessarily haven't staked recently and will have some age saved up.

I doubt there is a modification that would cause JD to stake fewer blocks. There could simply be a modification that the same *address* cannot stake twice in a row, but this has the obvious workaround that JD (and everyone else) would use different addresses for each staking output.

I can give you the numbers if you like, but pretty much we have 216k CLAM split into 54k piles of 4 CLAM each. Those 4's become 5, 6, then 7, and then 4+4 and the cycle repeats. Transaction fees get added in, and change from withdrawals too, so the actual picture is really messy.

The point of adding age back in is the following:

Suppose you have 10 CLAMs and are solo-staking. You stake for 20 days and eventually manage to stake a block. Unfortunately JD stakes a block at the same time, and goes on to orphan your block. You lose. And now you'll probably be waiting another 20 days to get another chance to try again.

With age, it will still take you 20 days on average for your first chance to stake (since all the competition is also aging), but if you get orphaned, your age doesn't get reset, and so you are likely to get your 2nd chance of staking after less than 20 more days. You will be getting to stake more and more often as your age (and thus weight) increases, and so will eventually get a block accepted.

The downside of reintroducing age is that it removes some of the incentive that currently exists for people to run their client 24/7.

[dooglus]

About a year ago the idea was floated of allowing JD 'investors' to only actually deposit a fraction of their bankroll to the site while declaring the size of their total bankroll. The site would then act as if they had deposited the whole amount, using the actual deposit as collateral in the event that they lose. This would allow people to stake the majority of their own coins in their own wallet, while still having them "work" as if they were in the JD bankroll. I hope to finally implement such a system "soon".

I think this is a great idea, but implementing it sounds like a nightmare.

I was hoping it would be relatively simple, but have just spotted a problem with it:

Currently we treat both staking rewards and player losses as "income" for the bankroll, and split it equally between those providing the bankroll. But with the proposed scheme, where you only deposit a fraction of your bankroll, and leave the rest locally, we don't want to consider the whole amount as active for staking (since it isn't). And that breaks the whole scheme (I only track the percentage of the bankroll that each user owns - I don't update their balance every time something happen, and don't want to).

I guess the solution is to treat staking rewards differently. They happen relatively rarely; the bankroll changes due to betting many times per second, and due to staking at most 4 times per minute. I can reduce the frequency at which staking rewards are credited to investors if necessary, and have them treated as a special kind of 'investment' event. This complicates things, but not too much.

As a quick fix, have you thought about running multiple copies of the client?  You would still have control of over 51% of the network, but no one client would have that power.  I have not looked at this any more then writing these words.  But I read a lot and haven't seen a technical reason you couldn't do it. 

I have tried running multiple copies of the client on different sites. I found that it really doesn't handle orphans very well. When both clients found a block at the same time, the one with the smaller weight would quickly get left behind, since its block would be orphaned. It would take up to 30 blocks before the smaller weight client realised this and did a reorg. For those 30 blocks it would see all the new blocks it received as "orphans" (which is weird, since they aren't) and would continue clinging to the hope that the single block it had staked would be accepted.

I should really have looked into this and fixed it, but instead all I did was move all the coins back to a single wallet to avoid the problem.

[Youghoor]

Too many wallets are not easy to manage.

[chilly2k]

I was hoping it would be relatively simple, but have just spotted a problem with it:

Currently we treat both staking rewards and player losses as "income" for the bankroll, and split it equally between those providing the bankroll. But with the proposed scheme, where you only deposit a fraction of your bankroll, and leave the rest locally, we don't want to consider the whole amount as active for staking (since it isn't). And that breaks the whole scheme (I only track the percentage of the bankroll that each user owns - I don't update their balance every time something happen, and don't want to).

I guess the solution is to treat staking rewards differently. They happen relatively rarely; the bankroll changes due to betting many times per second, and due to staking at most 4 times per minute. I can reduce the frequency at which staking rewards are credited to investors if necessary, and have them treated as a special kind of 'investment' event. This complicates things, but not too much.

  I'm not understanding how you can only accept a portion of the bankroll and leave the rest local. Are you planning to use the time lock thingy? 

  If you required everyone to have the same percent in the active bankroll, you would be exactly where you are today.  Each persons percent would be the same.  But I'm sure you will have some people that want to have all of their clams on the JD site.  If you made those the only options, the investors stake would either be X% or X% * percent really on JD site.

  I'm not sure how the system handles investing/devesting.  Does it take a snap shot at that point and update everyones balance? 

  And what happens if the bankroll falls below a certian point?  Is there a call option?  Some way you can gaurentee you can get the funds.  I'm not worried about you or me, but there are some that would be hessitent to send in addition funds to cover losses. 
   

I have tried running multiple copies of the client on different sites. I found that it really doesn't handle orphans very well. When both clients found a block at the same time, the one with the smaller weight would quickly get left behind, since its block would be orphaned. It would take up to 30 blocks before the smaller weight client realised this and did a reorg. For those 30 blocks it would see all the new blocks it received as "orphans" (which is weird, since they aren't) and would continue clinging to the hope that the single block it had staked would be accepted.

I should really have looked into this and fixed it, but instead all I did was move all the coins back to a single wallet to avoid the problem.

   Do you actually see the orphans in your clients transactions?  IE in the qt client?  I thought you just ran the daemon in Linux, but I could be mistaken.  I've just started staking locally again.  I haven't noticed a problems with orphans since the last fork. 

   Was there anything special about running 2 wallets on your end that you can think of?  Wouldn't it be the same as everyone else VS the JD wallet?   I moved clams into my personal wallet and got a stake about 1 hour after the blocks became mature.  And another 7 hours later.  No orphans in that time. At least not in the QT transaction list.   

[dooglus]

  I'm not understanding how you can only accept a portion of the bankroll and leave the rest local. Are you planning to use the time lock thingy? 

No, it's like this:

The bankroll is 90k, you deposit 100 and say "I have 9900 locally and want to invest the whole 10k with you". That makes the bankroll 100k in total, and you are 10% of it. You risk up to 0.5% of your total investment per roll, ie. 50 CLAMs. You get 10% of all losing bets, and lose 10% of all winning bets. If the site makes a net loss of 1000, you suffer 100 of that loss, and your actual deposit is all gone. You get divested at that point, and have lost your 100.

I can't tell, and don't care if you really have 9900 locally or not. You were risking up to 50 CLAMs per roll. If you only really had the 100 you deposited, then that's really risky behaviour. But it's only risky for you, not for JD. Once it's gone, you're divested.

But if you really DO have 10k CLAMs, it would make sense to send just 100 of it to JD and just tell it about the other 9900 you hold locally. Then your counterparty risk is vastly reduced, since only you have control of the majority of your coins. And the centralisation issue is moot, since 99% of your coins are no longer in the JD wallet.

  If you required everyone to have the same percent in the active bankroll, you would be exactly where you are today.

I won't. You can have 100% of your coins on deposit if you want to - then we'll stake them for you, and charge 10%. But why not stake most of them for yourself and keep 100% of the rewards?

  I'm not sure how the system handles investing/devesting.  Does it take a snap shot at that point and update everyones balance? 

The site just has a list of what percentage of the bankroll each investor owns. It calculates the size of individual user investments by multiplying their percentage by the current bankroll. When anyone invests or divests, all the percentages are adjusted accordingly.

  And what happens if the bankroll falls below a certian point?  Is there a call option?  Some way you can gaurentee you can get the funds.  I'm not worried about you or me, but there are some that would be hessitent to send in addition funds to cover losses. 

When you lose your actual deposit, you are forcibly divested. You aren't allowed to risk coins that aren't actually on deposit. You just risk a higher percentage of them based on the amount of coins you claim to hold locally.

   Do you actually see the orphans in your clients transactions?  IE in the qt client?  I thought you just ran the daemon in Linux, but I could be mistaken.  I've just started staking locally again.  I haven't noticed a problems with orphans since the last fork. 

I can't run the Qt client - it's just totally unresponsive. I've not looked into it very much, but I suspect it is updating every transaction (perhaps with the 'confirmations' count) every time a new block is received. The time it takes to update everything is longer than the time between blocks, so it's just constantly busy and unresponsive. I was just watching the debug logs on the clients. There's a message in all caps about orphans that I saw each time a new block was received.

   Was there anything special about running 2 wallets on your end that you can think of?  Wouldn't it be the same as everyone else VS the JD wallet?   I moved clams into my personal wallet and got a stake about 1 hour after the blocks became mature.  And another 7 hours later.  No orphans in that time. At least not in the QT transaction list.   

Actually, yes. Most times when I saw this problem I was staking from the same wallet on two different machines. That will obviously cause a lot of "race conditions" since they will both be staking at the same time always. The blocks they made had different hashes, but the same content. I'm not sure why the hashes were different, come to think of it. I'll look into this situation more when I get a chance. In another test, I imported just one of many privkeys from one wallet to the other, so the smaller wallet would be staking a subset of the blocks from the bigger one, but causing races when it did stake. It took a long time for the smaller wallet to recover from having a single block orphaned, and I don't know why.

[J. J. Phillips]

Keep in mind that however age is included, stakers will (legitimately) split their clams to optimize their rewards.

I don't know the real numbers, but suppose JD has 25,000 transaction outputs staking with 4 clams on each. No matter how many of these have recently staked, most of them necessarily haven't staked recently and will have some age saved up.

I doubt there is a modification that would cause JD to stake fewer blocks. There could simply be a modification that the same *address* cannot stake twice in a row, but this has the obvious workaround that JD (and everyone else) would use different addresses for each staking output.

I can give you the numbers if you like, but pretty much we have 216k CLAM split into 54k piles of 4 CLAM each. Those 4's become 5, 6, then 7, and then 4+4 and the cycle repeats. Transaction fees get added in, and change from withdrawals too, so the actual picture is really messy.

The point of adding age back in is the following:

Suppose you have 10 CLAMs and are solo-staking. You stake for 20 days and eventually manage to stake a block. Unfortunately JD stakes a block at the same time, and goes on to orphan your block. You lose. And now you'll probably be waiting another 20 days to get another chance to try again.

With age, it will still take you 20 days on average for your first chance to stake (since all the competition is also aging), but if you get orphaned, your age doesn't get reset, and so you are likely to get your 2nd chance of staking after less than 20 more days. You will be getting to stake more and more often as your age (and thus weight) increases, and so will eventually get a block accepted.

The downside of reintroducing age is that it removes some of the incentive that currently exists for people to run their client 24/7.

Thanks for the numbers. I might write a little python code to simulate what might happen with different coin age options. If I do, I'll post the results.

[dooglus]

Thanks for the numbers.

Actual numbers:

http://privatepaste.com/9533a910e0

It ends:

  501 5.00010000
  8316 5.00000000
  42365 4.00000000

which means we have 501 outputs of size 5.0001, 8316 of size 5, and 42.3k of size 4.

Edit: I'm surprised we only have 2 of size 7. I would have expected lots of the 4's to have gone 5, 6, 7 by now. I guess it takes longer to stake than I realised.

Edit2: those two 7's are here if anyone's interested:

http://khashier.com/tx/71d76437d72d9f581a4973bd1855f375073ca89cccc45a3666ab72ad181e3b7e
http://khashier.com/tx/faa31666e0575f985fce72ef910faa4298f5af793514f6ea8d9defd0e5a9998a

[Jbanna]

No, it's like this:

The bankroll is 90k, you deposit 100 and say "I have 9900 locally and want to invest the whole 10k with you". That makes the bankroll 100k in total, and you are 10% of it. You risk up to 0.5% of your total investment per roll, ie. 50 CLAMs. You get 10% of all losing bets, and lose 10% of all winning bets. If the site makes a net loss of 1000, you suffer 100 of that loss, and your actual deposit is all gone. You get divested at that point, and have lost your 100.

I can't tell, and don't care if you really have 9900 locally or not. You were risking up to 50 CLAMs per roll. If you only really had the 100 you deposited, then that's really risky behaviour. But it's only risky for you, not for JD. Once it's gone, you're divested.

But if you really DO have 10k CLAMs, it would make sense to send just 100 of it to JD and just tell it about the other 9900 you hold locally. Then your counterparty risk is vastly reduced, since only you have control of the majority of your coins. And the centralisation issue is moot, since 99% of your coins are no longer in the JD wallet.

This is absolutely brilliant and revolutionary. Margin investment on gambling dice? holy shit. Doog, I greatly hope you go through with this implementation  

[BayAreaCoins]

New service to add to the OP please:

https://fortunejack.com/

They now accept CLAM.

(I have not made a deposit/withdraw yet, but plan to do so after Christmas.)

They are a Bitcoin Foundation member and the website is fully licensed by Law of Saint Kitts and Nevis, owned and operated by the "Nexus Group Enterprises", LLC.

[hopenotlate]

New service to add to the OP:

https://fortunejack.com/

They now accept CLAM.

(I have not made a deposit/withdraw yet, but plan to do so after Christmas.)

They are a Bitcoin Foundation member and the website is fully licensed by Law of Saint Kitts and Nevis, owned and operated by the "Nexus Group Enterprises", LLC.

wow that's really a good news for clams.

I 'm a long time player at FortuneJack and never had issues with them.  I only used BTC there  until now and can definitely state doposits and withdraw works regularly and quickly at FJ.
My opinion, for what it matters, on them is they are reliable ( they also pay regularly and in time for their signature campaign I'm joining at trhe moment).

good job CLAM

[picolo]

No, it's like this:

The bankroll is 90k, you deposit 100 and say "I have 9900 locally and want to invest the whole 10k with you". That makes the bankroll 100k in total, and you are 10% of it. You risk up to 0.5% of your total investment per roll, ie. 50 CLAMs. You get 10% of all losing bets, and lose 10% of all winning bets. If the site makes a net loss of 1000, you suffer 100 of that loss, and your actual deposit is all gone. You get divested at that point, and have lost your 100.

I can't tell, and don't care if you really have 9900 locally or not. You were risking up to 50 CLAMs per roll. If you only really had the 100 you deposited, then that's really risky behaviour. But it's only risky for you, not for JD. Once it's gone, you're divested.

But if you really DO have 10k CLAMs, it would make sense to send just 100 of it to JD and just tell it about the other 9900 you hold locally. Then your counterparty risk is vastly reduced, since only you have control of the majority of your coins. And the centralisation issue is moot, since 99% of your coins are no longer in the JD wallet.

This is absolutely brilliant and revolutionary. Margin investment on gambling dice? holy shit. Doog, I greatly hope you go through with this implementation  

Other dice sites already had this option that lower the risk of losing all your coins in case of the site disappearing.

[lovewiki]

New service to add to the OP please:

https://fortunejack.com/

They now accept CLAM.

(I have not made a deposit/withdraw yet, but plan to do so after Christmas.)

They are a Bitcoin Foundation member and the website is fully licensed by Law of Saint Kitts and Nevis, owned and operated by the "Nexus Group Enterprises", LLC.

Great, one more good website is accepting CLAM.

This will certainly attract more people to start using CLAM and make this coin even stronger. 

[picolo]

New service to add to the OP please:

https://fortunejack.com/

They now accept CLAM.

(I have not made a deposit/withdraw yet, but plan to do so after Christmas.)

They are a Bitcoin Foundation member and the website is fully licensed by Law of Saint Kitts and Nevis, owned and operated by the "Nexus Group Enterprises", LLC.

Great, one more good website is accepting CLAM.

This will certainly attract more people to start using CLAM and make this coin even stronger. 

More people will hear about CLAM and the velocity of clam may increase with this new option to use clam but you can play at fortunejack with bitcoin so if you never used clam you will not use it to play fortunejack