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

well... I checked my blk0001.dat file and it's only 30,611,464 bytes
that's why I wonder why it's using so much data transfer (100MB) but only worth 30MB of blockchain data
and I only run the clam-qt connected to the net, not browsing or chatting or anything at the same time
it seems my client inefficiently re-downloading already downloaded block data

almost on every accepted new best chain, there always 4 or 5 messages with that error processblock
anyway to minimize this to save my bandwidth & resynch faster?
or is that how the peer-to-peer connection work and no way to avoid that?

edit: a little update, past block 10,000 the synching becomes faster by looking at the number of blocks downloaded
however if I added up all the data transfer so far, it totalled to 600MB just to download a 150MB worth of blockchain 
oh yeah someone won a lottery again 663.74264776 block 86690

They're about 50 US cents each...

Long live the Great CLAM!

now give me a lottery win already!

network weight has been consistently high the last days so it looks like people are consistently staking now, gone are the days of my daily staking, need more clams!

The early blocks were bigger because that's when the CLAMs were given out to all the BTC, LTC, and DOGE addresses.

My blk0001.dat file in the .clam folder is 154,029,202 bytes - so if you have 100 MB you're two thirds of the way there, by byte count.


Not me. My biggest mining reward is ~950 CLAM, and my 2nd biggest is ~567 CLAM.

I'll keep on staking though - so hopefully will regain my record soon.

finally downloaded the client successfully yesterday & continue synching today
started at block 910 and synching (slowly because of my isp) for about 2 hours up to block ~2700
and I see that it sucked up 100MB just to download ~2000 blocks
is this normal for earlier blocks? because the newer blocks are less than 1kb/block

oh btw congrats on whoever won the lottery block 86048 with the amount of 968.24781126
so I think this would be the highest reward so far, right?
@dooglus someone beat your record umm or it might be you again

Every outputs gets a very small chance of staking every second.

There's no guarantee that any particular output will ever stake, and sometimes it can take much longer (or much shorter) than expected.

Here are my oldest outputs - one has gone 19 days without staking:



Edit: here's the history of the oldest output's staking. It started as a 4.7 deposit, staked 4 times (in red) before splitting into a 2.63 (orange) and a 2.6300x (purple). The orange fork is still staking regularly, but the purple fork got stuck 19 days ago and has had no luck since:



Edit2: one other thing that you may not realised:

Your outputs only get their one-chance-per-second of staking while you are actively staking. You can't shut down the client overnight then run it in the morning to see if you would have won overnight. All those chances you would have had overnight are missed chances if the client wasn't running overnight. So if you're only running your client part of the time, that could explain your higher-than average staking delays.

Edit3: I just saw a 5.05 CLAM output that was 10 days old stake on the blockchain. At that weight (50 CLAMdays) and the current difficulty, it had a 1-in-303531 chance of staking each second. 303531 seconds is about 3.5 days, and so your outputs with similar value and age should each stake within 3 or 4 days if you're averagely lucky.

No stake in 10 days

Appears normal to me. Specifically, what were you concerned about? I see the three outputs at the top of the list, but I don't see a problem.

Is this normal?
https://i.imgur.com/EEVGN33.png

Yes, you're right it's 4 hours, sorry.

And I think it answers my questions, thanks a lot.

Your example falls within less than an order of magnitude with what I get, which is easily accounted by variations of difficulty, which seems to flail around a fair bit, at least in the last day or so.

Thanks!

Take a look at http://khashier.com:2750/address/xC6ktEBwaTk8G27wCWwQjGmDuK14SZPvJa for example.

The 4.6 staked to 4.7 and then to 4.8, taking about 3 days between those two events. Then 3 days later it split into two 2.45's, and each of those has been staking since, about once every 3 days between the two of them. Replace the address with your address and you'll see the data for your output - but about once per 3 days seems to be how it goes, roughly.

Network weight is indeed approximated based on recent staking rate, like PoW hashrate. There's no other way to know how many coins are currently staking. It could be that lots of coins are trying to stake but being incredibly unlucky, or the converse.

The difficulty is adjusted to try to make it so that one block is staked per minute - that's all. And the network weight is approximated based on how fast blocks actually staked based on the difficulty as it stood for each recent block.


I'm not sure of the details. But isn't it 4 hours not 6?

