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

[ari14]

Thank you for the well written explanation......i didn't see anything about unstaked coins

Any pile of coin that's available as an input to a transaction is "unstaked" - it's either too young or it's currently "staking" (trying to solve a block). The chance of those piles "staking" is based on the number of coins and the "age" (i.e. time, number of confirms etc.) which combine to give the "weight". In that coin control screen you can see how the coins are split up (number of inputs per address) and the number of confirmations. This gives you an insight into their weight. Every pile of coins can potentially stake, although it has been pointed out that if less than (or equal to?) 0.1 coins it effectively has 0 chance.

As Superclam says, when you send coins you might "break up" a partially used input and the "age" for that input (chance it will earn a reward) resets. This is not good and should be avoided, as it will mean that these coins will take that much longer to stake.

What's unique about CLAMs over traditional POS is that while logic might suggest that you should have all your coins in one pile (number of coins adds weight) that doesn't work out so well in practice because the reward is fixed(*). While your larger pile of coins has a better chance of solving a block than a smaller one (at the same age), a set of smaller blocks will all eventually stake anyway, potentially giving you a higher return (multiple rewards rather than just one). How you split up your coins to maximise returns is up to you to decide.

"Staked" coins don't appear as available as inputs in the coin control window - their total is displayed on the main screen as "Stake" and are unavailable to spend for 510 confirms.

(*) Although the standard reward is fixed (0.1 CLAM) there is a chance of a (much) higher payout should you be lucky and hit a lotto block (up to 1,000 CLAM). Each time you solve a block there's the potential to "win" one of these, so it's another reason why multiple smaller piles of staking coins is much better than a single larger one.

Hope the above helps!

I have a doubt.
"Coin Control" screen can be seen in tree mode or in list mode. When I see it in tree mode I notice that there are addresses with 1 node inside and addresses with more than 1 node inside. The question is: Which is called "pile" (or "output") ?  Is it each one of the nodes belonging to one address, or all the nodes of an address ?.  If I have the address A with 2 nodes, one with 5 CLAM and other with 3 CLAM; if I select the node of 3 CLAM and send it to another address, the age of node of 5 CLAM will be reseted ?

Thanks.

[istvandv]

I have a doubt.
"Coin Control" screen can be seen in tree mode or in list mode. When I see it in tree mode I notice that there are addresses with 1 node inside and addresses with more than 1 node inside. The question is: Which is called "pile" (or "output") ?  Is it each one of the nodes belonging to one address, or all the nodes of an address ?.  If I have the address A with 2 nodes, one with 5 CLAM and other with 3 CLAM; if I select the node of 3 CLAM and send it to another address, the age of node of 5 CLAM will be reseted ?

Thanks.

No, the age of the 5 CLAMS will not reset

[dooglus]

If I have the address A with 2 nodes, one with 5 CLAM and other with 3 CLAM; if I select the node of 3 CLAM and send it to another address, the age of node of 5 CLAM will be reseted ?

Thanks.

Addresses almost never matter. It's all about the individual outputs. Your 3 and your 5 are separate things with their own ages.

The client will probably merge them into a single output when either of them stakes, so you might want to keep them in different addresses. That will stop them being merged.

[ari14]

I have a doubt.
"Coin Control" screen can be seen in tree mode or in list mode. When I see it in tree mode I notice that there are addresses with 1 node inside and addresses with more than 1 node inside. The question is: Which is called "pile" (or "output") ?  Is it each one of the nodes belonging to one address, or all the nodes of an address ?.  If I have the address A with 2 nodes, one with 5 CLAM and other with 3 CLAM; if I select the node of 3 CLAM and send it to another address, the age of node of 5 CLAM will be reseted ?

Thanks.

No, the age of the 5 CLAMS will not reset

Thanks

[istvandv]

looks like the address x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w has a ton of 2.6 clam piles

when i try to check http://khashier.com:2750/address/x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w
it says "I'm sorry, this address has too many records to display."

