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

[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.

[dooglus]

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.

I got one:

2015-07-12 11:11:49 receive version message: version 60014, blocks=549117, us=, them=0.0.0.0:31174, peer=36.75.220.2:54944
2015-07-12 11:13:45 peer 36.75.220.2:54944: leap backwards in height request, from max 549812 to current 275001. penalty=1/100
2015-07-12 11:13:45 peer 36.75.220.2:54944: leap backwards in height request, from max 549812 to current 276001. penalty=2/100
2015-07-12 11:13:48 peer 36.75.220.2:54944: leap backwards in height request, from max 549812 to current 277001. penalty=3/100
2015-07-12 11:14:02 peer 36.75.220.2:54944: leap backwards in height request, from max 549812 to current 278001. penalty=4/100
2015-07-12 11:14:07 peer 36.75.220.2:54944: leap backwards in height request, from max 549812 to current 279001. penalty=5/100
2015-07-12 11:14:11 peer 36.75.220.2:54944: leap backwards in height request, from max 549813 to current 280001. penalty=6/100
2015-07-12 11:14:13 peer 36.75.220.2:54944: leap backwards in height request, from max 549818 to current 281001. penalty=7/100
2015-07-12 11:14:15 peer 36.75.220.2:54944: leap backwards in height request, from max 549823 to current 282001. penalty=8/100
2015-07-12 11:14:20 peer 36.75.220.2:54944: leap backwards in height request, from max 549833 to current 283001. penalty=9/100
2015-07-12 11:14:22 peer 36.75.220.2:54944: leap backwards in height request, from max 549839 to current 284001. penalty=10/100
2015-07-12 11:14:35 peer 36.75.220.2:54944: leap backwards in height request, from max 550015 to current 285001. penalty=11/100
2015-07-12 11:15:03 peer 36.75.220.2:54944: leap backwards in height request, from max 550407 to current 286001. penalty=12/100
2015-07-12 11:16:11 peer 36.75.220.2:54944: leap backwards in height request, from max 550576 to current 287001. penalty=13/100
2015-07-12 11:18:12 peer 36.75.220.2:54944: leap backwards in height request, from max 550582 to current 288001. penalty=14/100
2015-07-12 11:18:13 peer 36.75.220.2:54944: leap backwards in height request, from max 551047 to current 289001. penalty=15/100

There's no other mention of that peer in the log, so I don't know what happened to it, but that was a while ago now.

Do we have any understanding of why this happens, or ideas about how to prevent the next release from being similarly misbehaved when it is an old version some time in the future?

[almightyruler]

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.

I got one:

2015-07-12 11:11:49 receive version message: version 60014, blocks=549117, us=, them=0.0.0.0:31174, peer=36.75.220.2:54944
2015-07-12 11:13:45 peer 36.75.220.2:54944: leap backwards in height request, from max 549812 to current 275001. penalty=1/100
2015-07-12 11:13:45 peer 36.75.220.2:54944: leap backwards in height request, from max 549812 to current 276001. penalty=2/100
2015-07-12 11:13:48 peer 36.75.220.2:54944: leap backwards in height request, from max 549812 to current 277001. penalty=3/100
2015-07-12 11:14:02 peer 36.75.220.2:54944: leap backwards in height request, from max 549812 to current 278001. penalty=4/100
2015-07-12 11:14:07 peer 36.75.220.2:54944: leap backwards in height request, from max 549812 to current 279001. penalty=5/100
2015-07-12 11:14:11 peer 36.75.220.2:54944: leap backwards in height request, from max 549813 to current 280001. penalty=6/100
2015-07-12 11:14:13 peer 36.75.220.2:54944: leap backwards in height request, from max 549818 to current 281001. penalty=7/100
2015-07-12 11:14:15 peer 36.75.220.2:54944: leap backwards in height request, from max 549823 to current 282001. penalty=8/100
2015-07-12 11:14:20 peer 36.75.220.2:54944: leap backwards in height request, from max 549833 to current 283001. penalty=9/100
2015-07-12 11:14:22 peer 36.75.220.2:54944: leap backwards in height request, from max 549839 to current 284001. penalty=10/100
2015-07-12 11:14:35 peer 36.75.220.2:54944: leap backwards in height request, from max 550015 to current 285001. penalty=11/100
2015-07-12 11:15:03 peer 36.75.220.2:54944: leap backwards in height request, from max 550407 to current 286001. penalty=12/100
2015-07-12 11:16:11 peer 36.75.220.2:54944: leap backwards in height request, from max 550576 to current 287001. penalty=13/100
2015-07-12 11:18:12 peer 36.75.220.2:54944: leap backwards in height request, from max 550582 to current 288001. penalty=14/100
2015-07-12 11:18:13 peer 36.75.220.2:54944: leap backwards in height request, from max 551047 to current 289001. penalty=15/100

There's no other mention of that peer in the log, so I don't know what happened to it, but that was a while ago now.

Do we have any understanding of why this happens, or ideas about how to prevent the next release from being similarly misbehaved when it is an old version some time in the future?

There's a fundamental problem with the base *coin code which makes a forked client request the same set of blocks, in a continuous loop. There seems to be no code for either the asking or answering end to back off when a duplicate request is detected, so it can cause a lot of problems when a large number of clients fork (client hard fork, network problem, etc). I've seen this behaviour happen with many coins (including CLAM), but I'm not sure if it has ever been addressed before. My fix is fairly simple; it would probably be better to be a bit more sophisticated, and keep a running list of blocks that have recently been requested by that peer, sending back a soft "I don't have these blocks" response (or similar) if a peer requests the same set too many times, possibly banning the peer if they continue.

Anyway - at first glance this seems to be a mostly synced peer that is extending its chain to the current network tip, but for some reason it is still scrounging around for blocks that are 7 months behind... which doesn't make sense. I'm not really sure why it would be doing that.

[yudhistira]

just dice seems down and cannot accessed

ERROR 522

[BayAreaCoins]

just dice seems down and cannot accessed

ERROR 522

Doog took it off line for a minute.

Coinbase goes down... BTC drops over 15%.  Coinbase makes a small fraction of BTC. 

Just-dice goes down... CLAM increases.  JD is 90% of clam.

Can anyone argue that those Coinbase fucks arn't manipulating the markets.

[dooglus]

just dice seems down and cannot accessed

ERROR 522

Doog took it off line for a minute.

Coinbase goes down... BTC drops over 15%.  Coinbase makes a small fraction of BTC. 

Just-dice goes down... CLAM increases.  JD is 90% of clam.

Can anyone argue that those Coinbase fucks arn't manipulating the markets.

Trouble with a DDoS and cleaning up the aftermath. Back now.

[chilly2k]

So to effectively stake I should invest my CLAMs at Just-Dice? Is there any real downside to that?
I had thought they would constantly stake, but I only have my computer on for a few hours a day, so guess it isn't going to be worth it in the clam wallet.

I updated to the new wallet and now it says I should stake in 1 day! A big difference!

If you invest at Just-dice you will make more money, but you will be contributing to CLAM being centralized.

   I had to see how this played out. 

from 6/22 - 6/29 I staked 41.0029 clams  the starting size was about 2450

So 7 day at an average of 5.8576 per day.  Would give .00239 %

I always see .002% just staking on JD.  which would be 4.9 clams per day. 

So in my case staking alone is much better an extra 6.7 clams in 7 days.  or 350 clams a year. 

This was a small sample and your mileage may vary.  But it does show that staking solo can be done and can compete with JD. 

There were 2 orphans in the sample.   And I believe one was when I was staking a new block of 250 clams and splitting the output into blocks of 5.

I think that took 2 tries. 

Try this again. 

Dates                     Start Balance     Stakes      Avg/Day   Percentage     Orphans

6/22- 6/28 (7 days)  2456                 37.0027     5.2861     2.15%           2
6/29 -7/5                2493                 26.0005     3.7144     1.49%           2


   I'll try to keep this up for another 2 weeks, to see how variability comes into play.   My stakes have been all over the board from a low of 2 per day to 8 per day.  So over times we should see how it levels out. 

This week I lost almost 48 hours of staking due to a self inflicted power problem / internal network issue.

This is one of the risks self staking carries...
 

Dates                     Start Balance     Stakes      Avg/Day   Percentage     Orphans

6/22- 6/28 (7 days)  2456                 37.0027     5.2861     2.15%           2
6/29 -7/5                2493                 26.0005     3.7144     1.49%           2
7/6 - 7/12               2519                 27.0009     3.8571     1.53%           4   - I think 2 of these were due to my own network issue.   

[RENDERING]

Anyone know how to get my clams back from the dice site? I had some in there and cannot figure out what my login was.

[tspacepilot]

Anyone know how to get my clams back from the dice site? I had some in there and cannot figure out what my login was.

Assuming you're talking about just-dice, you should email dooglus.  His email is listed on the site as:

If you need to contact us, please do so via email: doog.justdice@gmail.com (if you want to encrypt your message, my GPG key is 4BE6A010492A358E).