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

[BayAreaCoins]

I have a weird question,  if someone could help me out

What is the minimum amount of  coins,  I need For the POS to work someone okay?

What I been doing this lending them out on poloniex,  I don't have a lot of coins as of yet will get more soon

Read the thread or search it in here.

I would answer, but I'm not exactly sure because I stake at Just-Dice.

[1714172600]

1714172600

[1714172600]

1714172600

[1714172600]

1714172600

[rocoro]

Hard to say - the price of the coin is going down https://bittrex.com/Market/Index?MarketName=BTC-CLAM

Compared to what timeframe?  
If you look back when it started out,  its not down at all.

For example, just picking a point in time,  in Oct. about 2 years ago it was only 18k satoshi.

Please be more specific in terms of a timeframe.

 

[dooglus]

I have found an oldd dogewallet and checked if there are clams on it.
the receiving addresses are empty but one of my sending addresses got 4 clams on it.

how to get the private key for the sending address?

What is a "sending address"? You can only send coins from addresses that previously received coins, so I would think the "sending address" is the same as the previous "receiving address". Or do you mean that there are some CLAMs on an address you once sent some coins to, but don't control? In that case the CLAMs belong to the owner of that address.

Sorry I can't give you a better answer, but I don't think I really understand the question.

What is the minimum amount of  coins,  I need For the POS to work someone okay?

What I been doing this lending them out on poloniex,  I don't have a lot of coins as of yet will get more soon

Every 16 seconds, the wallet client will hash together a bunch of information for each of your mature unspent outputs in turn and check whether the hash is lower than some target. If so, that output gets to stake. The target is based on the size of the output and the current network difficulty. The smaller the output, the lower the target, and so the lower the chance that the hash will be lower than the target.

Any non-zero valued unspent output has a chance of staking, but the chance is proportional to the value of the output.

A 1000 CLAM output will stake about once per day.
A 1 CLAM output will stake about once per 3 years.
A 0.1 CLAM output will stake about oonce per 30 years.
Etc.

So a single 'clamtoshi' output (0.00000001 CLAMs) can still stake, but it is very unlikely that it ever will. The expected time to stake for a single clamtoshi is around 300 million years.

So I'm telling you there's a chance, yeah!

[donarito]

bought some coins, price is moving very well, so planning to buy some more

[coinstash]

Clams will be added to the next release of the Bitsquare P2P exchange, v0.4.9.7 due out in about a fortnight.

For more information: https://bitsquare.io

[opmac]

Clams will be added to the next release of the Bitsquare P2P exchange, v0.4.9.7 due out in about a fortnight.

For more information: https://bitsquare.io

That is some good news!

[inkha]

does anybody know how to validate a CLAM address with PHP?

This works... using the regex from Nixsy:

Code:

$regex = "/^[x][a-km-zA-HJ-NP-Z0-9]{26,33}$/";
if (preg_match($regex, "xWEWfhF9hDvKksvWgFj6kmseLYShZG9Kx8")) {
    // match success
    echo "Found a match!";
} else {
    // If preg_match() returns false, then the regex does not
    // match the string
    echo "The regex pattern does not match. :(";
}

Helpful, saved aswell thanks!

Code:

function validateAddress($address){
  $regex = "/^[x][a-km-zA-HJ-NP-Z0-9]{26,33}$/";
  if (preg_match($regex, $address)) {
      // match success
      return true;
  } else {
      // If preg_match() returns false, then the regex does not
      // match the string
      return false;
  }
}

I Have saved this to my snippets folder, Thanks dude.

[len01]

Long Live The Great Clam!!

[garthkiser]

Long Live The Great Clam!!

LLTGC!!!!!!

[dooglus]

Helpful, saved aswell thanks!

Code:

function validateAddress($address){
  $regex = "/^[x][a-km-zA-HJ-NP-Z0-9]{26,33}$/";
  if (preg_match($regex, $address)) {
      // match success
      return true;
  } else {
      // If preg_match() returns false, then the regex does not
      // match the string
      return false;
  }
}

I Have saved this to my snippets folder, Thanks dude.

