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

I saw this pop up on the Clamcoin reddit today.

http://www.reddit.com/r/Clamcoin/comments/3a9w9y/clamstakernet_the_easiest_way_to_stake_your_clams/

Hopefully they set up a ref system

I haven't tested them yet.

EDIT:  I don't even see where their site shows the fees... would proceed with care!

Don't get me wrong - I have nothing against earning extra commission. I wouldn't want to burn it. Increasing the commission rate could well decrease the commission I get to take - if increasing it from 10% to 20% causes the bankroll to more than halve, I end up with less commission than I am currently taking. Burning half of it in that instance would make no sense at all.

I hear on IRC that there will be a new staking pool released soon with a 5% fee. If that takes half the JD bankroll then our 51% woes are over.

An interesting idea, to be sure.

However, I don't particularly agree with a private service being expected to change it's fee structure - or anything else for that matter.

Treating symptoms, as opposed to solving problems, rarely provides the results you really want.

I would much prefer some pledges of bounty toward an implementation like p2pool; accompanied by a feasibility study as to the possibility and results of implementing it.

---

I think this is an important facet of the conversation.
If it doesn't make economic sense - the idea is DOA.

I seem to remember some conversation some time ago about making p2pool mandatory, or at least de-facto standard, for BTC.

CLAM is in a unique position where the number of stakeholders is relatively small in comparison.
If p2pool was built-in to the client and the mandatory process of staking, everyone would be on an even playing field - regardless of potential economic issues.

Just an idea, and another topic for a more in-depth discussion and review of the idea.

I ended up restarting with a virgin db and a bootstrap.dat, and the same thing happened again, but almost immediately...

ProcessBlock: ORPHAN BLOCK 394, prev=150bbc3b26c30450c72982a4ddd76849f27772f789d4b5547cae84deb35c6916
SetBestChain: new best=ee238d43767cae1369976b95d725a0fefcb43c38eb472fab85bb4518ced9f5e8  height=56532  trust=181383289202  blocktrust=1783141  date=08/05/14 12:33:40
ProcessBlock: ACCEPTED
ProcessBlock: ORPHAN BLOCK 395, prev=1f04a53561e711ed5db2bd3d161a038aa7f537ec203cac8097dbcbe71ae60d21
ProcessBlock: ORPHAN BLOCK 396, prev=0c86aef87def03c22d332206bfbc3076b7205d24fe96462ce46fd1cdbecff6cc
ProcessBlock: ORPHAN BLOCK 397, prev=d7ab32165d83bbdb17706272736e8bffff63dfcd85e497fd30900137d247e43e
ERROR: CheckProofOfStake() : VerifySignature failed on coinstake 010c7653afd5e0d62dee0b077285749ac5e6bbd2e35a6091c333dee69778d4b9


Client is stuck at block 56532, rejected transaction 010c7653afd5e0d62dee0b077285749ac5e6bbd2e35a6091c333dee69778d4b9 is from block 56533, so it never accepts the block.

Given that it's not failing at a consistent spot I'm starting to wonder if there's some obscure bug with my OS/hardware (it's an Odroid C1/ARM CPU so probably not so well tested) or maybe a hardware issue.

It's important to note that transaction 010c7653afd5e0d62dee0b077285749ac5e6bbd2e35a6091c333dee69778d4b9 is repeatedly rejected (1679 times in this instance). Is this cached locally, or is it rejecting a "fresh" block from a peer each time? This could help determine whether it's a random bit flip that gets committed to disk, dooming that block forever, or there's some other reason it is repeatedly failing verification.

I was going to suggest sending the excess to something charitable, but that could become complicated.

How about something more simple: send anything over your 10% fee to a provably unspendable address. That way you're still reducing the chances of CLAM being controlled by JD, but you're not profiting from it.

Thanks man.  CLAM is surprisingly stable.  I'd say that's a good thing for newish crypto to have been able to establish a price point and hold it.  I don't think I've seen that from many (any?) altcoins other than LTC.

"I've been mining for 24 hours and still haven't got anything... what's wrong?!" *Check their stats and their miner is like in Romania, bounced off Mars and then jumps the J train to the mining pool*  Mind you that was with DOGE lol....

We had some issues with the system "eating" our fees.  It was really really strange.

I am pretty sure one of the complaints was that the system was PPLNS - but don't quote me.

'
I actually have some experience with this from Nix and I's DOGE pool (LocalMiners.com was P2Pool)

The issue with running a P2Pool DOGE pool compared to running a traditional "communist" pool is that people expect to get paid for nothing.  People really like the fact that they get something from the communist pools every block even if their miners aren't really helping the pool.  P2Pool was really good for the miners who have their shit together and they earn more because they aren't paying leaches.

A P2Pool for PoS seems like it would be much easier because there isn't all the other variables in the mining process (miner in China on a USA pool ect.)

It would decentralize CLAM over night.

This would be a really good service for CLAM to be on.  They said they are about to add some new coins.  If anyone has a few seconds to make a post over there it would be appreciated.

https://bitcointalksearch.org/topic/m.11653533

That is a good idea. I guess p2pool could work for PoS just as well as for PoW.

I've not looked at the Bitcoin p2pool stuff for a year or more, but from what I remember it used to give relatively poor returns compared to mining at a centralised pool. I don't remember why, or even if anyone ever figured out why. Did it ever become economically competitive with the centralised pools?

Idea... perhaps you could use the increased JD fees in order for you to hold the bounty on a P2Pool style PoS pool.

While bullshitting in the CLAM IRC today that seemed to be the least invasive decentralization option on the plate, but it would be extremely difficult and would need a solid backing from some whale service .  I believe that would solve the orphaning problem as well.

