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

Thanks, Dooglus, make now running

I have the richlist updating every 12 hours at the moment, so it should be temporary patch for the problem until I can redesign a bit of my code. I updated the richlist claim name length to display more text (and prevent user from recording a name that will be cutoff due to max size), and am not displaying the burn address... if its not part of the supply should it be included on a richlist? Up to you guys. Will play around with some of the other code tomorrow.

I figured you wanted feedback, so I gave it. I'm not good at sugar-coating it. I think your tool is good, and found a bunch of possible ways to improve it. That's all.

I figure with the rich-list you can keep a database table of address balances, and update it each time a new block is added to or removed from the chain. Then you can query it very quickly, esp. if there's an index on the balance column. See how blocktree does it - they have it always up to date and quick to query.

Maybe I worded my post poorly, I do very much appreciate all the feedback. It has me searching through my code at this very moment seeing how I can make it more efficient, as well as adjust some of the settings to display the information more properly. For example I have already customized the richlist code (other coins it is fine to calculate on the fly because the address count is not quite so high, and people really do like to see themselves move up this list in real time), the transaction input number so you can see exactly which input is being spent, address zoom, and a few other things as well. Its a work in progress and I do hope to be able to make as many people and coin communities as happy with the data analysis as possible. One thing that seriously has me bothered is the address that is sending outputs on coinstake transactions... I will need to perhaps reindex my db to deal with that.

Feel free to shout out any more bugs or suggestions.

dooglus is "special"

Believe it or not; that post was a compliment.

Notice the:

---

He doesn't say that very often

Definitely still is a lot of work to do. Built it from the ground up, and only really been live for about two weeks. Definitely not made specifically for clams and still yet to be determined how much time I will spend on applications that are specific to one coin. The richlist I do need to work over it queries it live and for clams which has a shit load of addresses it doesn't work well, I will go to a list that updates a few times a day. Annual stake rate shows the Apr of the stake. Small inputs on clams are staking for an obsurd return on value that is why this spike is so large, might see if canvas js has some settings I can tweak in this regard... But however it is in fact that rate. My indexing does not index per output and doing such for clams would not exactly be good for my resources, and adding this to my server out of my own pocket I am not exactly thrilled to add more resources to it.

I will look into the rewards that you think are out of whack and see what I can figure out there. Still plenty of additional features and analysis that I would love to add over the next few weeks.

That's quite impressive. Here are my initial observations:

I like that there are charts of address balances over time. Would like to be able to set the range of the x-axis (maybe just links for last day, last week, last month, etc. would do for starters.

When I look here, the 'total change' column is missing the transaction fees. Block rewards are 1 CLAM plus fees, and so are often 1.0001, 1.0002, etc. That's getting rounded to just '1'.

The transaction view doesn't tell me whether each output is spent or not. It would be nice to have that information, along with a link to the spending transaction for each spent output.

This address shows large amounts being 'minted'. Each block only mints around 1 CLAM, but you're showing it minting 9 through 16 CLAMs per transaction.

The rich list takes quite a while to appear. Maybe you're computing it every time the page is hit rather than serving cached results.

The 'claim' feature is nice, but the column displaying the claimed name is too narrow to display much text.

The 2nd biggest address is the CLAM burn address, and shouldn't counted as part of the money supply. Those coins aren't spendable. cf. http://blocktree.io/richlist/CLAM

You might want to remove 'PoW difficulty' from the charts page - CLAM doesn't have any PoW and hasn't since before it was launched to the public.

The PoS difficulty looks better on a log y-axis chart, because at some point the difficulty rose by a factor of a million or so. On a linear y-axis chart all history before that time appears as if the difficulty was zero.

The 'weight' chart would be better relabelled as 'weight spent'. I was hoping for a chart of the network staking weight when I saw "weight", but didn't get it.

The 'coin supply' chart would be better if it plotted the 'active supply' number (see clamd getinfo / clamd getblock). There are 15 million CLAMs still waiting to be claimed, the majority of which will probably never be claimed. The active supply is a more interesting number, since it only counts coins that have ever moved.

It's hard to tell what 'Annual Stake Rate' chart is showing. A splke back around block 75k makes the scale too small for any recent blocks to show up at all. When I zoom in on the chart, the y-axis doesn't rescale. It would be useful if it did.

I added CLAM to my explorer/PoS analyzing site. clam.presstab.pw (once it propogates) or http://www.presstab.pw/phpexplorer/CLAM/

Let me know any feedback. Took some custimization to get clams working

LOL

They got that future shit I suppose

    Their staking in the future.  Notice the last update July 2015.  

edit: added big smile to show I'm just messing around...

Will reference this post for the Reddit ppl.

Thanks Doog.

I would be very careful with that service. I only just heard of it, but some things just don't add up.

1) They claim to be staking 24k CLAMs:



