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

[SuperClam]

We are officially staking lottery blocks!

Woohoo!

[kidyubyub]

When I click the link for the Windows wallet update 1.4.2b, I get this as a file download: CLAMClient_1.4.2b_Windows.tar.gz. Is this incorrect, or am I doing something wrong?

Not at all, it is compressed to make it download quicker.
Most standard decompression programs should work (7zip, etc.).

If you still can't figure it out, I am happy to package up a zip file for folks!

I shall install 7Zip. It was the only computer on which I didn't have it installed!! Figures. Thanks!

[SuperClam]

When I click the link for the Windows wallet update 1.4.2b, I get this as a file download: CLAMClient_1.4.2b_Windows.tar.gz. Is this incorrect, or am I doing something wrong?

Not at all, it is compressed to make it download quicker.
Most standard decompression programs should work (7zip, etc.).

If you still can't figure it out, I am happy to package up a zip file for folks!

I shall install 7Zip. It was the only computer on which I didn't have it installed!! Figures. Thanks!

If anyone stakes a lottery block over 0.1 post in the forum here!

Let everyone see you basking in your CLAMS!

[dooglus]

If anyone stakes a lottery block over 0.1 post in the forum here!

i don't see any way of telling whether my stake was over 0.1 or not, because the excess could be due to transaction fees.

But the first block I staked this evening when I got home appears to be a lottery block over 0.1:



One thing I'm confused about: it used to be that most blocks I staked gave me around 0.00015000 clam, but now the minimum reward is 0.10000000, which is about 700 times bigger. So how does the change not increase inflation?

Edit: it looks like *only* the first block I mined this evening has more than the minimum 0.1 rewards - all the extras are transaction fees.

See http://khashier.com:2750/block/d3e163be7ecb84fe387ad34b1f3a6e59604e263ab7875136f1a447503b18a95c which shows I got 0.10000116 instead of the usual 0.01000000!

I'm such a lottery winner!

[SuperClam]

If anyone stakes a lottery block over 0.1 post in the forum here!

i don't see any way of telling whether my stake was over 0.1 or not, because the excess could be due to transaction fees.
But the first block I staked this evening when I got home appears to be a lottery block over 0.1:

One thing I'm confused about: it used to be that most blocks I staked gave me around 0.00015000 clam, but now the minimum reward is 0.10000000, which is about 700 times bigger. So how does the change not increase inflation?
Edit: it looks like *only* the first block I mined this evening has more than the minimum 0.1 rewards - all the extras are transaction fees.
See http://khashier.com:2750/block/d3e163be7ecb84fe387ad34b1f3a6e59604e263ab7875136f1a447503b18a95c which shows I got 0.10000116 instead of the usual 0.01000000!
I'm such a lottery winner!

LoL, Winner Winner, CLAMicken Dinner!

Okay, not 'huge', but a special block none-the-less


The target of the network at launch was to hit ~1% yearly inflation based on the total money supply.
Of coarse, CLAMS is odd in that the total money supply is unknown.

If you assume that the majority of CLAMS are claimed at some unknown time in the future (Less non-retrievable coins of coarse), then the claiming of the coins would not be considered inflation -> they already exist on the chain and can be claimed at any given moment.  This isn't accurate. 

If you assume they will not be claimed, then the act of claiming the coins itself is a sort of inflation.  This isn't accurate either.

