Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 408. (Read 1151252 times)

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

---

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.

---

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.

---

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

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.

is the price down because of the staking issue?

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

just-dice *poof!*



/\loser!!!

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

fyi no one trusts you ! :\  ....just sayin'.

*everyone knows what you are trying to do! = looks like you are trying to distribute a bitcoin wallet stealer? lmfao

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

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!

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.

It's good to see people are discussing this issue. The fact that JD controls so much of the staking power is a potential problem. (I don't know any of you, but it is reassuring to read positive comments about dooglus / JD.)

I don't think putting age back in would really help. (If age is put back in, it definitely should be sublinear. There are a variety of sublinear options we could consider, including dooglus' log suggestion.)

The fact that there are still so many unclaimed clams means someone else could bring JD under 50% without people withdrawing clams from JD.

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.

(1) The JD dig feature seems to be more popular than the import wallet feature. There might be an even easier/more popular way to do this. People are afraid of giving up any of their private keys. Technically they only need to use the private key to sign a tx to send the buried clams to a new address. Maybe someone could find a way for people to easily sign such tx's (on the client side) in exchange for something. They should be able to do this without needing to download the clam client and the first 10000 blocks of the block chain.

(2) A staking pool would not require having a website at all. It could all be done on the blockchain in a provably fair way. I thought about trying to set something like this up myself, but none of you know me. I know I'm trustworthy and won't run away with your clams, but realistically you don't. Plus I wouldn't want to spend more than 1 or 2 hours a week on it. There's probably someone in the clams community trusted enough to run such a pool, or a clever "trustless" way to do it.

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

A good point.

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

That's a good point, which I hadn't previously considered. JD is most often going to be racing against itself (two blocks both able to stake in the same 16 second slot) and when it does inevitably one of the two blocks goes to waste.

We can roughly work out the odds of the case you're talking about happening, where someone stakes a block which JD then orphans by finding a block at the same time and then staking the next block too. I'm not sure about this math, so please point out any errors I make:

Let's say JD has 75% of the network weight. For JD to orphan a block staked by the 25% of the network it doesn't control, these things must all happen:

1) someone from the 25% of the network stakes a block
2) JD stakes a block in the same 16 second slot
3) JD stakes the next block

We want to know the odds of 2) and 3) happening given that 1) has happened.

The probability of anyone staking a block in a given 16 second time period is 16/60, since we target 1 minute blocks (this is wrong, but probably not too far from the truth). So the probability of JD staking a block in that time slot is 0.75*16/60. That's 2)

The probability of JD staking the next block is 0.75. That's 3)

The probability of 2) and 3) both happening is the product of their probabilities: 0.75*0.75*16/60 = 0.15

ie. there's a 15% chance that your block will be orphaned by JD if you're staking on your own. That's obviously far too high - and more importantly it's a little higher than the 10% commission JD charges for staking! Could someone with a significant holding confirm that they're seeing something like a 15% orphan rate?

If we change the granularity to 8 second slots from 16 seconds, the orphan rate halves (the 16 in the equation is replaced by an 8 and nothing else changes). It seems that the orphan rate is inversely proportional to the granularity.


That seems fair. The concern with using 'age' is that it removes the incentive for people to stake 24/7. If I can stake for an hour a day, use up all my saved up coin age and earn the same as if I was staking the whole day, why wouldn't I?

I guess we need to design the weight formula such that it rewards people for securing the network. I guess some kind of non-linear function would suffice: weight = value * log(age) : so doubling the age of a coin adds a fixed amount to its weight, rather than doubling its weight.

Edit: the point here being that having age be ignored as it currently is makes it hard for small holders to stake at all, having it count linearly makes it cost effective to only stake for a small percentage of the time, and so something in between seems optimal. y=log(x) is somewhere between y=0 and y=x (for x > 4 hours, at least...)


Me too. But in the mean time you'll have to make do with my ramblings.

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.

Age sounds nice, but [most of] JD's wallet's coins would also age with others, this maintaining the same relative chance to stake, would it not?

Again, no offense meant to JD or doog.

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.

If you have X% of the actively staking CLAMs, you have an X% chance of staking the next block.

JD doesn't change that fact.

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