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

[cryyptc]

i'm not going to get you guys added to any more exchanges at this rate.

You didn't get CLAM listed on Cryptsy. It happened, but you didn't cause it to happen. You always seem to struggle with causality.

100 clams or don't ask me for shit!    :\     ~am i being greedy?

Nobody is asking you for anything, and yes you're being greedy. Now go away please.

just-dice *poof!*



/\loser!!!

[cryyptc]

...>>>> The problem as I see it is that JD is the only CLAM service out there. <<<<....

yes the original idea of thinking you were getting away with something by creating your own token will not help you. You mustregister your gambling site as a money transmitter & gambling commission or you going to end up in court(in my honest opinion)

>> same ole story here it appears Just-dice will be going offline soon imho! ~good LUCK!!!! bwaahahaha

[ymod123]

is the price down because of the staking issue?

[almightyruler]

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

See above (and in several previous posts) the warnings about change addresses. If you use JD solely for digging it's possible you may not get access to all of the CLAM you're entitled to.

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.

[SuperClam]

1. There is no need to trust digging at JD because the wallet should be empty and retired prior to digging.

True.
Just as there is no need to trust digging with the client because the wallet should be empty and retired prior to digging.

2.  People trust digging on JD way more than some strange client that magically shifts through your wallets for coins or whatever else.

The import process is no more "magic" than electricity.  
It may appear to be so to those who have never seen it and do not understand it - but that does not make it so.

In fact, in order to get the CLAMS for you, JD has to create and broadcast a transaction with your key.
It creates and broadcasts this transaction with the exact same "strange client" you seem to dislike.
There is no difference.

Further, coins do not exist "in" a wallet.  
They exist as a tree of sign-able outputs on the chain.
There is no "sifting" as you put it.

CLAM CLIENT sketches 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 is not a purposely ignorant argument.

You trust dooglus;
he has earned that trust with us as well.

dooglus has repository access to the CLAM client code base as a full core developer.
dooglus has contributed multiple pull requests to the CLAM client code base.
If there was an emergency, dooglus could unilaterally repair the client code with no other individual present or consulted.

You can not reasonably argue both that the client is magical and sketchy and that dooglus is trustworthy.

Pick one.

3.  I don't see centralization as a problem atm.  JD puts all the work out, provides all the services, has the best chat and therefore gets its fair share of the network... honestly I feel like JD should have 80%-95% of the coins right now. In 6mo prior to JD CLAM got on Poloniex.... In 2 weeks after JD opened this door we have seen huge growth both price wise as well as adoption wise.  

No one dislikes Just-Dice.  
Just-Dice provides a solid trustworthy service.  
Just-Dice adds value and utility to CLAMS.

I have not heard any argument otherwise.

However, decentralization is fundamental to this project - and should be fundamental to every block chain implementation.

The individuals that maintain this project (dooglus can speak for himself, though I expect he agrees) involved in this project value decentralization and the attribute of trust-less-ness.

If you want a centralized system, go buy XRP by Ripple Labs.

Those who "put all the work out", as you so eloquently put it, see decentralization as a core aspect of block chain technology and the revolution that is the trust-less ledger.

And by "all the work" I include the dozens and dozens of developers over dozens and dozens of branches that have contributed selflessly over years and years.

If you don't agree with that, then you have stumbled into the wrong forum, I am afraid.


That said, I don't think anyone has suggested that this issue need be solved over-night.  
Nor have I seen anyone suggest that there should be an effort to "steal" anyone's "fair share".

I think it would be wise not to do anything that might appear to be taking away from JD holders in order to be "more fair" to other people. My best advice who don't like the fact that JD has >51% of the network stake would be to make CLAM services and encourage services that you trust to accept clam!

I think it would be wise not to veil your implied threats.
Judging by your insinuations of "fair share", "more fair", etc. you appear to fore-see some "phantom" conspiracy.

There is no, nor has there ever been any, intention of "getting you" or Just-Dice.
Nor do we intend to turn a blind-eye to other core values, such as fairness, in the pursuit of working through the 51% issue.

This problem may indeed simply work itself out as more CLAMS are claimed and more services offered.
Thus, your recommendation to encourage services to accept CLAMS is a good idea.