You could replace the 0-9 with 1-9 because we don't allow 0's in CLAM addresses.

[krile]

Anyone else having this issue with initial sync of the chain.

The sync progresses normally, then at some point this starts happening:

Code:

ProcessBlock: ORPHAN BLOCK 751, prev=c1e3e257b2a9ebf45d63c275311689c2c29bf458d6bd1ec8da3c70b8bf01b208
ProcessBlock: ORPHAN BLOCK 751, prev=6cb372a465dbb396e8fc41b21316636efd37f77047963b5666faa80f647a614b
ProcessBlock: ORPHAN BLOCK 751, prev=9443038a4deae50ee9de0c6906a3631874c22775d950fd72234ca44e0a8a6cb1
ProcessBlock: ORPHAN BLOCK 751, prev=7dcb9eb72b81b4ded16826bc96ebf18c85a06cd36205faaea07f7c842b26a93e
ProcessBlock: ORPHAN BLOCK 751, prev=04980c95e9186146502f34f7f3420fafbb6512b82dbb7afc05cd68e2d155fe2f
ProcessBlock: ORPHAN BLOCK 751, prev=ce66047ca5fcf95b7894c0ec473af09efa75688f227a3c5659e3d06bc040d45f
ProcessBlock: ORPHAN BLOCK 751, prev=f88ee2ffffa1348f75833a88e3f3413fd0db6a26f476df63df96eca2f7740c38
ProcessBlock: ORPHAN BLOCK 751, prev=49b4acd4080c9424f253da8b260a6db12ef55bde613ff79c717c74f105e7be39
ProcessBlock: ORPHAN BLOCK 751, prev=874b8f14e1b39255362882a6459c58285fa589c683e2f7601641782b777d5476
ProcessBlock: ORPHAN BLOCK 751, prev=afa4e70a44a417015162b9bfcbf3f80dd12a4855df13da3610d6cf1560cfe8b3
ProcessBlock: ORPHAN BLOCK 751, prev=13faa391618c8ce2af52b136bd95e0216e058cb05cce73f7fe9a30c227b6e936
ProcessBlock: ORPHAN BLOCK 751, prev=ae7881cab91c7f663e1a54e6e5da13ad9b079d3a198d3ed603dbd76a28f9d980
ProcessBlock: ORPHAN BLOCK 751, prev=0c90bc368e236e1d7fa20cb3739e0fc70b342d4242e2507794c8c7920470a574
ProcessBlock: ORPHAN BLOCK 751, prev=4f15b023f629cddc3cfcdb7a78262b9374fd372b8dba527d318332263ca3edf8
ProcessBlock: ORPHAN BLOCK 751, prev=706b1eabdc786b2cf71e0006e22d659df071872a83a4d370638a1d016d94d408
ProcessBlock: ORPHAN BLOCK 751, prev=760f186d9c4b54c59a19cf4416c4076f7a60563b0fce8088310bed88dcb3d0b1
ProcessBlock: ORPHAN BLOCK 751, prev=6e80338b8a1d9988accff82a88645be4b3e3b942945abfcada1bd18f551134d9
ProcessBlock: ORPHAN BLOCK 751, prev=1c0a583c4bf5183b0a5f757abf05492df3cf8cadbc3eb33d09c87f4c013c8412
ProcessBlock: ORPHAN BLOCK 751, prev=ff9203afd4f60eaa22a3893a85d6d9827cc04bc54f3d386e3dd229a4d7929924
ProcessBlock: ORPHAN BLOCK 751, prev=7c22aebcdd488f4cf28f70533497423d3b1bf2b5976db29c15a851cbe6fbb56f
ProcessBlock: ORPHAN BLOCK 751, prev=81571af64fed87080855969f43251c061f6667d449515b9220595c446e09c986
ProcessBlock: ORPHAN BLOCK 751, prev=de464db8475579da1a0ff4451b9eb18b0a522619fccfb440efb4c3dcbffc4735
ProcessBlock: ORPHAN BLOCK 751, prev=f862c7096442bb53d53b2734b86045bcd6bb751a864f9a489cef9aac81eea377
ProcessBlock: ORPHAN BLOCK 751, prev=70a441a5033ebc73e02722711594f7b3e2892e84a291ed9b85b3cb79b78e8262
ProcessBlock: ORPHAN BLOCK 751, prev=99624e3ec94556e14c79a2b34db68caa99181df4816f7b538bd99c88c8e51e53
ProcessBlock: ORPHAN BLOCK 751, prev=3dfaca1b0910c1dc71f25a5c9b66ccf60abef131e70501752ea0eb00946e55fa
ProcessBlock: ORPHAN BLOCK 751, prev=29b44927a8a8da005fcbbba1eea59d53df663b131b80e7bf49166c0945fed523
ProcessBlock: ORPHAN BLOCK 751, prev=17d2f5012926afd20299117a3ad2546e7cea617be896b4aaaf53b5f62d0a7800

