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

[Thirdspace]

downloading the new client right now...
my chain is "again" on the wrong fork up to 2039xx
hopefully I can manage to resynch better than last time

2 times stuck @99% and the third time it saves to my hd but I got this error on chrome

CLAMclient_1.4.3.0_Windows.zip may harm your browsing experience, so Chrome has blocked it.

[1696115498]

1696115498

[dooglus]

Here's a chart showing the network difficulty per block from shortly before the fork until now:



The net client made it around 100 million times easier to stake, since the previous code would let you stake if your output's hash was less than:

Code:

difficulty_target * value_in_clams * age_in_days)

and the new code lets you stake if your output's hash is less than:

Code:

difficulty_target * value_in_satoshi

Your output's age is no longer taken into account. It used to be that your chance of staking increased the longer it had been since you last staked, but that no longer happens. Note that the output's value in satoshis is now used rather than its value in clams - that's where the factor of 100 million comes in. Given constant "difficulty", it is now 100 million times easier for a 1-day-old output to stake than it was before. However, it's only 50 million times easier for a 2-day-old output to stake, and only 1 million times easier for a 100-day-old output to stake. Most outputs used to stake within 50 days or so. I would guess the average time to stake used to be around 10 days. So we might expect the network difficulty to adjust by a factor of 10 million to compensate.

The difficulty adjustment code smoothly ramped the difficulty up by a factor of around 1 million, but it overshot, and it's taking a while to reach a new equilibrium. Here's a close-up of the last few hundred block difficulties:



Why did the network difficulty "only" adjust by a factor of 1 million? Perhaps because a significant percentage of the network didn't switch to the net client yet. Or perhaps because my math is wrong.

Edit:

To get the data, I ran:

Code:

block=203200
while ((block <= $(cc getblockcount)))
do
    echo $block $(cc getblock $(cc getblockhash $block) | grep difficulty) | cut -d" " -f1,4 | tr -d ","
    ((block++))
done > diff.dat

(where 'cc' is an alias for 'clamd') and to plot the charts:

Code:

$ gnuplot
gnuplot> unset key
gnuplot> set logscale y
gnuplot> set grid
gnuplot> plot "diff.dat" with linespoints pt 7
gnuplot> unset logscale
gnuplot> plot [204200:*] "diff.dat" with linespoints pt 7

[Karn]

This sound about right

(getinfo)
"version" : "v1.4.2.1-355-gf36c215",
"protocolversion" : 60014,
"walletversion" : 60000,
"balance" : 94.20881502,
"newmint" : 0.00000000,
"stake" : 0.00000000,
"blocks" : 204771,
"timeoffset" : 0,
"moneysupply" : 15054374.76984581,
"connections" : 20,
"proxy" : "",
"ip" : "",
"difficulty" : {
"proof-of-work" : 0.00024876,
"proof-of-stake" : 4613.98166182
},
"testnet" : false,
"keypoololdest" : 1404539916,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"mininput" : 0.00000000,
"errors" : ""

(getstakinginfo)
enabled" : true,
"staking" : true,
"errors" : "",
"currentblocksize" : 1000,
"currentblocktx" : 0,
"pooledtx" : 0,
"difficulty" : 4587.99675682,
"search-interval" : 16,
"weight" : 9420881502,
"netstakeweight" : 6627397658617,
"expectedtime" : 268435456


your weight 94
network weight 6,600,000,000,000
expected time to earn reward 3106 days

[paulc010]

The numbers look shocking but it's working fine. New staking chance isn't factored into the network weight (which was only ever an indicator) or the expected time to stake calculation.

My wallet is staking just fine even though the client is telling me I need to wait a year

[dooglus]

Updated difficulty charts:

[tryphe]

Edited Karn's quote to clarify a few things.

--quote cut off--
"weight" : 9420881502,
"netstakeweight" : 6627397658617,
"expectedtime" : 268435456

your weight 94 <-- this is actually 9.4 Billion as seen above
network weight 6,600,000,000,000
expected time to earn reward 3106 days <--This is completely wrong because of how the client interprets the data based on the old numbers (it takes a wildly overestimated guess right now)

All of these numbers are arbitrary and an estimation of the network state based on recent data. In no way do they accurately represent the actual values(they are impossible to know). They are in the process of being revised to be human readable and not a bunch of jumble =p