this address has lots of POS blocks, i would have thought the client would combine the clams since they are staking in less than 24 hrs

[dooglus]

this address has lots of POS blocks, i would have thought the client would combine the clams since they are staking in less than 24 hrs

The client is open source. I changed my copy to stop it combining outputs when they stake. The default behaviour is to combine all the outputs at the address that is staking into a single large output (up to 1000 CLAMs), thereby destroying the age of all those outputs for no benefit.

That may have made sense when the reward for staking was proportional to the amount being staked, but now that staking rewards are independent of the amount being staked it makes no sense at all the combine your outputs.

Edit: if you want the same behaviour without modifying your client, you can put each of your outputs at a different address. Combining only happens to outputs which share the same address.

[paulc010]

Edit: if you want the same behaviour without modifying your client, you can put each of your outputs at a different address. Combining only happens to outputs which share the same address.

Which is what I've done, although it begs the question - is there a limit to the number of addresses per wallet?

[dooglus]

Which is what I've done, although it begs the question - is there a limit to the number of addresses per wallet?

The wallet gets slower the more addresses you have, because it has to scan all incoming blocks and transactions against its list of addresses to see if any of them affect any of the addresses it owns. You probably won't notice that being a problem until you have thousands of addresses.

One thing I have noticed is that splitting your CLAMs into lots of small outputs puts quite a load on your CPU (whether they're at the same address or not doesn't make a difference here) since each output gets checked every second to see whether it is able to stake a block in that second. At a certain point it starts taking more than a second to check each output for stakability...

I currently have over a thousand separate outputs being checked each second and it's beginning to use all available CPU doing the checking.

That surprises me, since each 'check' is an sha256 (I think) hash. My CPU should be capable of doing a thousand hashes per second with no trouble I would have thought. Maybe hashing isn't the slowest bit, and there's some bottleneck in the client that could be improved upon.

[dooglus]

I don't think I ever posted this:

http://pastie.org/9456438

It's a small Python script that takes any number of BTC, LTC, DOGE, and CLAM addresses and gives links to the corresponding blockchain explorer pages for the equivalent BTC, LTC, DOGE, and CLAM addresses.

When there was a giant influx of newly dug CLAMs about a week ago, I ran this script on a bunch of the CLAM addresses that were staking, and discovered that the new CLAMs were being dug from DOGE addresses.

Here's an example of it in use:

$ ./clam.py 18KSgPcNRPi9K4bp91Vb3pVNygPon4y5Pw x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w

   BTC: http://blockchain.info/address/18KSgPcNRPi9K4bp91Vb3pVNygPon4y5Pw
  DOGE: http://dogechain.info/address/DCTYDeZ1iocRr4nQsbV9baeyrp878jRzaG
   LTC: http://block-explorer.com/address/LSYPwbvCW3xCZsHyK9UtKqZ9Btm5wrJXxa
  CLAM: http://khashier.com:2750/address/xFd5aGSqh7CBMShgVV8FUznACnh3DALPss


   BTC: http://blockchain.info/address/128PnUZvozqpLmM54pTioy7Giivj44ketX
  DOGE: http://dogechain.info/address/D6GVKjWa7Qk6smXfoQTHMjGsbrf2Nvx5Po
   LTC: http://block-explorer.com/address/LLMM3gsktf5sba3EExT25zB2vwJ17S9JV2
  CLAM: http://khashier.com:2750/address/x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w


It uses https://github.com/jgarzik/python-bitcoinlib.git to do the heavy lifting, so you'll need to fetch that using git, and update the path to it in the script itself.

Edit: I forgot to say why this is useful... If you only just heard about CLAMs, and are worried about sharing your Bitcoin wallet with the CLAM client, you can use this script to convert your BTC addresses to CLAM addresses and look up the balance on the CLAM address without needed to give anyone your private keys at all. Bear in mind that your wallet probably has a bunch of "change" addresses in it which it carefully hides from view, and those change addresses may have CLAMs on them too, so you probably have more CLAMs than you think...

