Topic: Bottlecaps 2.1 UPDATE REQUIRED - HARDFORK JULY 4 2014 to 200% Annual PoS - page 178. (Read 388610 times)

I have only ONE node >78k

 "addr" : "95.72.68.42:29670",
        "services" : "00000001",
        "lastsend" : 1376749254,
        "lastrecv" : 1376748478,
        "conntime" : 1376748399,
        "version" : 70000,
        "subver" : "/Satoshi:0.7.2/",
        "inbound" : true,
        "releasetime" : 0,
        "startingheight" : 78165,

It has UPnP checked, but no option to uncheck it... It is locked that way.

I don't need port-forwarding, as all connections are unblocked in my router, except the most extreme known viral and attack detected packets themselves. (Nothing shows in logs as being blocked. Nor do I have any problem connecting to over 40 connections on other coins who have wallets that have had the 8-connection limit removed.) I have not altered anything except my RPC port, to keep people from reading my personal info, or attacking my miners.

NOTE: When I say my versions below... I am talking about the windows wallet, used as a daemon, for mining and as a wallet. Not the linux compiles or OSX compiles...

I see people connect, and drop-off, after a few minutes, so I assume they got a faster connection or disconnected, or the program itself is having connection issues.

Everything was fine, up until the last few days, with the old 1.4.0 program. Nothing has changed in the 1.4.1 program, except now I get POS blocks, where I didn't before, on the 1.4.0 program.

My connections to the older 1.3 programs was perfect, from 1.4.0... It was when the 1.3 programs disappeared, that the issues began. Thus, whatever was changed from 1.3 to 1.4 is the actual issue, related to connections. Because those 1.3 programs were talking finem and keeping us 1.4 users connected, but 1.4 to 1.4 connections have been the trouble for me... Though 1.3 was just not doing POS well. 1.4 didn't do POS well, and also had/has comm issues... 1.4.1 has POS fine, but comm issues still.

Even the block-explorer which has 100 possible connections, is only able to get 25... Though, I am sure there are more than 100 attempting to connect to that daemon.

How is the IPV4:IPV6 and IPV6:IPV4 connections? That is a major f-up, for most sockets. Could that be an issue here? Packets forward and have multiple forwards which can shift packet data out of the MTU range. Check that data fits within the MTU range for UPnP, and is also not being chewed-up by a IPV4->IPV6 or IPV6->IPV4 conversion that ISP's like to break, and programs don't like to digest.

EG, with 1 forward of IPV4:IPV6 and (data) the MTU may be fine... but if a packet hits another forward, or multiple 4->6 then 6->4 then 4->6... it pushes data out of the packet to make room for the growing header in the packet. Causing it to break the TCP send link. Change the data-size to a little less, and see if that helps. If it does, then that is the issue with the connections. Multiple failed TCP connections due to corruption from MTU failures will kill the TCP connection. It won't try to resend more than 6 times.

