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

[almightyruler]

Serious problem.

Clients on the old fork are repeatedly requesting the same set of blocks from me. They're stuck in an infinite loop.

My clams client is currently consuming the majority of my link's upstream bandwidth.

The base code doesn't seem to have any way of tracking blocks it has already requested, so there's no way to detect that it asked for the very same block only 10 seconds ago, and back off. Same for the client at my end, which should be refusing to send (or delaying sending) exactly the same data the 2nd, 3rd, 4th, nth time...

I'm either going to have to firewall and allow only IPs which I know are on the correct chain, or just stop the client completely. To be honest, since the lottery was disabled I don't really see much point in keeping the client open.  

[tryphe]

Serious problem.

Clients on the old fork are repeatedly requesting the same set of blocks from me. They're stuck in an infinite loop.

My clams client is currently consuming the majority of my link's upstream bandwidth.

The base code doesn't seem to have any way of tracking blocks it has already requested, so there's no way to detect that it asked for the very same block only 10 seconds ago, and back off. Same for the client at my end, which should be refusing to send (or delaying sending) exactly the same data the 2nd, 3rd, 4th, nth time...

I'm either going to have to firewall and allow only IPs which I know are on the correct chain, or just stop the client completely. To be honest, since the lottery was disabled I don't really see much point in keeping the client open.  

I had this same issue on my DSL connection. The upstream was saturated.

The fix for me was to go into main.cpp Line 3274 or simply search for "getblocks", change:

Code:

        int nLimit = 500;

to

Code:

        int nLimit = 20;

As far as I can tell, this stops you from sending 500 'invalid' (to them not us =p) blocks to the other fork. This causes a little more TCP/local chatter but far less wasted bandwidth.

If you either can't compile, or are using Windows you might want to check out NetLimiter 3. I keep it running on my coins vm and it shapes the bandwidth for selected programs, making peers less likely to request more from you constantly.

[almightyruler]

Code:

        int nLimit = 20;

Cheers for that. debug.log is still filling up with rapid repeated requests, but the excessive outbound bandwidth usage on port 31174 has disappeared.

Funny thing (not really) is that it only took 3 peers on the old fork to saturate my link.

[Thirdspace]

I need some help please... my chain is already at block 170980 before I downloaded the new client
and after I ran the new version, instead of reorganizing & reconnecting to the correct fork it keeps continuing up to 171046 and stuck.
what should I do to go from this situation and back to the right fork without re-downloading the whole chain from 0
is there a way to force my client to start re-download from specified block height from 1-3 trusted hand picked nodes only?
would deleting peers.dat helps weeding out the bad nodes with wrong fork?

[dooglus]

I need some help please... my chain is already at block 170980 before I downloaded the new client
and after I ran the new version, instead of reorganizing & reconnecting to the correct fork it keeps continuing up to 171046 and stuck.
what should I do to go from this situation and back to the right fork without re-downloading the whole chain from 0
is there a way to force my client to start re-download from specified block height from 1-3 trusted hand picked nodes only?
would deleting peers.dat helps weeding out the bad nodes with wrong fork?

I don't know enought about how it works, but from what I know isn't the client meant to treat the longest chain as the best chain? If so, I don't see why it wouldn't "just work".

Anyone?

[tryphe]

I need some help please... my chain is already at block 170980 before I downloaded the new client
and after I ran the new version, instead of reorganizing & reconnecting to the correct fork it keeps continuing up to 171046 and stuck.
what should I do to go from this situation and back to the right fork without re-downloading the whole chain from 0
is there a way to force my client to start re-download from specified block height from 1-3 trusted hand picked nodes only?
would deleting peers.dat helps weeding out the bad nodes with wrong fork?