but the CLAM rich-list doesn't show any address that could be theirs unless they have split the 24k into lots of different addresses:



The screenshot lists their 'staking address', but that address has never staked:



They also claim that they staked 287 times but made just 5.75 CLAMs profit. Since each stake makes at least 1 CLAM, this is clearly wrong.

It's hard to tell whether they're making up numbers and pretending to be staking, or whether they just aren't very good at presenting information. Either way, be careful.

I would expect at least a proper proof of solvency before depositing anything to such a site.

Edit: I tried visiting the site from multiple browsers, from different IP addresses, in incognito mode. Every time it told me the same: "Your Unique ID: C3438188-38". Why are all the unique ID's the same?

Edit2:


Edit3: everyone's deposit address is the same too...


Pretty sure this is nothing but a scam.

Cut off new investments until JD is <51% of the staking power.  Grandfather current investors in.  That way you aren't kicking anyone out of "Club Dooglus".

It won't fix the decentralization this week, but it will fix it down the road.

There are a number of positives that come from this as well.  People will encourage people to dig their clams (similar to getting ppl to mine DOGE.)  People can still buy/sell JD accounts that are already invested ect. Just another layer of value for JD + it in my heart of hearts Dooglus I think it is the right thing to do.  

I use libdb5.3++-dev. It complains that the wallet.dat won't be compatible with those from official builds, but I don't care about that.

Edit: and I think I had to run:

  ./configure --with-incompatible-bdb

to tell it that I don't care.

Thanks. I was having a hard time remembering how it worked, and figured writing it up would help clarify it for myself and for others. I can't promise what I wrote is still how it works, but I'm guessing it's mostly correct.


I guess p2pool would improve things, as follows:

Currently if you are staking 10 CLAMs, you can expect to stake 1 CLAM every 50 days or so. If there are 100 people staking 10 CLAMs each, they each get that same very irregular reward for staking.

With p2pool, those 100 people can expect to get the same return, but with much lower variance. They each get to stake 0.01 CLAM about twice per day. Their expectation is the same (still 14% lost due to orphans) but their income is much steadier.

If that steadier reward stream makes it attractive enough for enough people to leave JD and join p2pool on their own, then the orphan rate drops, and each individual's expectation also increases.

So we have an unfortunate situation that if everyone leaves JD, it's better for everyone, but if only a few leave, it's better for the ones who stay. Classic Prisoner's Dilemma stuff.

Thats an excellent explanation of how p2pool works. 

I'm working hard to find a flaw in your logic as I was hopeful p2pool would help with these problems.. but i dont see any. 

It has been years since I last looked at p2pool, but from what I remember, it works like this:


Centralised pools: Mining is hard. You need to find a block which hashes less than a very low target, T. Traditional mining pools allow people to work together by giving them easier work to do: the members of the pool are asked to find blocks which hash to less than a higher target, 1000*T (say). This is 1000 times easier, and so happens about 1000 times more often than the pool finds blocks. Each time a member solves one of these easier blocks, it reports it to the pool as proof that it is trying. The pool makes sure that the reward is going to the pool's addresses, counts up how many of these easy blocks (called 'shares') each member solves, and when someone does eventually solve a real block the pool splits the reward to the members in some way based on their history.

Problem: the centralised pools get big, and end up threatening the network. The pools decide which transactions to include in the blocks which gives the pool operator the power to double spend. The members also have to trust that they actually will distribute the rewards fairly, and so on. All the usual problems with centralisation.