In other words, you should not pay attention to any of the numbers in the staking tooltip(short of the network weight), especially the expected time. Please do not make any judgements based on these values. My best advice would be to stake for a while, and then make some estimations based on that.


Also:

"protocolversion" : 60014

This indicates that you are running the proper build. You should ignore the version string for now (i.e. "1.4.2.1..")

[Trololoh]

A few "fresh" nodes for ppl who need to re-download chain and to make sure you end up syncing the correct chain.

Clam.conf :

Code:

listen=1
connect=73.172.149.95
connect=54.75.227.85
connect=104.131.67.225
connect=73.55.207.245
connect=80.195.253.183
connect=82.26.243.220
connect=173.31.55.8

-As usual, move your wallet.dat to safe location before you sync.
-Check and verify that you are indeed on the right chain before you copy wallet.dat back.
-Currently use IRC chat for chain verification or post in forum.
-When done, delete peers.dat and change connect= to addnode=

[dooglus]

-Currently use IRC chat for chain verification.

Here's a recent block in my client:

> getblockhash 204990
d4dbfae71d2fd6bf224a4a4cfe83a7a17c2c40c6e7f7cdcb738bf597beb3d6c6

Can someone please confirm they see the same hash for that height?

[tryphe]

-Currently use IRC chat for chain verification.

Here's a recent block in my client:

> getblockhash 204990
d4dbfae71d2fd6bf224a4a4cfe83a7a17c2c40c6e7f7cdcb738bf597beb3d6c6

Can someone please confirm they see the same hash for that height?

Copy that!

[Trololoh]

-Currently use IRC chat for chain verification.

Here's a recent block in my client:

> getblockhash 204990
d4dbfae71d2fd6bf224a4a4cfe83a7a17c2c40c6e7f7cdcb738bf597beb3d6c6

Can someone please confirm they see the same hash for that height?

Yep, same hash for 204990 on my wallet.

[Quantum12]

-Currently use IRC chat for chain verification.

Here's a recent block in my client:

> getblockhash 204990
d4dbfae71d2fd6bf224a4a4cfe83a7a17c2c40c6e7f7cdcb738bf597beb3d6c6

Can someone please confirm they see the same hash for that height?

Also can confirm

correct

Q

[ymod123]

im trying to unlock my wallet I got this message "

Error: RPC server was not started, use server=1 to change this. (code -18)

[xploited]

im trying to unlock my wallet I got this message "

Error: RPC server was not started, use server=1 to change this. (code -18)

RPC is getting separated from the wallet (code wise). You can choose not to activate it if you don't need to.
 
If you add  server=1  to the clam.conf file the RPC will work.  

[dooglus]

Run with "-reindex -rescan -addnode=67.35.116.81:31174" and you should be on the correct chain

Did we lose -reindex functionality in the recent hardfork?

All I see is a comment:

Code:

$ grep reindex *.h *.cpp
main.cpp:        // point should only happen with -reindex/-loadblock, or a misbehaving peer.

[ymod123]

im trying to unlock my wallet I got this message "

Error: RPC server was not started, use server=1 to change this. (code -18)

RPC is getting separated from the wallet (code wise). You can choose not to activate it if you don't need to.
 
If you add  server=1  to the clam.conf file the RPC will work.  

hello! tnx for the help i add the server=1 still dont work

server=1
connect=84.194.247.232:31174
connect=23.92.210.2:31174
connect=54.75.227.85:38343
connect=104.131.59.43:53103
connect=77.247.181.165:65190
connect=162.218.65.19:45406
connect=96.246.211.120:19476
connect=83.86.189.163:58108
connect=93.103.131.59:53324
connect=71.188.55.212:31174
connect=76.94.201.185:36079
connect=109.195.211.62:50318
connect=86.58.104.183:49860
connect=203.20.114.252:31174
connect=108.195.138.58:60527
connect=193.166.139.206:55786
connect=78.134.3.254:63941
connect=198.245.60.38:53497
connect=24.96.235.190:61000
connect=108.237.13.94:34724
connect=71.241.130.246:31174
connect=198.245.60.38:55364
connect=203.174.191.230:50533
connect=69.131.59.58:4719
connect=24.67.30.88:51620
connect=89.88.199.104:51398
connect=37.209.45.163:49312
connect=108.227.82.11:50317
connect=108.91.73.3:63989
connect=73.55.207.245:64773
connect=80.195.253.183:31174
connect=95.91.224.82:11614