So which do you go with?
If you choose to not count the un-claimed coins, then estimates of "inflation" are entirely useless.  Many people claiming, or a large service claiming (such as Poloniex's giveaway) would entirely destroy any attempt at an estimate.
If you choose to count un-claimed coins, under the logic that they exist and could enter the system at any moment, then you greatly under estimate yearly inflation.

Frankly, it is a very difficult question; and there isn't really any "prior art" or standard way of dealing with it that we are aware of.
I am choosing to speak of it as if the CLAMS on chain are CLAMS in existence, because they can enter the money supply at any moment, and that is the only solid immovable reference point from which to function.

So, if you don't count CLAMS possible; you're yearly inflation numbers will be much higher than ~1%.
But then, you would also have to count every CLAM claimed as inflation - which we haven't established a way of getting a peg on yet.
In addition, the reward would become woefully inadequate to sustain the network, requiring another hard-fork immediately, with even a moderate spike in popularity (causing another wave of folks to "claim").

[almightyruler]

Interesting, I've just noticed that PoS blocks do not appear in my transaction list. But they clearly show for you. I'm on a commandline client under *nix, presumably you're using the Windows -qt client?

My client has definitely staked before - it did so when I was about to send to Poloniex, locking part of the balance for about a day. The amount showed under 'stake' via 'getinfo'

The only transactions showing in the transaction list are the initial grants (30000+ confirms) and 3 sends a few days ago. Am I missing something?

edit: just to confuse things, a client I'm running on another machine - same version, same OS - does show PoS blocks as expected ('generate')

[Zer0Sum]

The target of the network at launch was to hit ~1% yearly inflation based on the total money supply.
Of coarse, CLAMS is odd in that the total money supply is unknown.

If you assume that the majority of CLAMS are claimed at some unknown time in the future (Less non-retrievable coins of coarse), then the claiming of the coins would not be considered inflation -> they already exist on the chain and can be claimed at any given moment.  This isn't accurate. 

If you assume they will not be claimed, then the act of claiming the coins itself is a sort of inflation.  This isn't accurate either.

So which do you go with?
If you choose to not count the un-claimed coins, then estimates of "inflation" are entirely useless.  Many people claiming, or a large service claiming (such as Poloniex's giveaway) would entirely destroy any attempt at an estimate.
If you choose to count un-claimed coins, under the logic that they exist and could enter the system at any moment, then you greatly under estimate yearly inflation.

Frankly, it is a very difficult question; and there isn't really any "prior art" or standard way of dealing with it that we are aware of.
I am choosing to speak of it as if the CLAMS on chain are CLAMS in existence, because they can enter the money supply at any moment, and that is the only solid immovable reference point from which to function.

So, if you don't count CLAMS possible; you're yearly inflation numbers will be much higher than ~1%.
But then, you would also have to count every CLAM claimed as inflation - which we haven't established a way of getting a peg on yet.
In addition, the reward would become woefully inadequate to sustain the network, requiring another hard-fork immediately, with even a moderate spike in popularity (causing another wave of folks to "claim").

I don't understand why you failed to code a way of knowing how many clams are found and "live"...
Every successful wallet scan should flag those clams as "live" and transmit to the network...
Without this number you have no way of knowing the number of coins. Or do you???

In this context discussion of 1% staking and "inflation" is absurd...
There are coins staking 50%, 100%, 200%, now one nut just launched a 750% stake coin.

This is a promotion driven business...
You are completing against at least 500 coins of which 90% will die.

[dooglus]

Interesting, I've just noticed that PoS blocks do not appear in my transaction list. But they clearly show for you. I'm on a commandline client under *nix, presumably you're using the Windows -qt client?

My client has definitely staked before - it did so when I was about to send to Poloniex, locking part of the balance for about a day. The amount showed under 'stake' via 'getinfo'

The only transactions showing in the transaction list are the initial grants (30000+ confirms) and 3 sends a few days ago. Am I missing something?

edit: just to confuse things, a client I'm running on another machine - same version, same OS - does show PoS blocks as expected ('generate')

I am running the QT client under Linux precisely because of the issue you describe. I could find a way to get the command line client to reliably indicate that I owned any outputs recently used in staking. They would reappear after hitting maturity, and sometimes wouldn't disappear at all.

I don't understand why you failed to code a way of knowing how many clams are found and "live"...
Every successful wallet scan should flag those clams as "live" and transmit to the network...
Without this number you have no way of knowing the number of coins. Or do you???

In general there is no way of knowing how many clams have been "claimed". You could modify the client to violate my privacy and report on how many clams I have claimed, and I could remove your change if I didn't want it.

If I chose to start staking, then it becomes public knowledge that my clams are "live". You could count up all the clams from the initial distribution and see how many have been used in staking. That would give a pretty good indication of how many have been claimed.

[dooglus]

See http://khashier.com:2750/block/d3e163be7ecb84fe387ad34b1f3a6e59604e263ab7875136f1a447503b18a95c which shows I got 0.10000116 instead of the usual 0.01000000!
I'm such a lottery winner!

LoL, Winner Winner, CLAMicken Dinner!

Okay, not 'huge', but a special block none-the-less

I got another:

http://khashier.com:2750/block/1ccbfe52a98733d4e804b005f298537dabdb61679662879c9299b51dbfc97969

This time it was a massive 0.10010956 reward!

I added some debug to see how it comes up with the subsidy amount:

Code:

randSpan: 2147483647.000000
hash: 2dd526f7d04b8581c64e37dc04a601e411ce122905dd461b7ae399684bd2669a
          substr: 8581c64
seed: 139992164
random: 2136041863
randCoefficient: 0.994672
nCoefficient: 0.000000
nSubsidy: 10010956.000000

Basically, the 'random' number has to be very high to get a non-minimum reward. Mine was in the top 99.46% and still only got 11k extra satoshis.

[almightyruler]

Interesting, I've just noticed that PoS blocks do not appear in my transaction list. But they clearly show for you. I'm on a commandline client under *nix, presumably you're using the Windows -qt client?

My client has definitely staked before - it did so when I was about to send to Poloniex, locking part of the balance for about a day. The amount showed under 'stake' via 'getinfo'

The only transactions showing in the transaction list are the initial grants (30000+ confirms) and 3 sends a few days ago. Am I missing something?

edit: just to confuse things, a client I'm running on another machine - same version, same OS - does show PoS blocks as expected ('generate')

I am running the QT client under Linux precisely because of the issue you describe. I could find a way to get the command line client to reliably indicate that I owned any outputs recently used in staking. They would reappear after hitting maturity, and sometimes wouldn't disappear at all.

Are you using the same wallet.dat and block db for both clients, or are they effectively separate? Definitely a worry that a stake is not shown in the tx list. I also noticed that my client didn't seem to want to stake, even though I'd had PoS disabled for a few days (via reservebalance). Once reservebalance was set to zero, CPU usage did not change - typically I can see a PoS client climbing in the CPU usage list when it is eligible to stake.

I restarted from scratch 7.5 hours ago with a fresh wallet and zero reservebalance; will see what happens.

[kbroadfoot]

I needz MOAR CLAMz

[kbroadfoot]

TX ID: 84ca6648976ce1c218f363acfccc273c6d87dee4f9649417761efac96bf28934

Reward: 0.11

( I win )

[almightyruler]

TX ID: 84ca6648976ce1c218f363acfccc273c6d87dee4f9649417761efac96bf28934

Reward: 0.11

( I win )

07/13/14 19:49:58 DebugProofOfStakeReward hash=4f83c952dda0866791df seed=140933405 random=1145612615 randCoefficient=0.533467445 nCoefficient=0.000000000 nSubsidy=0.10

That appears to be a standard 0.1 block. The extra 0.01 is probably from fees.

[kbroadfoot]

TX ID: 84ca6648976ce1c218f363acfccc273c6d87dee4f9649417761efac96bf28934

Reward: 0.11

( I win )

07/13/14 19:49:58 DebugProofOfStakeReward hash=4f83c952dda0866791df seed=140933405 random=1145612615 randCoefficient=0.533467445 nCoefficient=0.000000000 nSubsidy=0.10

That appears to be a standard 0.1 block. The extra 0.01 is probably from fees.

Aw....  I thought I ruled 

[dooglus]

That appears to be a standard 0.1 block. The extra 0.01 is probably from fees.

Aw....  I thought I ruled  

Maybe you do, but "lucky" blocks will almost always have "messy" rewards, going to 7 or 8 decimal places.

I just plotted a chart showing how likely various rewards are:



What it's saying is that:

98.4682% of the time, your reward is exactly 0.1
99.5% of the time, your reward is very close to 0.1 (0.1003 or less),
99.6% of the time, your reward is 0.106 or less,
99.7% of the time, your reward is 0.2256 or less,
99.7659% of the time your reward will be less than 1,
99.8% of the time, your reward is 2.4948 or less,
99.8475% of the time, it's less than 10,
99.9% of the time, it's less than 47.702,
99.9239% of the time, it's less than 100,
etc.

Edit: I just noticed I set a new personal best mining reward:
http://khashier.com:2750/block/564c29502b6df08cc9ee84892b85e7ce9e03ac7fae4478375efab1d836b8ff96 got 0.16 clams - the 0.10 minimum and 6 separate 0.01 fees.

Edit2: added more data points to the text description

[phzi]

I just plotted a chart showing how likely various rewards are:

https://i.imgur.com/9ZpEh4M.png

What it's saying is that:

99.76% of the time your reward will be less than 1,
99.84% of the time, it's less than 10,
99.9% of the time, it's less than 60,
99.92% of the time, it's less than 100,
etc.

Thanks for running the calculations and creating this chart.  Definitely makes the hard-fork much more understandable.

[dooglus]

I just plotted a chart showing how likely various rewards are:

https://i.imgur.com/9ZpEh4M.png

What it's saying is that:

99.76% of the time your reward will be less than 1,
99.84% of the time, it's less than 10,
99.9% of the time, it's less than 60,
99.92% of the time, it's less than 100,
etc.

Thanks for running the calculations and creating this chart.  Definitely makes the hard-fork much more understandable.

To be clear, I ran simulation for 10 million different hashes, counted up the rewards, and plotted it. Interesting how most of the chart is very close to a straight line when plotted with a log y axis.

I've been thinking about the best strategy re. deliberately not submitting min-reward blocks. It looks to me like withholding is possibly never a good strategy.  For example, 99.84% of the time the reward is less than 10, so if you decided to withhold blocks until you got a reward of 10 or more, on average you would be withholding way more than 100 0.1 blocks before you got your reward of 10. Similarly you need to withhold more than 1000 blocks to expect to get a reward of 1000 times 0.1 or more. And so on.

In short it looks like withholding low-reward blocks in the hope of getting a high-reward block later may be a losing strategy.

[kyma]

mac users are on the sidelines waiting to claim their clams?

[maccd123]

I'm only getting stakes reward every 500 blocks(.1 Clam) Is there anything I can change? Thank you.

[dooglus]

I'm only getting stakes reward every 500 blocks(.1 Clam) Is there anything I can change? Thank you.

Each time you use a transaction output to create a block, it takes 510 blocks before the resulting (slightly bigger) output is "mature". While you're waiting for the 510 blocks you can't spend or mine with that output.

You can split your output into 2 smaller outputs (by sending half of its value to yourself). Each smaller output will on average take twice as long to mine a block and so won't make a net difference to your "income", except if the 510 block waiting period is significant. That is, if your large coin is big enough that you would normally expect it to mine a block within 510 blocks, it's worth splitting it up until the parts are small enough that they each take an average of more than 510 blocks each to mine.