[ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin"

[mrsalve]

I have calculated that the return as today is around 0,18% per day (even less if you consider the 8 hours you have to wait after you get a block). You have to keep yor wallet open and online 24/7. With hashnest, for example I can get from 0.3% to 0.35%, if I buy some s5 ghs without the burden of keeping my pc on all the time.
I like your project and how you developed the proof of working stake, but honestly 0.18% that will get lower and lower over time doesn't sounds a good deal to me when the dear old BTCBTC give me almost the double.
Maybe I lost something or I didn't get something.

Some things you may have missed:

1) With hashnest you are trusting them with your money. They could turn out to be a scam and you end up with nothing. With CLAM you can keep control of your coins at all times. You can run the staking locally so that nobody can steal your coins.

2) With hashnest there is presumably a sunk cost. After buying the "s5 ghs" you have presumably made a loss, which it will take you some time to break even from. With CLAM there is no sunk cost, other than the exchange fee (typically 0.2%). It's possible to buy CLAM one day, stake for a day, then sell them again and break even. Is that possible with hashnest?

Having said that, I think you're probably right at the moment. CLAM isn't a good investment while there is someone able to dig up huge amounts of CLAM. He's slower his digging over the last few days, but that doesn't change the fact that he has large amounts of CLAM he can dump on the market whenever he likes. Maybe look again after Christmas, by which time he may have finished his long slow dump.

Thank you for your reply.

About hashnest and bitmain the leader asic bitcoin miner hardware manufaturer, think that they could be scammer is very hard to believe (bitmain has an hero member account with positive trust like you), but hey everything could be. Could be that the CLAMs coin is a scam as well, who knows? Never say never!

About the dig actor, pardon my ignorance but what is "digging"? Can I dig as well?

Thank you again

Yes, you can dig as well if ... read here: http://clamclient.com/start/getting-started/

[1714162949]

1714162949

[1714162949]

1714162949

[SuperClam]

I have calculated that the return as today is around 0,18% per day (even less if you consider the 8 hours you have to wait after you get a block). You have to keep yor wallet open and online 24/7. With hashnest, for example I can get from 0.3% to 0.35%, if I buy some s5 ghs without the burden of keeping my pc on all the time.
I like your project and how you developed the proof of working stake, but honestly 0.18% that will get lower and lower over time doesn't sounds a good deal to me when the dear old BTCBTC give me almost the double.
Maybe I lost something or I didn't get something.

Some things you may have missed:
1) With hashnest you are trusting them with your money. They could turn out to be a scam and you end up with nothing. With CLAM you can keep control of your coins at all times. You can run the staking locally so that nobody can steal your coins.
2) With hashnest there is presumably a sunk cost. After buying the "s5 ghs" you have presumably made a loss, which it will take you some time to break even from. With CLAM there is no sunk cost, other than the exchange fee (typically 0.2%). It's possible to buy CLAM one day, stake for a day, then sell them again and break even. Is that possible with hashnest?
Having said that, I think you're probably right at the moment. CLAM isn't a good investment while there is someone able to dig up huge amounts of CLAM. He's slower his digging over the last few days, but that doesn't change the fact that he has large amounts of CLAM he can dump on the market whenever he likes. Maybe look again after Christmas, by which time he may have finished his long slow dump.

Thank you for your reply.
About hashnest and bitmain the leader asic bitcoin miner hardware manufaturer, think that they could be scammer is very hard to believe (bitmain has an hero member account with positive trust like you), but hey everything could be. Could be that the CLAMs coin is a scam as well, who knows? Never say never!
About the dig actor, pardon my ignorance but what is "digging"? Can I dig as well?
Thank you again

Yes, you can dig as well if ... read here: http://clamclient.com/start/getting-started/

It should be noted that the website is a work in progress.
It is open source and we hope that the community will eventually become active and help make it an awesome resource for new users.
The source is here, and is live-compiled into the actual site:
https://github.com/nochowderforyou/nochowderforyou.github.io

The link concerning how to "dig" is here:
http://clamclient.com/learn/import/

You may only "dig" initial distribution CLAM if you owned BTC, LTC or DOGE May 12th of last year (when we launched).

[dooglus]

Back by popular demand: updated dig charts...

[dooglus]

About hashnest and bitmain the leader asic bitcoin miner hardware manufaturer, think that they could be scammer is very hard to believe (bitmain has an hero member account with positive trust like you), but hey everything could be. Could be that the CLAMs coin is a scam as well, who knows? Never say never!

I'm not saying they're scammers. I've never looked into their operation, not even a little. What I'm saying is that with cloud mining you have to trust a third party with your funds, and with CLAM staking you don't. So with cloud mining there is *a theoretical possibility* that they can steal your coins, and with CLAM staking there isn't. That's a difference worth pointing out.

About the dig actor, pardon my ignorance but what is "digging"? Can I dig as well?

Others already answered. To make it brief, "digging" is the act of claiming the CLAMs that were given to you for free when CLAM first launched. Every BTC, LTC, and DOGE address that had a "non dust" balance on 12th May 2014 was given 4.6 CLAMs. If that includes you, then yes, you can dig as well.

[cryptospout]

I would like to announce that I am offering clam node hosting. The system is completely automated and can have your node up and running within a few minutes. You can select from a number of locations to setup your node including: New York, Frankfurt,Amsterdam,London,Singapore, San Francisco. Come check it out I would love some feedback: https://cryptospout.com/cryptonode.php

[SebastianJu]

- if we are saying many people should benefit from the dig, surely there should be a limit on clam clients on how many addresses they can dig, daily or over the lifetime

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

Regarding BetVIP. There was a post in the scam accusation thread against stakeminers https://bitcointalk.org/index.php?topic=990219.msg12203429#msg12203429 where Gleb Gamow found connections to betvip that probably are not possible because the transaction belongs to stakeminers.com. And you found such a connection too. Since i know the owner of walletexplorer i asked him about that and it is probably an error. He disabled the label for now.

Just a headsup.

[Jdj1727]

I'm officially addicted to just-dice.com!

[presstab]

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

[dooglus]

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

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?

[presstab]

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

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?

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

[SuperClam]

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

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?

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

Nice work, presstab

[dooglus]

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

[grunt]

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

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

[dooglus]

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

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.

[dooglus]

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

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

[Alexis]

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

[presstab]

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

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

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

[dooglus]

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

Every time I look into the digger's transactions, he appears to be sending his CLAMs to poloniex. From there they mostly move to Just-Dice.

There's no way (short of attempting to gain inside knowledge from poloniex staff) that I can tell the difference between him simply withdrawing his deposited CLAMs from poloniex to Just-Dice and unrelated third parties buying his CLAMs on the poloniex market and withdrawing them to Just-Dice.

We have seen higher levels of trading on poloniex recently, which suggests that for the most part he is selling his CLAMs to JD investors. Then again maybe he's selling them to himself and investing them.

tl;dr: idk

[dooglus]

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

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

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

It appears that I formed that scriptPubKey backwards. In future we'll be standardising on having the TIMELOCK check at the end of the scriptPubKey, like this:

    "OP_DUP OP_HASH160 <key> OP_EQUALVERIFY OP_CHECKSIG <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP"

[AgentofCoin]

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

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.

Hey Dooglas,
Just for clarification since I'm not fully informed with the whole Whale Digger situation,
as well as how you can estimate how many clams he will dig in total,
but 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?

Thanks.