Edit2: the two addresses I gave in the example aren't great. The first is a BTC address that wasn't funded for the initial CLAM distribution, and the second is a CLAM address that I created in the CLAM client. But you get the idea!

[paulc010]

Here's a weird one. I have an address in my wallet that has aged nicely but that's not staking, well not since this:

http://khashier.com:2750/tx/d0c9d9695110200d714a70b65a1ec42f4281988835cf0035d0119243134ec6f3

It shows as "Not yet redeemed"...??!

Any ideas?

EDIT: I ran the client with -salvagewallet but all that seems to have done is mess up the addresses (many more appearing as change even though they were sent to multiple individual addresses) and removed the labels :/

Sorted out in my head by dooglus in IRC. All normal

Going back to chillin' with my CLAMS....

[ari14]

If I have the address A with 2 nodes, one with 5 CLAM and other with 3 CLAM; if I select the node of 3 CLAM and send it to another address, the age of node of 5 CLAM will be reseted ?

Thanks.

Addresses almost never matter. It's all about the individual outputs. Your 3 and your 5 are separate things with their own ages.

The client will probably merge them into a single output when either of them stakes, so you might want to keep them in different addresses. That will stop them being merged.

Thanks !

[dooglus]

Here's a weird one. I have an address in my wallet that has aged nicely but that's not staking, well not since this:

http://khashier.com:2750/tx/d0c9d9695110200d714a70b65a1ec42f4281988835cf0035d0119243134ec6f3

It shows as "Not yet redeemed"...??!

Any ideas?

Sorted out in my head by dooglus in IRC. All normal

Here's the IRC log, in case anyone else is interested in how we sorted it out:

01:42 < dooglus> paul: http://khashier.com:2750/address/xL1vCQ2Xbwg5mz7tvte4hXcMfBKKfgQr4D
01:42 < dooglus> you see it's been staking regularly
01:42 < dooglus> every 4 days or so
01:42 < dooglus> it's due...
01:43 < dooglus> 'not yet redeemed' just means the current output hasn't staked yet
01:43 < dooglus> (or otherwise been spent)
01:43 < paulc010> Yes it was. Maybe it's my ignorance of how these things work but I added new coins in 5 coin piles and they've staked before those.
01:44 < dooglus> it's random
01:44 < paulc010> Ah - right that makes sense. I went to check on others but the explorer was down
01:45 < paulc010> See I'm thinking 5 coins at 3k confirms would stake after 3.4 coins at almost 8k confirms
01:45 < dooglus> see this one:
01:45 < dooglus> http://khashier.com:2750/tx/36012e5359b1834e20a45d6dec3e1aff81d9da76c96b6860dc24640b564e9534#i0
01:45 < paulc010> But two of them staked today
01:45 < dooglus> 130 different 5 CLAM outputs
01:45 < dooglus> some staked, some didn't (yet)
01:46 < dooglus> (looking at the 'redeemed at input' column of the list of outputs)
01:46 < paulc010> (that should be 4.3 not 3.4 of course)
01:46 < dooglus> every second, each output has a chance of staking, proportional to its age and its size
01:46 < paulc010> Yup - I see it now. Just didn't have a clue what that meant
01:47 < paulc010> Hence the CPU load you mentioned in the thread
01:48 < dooglus> the 'not yet redeemed' turns into a link to the transaction in which they staked (or were spent) once they stake (or are spent)
01:48 < paulc010> Got it
01:48 < dooglus> so click the link on output 13 - you see the 5 staking into two 2.55's
01:48 < dooglus> (nether of which has since yet staked again)
01:49 < dooglus> if you trace http://khashier.com:2750/tx/b74eb0568ed7727c3da8c40eee8083eed615ddc7ed2bbe5a29872965a9f919fc you'll see it split over and over as it stakes
01:49 < paulc010> OK
01:49 < dooglus> halving each time - until I finally remembered it when it was mature and split it into those 5's
01:50 < dooglus> oh, I got output 2 right away, but not output 1
01:50 < paulc010> I was about to ask why it split into 5s lol
01:51 < paulc010> Normal behaviour would be for it to halve each staking, yes?
01:51 < paulc010> Ah, looking at the other one it's halving

