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.