It is important, however, to note that this has nothing to do with what we "don't like".
It is in everyone's interest that CLAMS finds a way to become more stake decentralized; including your own.
Even if you do not realize it.

[xploited]

1. There is no need to trust digging at JD because the wallet should be empty and retired prior to digging.

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

3.  I don't see centralization as a problem atm.  JD puts all the work out, provides all the services, has the best chat and therefore gets its fair share of the network... honestly I feel like JD should have 80%-95% of the coins right now.

In 6mo prior to JD CLAM got on Poloniex.... In 2 weeks after JD opened this door we have seen huge growth both price wise as well as adoption wise.  

I think it would be wise not to do anything that might appear to be taking away from JD holders in order to be "more fair" to other people. My best advice who don't like the fact that JD has >51% of the network stake would be to make CLAM services and encourage services that you trust to accept clam!

Hell... maybe even lobby your local mining pool to start a CLAM pool!  Very little over head in them at least trying!  Do not be scared to start your own shit for fear that people won't trust you... everyone had to have their first trade somewhere!  I really really expect that the CLAM holders will at least give you a shot in trust, so fucking take the risk!

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

I disagree wholeheartedly with just about everything you said.  The client is significantly safer then a website you send your private keys to. dooglus himself trusted it and continues to use it. It is after all where those 200k+ clams are being held. In all the hundreds of wallets that been imported by now there's never been one case of anything nefarious and there never will be.  

You say you think its safe but it sketches you out?  how can you have it both ways.. The fact you haven't even downloaded the client shows me you have no care at all about clams, its just a game to you and you make your decisions on anything but fact or logic.

The price is certainly one aspect of any coin, but for the 6 months before the increase in adoption things were doing just fine and development continued along. For some there's more concern then just price, but where not all just day traders like yourself, some of us care and believe in the technology and are trying to improve it in some way. Its not very valuable if all the adopters are not actually interested in clams but just want to make a quick buck. Adoption is great but the wrong type of adoption is not.  

If all the investors at JD want to devest and drop all the coins in the market, so be it, I welcome that. At least the network would almost certainly be secure which it currently isn't.

Crypto currency should not be based on trust. The fact you think its all right speaks volume to your character and the reasons you do what you do. It does not matter how trustworthy the individual is in the slightest.  

Me and dooglus 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. If another service pops up and the problem resolves its self that would be wonderful but I would much rather have people dump coins into users who care about clams and will help secure the network themselfs at any price then have the JD stack become larger and larger making the issue worse.

There is no magic in anything we do with your wallet. Its quite simple what we've done. Its all encapsulated in a single function and is almost a complete direct copy of the standard LoadWallet function but we ignore all other data other private keys where thats the only important information.

All the times you've been on irc and talking to us I would have been more then happy to exactly explain what we did, why did you never ask?

[BayAreaCoins]

Crypto currency should not be based on trust.

Absolutely laughable.

Trust is everything.  Without trust there would be no Bitcoin.

People TRUST Coinbase to send their cash, people TRUST Bitstamp to send their cash, people TRUSTED SR to send their whatever, even with escrow... if there isn't any mutual trust with the person involved with the deal then the deal probably won't happen.

People TRUST banks, stocks and other investments more than they TRUST Bitcoin right now.  When this changes then we will see massive values spill into BTC.

For example with CLAM and trust.  

People TRUST JD and this brings value to the CLAM network as a whole.

If another service pops up and the problem resolves its self that would be wonderful but I would much rather have people dump coins into users who care about clams and will help secure the network themselfs at any price then have the JD stack become larger and larger making the issue worse.

If... lol k xploited.

If you want a centralized system, go buy XRP by Ripple Labs.

lol again.  Thanks for the free advice, but I'll stick with the "your best trade is your own trade" mindset  

Encouraging people to make CLAM better, safer and more easy to obtain without trusting even the wallet sniffing client would be more productive than encouraging people to buy Ripple.

I disagree wholeheartedly with just about everything you said.  The client is significantly safer then a website you send your private keys to.

The client is not "significantly" safer than Just-dice because everyone who is claiming via JD is doing it with empty keys.  There is no risk at all doing it via JD and the user has total control of the address put into the system... downloading the client you click a button and it goes through your shit for you... sorry if it upsets you that I think this is Sketchy and I'm sure it is frustrating for you as a coder, but for me as a person who can't code or read code it seems like a risk.  