The solution is to stop clamd and restart it, again it repeats, for some time it syncs new blocks but then get stuck doing this ORPHAN BLOCK 751 over and over and over again.

At this pace it will take a long time to sync, I am around block 300k right now.

Any tips?

[andulolika]

Anyone else having this issue with initial sync of the chain.

The sync progresses normally, then at some point this starts happening:

Code:

ProcessBlock: ORPHAN BLOCK 751, prev=c1e3e257b2a9ebf45d63c275311689c2c29bf458d6bd1ec8da3c70b8bf01b208
ProcessBlock: ORPHAN BLOCK 751, prev=6cb372a465dbb396e8fc41b21316636efd37f77047963b5666faa80f647a614b
ProcessBlock: ORPHAN BLOCK 751, prev=9443038a4deae50ee9de0c6906a3631874c22775d950fd72234ca44e0a8a6cb1
ProcessBlock: ORPHAN BLOCK 751, prev=7dcb9eb72b81b4ded16826bc96ebf18c85a06cd36205faaea07f7c842b26a93e
ProcessBlock: ORPHAN BLOCK 751, prev=04980c95e9186146502f34f7f3420fafbb6512b82dbb7afc05cd68e2d155fe2f
ProcessBlock: ORPHAN BLOCK 751, prev=ce66047ca5fcf95b7894c0ec473af09efa75688f227a3c5659e3d06bc040d45f
ProcessBlock: ORPHAN BLOCK 751, prev=f88ee2ffffa1348f75833a88e3f3413fd0db6a26f476df63df96eca2f7740c38
ProcessBlock: ORPHAN BLOCK 751, prev=49b4acd4080c9424f253da8b260a6db12ef55bde613ff79c717c74f105e7be39
ProcessBlock: ORPHAN BLOCK 751, prev=874b8f14e1b39255362882a6459c58285fa589c683e2f7601641782b777d5476
ProcessBlock: ORPHAN BLOCK 751, prev=afa4e70a44a417015162b9bfcbf3f80dd12a4855df13da3610d6cf1560cfe8b3
ProcessBlock: ORPHAN BLOCK 751, prev=13faa391618c8ce2af52b136bd95e0216e058cb05cce73f7fe9a30c227b6e936
ProcessBlock: ORPHAN BLOCK 751, prev=ae7881cab91c7f663e1a54e6e5da13ad9b079d3a198d3ed603dbd76a28f9d980
ProcessBlock: ORPHAN BLOCK 751, prev=0c90bc368e236e1d7fa20cb3739e0fc70b342d4242e2507794c8c7920470a574
ProcessBlock: ORPHAN BLOCK 751, prev=4f15b023f629cddc3cfcdb7a78262b9374fd372b8dba527d318332263ca3edf8
ProcessBlock: ORPHAN BLOCK 751, prev=706b1eabdc786b2cf71e0006e22d659df071872a83a4d370638a1d016d94d408
ProcessBlock: ORPHAN BLOCK 751, prev=760f186d9c4b54c59a19cf4416c4076f7a60563b0fce8088310bed88dcb3d0b1
ProcessBlock: ORPHAN BLOCK 751, prev=6e80338b8a1d9988accff82a88645be4b3e3b942945abfcada1bd18f551134d9
ProcessBlock: ORPHAN BLOCK 751, prev=1c0a583c4bf5183b0a5f757abf05492df3cf8cadbc3eb33d09c87f4c013c8412
ProcessBlock: ORPHAN BLOCK 751, prev=ff9203afd4f60eaa22a3893a85d6d9827cc04bc54f3d386e3dd229a4d7929924
ProcessBlock: ORPHAN BLOCK 751, prev=7c22aebcdd488f4cf28f70533497423d3b1bf2b5976db29c15a851cbe6fbb56f
ProcessBlock: ORPHAN BLOCK 751, prev=81571af64fed87080855969f43251c061f6667d449515b9220595c446e09c986
ProcessBlock: ORPHAN BLOCK 751, prev=de464db8475579da1a0ff4451b9eb18b0a522619fccfb440efb4c3dcbffc4735
ProcessBlock: ORPHAN BLOCK 751, prev=f862c7096442bb53d53b2734b86045bcd6bb751a864f9a489cef9aac81eea377
ProcessBlock: ORPHAN BLOCK 751, prev=70a441a5033ebc73e02722711594f7b3e2892e84a291ed9b85b3cb79b78e8262
ProcessBlock: ORPHAN BLOCK 751, prev=99624e3ec94556e14c79a2b34db68caa99181df4816f7b538bd99c88c8e51e53
ProcessBlock: ORPHAN BLOCK 751, prev=3dfaca1b0910c1dc71f25a5c9b66ccf60abef131e70501752ea0eb00946e55fa
ProcessBlock: ORPHAN BLOCK 751, prev=29b44927a8a8da005fcbbba1eea59d53df663b131b80e7bf49166c0945fed523
ProcessBlock: ORPHAN BLOCK 751, prev=17d2f5012926afd20299117a3ad2546e7cea617be896b4aaaf53b5f62d0a7800

