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

I could be over thinking this greatly and do not in anyway understand how the Clam System works,
but maybe Whale Digger knows doing it this way (backwards) discloses what the total amount to be dug will be,
as well as when the digging will end, so that the market and users don't become totally disillusioned with CLAM?

It is like a controlled dig that is stabilizing, versus the random dig where no one knows how bad it could get.

I could be over thinking this greatly and do not in anyway understand how the Clam System works,
but maybe Whale Digger knows doing it this way (backwards) discloses what the total amount to be dug will be,
as well as when the digging will end, so that the market and users don't become totally disillusioned with CLAM?

It is like a controlled dig that is stabilizing, versus the random dig where no one knows how bad it could get.

But as you said, we can only guess, I guess.
Thanks for your response Dooglus.

Yes.
We can only guess at his reasons. I don't see what advantage it gives him to disclose his holdings in this way, so maybe it's accidental.

when you say that "Our digger is working backwards",
you mean Whale Digger is entering the btc privatekeys backwards through clam block time?

Why isn't the digging random? Why would there be a predictable digging of clams going backwards?
Why doesn't it jump back and forth all over?

The point of the chart was to show the effect of the ongoing large dig. Our digger is working backwards through the blocks, and is in the mid 8000's at the moment. He has many CLAMs still to dig, as shown by the chart.

thanks for the heads up on that one. I will see if I can get those accounted properly.

Apart from dumping on Poloniex. Do you think the digger is investing in JD?
Maybe Doog can answer that one?

We were playing around this morning with "timelocked" outputs.

Here's one, and it displays wrongly in your block explorer:

  http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=9cf10e3816012c8ff6a658d59ae34897476a3489be50b55934bc67132f0f450a

When I spent it, it showed up correctly:

  http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=9ae57b97316ed7b725624cb2a64612b65e95797cc7a954d7e0b255318a89c4dd

Awesome to see the numbers finally synced up as they should be! The problem was my code was assuiming that if the tx was coinstake, that the net difference in balance from that tx was the minted amount. The JD staking wallet has those transactions that send outputs to other wallets in the coinstake tx, so that created a negative mint Just switched that out and indexed it with pindex->nMint instead which should be accurate.

1) I'll fix this, its actually a variable populated for different coin's page with the coin name and 'd' on the end I'll make an exception for clams in there.

2) I hid the burn address for clams. This is what is causing this row count to be off. I can either a) show the burn address or b) fix the row count.  Although the burn address coins are gone, some users might be interested in seeing the address. Thoughts?

3) In my context it is 'amount in' would mean amount deposited into the address, and 'amount out' means amount taken out of the address. A bit different then inputs/outputs of bitcoin protocol, maybe I should word it better to be more clear (maybe withdraw/deposit or credit/debit). So for your example, 19 clams sent out from the wallet into the coinstake tx, 20 clams sent back into the wallet in the coinstake tx.

PS - I haven't checked this, but I do believe the JD staking address has the most transactions out of all the addresses I have indexed on my site. Quite the accomplishment

So overall about 5% of total possible clams have been claimed? That's interesting! Some of the big exchanges should take notice at some point if clam remains valuable. I imagine Karpeles would be interested in a way to repay his creditors. If he had access to any private keys that is...

Here's a chart showing what percentage of the CLAMs given out in each distribution block have moved so far:

https://i.imgur.com/JKI9R70.png

Awesome to see the numbers finally synced up as they should be! The problem was my code was assuiming that if the tx was coinstake, that the net difference in balance from that tx was the minted amount. The JD staking wallet has those transactions that send outputs to other wallets in the coinstake tx, so that created a negative mint Just switched that out and indexed it with pindex->nMint instead which should be accurate.
1) I'll fix this, its actually a variable populated for different coin's page with the coin name and 'd' on the end I'll make an exception for clams in there.
2) I hid the burn address for clams. This is what is causing this row count to be off. I can either a) show the burn address or b) fix the row count.  Although the burn address coins are gone, some users might be interested in seeing the address. Thoughts?
3) In my context it is 'amount in' would mean amount deposited into the address, and 'amount out' means amount taken out of the address. A bit different then inputs/outputs of bitcoin protocol, maybe I should word it better to be more clear (maybe withdraw/deposit or credit/debit). So for your example, 19 clams sent out from the wallet into the coinstake tx, 20 clams sent back into the wallet in the coinstake tx.
PS - I haven't checked this, but I do believe the JD staking address has the most transactions out of all the addresses I have indexed on my site. Quite the accomplishment

Great news!

I'm happy to see the chart for this address again - it was beautiful last time I saw it, shortly before it became too big to plot.

Transaction Count   55679
Balance   535,799.154328
Minted   55,695.532970

I believe that every "deposit" into that address was the result of staking, and so the transaction count should be the same as the number of stakes. It looks about right:

minted / tx_count = 55695.532970 / 55679 = 1.00029693

1.0003 seems about right for the average block reward size

Edit: there's a typo on your address claim page:

"For daemons: ./clamsd signmessage addressgoeshere nametosignfor"

It's "clamd", not "clamsd".

Edit2: your row count is off by one:

http://www.presstab.pw/phpexplorer/CLAM/richlist.php?count=5 only shows 4 addresses, not 5.

Edit3: it looks like the 'amount in' and 'amount out' columns are labelled wrongly on the address.php page. I see staking transactions with Amount In=20, Amount Out=19. The output should be greater than the input surely?

I think I was finally able to fix the error in my block explorer showing the JustDice wallet 'special' coinstake tx's as a negative mint. If anyone sees any issues with balances, please let me know I am still working on getting the charts to display for very large transaction histories, hopefully have that worked out soon too.

http://www.presstab.pw/phpexplorer/CLAM/richlist.php

I don't think this point was fully addressed in SuperClam's answer.

Note that the CLAM client is open source. Any limit we put in the client could easily be changed or removed.

There is no network consensus rule about "digs per client per day", and there cannot be, because it is impossible to tell clients apart from each other.

To spend an initial-distribution output all you need to do is sign a transaction that spends it. Each initial-distrubition output was created using the BTC (or LTC, or DOGE) address' public key, and so to spend it you need the corresponding private key.

Any exploit that is able to spend other people's initial-distribution CLAMs on the CLAM blockchain would also be able to spend their BTC on the BTC blockchain, since exactly the same mechanism is used in both cases.


Yesterday I spent some time looking at the BTC addresses which were "dug" recently. I fed them into https://www.walletexplorer.com/ which calls itself a "Bitcoin block explorer with address grouping and wallet labeling". The idea is that for each BTC address you give it, it tells you which site's hot wallet the address is in.

It was unable to identify the wallet of very many of the dug addresses I tried. It was only able to identify the wallet of about 1% of the addresses I looked up, and in every case it identified them as being in the BetVIP.com wallet. BetVIP appears to have launched in March 2014 and shut down in June 2015. Here's a video of its founder talking in April 2015, claiming (at 0:30) that it officially launched in June 2014. I guess it's possible that their hot wallet was stolen by or sold to the digger, or that someone from BetVIP is the digger.

It seems unlikely that a relatively unknown site that launched just 2 months before (or one month after) the CLAM snapshot could have received 3% of the CLAM distribution, and so it remains a mystery where the bulk of the addresses have come from.

I'm not sure how accurate or complete walletexplorer.com is, but I would expect it to have shown up at least one hit on the MtGox or BTC-e wallets if it was them who were digging...