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

[dooglus]

Black vortex. You know, something silly like that...

Do you mean kimoto gravity well?

Doesn't sound right to me. I think it was cooler sounding.

I guess I'm thinking of this, from https://en.wikipedia.org/wiki/Dogecoin:

On March 12, 2014, version 1.6 of the Dogecoin client was announced. Along with allowing for there to be a fixed reward per block, the new client update also introduced a new difficulty algorithm called DigiShield

But KGW looks interesting too:

http://bitcoin.stackexchange.com/questions/21730/how-does-the-kimoto-gravity-well-regulate-difficulty

My point is that there are probably better ways to retarget the difficulty than the naive way we're currently doing it (which in turn is better than the way we were doing it before...).

[dooglus]

If I have 1 clam and I split it as far as possible down to 100,000,000 "clamtoshis" in order to have the best chance to stake is this really the right thing to do?  And if everyone else does it wouldn't it make your UTXO set astronomically huge?  And wouldn't it make spending any reasonable amount of clams extremely expensive (because of all the nano-outputs you'd have to reference)?

I'm sure I'm missing something.  Thanks in advance!

Splitting a CLAM into 10^8 separate outputs is going to cost you a lot in transaction fees.

Splitting is a case of diminishing returns. The gains you get from splitting 1 CLAM into two halves are far bigger than any gain from splitting those two halves into 4 quarters.

And yes, merging those outputs back into a single output will also cost you a fortune in transaction fees.

So it's a trade-off. There's pressure in both directions (too little splitting and your coins spend too much of their life "maturing"; too much splitting and you pay a lot of transaction fees both when splitting and when re-joining, and use too much CPU time checking all your outputs for staking opportunities), and so you can solve some equations to find the optimal splitting level based on how long you anticipate staking for, the speed of your staking machine, the price of CLAM, etc. (Or you can just set all your outputs to be 13.37 CLAM each because you think the number is 'kewl').

[SuperClam]

Black vortex. You know, something silly like that...

Do you mean kimoto gravity well?

Doesn't sound right to me. I think it was cooler sounding.
I guess I'm thinking of this, from https://en.wikipedia.org/wiki/Dogecoin:

On March 12, 2014, version 1.6 of the Dogecoin client was announced. Along with allowing for there to be a fixed reward per block, the new client update also introduced a new difficulty algorithm called DigiShield

But KGW looks interesting too:
http://bitcoin.stackexchange.com/questions/21730/how-does-the-kimoto-gravity-well-regulate-difficulty
My point is that there are probably better ways to retarget the difficulty than the naive way we're currently doing it (which in turn is better than the way we were doing it before...).

The main concept behind the the DigiShield and Kimoto Gravity Well was resistance to multi-pool hash "attacks".

If I understand Kimoto Gravity Well correctly, it worked by applying a curve such that more recent blocks have a higher weight in the equation that figures the next difficulty target.  This is of course similar to simple one block re-targets which were also a popular "solution".

DigiShield had implementation and exploit-ability issues.  I know because I was closely involved in the project when that feature was launched.  It functioned by making the difficulty adjustment non-symmetric.  In testing, this seemed to show a reduction in the type of "wave" oscillation you see as adjustments over-shoot.  In practice, it didn't work all that well.

xploited might be able to offer some insight into DigiShield's problems; as he was even more closely involved in it's inception.

[dooglus]

The main concept behind the the DigiShield and Kimoto Gravity Well was resistance to multi-pool hash "attacks".

If I understand Kimoto Gravity Well correctly, it worked by applying a curve such that more recent blocks have a higher weight in the equation that figures the next difficulty target.  This is of course similar to simple one block re-targets which were also a popular "solution".

DigiShield had implementation and exploit-ability issues.  I know because I was closely involved in the project when that feature was launched.  It functioned by making the difficulty adjustment non-symmetric.  In testing, this seemed to show a reduction in the type of "wave" oscillation you see as adjustments over-shoot.  In practice, it didn't work all that well.

xploited might be able to offer some insight into DigiShield's problems; as he was even more closely involved in it's inception.

I didn't realise you guys were at all involved with DigiShield, or I probably wouldn't have been so flippant about it. Which coin were you involved with which first added DigiShield? Was it a DOGE thing? I really don't pay much attention to other altcoins.

While we don't have to worry about multi-pools we do have to be able to cope with sudden changes to the total network stake weight. A big staker could go offline temporarily leaving the difficulty too high for a while, or someone could dig up a bunch of distribution CLAMs and start staking them, leaving the difficulty too low for a while. The effect is similar to a big multi-pool visiting.

With the first (single block) difficulty retargetting what would happen that due to variance we would see 20 second gap between blocks occasionally, and the retargetting algorithm would overreact, setting the difficulty far too high, and it would take quite a while for things to recover. That would leave us with >2 minute blocks for a while, when all that had happened was one staker got lucky once.

Are there any plans for a hard fork any time soon? If so, it would be worth experimenting with the various adjustment algorithms and seeing what we can do to improve things. I imagine running a simulation, plotting the difficulty over time with various different retarget algorithms, etc. If not, I don't think it's a big enough problem to warrant a hard fork on its own.

[daxxog]

Hey guys. Just created an instant exchange. It allows you to permanently link a bitcoin deposit address to a CLAM address. So you could use it to buy CLAMS automatically with coinbase or something. Also included is a simple API. If you have any questions, shoot me an email. Thanks!

https://clamgate.com/

[BayAreaCoins]

Hey guys. Just created an instant exchange. It allows you to permanently link a bitcoin deposit address to a CLAM address. So you could use it to buy CLAMS automatically with coinbase or something. Also included is a simple API. If you have any questions, shoot me an email. Thanks!

https://clamgate.com/

If it could scroll down on its own (the text box.)

[daxxog]

Hey guys. Just created an instant exchange. It allows you to permanently link a bitcoin deposit address to a CLAM address. So you could use it to buy CLAMS automatically with coinbase or something. Also included is a simple API. If you have any questions, shoot me an email. Thanks!

https://clamgate.com/

If it could scroll down on its own (the text box.)

Yeah I suppose I could add that feature. I mainly put the text box in so developers could easily see how the API works.

[BayAreaCoins]

Hey guys. Just created an instant exchange. It allows you to permanently link a bitcoin deposit address to a CLAM address. So you could use it to buy CLAMS automatically with coinbase or something. Also included is a simple API. If you have any questions, shoot me an email. Thanks!

https://clamgate.com/

If it could scroll down on its own (the text box.)

Yeah I suppose I could add that feature. I mainly put the text box in so developers could easily see how the API works.

ahhh no worries man! I just like chipping my 2 cents at shit lol

[dooglus]

Hey guys. Just created an instant exchange. It allows you to permanently link a bitcoin deposit address to a CLAM address. So you could use it to buy CLAMS automatically with coinbase or something. Also included is a simple API. If you have any questions, shoot me an email. Thanks!

https://clamgate.com/

The BTC address field is editable. Does that mean the service works in both directions? Can I give a BTC address and get a linked CLAM address?

If not, the BTC address field should be readonly.

[daxxog]

Hey guys. Just created an instant exchange. It allows you to permanently link a bitcoin deposit address to a CLAM address. So you could use it to buy CLAMS automatically with coinbase or something. Also included is a simple API. If you have any questions, shoot me an email. Thanks!

https://clamgate.com/

The BTC address field is editable. Does that mean the service works in both directions? Can I give a BTC address and get a linked CLAM address?

If not, the BTC address field should be readonly.

The service only works in one directions. I changed it to readonly as you suggested. Thanks!

@bayareacoins I also added auto scrolling to the textbox

[dooglus]

Hey guys. Just created an instant exchange. It allows you to permanently link a bitcoin deposit address to a CLAM address. So you could use it to buy CLAMS automatically with coinbase or something. Also included is a simple API. If you have any questions, shoot me an email. Thanks!

https://clamgate.com/

The BTC address field is editable. Does that mean the service works in both directions? Can I give a BTC address and get a linked CLAM address?

If not, the BTC address field should be readonly.

The service only works in one directions. I changed it to readonly as you suggested. Thanks!

@bayareacoins I also added auto scrolling to the textbox

Maybe having it work in both directions would be better - if the volume in both directions was similar you could save a lot on exchange fees, and either pass the saving on to the users or keep it for yourself...

[daxxog]

Hey guys. Just created an instant exchange. It allows you to permanently link a bitcoin deposit address to a CLAM address. So you could use it to buy CLAMS automatically with coinbase or something. Also included is a simple API. If you have any questions, shoot me an email. Thanks!

https://clamgate.com/

The BTC address field is editable. Does that mean the service works in both directions? Can I give a BTC address and get a linked CLAM address?

If not, the BTC address field should be readonly.

The service only works in one directions. I changed it to readonly as you suggested. Thanks!

@bayareacoins I also added auto scrolling to the textbox

Maybe having it work in both directions would be better - if the volume in both directions was similar you could save a lot on exchange fees, and either pass the saving on to the users or keep it for yourself...

Currently working on a CLAM to BTC feature that will give users back a portion of the staking profit received while the CLAMs are in order book limbo.

[dooglus]

Edit: I don't see how to adjust the date range on your chart, but http://blocktree.io/charts/CLAM shows this:



The difficulty wasn't really 0 before November 2014, it just looks that way when you don't use a log y-axis.

I made a chart of the difficulty over time with a log y-axis:



It clearly shows the difficulty adjusting upwards dramatically when v2 of the protocol was introduced.

[almightyruler]

I've been working on some code to detect forked peers - the kind who keep asking for the same blocks, over and over, in an endless loop. It's for another coin, where there are a couple of peers who have been doing this for literally months, but apart from changing printf("... to LogPrint("net", "... it's a straight copy & paste into the CLAM source:

https://github.com/almightyruler/cloudcoin/commit/fdecc06a54600c4de0be6b683fdaa90dc194da79

Basically it detects when the peer sends a getblocks request that is lower than its previous maximum. This will allow a peer to ride up the getblocks height as it syncs (with a bit of leeway for dupe requests), but it will be penalised if it goes backwards. If this happens enough times, the peer is banned.

I've been testing this for a few days. Here's an example of one peer which had getblocks requests all over the place:


2015-07-09 17:04:52 receive version message: version 60014, blocks=538391, us=, them=24.84.188.5:31174, peer=24.84.188.5:31174
2015-07-09 17:10:23 peer 24.84.188.5:31174: leap backwards in height request, from max 539176 to current 275001. penalty=1/100
2015-07-09 17:10:28 peer 24.84.188.5:31174: leap backwards in height request, from max 539178 to current 538562. penalty=2/100
2015-07-09 17:11:11 peer 24.84.188.5:31174: leap backwards in height request, from max 539327 to current 276001. penalty=3/100
2015-07-09 17:12:44 peer 24.84.188.5:31174: leap backwards in height request, from max 539537 to current 277001. penalty=4/100
2015-07-09 17:15:29 peer 24.84.188.5:31174: leap backwards in height request, from max 540236 to current 278001. penalty=5/100
2015-07-09 17:16:11 peer 24.84.188.5:31174: leap backwards in height request, from max 540270 to current 279000. penalty=6/100
...
2015-07-09 18:06:20 peer 24.84.188.5:31174: leap backwards in height request, from max 547158 to current 295001. penalty=79/100
2015-07-09 18:07:36 peer 24.84.188.5:31174: leap backwards in height request, from max 547161 to current 435001. penalty=80/100
2015-07-09 18:07:43 peer 24.84.188.5:31174: leap backwards in height request, from max 547161 to current 296001. penalty=81/100
2015-07-09 18:07:59 peer 24.84.188.5:31174: leap backwards in height request, from max 547160 to current 436001. penalty=82/100
2015-07-09 18:08:00 peer 24.84.188.5:31174: leap backwards in height request, from max 547162 to current 297001. penalty=83/100
2015-07-09 18:08:59 peer 24.84.188.5:31174: leap backwards in height request, from max 437001 to current 298001. penalty=84/100
2015-07-09 18:09:01 peer 24.84.188.5:31174: leap backwards in height request, from max 438001 to current 299001. penalty=85/100
2015-07-09 18:09:06 peer 24.84.188.5:31174: leap backwards in height request, from max 439001 to current 300001. penalty=86/100
2015-07-09 18:09:10 peer 24.84.188.5:31174: leap backwards in height request, from max 440001 to current 301001. penalty=87/100
2015-07-09 18:09:13 peer 24.84.188.5:31174: leap backwards in height request, from max 441001 to current 302001. penalty=88/100
...
2015-07-09 18:09:39 peer 24.84.188.5:31174: leap backwards in height request, from max 449001 to current 310001. penalty=96/100
2015-07-09 18:09:41 peer 24.84.188.5:31174: leap backwards in height request, from max 450001 to current 311001. penalty=97/100
2015-07-09 18:09:44 peer 24.84.188.5:31174: leap backwards in height request, from max 451001 to current 312001. penalty=98/100
2015-07-09 18:09:48 peer 24.84.188.5:31174: leap backwards in height request, from max 452001 to current 313001. penalty=99/100
2015-07-09 18:09:50 peer 24.84.188.5:31174: leap backwards in height request, from max 453001 to current 314001. penalty=100/100
2015-07-09 18:09:50 ERROR: peer 24.84.188.5:31174: sync repeatedly leaping backwards to lower height


This peer initially seems to be syncing upwards (start height 538391), but then it jumps back down to requesting blocks around 450k and then 300k. Eventually it gets banned.

Since I added this code the client has connected with 94 different peers; out of those it has banned 2.

Just thought the devs may be interested.

[ryanb]

Is there a new bootstap?

[dooglus]

Is there a new bootstap?

Yes. See https://bitcointalk.org/index.php?topic=623147.msg9772191#msg9772191

[dooglus]

I've been working on some code to detect forked peers - the kind who keep asking for the same blocks, over and over, in an endless loop. It's for another coin, where there are a couple of peers who have been doing this for literally months, but apart from changing printf("... to LogPrint("net", "... it's a straight copy & paste into the CLAM source:

https://github.com/almightyruler/cloudcoin/commit/fdecc06a54600c4de0be6b683fdaa90dc194da79

Basically it detects when the peer sends a getblocks request that is lower than its previous maximum. This will allow a peer to ride up the getblocks height as it syncs (with a bit of leeway for dupe requests), but it will be penalised if it goes backwards. If this happens enough times, the peer is banned.

I've been testing this for a few days. Here's an example of one peer which had getblocks requests all over the place:


2015-07-09 17:04:52 receive version message: version 60014, blocks=538391, us=, them=24.84.188.5:31174, peer=24.84.188.5:31174
2015-07-09 17:10:23 peer 24.84.188.5:31174: leap backwards in height request, from max 539176 to current 275001. penalty=1/100
2015-07-09 17:10:28 peer 24.84.188.5:31174: leap backwards in height request, from max 539178 to current 538562. penalty=2/100
2015-07-09 17:11:11 peer 24.84.188.5:31174: leap backwards in height request, from max 539327 to current 276001. penalty=3/100
2015-07-09 17:12:44 peer 24.84.188.5:31174: leap backwards in height request, from max 539537 to current 277001. penalty=4/100
2015-07-09 17:15:29 peer 24.84.188.5:31174: leap backwards in height request, from max 540236 to current 278001. penalty=5/100
2015-07-09 17:16:11 peer 24.84.188.5:31174: leap backwards in height request, from max 540270 to current 279000. penalty=6/100
...
2015-07-09 18:06:20 peer 24.84.188.5:31174: leap backwards in height request, from max 547158 to current 295001. penalty=79/100
2015-07-09 18:07:36 peer 24.84.188.5:31174: leap backwards in height request, from max 547161 to current 435001. penalty=80/100
2015-07-09 18:07:43 peer 24.84.188.5:31174: leap backwards in height request, from max 547161 to current 296001. penalty=81/100
2015-07-09 18:07:59 peer 24.84.188.5:31174: leap backwards in height request, from max 547160 to current 436001. penalty=82/100
2015-07-09 18:08:00 peer 24.84.188.5:31174: leap backwards in height request, from max 547162 to current 297001. penalty=83/100
2015-07-09 18:08:59 peer 24.84.188.5:31174: leap backwards in height request, from max 437001 to current 298001. penalty=84/100
2015-07-09 18:09:01 peer 24.84.188.5:31174: leap backwards in height request, from max 438001 to current 299001. penalty=85/100
2015-07-09 18:09:06 peer 24.84.188.5:31174: leap backwards in height request, from max 439001 to current 300001. penalty=86/100
2015-07-09 18:09:10 peer 24.84.188.5:31174: leap backwards in height request, from max 440001 to current 301001. penalty=87/100
2015-07-09 18:09:13 peer 24.84.188.5:31174: leap backwards in height request, from max 441001 to current 302001. penalty=88/100
...
2015-07-09 18:09:39 peer 24.84.188.5:31174: leap backwards in height request, from max 449001 to current 310001. penalty=96/100
2015-07-09 18:09:41 peer 24.84.188.5:31174: leap backwards in height request, from max 450001 to current 311001. penalty=97/100
2015-07-09 18:09:44 peer 24.84.188.5:31174: leap backwards in height request, from max 451001 to current 312001. penalty=98/100
2015-07-09 18:09:48 peer 24.84.188.5:31174: leap backwards in height request, from max 452001 to current 313001. penalty=99/100
2015-07-09 18:09:50 peer 24.84.188.5:31174: leap backwards in height request, from max 453001 to current 314001. penalty=100/100
2015-07-09 18:09:50 ERROR: peer 24.84.188.5:31174: sync repeatedly leaping backwards to lower height


This peer initially seems to be syncing upwards (start height 538391), but then it jumps back down to requesting blocks around 450k and then 300k. Eventually it gets banned.

Since I added this code the client has connected with 94 different peers; out of those it has banned 2.

Just thought the devs may be interested.

That looks useful. I will merge it into the CLAM client tree.

Thanks.

[ryanb]

Is there a new bootstap?

Yes. See https://bitcointalk.org/index.php?topic=623147.msg9772191#msg9772191

thank you

[dooglus]

I've been working on some code to detect forked peers - [...]

That looks useful. I will merge it into the CLAM client tree.

Thanks.

I merged it here:

https://github.com/nochowderforyou/clams/commit/c351f7

Thanks again. I'm running it on a couple of servers and haven't seen it trigger at all yet. I'll keep watching.

[almightyruler]

I've been working on some code to detect forked peers - [...]

That looks useful. I will merge it into the CLAM client tree.

Thanks.

I merged it here:

https://github.com/nochowderforyou/clams/commit/c351f7

Thanks again. I'm running it on a couple of servers and haven't seen it trigger at all yet. I'll keep watching.

I think it's a case of, no news is good news. My CLAM client hasn't logged any backward leaps for about 36 hours.