The solution is to stop clamd and restart it, again it repeats, for some time it syncs new blocks but then get stuck doing this ORPHAN BLOCK 751 over and over and over again.

At this pace it will take a long time to sync, I am around block 300k right now.

Any tips?

I have no idea bout these shits but I think you could use the bootstrap that dooglus updates regularly, Ill search the link and update.

[almightyruler]

The solution is to stop clamd and restart it, again it repeats, for some time it syncs new blocks but then get stuck doing this ORPHAN BLOCK 751 over and over and over again.

At this pace it will take a long time to sync, I am around block 300k right now.

I've run into this problem before too. I think it may be because peers are sending you blocks out of order, so rather than extending the end of the chain in a consistent sequence, you're building up fragmented bits and pieces of the whole thing. The client only keeps track of 750 orphaned blocks by default, and after that it just ignores any further ones it sees (thus the string of error messages). An orphaned block is one that doesn't have any link to your local blockchain, but that doesn't mean it's necessarily invalid, as a future sequence of blocks could include that link and properly connect it into the blockchain.

Bootstrap information is here, hopefully that will help: https://bitcointalk.org/index.php?topic=623147.msg9772191#msg9772191

[dooglus]

The solution is to stop clamd and restart it, again it repeats, for some time it syncs new blocks but then get stuck doing this ORPHAN BLOCK 751 over and over and over again.

At this pace it will take a long time to sync, I am around block 300k right now.

I've run into this problem before too. I think it may be because peers are sending you blocks out of order, so rather than extending the end of the chain in a consistent sequence, you're building up fragmented bits and pieces of the whole thing. The client only keeps track of 750 orphaned blocks by default, and after that it just ignores any further ones it sees (thus the string of error messages). An orphaned block is one that doesn't have any link to your local blockchain, but that doesn't mean it's necessarily invalid, as a future sequence of blocks could include that link and properly connect it into the blockchain.

Bootstrap information is here, hopefully that will help: https://bitcointalk.org/index.php?topic=623147.msg9772191#msg9772191

I just updated that bootstrap post with an up-to-date copy of the blockchain.