That post was all feedback that I am getting from people via Forums, troll box and IRL.  Sorry it isn't what you two wanted to hear.

I want to see CLAM continue to grow and become decentralized naturally.

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.

but where not all just day traders like yourself,

Lol you're telling me something about me that I don't know about me because last I checked I got all my shit locked away staking. Far more profitable pwning blocks than day trading a uptrending market

[Vortex20000]

Crypto currency should not be based on trust.

Absolutely laughable.

Trust is everything.  Without trust there would be no Bitcoin.

People TRUST Coinbase to send their cash, people TRUST Bitstamp to send their cash, people TRUSTED SR to send their whatever, even with escrow... if there isn't any mutual trust with the person involved with the deal then the deal probably won't happen.

People TRUST banks, stocks and other investments more than they TRUST Bitcoin right now.  When this changes then we will see massive values spill into BTC.

For example with CLAM and trust.  

People TRUST JD and this brings value to the CLAM network as a whole.

If another service pops up and the problem resolves its self that would be wonderful but I would much rather have people dump coins into users who care about clams and will help secure the network themselfs at any price then have the JD stack become larger and larger making the issue worse.

If... lol k xploited.

If you want a centralized system, go buy XRP by Ripple Labs.

lol again.  Thanks for the free advice, but I'll stick with the "your best trade is your own trade" mindset  

Encouraging people to make CLAM better, safer and more easy to obtain without trusting even the wallet sniffing client would be more productive than encouraging people to buy Ripple.

I disagree wholeheartedly with just about everything you said.  The client is significantly safer then a website you send your private keys to.

The client is not "significantly" safer than Just-dice because everyone who is claiming via JD is doing it with empty keys.  There is no risk at all doing it via JD and the user has total control of the address put into the system... downloading the client you click a button and it goes through your shit for you... sorry if it upsets you that I think this is Sketchy and I'm sure it is frustrating for you as a coder, but for me as a person who can't code or read code it seems like a risk.  

That post was all feedback that I am getting from people via Forums, troll box and IRL.  Sorry it isn't what you two wanted to hear.

I want to see CLAM continue to grow and become decentralized naturally.

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.

but where not all just day traders like yourself,

Lol you're telling me something about me that I don't know about me because last I checked I got all my shit locked away staking. Far more profitable pwning blocks than day trading a uptrending market

All you do is transfer all the money out of your Bitcoin client to a temporary address on a different device, scan the wallet, delete wallet.dat, and then create a new wallet in the client and send the money back to yourself. I don't see how this is any riskier than using JD, other than the fact that disregarding the fact I trust xploited and the other coders, they might install malware on my computer. My keys are no biggie, xD.

[xploited]

Absolutely laughable.

Trust is everything.  Without trust there would be no Bitcoin.

People TRUST Coinbase to send their cash, people TRUST Bitstamp to send their cash, people TRUSTED SR to send their whatever, even with escrow... if there isn't any mutual trust with the person involved with the deal then the deal probably won't happen.

Were talking about the security of a block chain here, not if I trust a person or entity to give me a service that I paid for. There not the same thing. The entire principle behind bitcoin and the reason I see it as a novel idea is that I don't have to trust a human being to do the right thing. Not only is the code available for me to look though if I'm so inclined but the consensus mechanism and protocol built around consensus provide a verifiable way to transfer a store of value from one person to another without any human trust involved.

Other then in certain cases, and for PoS, staking more then 51% in a single place breaks the consensus mechanism and degrades us back into trusting a human to do the right thing.    

People TRUST JD and this brings value to the CLAM network as a whole.

You have me here. People do trust JD and it does bring value to the clam network as a whole, I would never argue that. Currently at the same time however its breaking the key part of the system that required no human trust to begin with.

If another service pops up and the problem resolves its self that would be wonderful but I would much rather have people dump coins into users who care about clams and will help secure the network themselfs at any price then have the JD stack become larger and larger making the issue worse.

If... lol k xploited.

My english is often poor so let me clarify. I have no doubt other services will pop up. I do have a small  amount of doubt that the other services will help the situation. I can't predict the future and neither can you. When other services start to exist the situation will be much more clear and I truly hope no interaction by anyone is required at all and the problem fixes itself.