Deleting peers.dat will definitely help.
Run with "-reindex -rescan -addnode=67.35.116.81:31174" and you should be on the correct chain, although you might have to delete your chain too due to having no versioning discrepancies (most likely you don't have to delete the chain though).

[dooglus]

you might have to delete your chain too due to having no versioning discrepancies.

Why doesn't the longest chain just replace the 2nd longest chain?

Edit: actually, a -reindex should make the client recognise that the blocks on the incorrect fork are no longer valid, right?

[tryphe]

you might have to delete your chain too due to having no versioning discrepancies.

Why doesn't the longest chain just replace the 2nd longest chain?

Edit: actually, a -reindex should make the client recognise that the blocks on the incorrect fork are no longer valid, right?

I think that's right. I've had a few people fork over successfully just from adding me as a node too.

[istvandv]

yehey! i finally won a stake lottery of 1 clam!

oh wait... all stakes are now 1 clam

well thats 10 times what i was getting before! hurray for me!

[macorcina]

you might have to delete your chain too due to having no versioning discrepancies.

Why doesn't the longest chain just replace the 2nd longest chain?

Edit: actually, a -reindex should make the client recognise that the blocks on the incorrect fork are no longer valid, right?

I think that's right. I've had a few people fork over successfully just from adding me as a node too.

i install new client,
 download from scratch whole blockchain ,
and
it's again stuk on blok 171001

after that i type
./clam-qt -reindex -rescan -addnode=67.35.116.81:31174
and  its suck again at blok 171001
plese help

[Thirdspace]

@tryphe your node doesn't seem to be running, I'm getting this a few times on the logfile

trying connection 67.35.116.81:31174 lastseen=365146.2hrs

I deleted peers.dat, used my previous chain with block @170980 wrong fork
run the clam-qt as you instructed with -rescan -reindex and it still perform like before...
it is continuing to 171046 and stuck (still downloading, perhaps trying to figure out the best fork)
currently with 13 active connections, never drop below 10

I think there are still a few (probably many) nodes running on the wrong fork, and my client keeps connecting to them
what is the use of data inside "txleveldb" dir? I was thinking maybe something left over here that makes it advance to 171046
it keeps downloading data from nodes (by looking at my network activity) but the block stuck at 171046
I'm gonna try let it run and hopefully it fixes itself without actually re-downloading the whole chain without warning to me

is there a way to figure out or indication when my client starts reconnecting to the correct chain?
where can I see that... other than checking my best block hash & comparing with khash

[SuperClam]

The patience and faith is appreciated.


The issues reported by some users seem to be similar to issues that have been experienced with other chains (including Bitcoin) after hard-forks. 

We had intended to push another update very soon anyway to incorporate some good work dooglus contributed which fixes some of the timestamp and difficulty fudging that has been occurring on the chain. 

In addition, it looks like one of the features we had intended to add at the next update, to help make CLAMS more resistant to censorship and licensing, will be ripe for the picking as well.


Working on getting it all polished and ready to ship.

Again, better we experience these frailties in the protocol now and repair them, adding resilience; than letting 'sleeping dogs lie'.

[istvandv]

also, how about posting a copy of the correct blockchain ready for download to make synching much faster and easier

[tryphe]

@tryphe your node doesn't seem to be running, I'm getting this a few times on the logfile

trying connection 67.35.116.81:31174 lastseen=365146.2hrs

Sorry about that, I had to cap the connections for a bit. It works now, port changed:

Code:

-addnode=67.35.116.81:54545

Make sure you are up to block 170,000

also, how about posting a copy of the correct blockchain ready for download to make synching much faster and easier

It would be fantastic if someone did this to get things rolling again. Unfortunately I don't have the upstream bandwidth available. (Would take 3 days =D)

[dooglus]

also, how about posting a copy of the correct blockchain ready for download to make synching much faster and easier

Not a bad idea.

There's already code in the CLAM client that checks for the existence of a specially formatted file called 'bootstrap.dat' and if it finds it, it uses it to import the blockchain.

There's a blockchain.dat available as a bittorrent download (see this thread). I will try to make a bootstrap.dat for CLAMs too, and make a torrent available.

I don't have much bandwidth available either, but if people are willing to seed a torrent it could work.

Probably the way forward is to add a "dumpbootstrap" RPC call to the CLAM client that makes it dump a bootstrap.dat file, which people can then seed.

I'll see what I can do.

[istvandv]

now that you mention it, ive already used a bootstrap.dat from HYP and it has been very efficient

theirs was 55MB for 119,000 blocks so its pretty small

i have absolutely no idea how to create one though or even if i am on the right chain so ill leave it to the experts 

[dooglus]

now that you mention it, ive already used a bootstrap.dat from HYP and it has been very efficient

theirs was 55MB for 119,000 blocks so its pretty small

i have absolutely no idea how to create one though or even if i am on the right chain so ill leave it to the experts 

Long ago I wrote some code that uses the Armory library to dump a fresh copy of bootstrap.dat, but I don't think Armory works with CLAMs, and so that's not going to work.

I figure it will be quickest to modify CLAM-qt to be able to create a bootstrap.dat from its own copy of the blockchain - which is what I'm currently attempting to do.

[dooglus]

Is there anyone who is willing and able to download a copy of bootstrap.dat from me and make a torrent of it please?

[istvandv]

Is there anyone who is willing and able to download a copy of bootstrap.dat from me and make a torrent of it please?

wish i could help
torrent is blocked by my ISP, i use zbigz to download torrent files

[dooglus]

Is there anyone who is willing and able to download a copy of bootstrap.dat from me and make a torrent of it please?

wish i could help
torrent is blocked by my ISP, i use zbigz to download torrent files

I guess I can upload it to mega or a similar service. I don't really like mega, for it's ugly URLs and weird download system, but I'll find somewhere to host it.