unsigned int nStakeMinAge = 4 * 60 * 60; // 4 hours

I have an output here that just staked. It was worth 2.55 CLAM and is 8.96 days old. That's a weight of 22 CLAMdays.

The first 8 digits of the hash were 00000c76, and they had to be less than 00002092. That's a 1-in-515107 chance (0x100000000 / 0x00002092), and so on average that output would take 515k seconds to stake. That's 5.96 days.

Does that help you check your math?

Also, in order to understand how this works, I added age and weight columns to the coin control window. I find it's useful. If you think it's a good addition, feel free to use this patch.
Also, if I messed up on how these are actually calcualted, feel free to correct me It appears consistent with the total weight displayed in the bottom right corner, at least.



From 76cc57216ac6789972d769185b75e4c4a1de051d Mon Sep 17 00:00:00 2001
From: moneromooo <[email protected]>
Date: Mon, 25 Aug 2014 09:05:11 +0100
Subject: [PATCH] coincontrol: add age/weight columns

---
 src/qt/coincontroldialog.cpp      | 16 +++++++++++++++-
 src/qt/coincontroldialog.h        |  2 ++
 src/qt/forms/coincontroldialog.ui | 16 ++++++++++++++++
 3 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/src/qt/coincontroldialog.cpp b/src/qt/coincontroldialog.cpp
index f1008d4..11966a2 100644
--- a/src/qt/coincontroldialog.cpp
+++ b/src/qt/coincontroldialog.cpp
@@ -110,6 +110,8 @@ CoinControlDialog::CoinControlDialog(QWidget *parent) :
     ui->treeWidget->setColumnWidth(COLUMN_ADDRESS, 290);
     ui->treeWidget->setColumnWidth(COLUMN_DATE, 110);
     ui->treeWidget->setColumnWidth(COLUMN_CONFIRMATIONS, 100);
+    ui->treeWidget->setColumnWidth(COLUMN_AGE, 60);
+    ui->treeWidget->setColumnWidth(COLUMN_WEIGHT, 60);
     ui->treeWidget->setColumnWidth(COLUMN_PRIORITY, 100);
     ui->treeWidget->setColumnHidden(COLUMN_TXHASH, true);         // store transacton hash in this column, but dont show it
     ui->treeWidget->setColumnHidden(COLUMN_VOUT_INDEX, true);     // store vout index in this column, but dont show it
@@ -622,6 +624,7 @@ void CoinControlDialog::updateView()
         double dPrioritySum = 0;
         int nChildren = 0;
         int nInputSum = 0;
+        int dWeight = 0;
         BOOST_FOREACH(const COutput& out, coins.second)
         {
             int nInputSize = 148; // 180 if uncompressed public key
@@ -683,7 +686,17 @@ void CoinControlDialog::updateView()
 
             // confirmations
             itemOutput->setText(COLUMN_CONFIRMATIONS, strPad(QString::number(out.nDepth), 8, " "));
-            
+
+            // age
+            float age = (GetTime() - out.tx->GetTxTime()) / (float)(1440 * nTargetStakeSpacing);
+            itemOutput->setText(COLUMN_AGE, strPad(QString::number(age, 'g', 3), 8, " "));
+
+            // weight
+            int weight = floorf((GetTime() - out.tx->GetTxTime() - nStakeMinAge) * out.tx->vout[out.i].nValue / BitcoinUnits::factor(BitcoinUnits::BTC) / (float)(1440 * nTargetStakeSpacing));
+            if (weight < 0) weight = 0;
+            itemOutput->setText(COLUMN_WEIGHT, strPad(QString::number(weight), 5, " "));
+            dWeight += weight;
+
             // priority
             double dPriority = ((double)out.tx->vout[out.i].nValue  / (nInputSize + 78)) * (out.nDepth+1); // 78 = 2 * 34 + 10
             itemOutput->setText(COLUMN_PRIORITY, CoinControlDialog::getPriorityLabel(dPriority));
@@ -721,6 +734,7 @@ void CoinControlDialog::updateView()
             itemWalletAddress->setText(COLUMN_AMOUNT_INT64, strPad(QString::number(nSum), 15, " "));
             itemWalletAddress->setText(COLUMN_PRIORITY, CoinControlDialog::getPriorityLabel(dPrioritySum));
             itemWalletAddress->setText(COLUMN_PRIORITY_INT64, strPad(QString::number((int64_t)dPrioritySum), 20, " "));
+            itemWalletAddress->setText(COLUMN_WEIGHT, strPad(QString::number((int64_t)dWeight), 5, " "));
         }
     }
    