This is something were going to have to wait to see how it unfolds.  

The client is not "significantly" safer than Just-dice because everyone who is claiming via JD is doing it with empty keys.  There is no risk at all doing it via JD and the user has total control of the address put into the system... downloading the client you click a button and it goes through your shit for you... sorry if it upsets you that I think this is Sketchy and I'm sure it is frustrating for you as a coder, but for me as a person who can't code or read code it seems like a risk.  

That post was all feedback that I am getting from people via Forums, troll box and IRL.  Sorry it isn't what you two wanted to hear.

This will be technical so you might not get it but I'll explain it anyways.  

First, significantly might be overplaying it but I still fully believe it is safer and could easily be made much more verifiable safe by the way I create the binarys. Let me explain why.  

The way I envisioned it working since launch date requires much less trust. You can't see dooglus's code on JD. He himself states he could be keeping the keys, or whatever with them so your left trusting a single person. A incredible trustworth person yes, but its still trusting a single point of failure.

So your not a coder you say, how can you possible trust the client!  well. let me explain to you the process I use to build the client.

I use gitian builder, which is a deterministic method to build it.  What that means is it can be built identically, the same way every time by more then just me using the code directly from the git repo. I provide my signature and the checksums of the client, lets say dooglus does the same and other trusted members of the community who can read and understand the code who trust the code is safe build it the same, sign it and all provide identical checksums.

This ensures the binary your downloading has been built directly from the code on the github repo and that multiple people verified the code in github was safe. This has ALWAYS been my end goal but it was not tell now there were people involved other then myself who were capable of compiling using gitian builder.

The new version of the client 1.4.3.2 with the autotools build system will include at the very least my gpg signature and at least one other. I would love to get dooglus to do it as well and the process will be much simplified in the new source code.

 because everyone who is claiming via JD is doing it with empty keys ....  and the user has total control of the address put into the system

I would also like to point out, since the very beginning we have constantly told people to move their funds into new wallets before importing. Your logic here is lost on me entirely. How is the client any less safe if this is done then if its done at JD?  Also, the user does not have total control of the addresses on the JD system. JD has total contol as the moment you dig the funds are swept into a JD wallet. dooglus has even posted the code that does that part of the process when you dig.

If JD were to go offline you would lose access, unlike your client which you actually will never lose access to baring your own person computer failure. Everything remains in your control in the client locally.  

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.

My name is actually Scott, xploited being a nicname I picked up when I was younger and interested in operational security. I'm pretty sure no sane parent would name there child xploited.  I should totally just change my nic to MostTrustedPersonInTheWorld and then the issue who be completely moot!

If you had bothered to ask me my name I would have glady given it to you, its not like i'm hiding.  

[ranlo]

The best solution IMO is for someone else to do the 2 most important things JD has done: (1) make it very easy for people to claim their unclaimed clams and (2) provide a staking pool.

Let's get real for a minute here. Exchanges take fees on each coin traded. This is where they make their money. Exchanges are then taking money from stake as well. This is where the staking should really be shared. We shouldn't have them just racking in whoknowshowmuch money on staking when they're already racking it in from fees. I think this needs to be the first priority: one that shares its stake with users. On every coin they support that uses PoS.

[BayAreaCoins]

The best solution IMO is for someone else to do the 2 most important things JD has done: (1) make it very easy for people to claim their unclaimed clams and (2) provide a staking pool.

Let's get real for a minute here. Exchanges take fees on each coin traded. This is where they make their money. Exchanges are then taking money from stake as well. This is where the staking should really be shared. We shouldn't have them just racking in whoknowshowmuch money on staking when they're already racking it in from fees. I think this needs to be the first priority: one that shares its stake with users. On every coin they support that uses PoS.

It would be nice to have a exchange that gave the users staked amount back to them.

I was speaking with the https://yacuna.com/ guys and I believe they are working on something! It is easier said than done I believe.

At the same time I support exchanges keeping the fees and the coins the earn off staking.  This is a great income for a exchange that is looking to expand and gives them a lot of incentive to list the coin.

Bottom line is they can run their company however they want and people looking to use a exchange are also free to choose who they want!

I'm sure in a month we will have exchanges of all different flavors.

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