p2pool: In the same way that Bitcoin decentralised currency by the use of a blockchain, p2pool does the same for mining pools. Instead of a central mining pool tracking how many shares each miner has accumulated, there is a blockchain which tracks it. It's entirely separate from the Bitcoin blockchain. A new block is added to the chain each time a miner solves a share. Each miner checks the last N blocks in the sharechain, calculates how much of the block reward should go to each miner, and sets the coinbase accordingly. When a miner receives a new share from a peer, he will check the coinbase of the share to make sure that the peer is distributing the coins correctly. If so, the share will be added to the chain. Eventually one of the shares will also be an actual Bitcoin block, and once broadcast all the miners who solved any of the last N shares will be paid.


I don't see anything there that couldn't be made to work with CLAM. Some thoughts:

1) p2pool removes the need for a central pool by having the coinbase in each share pay out the block reward to all the contributing miners. CLAM has a rule that staking transactions must pay out to the same address as they come from. But upon further investigation this is only enforced for the first output. It's possible to make this kind of staking transaction which pays to two different addresses. And so it should be possible to pay to as many addresses as we like, so long as each miner pays themselves first.

2) The whole reason p2pool is being discussed with respect to CLAM is that it is thought to be a way of decentralising things, and getting rid of the "orphan" problem. The orphan problem is that JD orphans a lot of other people's staked blocks. JD has 75% of the staking weight, and there are only 4 chances to stake per minute (due to the 16 second granularity). When a non-JD staker finds a block, there's a 1/4 * 75% = 3/16 chance that JD finds a block in the same timeslot. And there's a 75% chance that JD will find the next block too. In the event that two stakers find a block in the same timeslot, each miner considers their own block to be the valid one, and attempts to stake the next block on top of it, so if JD finds the next block it orphans the other miner's block. So that's a 9/64 chance that any non-JD block is orphaned by JD. That's 14%.

That's too many, and so can p2pool help fix that? I'm not sure, but it seems to me that instead of orphaning 14% of blocks on the CLAM blockchain, JD will orphan 14% of shares on the sharechain. And the end result will be the same.

Is that right? If so, is this even worth pursuing?

I don't know why the arrow keys weren't working for me.  Maybe the wrong part of the window was in focus or something.  Anyway, I decided to clone the repo from git and build it.  I run "./autogen.sh && ./configure" and I note that I need the header files for libdb.    I'm on debian jessie and I'm looking at the build instructions in doc/build-unix.md, it says to add oldstable main to my repos, so I add this:


But I'm not finding the libdb packages which the readme says I should find:


So, obviously I could look for the header for the berkeley db somewhere else, and I can do this, no problem.  I just thought I'd update you guys about the instructions in your readme, maybe they're not so current (or maybe I'm doing something wrong, hehe).

Cheers

The official website is a mess.
Currently working on pulling in some API stuff to make the new web site more useful, before replacing it.

That said, arrow keys seem to work fine for me on Firefox.

Guys, there's a problem with the main clam website.  I go to the OP of this thread, I click on official website looking to download the client,  I see gian pictures oceany things.  15 seconds later, I figure out that there's a hidden nav-bar on the right of the page.  Okay, I open the nav bar,  I see "download clamclient"  I think "yes!".  I click, I see a giant picture of an shipping vessel.  I see text above the vessel "download clamclient", but this is not a link.  I start pressing arrow keys, maybe there's a link below the tanker pic---nothing moves.  I find many many many social media links about clamclient in the in nav-bar, still haven't found where to wget a tar of the client or the source.  I'm not stupid.  I'm using firefox.  Can I get the text version of this page or something?

EDIT: ohmygod, I finally found it.  If i rehide the nav bar on the right, there's like 4 pixel scrollbar that allows the page to scroll down.  Why didn't my arrow keys work?  I'm leaving this post up in case whoever runs the clam site considers this useful feedback about my experience with the website.  I found many large and beautiful pics (which was cool), but it was hard to find any text or links (which was annoying).