I think you're right about the cause of the problem. The blocks arrive out of order, the client keeps up to 750 new blocks in memory while it waits for the missing older blocks to arrive, but is only willing to keep 750 in memory before it starts ignoring out of order blocks.

I think rebasing the CLAM client from a newer release of the Bitcoin client would solve this problem. I also think xploited is in the process of doing exactly that. You can see his work on the 'reindex' branch of his own github repository, here:

    https://github.com/l0rdicon/clams/tree/reindex

Hopefully he'll merge his work onto the release branch some time so everyone can benefit from the improvements.

[SuperClam]

The solution is to stop clamd and restart it, again it repeats, for some time it syncs new blocks but then get stuck doing this ORPHAN BLOCK 751 over and over and over again.
At this pace it will take a long time to sync, I am around block 300k right now.

I've run into this problem before too. I think it may be because peers are sending you blocks out of order, so rather than extending the end of the chain in a consistent sequence, you're building up fragmented bits and pieces of the whole thing. The client only keeps track of 750 orphaned blocks by default, and after that it just ignores any further ones it sees (thus the string of error messages). An orphaned block is one that doesn't have any link to your local blockchain, but that doesn't mean it's necessarily invalid, as a future sequence of blocks could include that link and properly connect it into the blockchain.
Bootstrap information is here, hopefully that will help: https://bitcointalk.org/index.php?topic=623147.msg9772191#msg9772191

I just updated that bootstrap post with an up-to-date copy of the blockchain.
I think you're right about the cause of the problem. The blocks arrive out of order, the client keeps up to 750 new blocks in memory while it waits for the missing older blocks to arrive, but is only willing to keep 750 in memory before it starts ignoring out of order blocks.
I think rebasing the CLAM client from a newer release of the Bitcoin client would solve this problem. I also think xploited is in the process of doing exactly that. You can see his work on the 'reindex' branch of his own github repository, here:
    https://github.com/l0rdicon/clams/tree/reindex
Hopefully he'll merge his work onto the release branch some time so everyone can benefit from the improvements.

Increasing the size of the orphan pool can help, to a certain extent.
Orphans are also not 'ignored' once the pool is full; they are randomly ejected.

Here is a cmdline arg to expand the size of the orphan pool, in terms of count:  

Code:

-maxorphanblocks=<n>

I believe novacoin or blackcoin have an implementation that uses the size(data) of the orphan pool, which makes more sense considering that blocksize itself can vary quite a lot.  

However, I don't personally believe that this is the entire story.  
Doing a diff between ppcoin, novacoin, blackcoin, or another codebase close to ours reveals only a handful of differences in terms of sync code.

Of course, rebasing to a more current Bitcoin codebase would almost certainly help as dooglus has noted - as the BTC network doesn't display the same problem.

[krile]

I made an updated bootstrap.dat file for people having trouble syncing their client.

It goes up to block 1220900 which was staked on Sun Oct 23 17:29:04 UTC 2016.

It's available as a download here:

  bootstrap.dat

Tnx for the link. Flying now with the bootstrap

Even though syncing through the p2p network would be slow it would be done by now if it weren't for the 750 orphan limit. Its been almost four days now, as a test I left it running, I noticed that very slowly new blocks were getting in, but at a rate of maybe a 1000 a day - which is silly.

This really should be fixed.

[gamblingbad]

Is there a recent chart over staked and mined coins?

[andulolika]

Is there a recent chart over staked and mined coins?

Chart most certainly not but you can use /supply on the just-dice chat to see the whole.

[gamblingbad]

Is there a recent chart over staked and mined coins?

Chart most certainly not but you can use /supply on the just-dice chat to see the whole.

Yes i know, i just wanted see rate of new supply.

[rocoro]

Is there a recent chart over staked and mined coins?

Chart most certainly not but you can use /supply on the just-dice chat to see the whole.

Yes i know, i just wanted see rate of new supply.

digsupply says 848651

If not much has changed since last chart (848k being just under 850k)
https://ip.bitcointalk.org/?u=http%3A%2F%2Fi.imgur.com%2FRKrudHU.png&t=570&c=jH_XZnWUQ8sqVA

I don't think it would look much different.