It'd probably help if you ensure you're connectible. All of those connections are initiated by you as can be seen by inbound returning false in all 4 peers. If you want more peers you need to forward the default P2P port (7685) in your router or enable the UPnP option if the QT wallet comes with UPnP support (I self compile a daemon so I don't know if it does or not) and your router supports it.

I must be on the same chain as you. What nodes have over 78k? Can I get an IP for them? I briefly connected to one, but whoever it was dropped me before I could sync, which sucks, as I'm connected to over a dozen other nodes.

Ok, I connecting to those nodes, but looks like onely 2 have over 78k blocks.
I have 21 connections.... still on block 77937...
I stoppped mining, waitin till it will settle.
Looks like i mine half day in fork :/

I am watching this like a hawk until 5:00 PM (GMT -5)...

Might as well, since I am here. I need my port-snooper to check-out the raw packet data. lol. Where did I put that program...

I agree connections are set low in that list I had a hard time connecting to more than 4 initially; but, when I forwarded the port I seemed to end up on the wrong chain after several hours of mining. So I closed it and had no problems mining.....although blocks seemed to really slow down about 9 hours ago.

I'll wait for the change over to be complete and then open the port back up. Definitely don't want to have to download the block chain again.

http://bottlecaps.kicks-ass.net/peers.php

Though, in that list... I still only get 2 connections...

I think everyone has connections set too low... (Due to the wallets not accepting more than 8 connections, it is like 8 are connecting to the same 8, and isolating themselves over and over. And the ones accepting more connections, are connecting, but not talking, or not sending data that the wallets are able to read/use.)

Got 4 connections now... lol... love the start-height variance...
09:30:11
[
{
"addr" : "92.5.104.42:7685",
"services" : "00000001",
"lastsend" : 1376746126,
"lastrecv" : 1376746182,
"conntime" : 1376744432,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 78102,
"banscore" : 0
},
{
"addr" : "50.137.233.14:7685",
"services" : "00000001",
"lastsend" : 1376746182,
"lastrecv" : 1376746182,
"conntime" : 1376745877,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 78125,
"banscore" : 0
},
{
"addr" : "115.76.11.1:7685",
"services" : "00000001",
"lastsend" : 1376746182,
"lastrecv" : 1376746130,
"conntime" : 1376746046,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 78127,
"banscore" : 0
},
{
"addr" : "91.235.254.37:7685",
"services" : "00000001",
"lastsend" : 1376746188,
"lastrecv" : 1376746188,
"conntime" : 1376746159,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 77921,
"banscore" : 0
}
]

Apparently they are catching-up... so I assume I am delivering blocks that they are reading... I hope.

My IP in the list of the 25 is 107.217.208.215

Do not use that as a connect, except for temporary connection... My IP changes hourly, I believe. But if you need a quick-connect... add it, then remove it once connected, so you don't restart with it next time you connect... a week later.

In what list?
I have restarted daemon like 2 hrs ago deleting peers.dat
It should connect to hardcoded nodes in 1st place.

Shut-down your daemon... (Wait for it to completely die)... Then delete peers, and reconnect with the peers in that list. Wait a minute for it to run through the connections and find and link the right heights.

If it doesn't get the right height... do that again... until you do get the right height.

Also, save yourself some time... once you get the right height... save a backup of everything in your folder... so when/if this happens again, you can just restore that backup and continue from that point on... you connect faster that way too.

Apparently no-one wants to send the whole chain to everyone that keeps connecting with 0 blocks downloaded. Leaving the burden to one IP to deliver the whole chain over and over... and the chain it is sending is the wrong ending... you have to HOPE to get a taller connection before it begins sending you the wrong blocks. (Because if it does, you have to do it all over again.)

The list isn't necessarily complete since a client only tells you how many blocks it has on the initial connection, it doesn't update you to the number of blocks it has as time goes by. I try to restart the daemon periodically to get fresh block counts from the peers and raise the bar on the number of blocks required to be included on the list so that I'm sure they're definitely on the same chain as me.

Currently I have 21 connections, all are on the same chain and only 1 of them is using a older version of Bottlecaps. Only 2 hours and 45 minutes to go until old clients start getting blacklisted, that'll be where the real fun begins.

my daemon  "blocks" : 77901,
block crawler: Block Count: 78,113
Sooo.....

The block explorers just went down... but I am on height 78103 on IP: 50.137.233.14 which oddly reports the starting-height as 78026... That is the only connection I get from the list of connections.

Even blockcrawler is having connection issues, as we are... http://bottlecaps.kicks-ass.net/block_crawler.php

Just reported 0 connections, and 0 blocks, and now is back up with 15 connections and my height.

Now also having IP: 92.5.104.42 connect with the correct height as the starting height. Apparently the other IP isn't getting the missing blocks delivered, and is hung-up, but still relaying the top block.

Nice! Good job.

Are there any active pools? Looks like Silverwolf's is on the wrong chain, Bottlecapspool.com is down, and I believe CAP is disabled at Multipool.

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

did you use the command -rescan, after getting on the right block-height?

They should move back, in time... once enough blocks have gotten above them, beyond the point of (Confirmed invalid) eg, the point where they should be confirmed, but the chain indicates they were not the actual blocks that were confirmed as valid.

The only thing you have to deal with, is that those coins can not be staked, while they remain pending-stake, waiting for release back to your wallet.

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

my client minted blocks during one of it's trips down the wrong path. I have finally got it updated on the right chain and minting blocks but the ones that were rejected still show as generated but not accepted and my balance is missing the staked coins for those blocks that were not accepted.

How do I get my coins back? Will they timeout eventually and remove the transactions that were not accepted?

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