[istvandv]

thanks for sharing the IRC logs, i was not online to see that, very informative

and thanks for all the contribution, dooglus, i keep learning day by day 

[almightyruler]

I use the daemon rather than the -qt client, so I believe I'm missing out on coin control functionality. I just inadvertently destroyed half of my weight by trying to split one of my unspent outputs into 4 pieces (was hoping it would split the output with the least confirms, but instead it gobbled up one of the oldest in the very first transaction.)

I thought that perhaps using multiple accounts and 'sendfrom' may solve this problem, but stitching together a transaction would probably ignore accounts and just use all available outputs, correct?

If so, I guess creating raw transactions are the only solution... but the potential for mistakes - such as forgetting the change address and giving the remnant balance as a fee to the next person who mines a block - seems high with this one.

[dooglus]

If so, I guess creating raw transactions are the only solution... but the potential for mistakes - such as forgetting the change address and giving the remnant balance as a fee to the next person who mines a block - seems high with this one.

That's what I do:

cc sendrawtransaction $(cc signrawtransaction $(cc createrawtransaction '[{"txid":"5c4a0eee3cce1c82b460df0b527570f00ce5f02f5378d88c8ec56cae0ee713a9","vout":1},{"txid":"5c4a0eee3cce1c82b460df0b527570f00ce5f02f5378d88c8ec56cae0ee713a9","vout":2}]' '{"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":5,"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":5,"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":5,"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":5,"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":5,"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":5,"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":5,"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":5,"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":5,"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":5,"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":5,"x9S2gMQQ5iKrP9SwRJ6PF9Q3wqDxRegc2w":2.13990000}') | grep hex | cut -d'"' -f4)

[almightyruler]

The client is open source. I changed my copy to stop it combining outputs when they stake. The default behaviour is to combine all the outputs at the address that is staking into a single large output (up to 1000 CLAMs), thereby destroying the age of all those outputs for no benefit.

That may have made sense when the reward for staking was proportional to the amount being staked, but now that staking rewards are independent of the amount being staked it makes no sense at all the combine your outputs.

Any plans to offer this change for a future version? I'm familiar with *coind source in general, but I'm not yet comfortable with the inner workings of creating transactions (as evidenced by my above failure.)

edit: even a change in algorithm which prefers newer outputs when creating a transaction would probably help the network, in the long run.

[dayandnight]

The concept of proof of chain and proof of pearl is intresting.will notice!

[istvandv]

The client is open source. I changed my copy to stop it combining outputs when they stake. The default behaviour is to combine all the outputs at the address that is staking into a single large output (up to 1000 CLAMs), thereby destroying the age of all those outputs for no benefit.

That may have made sense when the reward for staking was proportional to the amount being staked, but now that staking rewards are independent of the amount being staked it makes no sense at all the combine your outputs.

Any plans to offer this change for a future version? I'm familiar with *coind source in general, but I'm not yet comfortable with the inner workings of creating transactions (as evidenced by my above failure.)

edit: even a change in algorithm which prefers newer outputs when creating a transaction would probably help the network, in the long run.

if i have my info right, devs are updating wallet to improve further the algorithm for auto combining and splitting the coins to maximize staking efficiency as well as having the option to manually control how coins will split/combine

[dooglus]

Any plans to offer this change for a future version? I'm familiar with *coind source in general, but I'm not yet comfortable with the inner workings of creating transactions (as evidenced by my above failure.)

Oh, it was pretty trivial.

Edit src/wallet.cpp and change:

int64_t nStakeCombineThreshold = 1000 * COIN;

to

int64_t nStakeCombineThreshold = 0 * COIN;

[Karn]

ok so make more addys in my wallet and send X number of coins to each for best staking? I only have 15 so any thing that gives me a slightly higher chance of a lotto block would be worth doing.