[dooglus]

One last difficulty chart update:

[Hippie Tech]

The last two stakes orphaned and my client has lost all connections/ gone offline.
51'd ?

We went for a bit of a ride after the fork, all of the estimates are entirely off, though things are balancing out now.
If you want to check that you are on the right chain, or get things straightened out stop into IRC, friend.

Everything is ok now that I'm on the newest client.

What do you say to, adding blockhash updates (every 100? - 1000? blocks) to the OP and /or display the current client version to the main title ?

BLOCK        HASH
207959       8b0e61e98ae4f8fff4355c4f6a2f5b99d6bee61c8f530143dfbd7627a1af7e6e
 
EDIT

Here is my .conf. As you can see, no addnode and connect flags were used.
 

Code:

listen=0
daemon=1
server=1
rpcuser=you
rpcpassword=yourpass
rpcport=4320
rpcconnect=127.0.0.1

[SuperClam]

BLOCK        HASH
207959       8b0e61e98ae4f8fff4355c4f6a2f5b99d6bee61c8f530143dfbd7627a1af7e6e

Unfortunately, it is a bit.. contentious.. to declare an "official" block for a given height.
During code updates, we often do place checkpoints for sanity, however beyond that it becomes a bit more murky.

On my personal client, I show for block# 208000:

d2ca72505c79979957573e5dd6e0bf08955e79cda57b66c2126f7cb85f200e83

Hope that is helpful

[dooglus]

Unfortunately, it is a bit.. contentious.. to declare an "official" block for a given height.
During code updates, we often do place checkpoints for sanity, however beyond that it becomes a bit more murky.

Well, like you say the client itself has a list of blocks and their hashes:

Code:

( 6666,  uint256("0x000002129d8a2b43509d2abb0aa24932b7af2f760e869d5952dee97d4b8ea8bf") )
        ( 10000,  uint256("0x00000de398b1ec72c393c5c54574a1e1784eb178d683e1ad0856c12fac34f603") )
        ( 29000,  uint256("0x068769a2ab0e35fc3ac31690158401b9538a7cce2a97096b22d47e50355b2e1f") )
        ( 175000,  uint256("0xec64deeb7f1295216f20ce5dbe68b0bd28189a5a644a111e722c05451d51e66c") )

but you also get to change the code however you like, including forcing hardforks, so it's a little off to say that there isn't an "official" chain.

[SuperClam]

Well, like you say the client itself has a list of blocks and their hashes:
but you also get to change the code however you like, including forcing hardforks, so it's a little off to say that there isn't an "official" chain.

True.

During code updates, we often do place checkpoints for sanity, however beyond that it becomes a bit more murky.

For those who do not have a deeper understanding, the above listed blocks are called "checkpoints".
They provide a bit of sanity for syncing clients on the network; more importantly, they are added to the code periodically during updates and as a matter of policy should include a block that is deep enough into the past to give a strong cost:benefit argument for their addition.  It is important when a checkpoint is set, that there are no competing chains at that depth so that the effect becomes to solidify a non-contentious point in the chain as opposed to "choosing".

For instance, the last checkpoint in the code you listed above was block # 175,000.  It was added during the last update which went into effect on block #203,500.  For those with less mathematical patience, that is 28,500 blocks into the past.

With a target of 1,440 blocks a day (though we were moving faster than that due to the exploits fixed), I think we can all agree that the impact of a re-organization in the magnitude of multiple "days" would not be conductive or appropriate in a ledger system; especially considering that the above re-organization would have had to emerge from a disconnected set of clients that did not exist in the cluster of nodes which included Poloniex, the primary exchange, or the primary network - which is quite simple given the limited scope of the current network.

In the future, that may not be so simple.  However, I think some comfort can be gleaned from the fact that we have publicly denounced other chain development teams which have chosen to "rollback" the ledger.  In addition, we clearly chose NOT to rollback the chain or blacklist addresses given the recent lottery exploit.  And, as long as the current team in place maintains control of the development project behind CLAMS - that will continue to be the case

The ledger is sacred.  
The ability to transact without fear of reprisal or seizure is sacred.


Caritas. Libertas. Aequitas. Monetas.