Increasing fees is still another "I hope they decentralize" tactic.  I think it might boil down to forcing her to become decentralized.  I do not think it would hurt CLAM though and I actually believe it might help CLAMS in more way than one. 

Since December:



The last week:



Right now:

0.00574000 BTC

If you want to add CLAMs to your service, just add them. There's no need to ask anyone's permission. And votes are easily manipulated.

I charge a hefty 10% fee for staking. That leaves lots of room for competition. I keep hearing rumours of competing staking pools opening, but never see anything come of it.

I could continually increase JD's staking fees until it has less than 50% of the CLAMs, but I suspect that would be seen as me trying to grab more CLAMs for myself. How could such a thing work? Maybe the fee goes up 1% each day at midnight if we have >50% of all active CLAMs, and down by 1% if we have less than 40%, and we just leave it to change day by day. Eventually (after less than a month, I guess) we would have less than half the CLAMs - or we would be taking 40% of all stakes. Does that seem more fair? It would be an interesting experiment for sure.


You're almost certainly right.


I've often wondered how bad it is for others trying to stake so I finally looked around for some data. Checking http://blocktree.io/richlist/CLAM for the biggest address that's staking, I found this guy. The last non-staking transaction was 13 days ago. Since then it has staked 111 times:

111 blocks in 13 days with 4400 balance : 111 / 13.0 / 4400 = 0.00194 blocks per day per clam

JD has 548k clams and stakes 1200 blocks per day : 1200 / 548e3 = 0.00218 blocks per day per clam

So it seems like JD stakes about 10% more efficiently. Or maybe 13 days isn't long enough to reduce the effects of variance.

Here are the day-by-day staking stats for that address. (date, block count, block numbers)

@BayAreaCoins, I don't mean this to be an insult, but I think that the eventual fate of CLAM is to be basically a Just-Dice coin. I'm really not surprised that JD is basically owning the coin.  FWIW, Clams could have done a lot worse when it comes to the /dev/null of history that most altcoins end up in real fast.



Hehe, I'm going to go ahead and assume that if you were in the business of maliciously stealing everyone's clams left and right that I would have heard something about it by now. Anyway, I do appreciate this functionality, and thanks for pointing out that about not having to wait on a blockchain sync.  I may give this a try this evening.  Take my final 4.6 clams and decide what to do with 'em.

Voting can be a very dangerous thing.  Voting is OK until you vote in a bad apple and at that point someone generally gets fucked.


I don't mean you actually giving out private keys.  I think of all these coins like little keys to wealth or power.  When someone sends you their BTC, DOGE or CLAM they are trusting you with a drop box key.

I know you are a fair guy and go to great lengths to make sure games/coins are fair.  At this point would you say CLAM is fair to the average staker outside Just-Dice?  If the game isn't fair why would anyone try to play it?  

I'm scared Just-Dice is actually hurting CLAMS growth by being so strong % wise.  If Bitcoin had all the mining power on one pool in 2010 would Bitcoin be where Bitcoin is today?  I don't believe so.



E was concerning to forks.  I'm sure consensus would be reached, but it's comforting to at least know you have a hand in it.

F was in regards to if you did put a cap on investing at Just-Dice.  Traditional mining pools stop miners from joining all the time in order to keep Bitcoin decentralized (or at least the appearance of decentralization.)

Let's say the total OS (outstanding shares) of CLAMS is 1,000,000 CLAMS.  This means the max the JD system would allow invested is 499,999 coins.  I believe this would lead to:

1.  A strong JD account selling market.  If someone has 10k CLAMS invested and the site isn't accepting investments any more due to trying to avoid centralization... I would imagine someone would pay 11k CLAMS for the account.
2.  Decentralization of CLAMS
3.  Encouragement for people to get people to dig more CLAMS (this will drastically increase the market cap of CLAMS)
4.  Encourage people to stake on their own because their blocks they find won't be orphaned by possibly unfair staking
5.  Encourage people to create CLAM services because people can't and won't use their CLAMS for just one thing if they physically can't.  If there was one Bitcoin pool in 2010 with 80% of all the mining power that caused other miners to either join them or get their shit orphaned into the middle of next week... I imagine not many other mining pools would be popping up!  I think that is what we are seeing here as well... I could be wrong.

Please come visit us in IRC #clams.

We could use your currently stuck client to help us debug the issue.

   I think he was using a metaphor.  I believe he was referring to your offering the offsite option to try and encourage more offsite staking.  


edit: and that was a great explanation on forking a coin...

That's OK unless he steals the coins. At that point you can't change your decision on who to trust with your wealth.


I'm not sure what you're referring to. I don't think I ever gave a private key to anyone. I did refund a bunch of Bitcoin to JD investors, but that was done with regular transactions, from my private key to theirs.


Are you talking about a JD fork of CLAMs here? In a hypothetical* scenario where the CLAM developers do something crazy that is broadly disliked (setting the transaction fee to 100 CLAMs per kB for instance) anyone is able to fork the chain. You don't need 75% of the active coins to do that. You can say "I'm not switching to the new version; I'm going to keep running the current version with the low fees". You then make a transaction that the new official expensive version won't accept, wait for it to be staked by your own client, then add a checkpoint for the block that staked it. Distribute your version with the checkpoint to anyone who agrees with you, call it "BayCoin" or whatever, and you've forked the network. It will take a while for the difficulty to adjust downwards if you and your supporters only have a small percentage of the network, but it will happen eventually. So in that sense *everyone* can veto changes. Having 75% of the active coins just means that the difficulty will adjust more quickly.

* It's interesting to think about, but would be horrible to actually do. Like the Bitcoin/Gavincoin thing - we hope consensus is reached without a contentious hard fork.