Updated download for the block chain. Copy/replace files into your appdata/roaming/BottleCaps directory

https://docs.google.com/file/d/0B0V-7FME2rcyeFM4czNoVmEyVjg/edit?usp=sharing

EDIT: Also cleared the peer list from my nodes so they should be connectable to you again

pool if off the chain again - I dont know what is happening, but windows client doesn't have such problem

Twelve hours of staying on the right chain here...one thing I did was turn off my port forwarding limiting the number of nodes I can connect to. Started out with good nodes on the right chain and locked out those bad nodes. Seemed to help

Wow that's great news Sorry I missed it

Do you have any plans of setting up one of your own?

so far so good

What will happen with epool? It is down, will Erundook turn it back on?

And will caps need another fix or somethoing?

Hmm im getting lots of errors in log:
What is goin on? Not updated nodes banging to my ports?

edit:
ok, looks like it is p2pool messing...
in same time error in p2pool log:
Have no idea it is harmless or not :/

edit2:
There is another error in daemon log, nothing in p2pool:

Odd...

What one is correct?
My daemon says::
Using latest git, compiled yesterday.

grr... I went to sleep at 1AM (gmt -5), and just as I left, the programs all shut-down and apparently forked on a new chain.

That, or this program just hates me...

Only lost about 20 blocks, because the miner seemed to be connecting and rejecting randomly... The 16k diff on cgminer let me know something was up. lol.

Have you considered changing the POS diff to 1k (0.015), to stop massive burps of near-zero diff blocks from flooding the network. That is still an acceptable CPU diff, and would add more time between blocks.

I wasn't kidding when I said I was getting TONS of POS blocks. Just last night I believe I had found over 97 POS blocks and only 39 normal blocks. (Near the end, before I was severed from the net, by being rejected by the other miners... I had found 20 POS's in a row.)

Now, I am sitting at an uncomfortable 2 connections, out of the 25 listed... so that is a lot of connections not talking/communicating with anyone, on that list at http://bottlecaps.kicks-ass.net/block_crawler.php

Good to see that diff back up to normal... 100K (1.53) That comforts me a lot more than what it was last night. I don't mind making less and demanding more for my efforts, since the coins are majorly undervalued by those who are trading them. They will stop selling themselves short, once people stop hoarding them and actually start spending them.

Now that the number of places to spend is growing, and hopefully this next release will address many of the connection issues that is leading to the forking issues.

I still think the best solution is to have at-least one roaming connection, of the 8 that the wallets are limited to... used to traverse the rooms, looking for higher blocks, and 1 of the 8 to look for rooms with less blocks, to alert them and deliver the higher blocks.

However, that will not do much good if you HAVE to shut-down, delete the database, restart, hope to connect to a higher chain, and then wait for the whole chain to be delivered, and then unlock and restart the miners that were running, so they can mine again, on the unlocked taller chain.

Having an archive of the "block-0 to block-last-hard-coded", in addition to "new-blocks", and having the ability to "delete invalid block from database", up to the point of the branch... to rebuild it from that point forward... would make most of these issues go away. (Except the connection issues, where people keep getting connections killed and invalid packets are being sent, or packets are being improperly read/translated, once sent.)

I would also like to mention... I see "ping" in the debug info that was posted on the last few posts...

You do realize that 90% of the world's routers do not allow or respond to pings, even if a router does, ISP's do not allow them. Pings from the internet are "suspicious", as they are usually a sign of a hacker attempt to find an open port or get a response. Internally, in an intranet, routers will allow pings, because that is how home-devices let other devices know they are alive. But ISP's block pings, inbound and outbound, and most routers block any inbound pings, only allowing internal pings to be used.

If our connections are being killed because we are not responding to pings that we never hear... then you need to remove that part of the code.

That will FORCE segregation, as it will keep only intranet (private networks), who DO respond to pings, isolated as the only valid connections. EG, If I had 10 rigs, all connected to my wallet, and 20 connections, but 10 from the net didn't respond to pings, so I sever those connections, and my 10 rigs DO respond to pings... I would end-up isolating myself from the world, only talking to my 10 rigs with running wallets, building my own chains.

You can't ask people to "allow pings" and HOPE that works. (Not only because it exposes them to hacking detection, but also because many ISP's will drop most pings, and make it a useless fix.) They should just not be used, except to determine if that connection is possibly an internal connection on an intranet, or an external connection on an internet. Nothing more.

Spitting-out a UDP packet is the correct way to test for a connection, when a TCP connection is severed. Not a PING. Though, those too can be blocked, if they contain detectable data that is not encrypted. (Eg, if an ISP doesn't want mining, and they can detect mining packets, they will block them. If the packets are encrypted, they have no real detection, and usually allow them to pass. That is what TOR and torrents now do.)