i have a old doge wallet in my clamcoin wallet how can i clam it?

To confirm, users with Multibit, when exporting addresses, do show all of them, correct?

for someone that dont gamble in JD have a veryyyy TINYYY chance to stake my coin now...? 

The time granularity on the CLAM network is currently 16 seconds.
In this context, "most recent" simply means the entire period during which a given block would exist inside of that 16~ second window.

During any "race condition", an often occurrence given the large number of blocks the Just-Dice wallet stakes, the Just-Dice wallet indeed ignores and often eventually orphans the competing block.  This is not malicious, it is competitive and standard behavior.

The concern, however, is that given the Just-Dice wallet's propensity for staking consecutive blocks this might make it nearly impossible for other clients to win any "race condition".

---

There is no argument that Just-Dice adding CLAMS has increased interest, claim rate, and utility.
Further, there are few people I am aware of that are better trusted to possess such a position in a network.
That said, such control is trouble-some for any decentralized network.

An educated and informed discussion about the future of the CLAM network is warranted.
It very well might be that increased interest will eventually result in an expansion of the network such that this is a temporary issue.
We should all work to expand utility, awareness, and solo staking towards that end.

---

In that sentiment, I would like to start a discussion about the re-implementation of "Age" as a factor in the chance to stake.

In a system with "age", the above mentioned orphaned outputs would retain their favorable position and chance to stake.
In addition, the accrual of "age" might allow for small outputs and small holders (given the patience to wait) a chance to eventually stake.

---

I look forward to the commentary of those with specific and insightful knowledge.

Indeed.

Though it would allow users who have had their blocks orphaned by consecutive JD staking to at least retain the age and thus improved chance to stake in the future.

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.

Now, I think the idea of orphaning blocks should be ignored in relation to JD vs. elsewhere. The reason for this is because just like JD can orphan someone's block, someone else can orphan JD's. On the same token, the stake amount should be about equal over time. Take it like this:

Let's say JD has 75% and everyone else has 25%. We look at stakes:

JD
JD
JD
JD
JD
JD
OTHER
JD
JD
OTHER
OTHER
JD

What you'll see here is that JD locks in a lot in a row, leading to people feeling like they're being ripped off. Then they get a couple in a row, evening it out. Staking should be, over time, about equal to your percentage. The only difference being that instead of getting, say 0.0001 CLAM a day, you get the full CLAM when it hits.

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

Yes, as simple as that. JD is just giving an option to people having CLAM.

Thank you for your input!

---

I believe your reasoning is somewhat circular, however.

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.  

First, a user can not very well stake, and thus decentralize the network, without the client.  

Second, the vast majority of users do not understand how the protocol works - and thus, any individual key solution will almost certainly result in incomplete claims.  Even use of the command 'listunspent' will not produce the required private keys, as the pertinent keys may very well not contain an unspent output now; though they did at the time of the distribution snapshot.  The fact is that a miniscule portion of the users I have spoken with understand that "change" addresses even exist, let alone the process a client goes through to produce the tree of outputs one finds on the chain.

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.  Even in the case of Just-Dice, it is impossible to argue from a security stand-point, given that the same individual you trust, dooglus, has thoroughly reviewed and contributed to the code of the client.  Therefore, a great deal of that "trust" must exist in both methods of claiming CLAMS.  The difference being that claiming in the client does not involve the private keys ever leaving your personal system.  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.

Fourth, the process of entering the console and utilizing commands to sally-forth individual private keys, which you hope happen to have had control of the outputs on May 12th, can hardly be considered "easier" (though it could indeed be faster, considering the requirement to sync - though individually importing keys is likely NOT faster when more than a handful of keys are concerned) than the three clicks required to click "Import Wallet".

---

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.  

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.

The only way it would make sense to "accrue" age would be if a user had a single output, which had just staked, and therefore they were not even close to solving a block; and thus decided to forgo the minimal chance of solving a block in favor of not staking.  However, even with a handful of staggered outputs, not staking the client consistently would result in drastically reduced chance to stake, and therefore drastically reduced reward, as surely at least one of the outputs at any given time is near enough to accruing enough age to have at least some chance to stake.

Is age a silver bullet?  
No, absolutely not.  It doesn't solve the crux of the problem at all.

Would competition in the realm of stake-pooling (something entirely un-heard of before CLAMS) be beneficial?
Yes.

However, arguing that it makes any logical sense at all for the average user to claim via any method other than the client simply doesn't hold weight in my opinion.  

The only reasonable argument, in that regard, is for users who KNOW they have all of their keys, have a reasonably small number of keys, and desire the additional speed of not having to sync the client.

/\gfys scammers; see how far you get with that attitude i want my 200 clams as promised

no worries we will just hardfork CLAMS ... sit back and enjoy the ride lmao