diff --git a/src/qt/coincontroldialog.h b/src/qt/coincontroldialog.h
index 5d0a90b..2f803d5 100644
--- a/src/qt/coincontroldialog.h
+++ b/src/qt/coincontroldialog.h
@@ -57,6 +57,8 @@ private:
         COLUMN_ADDRESS,
         COLUMN_DATE,
         COLUMN_CONFIRMATIONS,
+        COLUMN_AGE,
+        COLUMN_WEIGHT,
         COLUMN_PRIORITY,
         COLUMN_TXHASH,
         COLUMN_VOUT_INDEX,
diff --git a/src/qt/forms/coincontroldialog.ui b/src/qt/forms/coincontroldialog.ui
index 1364269..f002872 100644
--- a/src/qt/forms/coincontroldialog.ui
+++ b/src/qt/forms/coincontroldialog.ui
@@ -494,6 +494,22 @@
      
      
      
+       Age
+      
+      
+       Age in days
+      
+    
+    
+      
+       Weight
+      
+      
+       Weight
+      
+    
+    
+      
        Priority
      
      
--
1.9.3

clams lol proof of pearl lolol

Ah, it seems I was confusing difficulty and network weight. I get 0.002 like numbers from getstakinginfo too, and I was giving the network weight as what I thought was a synonym for difficulty.

And it seems the random factor is rather large - my 4.6 block made two 0.1 stakes on two consecutive days, but is now staying silent. I guess it'll even out over a long period of time.

This makes me even more curious about how this works, though. How is the difficulty connected to network weight ? Is the weight "approximated" backward from stake times like the network hash rate is in PoW coins ? This is why I confused difficulty and network weight, since these two (difficulty and (estimated) hash rate are connected with PoW).

So, to understand if I get it now, each second, a coin has a chance to stake equal to 1 in the integer part of ( (2^20) * coin-age-in-days-minus-6-hours * coin-value * difficulty / 0.0001 ), with difficulty being 0.003 at the moment.

Thanks

When very little weight is staking, the difficulty decreases, to make it easier for people to stake.

The lowest it goes is 1/4096 = 0.00024414

Currently it's around:

0.00224045
0.00240555
0.00264976
0.00261897
0.00279432
0.00314596

(those were the difficulties after 6 recent blocks).

That's about 10 times higher than the minimum of 1/4096.


Where do you see that number?

I see a number around 0.002:

$ clamd getdifficulty
{
    "proof-of-work" : 0.00024876,
    "proof-of-stake" : 0.00275561,
    "search-interval" : 1
}


The client has been quite inaccurate about expected staking times. I'm not sure whether it is better now or not.

The way the randomness works is that each second, each of your coin outputs gets hashed with the current time (in seconds). If that hash is lower than the current target per CLAM-day (which is a function of the current difficulty) multiplied by the weight of the output (which is its value times its age) then it gets to stake.

In effect you are entering a lottery every second, with a tiny chance of winning each time. As you keep failing to win, your output gets older, which gives it more weight, and so a better chance of winning. But at the same time everyone else is doing the same, and the faster they stake, the higher the difficulty increases, making the lottery harder to win.

Edit: about half an hour after posting this, the difficulty fell dramatically. Now it's relatively easy to stake again:

$ clamd getdifficulty
{
    "proof-of-work" : 0.00024876,
    "proof-of-stake" : 0.00054170,
    "search-interval" : 1
}

There's a pool that pays out in CLAMs, although those are bought with 75% of the mining proceeds. The other 25% is used as the CLAM Shell - To add buy support below market value.

Is this correct, that this coin is POS only ? No way to mine it ?

The network weight isn't the difficulty though. If you go into the client Debug console and type "getstakinginfo" that will tell you what the current difficulty is. The network weight is the sum of the weights of all the coins available to stake. Current difficulty is 0.00284345 (which is used just as in traditional POW mining). IIRC minimum difficulty is 0.0001.

You need have DOGE when clam was launced.

9-10k weight was common for a long time. It is starting to look like those days are long gone