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

I don't need port forwarding, it does that automatically. Otherwise I wouldn't have any connections, or show on any lists. I show on the big list often, normally... (Just not after this happens.)

Port-monitor shows many open connections, but they are just waiting to die... nothing connected on them anymore.
http://technet.microsoft.com/en-us/sysinternals/bb896644.aspx
also TCPview shows about 5, and two loopbacks for bottlecaps, and 4 others, including 8 for my miners.
http://technet.microsoft.com/en-us/sysinternals/bb897437

No firewalls, other than standard ISP protection from pings and probes and ack-attacks.

Never had an issue up until last week, prior to 1.4. Actually, about 5 hours before 1.4 was released, this started happening. But the issue on 1.3 was that I was not getting any POS at all, though I had over 5000 coins ready for POS. Once 1.4 was released, I got like 40 POS per day... Then all hell broke loose.

Just had 4 again, but it dropped back down to 3, then 2...

P.S. If it is any importance, this is win-7 home-premium up to date 64-bit version

Hmm that is probably part of your issue right now. I am averaging about 30-35 connections on my main nodes and my wallet. I think due to me using a lot of internet traffic i may have dropped a few peers and have been susceptible like you with a small number of peers. Do you have port 7685 forwarded?

Once the blocks stop trickling there way through this shouldn't be an issue anymore. That may have even been the last

My config is setup for 30, but I never get more than 8... that is most wallets. Only a few wallets seem to ever get over 8. Normally on those I have about 20-25. I figured that was a windows wallet limitation for this wallet too. Might not be... someone said they had 12 on windows wallet, I think...

my ip 107.217.208.215

only one of my connections is in that list from the block-crawler

Here, the most I ever get is 8. Fast... unless this happens... then it takes about 10-20 min to get 1, which I assume is some new person, as they are not on the big list, and thus, not banning me or not banned themselves, which turns them into a relay for my work... then I get 1 new one again... a few minutes later.

Stuck at 2 still... if one is accused of misbehaving, I am screwed again... I have to wait for someone new to join, to piggy-back on them as a relay. Because all three of us will become isolated again, or all become isolated ourselves, as three separate chains or waiting for someone new to piggy-back on.

How many connections were you averaging before?

I am still stuck on 2 connections... I see 3 and 4 for a split second... then they instantly disappear. (All version 1.4.2/1.4.1 and all in that long list. They just refuse the connection, once connected.)

I still don't get how that issue causes all 8 of my connections to drop, and causes all 25 of the other connections to refuse my connection. Leaving me connecting to the first new people that are trying to connect, but they can't connect to them either, only me... mining on my chain, but eventually leaving to the taller chain, leaving me isolated again.

Unless the calculation for Computeminwork() is still off by a fraction of a decimal, or just too high for what is actually being submitted.

The reason for the error is the blocks are failing Computeminwork() a condition in the code.

Sunny king mentioned this as the reason and upon inspection of the message itself it turned out they were failing this condition. This has been fixed in 1.4.1 but somehow a older client must have worked its way in and submitted the block to a few peers.

The network responded quickly and isolated those it was broadcast to. Once back on the right chain you will slowly gain connections back im up to 12 again

Here is the message itself:

  // Extra checks to prevent "fill up memory by spamming with bogus blocks"
        int64 deltaTime = pblock->GetBlockTime() - pcheckpoint->nTime;
        CBigNum bnNewBlock;
        bnNewBlock.SetCompact(pblock->nBits);
        CBigNum bnRequired;
        bnRequired.SetCompact(ComputeMinWork(GetLastBlockIndex(pcheckpoint, pblock->IsProofOfStake())->nBits, deltaTime));
        if (bnNewBlock > bnRequired)
        {
            if (pfrom)
                pfrom->Misbehaving(100);
            return error("ProcessBlock() : block with too little %s", pblock->IsProofOfStake()? "proof-of-stake" : "proof-of-work");
        }
    }

I had to manually delete the chain again, restore a backup, reconnect manually, unlock my wallet, restart my miners... then I was able to mine again. From 1AM to 3:30AM my miners were dead in the water...

I HOPE that is not "what it was supposed to do"... That is the problem we have all had. With the addition of no reconnections, which I still have. I just happened to luck out and catch 2 new connections that just joined the chain. The rest in the list are auto-killing my connection attempts to them, once they get connected. (As if I was personally responsible for the misbehaving. Guilt by association, though we were all connected to that peer. How do 20 connections stay, and five get perma-ban and isolated to mining alone, every time?)

When it says "not enough proof of stake"... is it complaining because someone created a POS block, and there was already enough "claimed"... Thus, not enough POS to accept that block? It shouldn't disconnect us for that, ever... just reject it, and update the height, as obviously, that one that submitted the block did not have the latest POS block, which was the "limit" for that minute/hour.

Unless it is complaining that someone created a POS but they didn't have enough POW blocks to convert to POS, thus, not enough POS... (That is the most uninformative warning I have ever seen. lol. Might as well say, "something didn't work right" as the warning... like javascript does! xD)

If it is bitching about someone creating a POS for a block which they don't have enough POW available... then you need to check one of two things in our wallets... or both...
1: Is there a POW block ready for POS (then mine POS, if it is accepting POS on the system)
2: Is there STILL a POW block ready for POS (then submit POS, if it has not been spent, or consumed by a prior POS solution)

Optionally 3: Reserve 10 POW for POS, prior to mining/solving the actual POS block, as "unavailable for POS"... Since I notice that POS happens first, THEN it removes the coins after submitting... at which point the coins could have been spent, or consumed by a POS that just got accepted a few seconds ago.

and on the other side...

Don't kill people because they submitted what they thought MIGHT be accepted, being unaware that the unrelayed POS block the server didn't distribute, was the last POS block that was just about to be sent to that user for building-on. Simply ignore it, since it is a POS block, that has near-zero diff, and you should be expecting a ton of invalid ones to arrive, as we all solve them real fast. (Unless you raise the diff, then they come more spaced-apart, and traverse the network to us, faster. Stopping us from submitting the POS we were just about to submit, if we thought the limit wasn't reached yet.)

If the first thing is true... about us being banned because the wallet is creating POS for POW's that we don't have available... then you might want to tell us to stop mining when there is (limit - 1), as having one less will not matter on the next cycle it will ask for one more. However, that WILL reduce the last flood of submissions, letting the ones still in transit, or ones that have not gotten the (limit value) yet... get accepted without forking and rejecting them for something the wallet did.

Also...

Instead of just "disconnecting us", under suspicion of whatever... (Which is what is creating the forks, the program isolates us as a group, through the one relaying to the one severing the connection.)

Give the program some kind of warning to let it know WHY it is being disconnected, before disconnecting. If only so you can locate the issue better, by talking to the one being disconnected. Since you have no idea who is disconnecting who, or why, unless you witness it yourself. It is easy to find those of us getting disconnected. We are the ones frequenting the forums. But it doesn't tell us why we are being rejected, it just rejects us.

It seems the protocol did its job on that one. One of my nodes quickly dropped to 3 connections I immediatly shut it dow and moved back to the correct chain. I was flagged so quick it has taken hours for me to build up connections again but its getting there.

Prob just one last bad block stuck in there?  I can tell you I  received the block form:

received block a6596a12fd0ce2573028
Misbehaving: 70.64.147.242:55514 (0 -> 100) DISCONNECTING
disconnecting node 70.64.147.242:55514
ERROR: ProcessBlock() : block with too little proof-of-stake

My node then very quickly dropped to just a few connections. Seems like the large majority of the network stayed on track. I was using the server when it happened maybe my traffic dropped it down in connections all together. We will see over the coming days. Pool is still on the right chain

The beast be forked again... dead fork, but forked... all connections being refused again. (Refusing me) Version 1.4.2

Won't even let me connect to get the chain... any chain... (From 79997 up, not from 0.)

Got one to accept my connection, back on track... but I was stuck on that dead fork that couldn't be mined. "Not enough work"... and the other connections kept refusing me, I guess, after they left and started a new branch. Left me mining with 2 connections, then one... which wasn't enough to mine...

Got only one connection here, but it is letting me mine on it, at the correct height. Hope it relays my blocks!

Also note, it was at almost 01:00 am again...8/19/2013 00:54... same time as last time... (GMT -5)

I'm never sleeping again... ever!

When do i can sync?

 

LOL respect the elders


needed that laugh

That I can do... There are hundreds of them all over my house... lol.

Or did you want this... http://fallout.wikia.com/wiki/Gecko_(creature)

Challenge accepted... Pack of baby-geckos, huddled around a bottlecap! (I will put my own artistic twist on them, to make them unique.)

how about a pack of geckos 

Nice... love it...

I can attest that 1.4.1 is also running strong, attached to the 1.4.2 clients. Switching back to 1.4.2 soon, just because I would rather not be the source of future forks, running 1.4.1. (Just wanted to see if 1.4.1 would continue to operate without error, and it has for over 10 hours now.)

Off topic...

I am bored and about to begin making a clay-sculpture, to be used for molding. Anyone have any suggestions of something cool or any requests? (I prefer sci-fi and fantasy things, but that is not a limitation.)

Speak up, since you have nothing-else to do, while your miners are running without error.

Yep yours looks fine

The starting height is the peers height when you first connected , the low numbers are when you first opened it and the later numbers are peers you picked up later

Downloads:

Source:
https://github.com/bottlecaps-foundation/bottlecaps

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

Version 1.4.2 Release notes:

Added checkpoints to help sync

I'm watching these 2 nodes like a hawk

addnode=199.180.115.100
addnode=50.137.233.14

20:41:02

getpeerinfo


20:41:02

[
{
"addr" : "188.165.194.201:44500",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872857,
"conntime" : 1376869021,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80119,
"banscore" : 0
},
{
"addr" : "88.195.204.114:47970",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872565,
"conntime" : 1376869022,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80119,
"banscore" : 0
},
{
"addr" : "221.215.222.34:50962",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872717,
"conntime" : 1376869022,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80119,
"banscore" : 0
},
{
"addr" : "199.180.115.100:54446",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872856,
"conntime" : 1376869022,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "80.229.2.127:7685",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872857,
"conntime" : 1376869027,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "85.228.195.71:7685",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872856,
"conntime" : 1376869028,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "67.167.228.42:7685",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872856,
"conntime" : 1376869034,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "188.165.211.202:7685",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872856,
"conntime" : 1376869051,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "50.137.233.14:7685",
"services" : "00000001",
"lastsend" : 1376872533,
"lastrecv" : 1376872856,
"conntime" : 1376869091,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "92.5.104.42:5649",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872856,
"conntime" : 1376869096,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "217.169.211.146:59127",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872565,
"conntime" : 1376869101,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "107.217.208.215:51060",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872856,
"conntime" : 1376869155,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80121,
"banscore" : 0
},
{
"addr" : "223.64.63.17:11337",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872534,
"conntime" : 1376869285,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80122,
"banscore" : 0
},
{
"addr" : "174.52.220.23:56882",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872565,
"conntime" : 1376869371,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80123,
"banscore" : 0
},
{
"addr" : "99.227.137.145:55732",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872856,
"conntime" : 1376869550,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80125,
"banscore" : 0
},
{
"addr" : "37.229.117.57:7685",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872857,
"conntime" : 1376869804,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80128,
"banscore" : 0
},
{
"addr" : "192.241.222.16:40518",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872857,
"conntime" : 1376870314,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80136,
"banscore" : 0
},
{
"addr" : "200.8.23.64:52146",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872666,
"conntime" : 1376871220,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80154,
"banscore" : 0
},
{
"addr" : "192.95.37.194:62616",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872765,
"conntime" : 1376871574,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80159,
"banscore" : 0
},
{
"addr" : "186.91.190.123:49213",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872856,
"conntime" : 1376871916,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80156,
"banscore" : 0
},
{
"addr" : "171.37.45.111:39176",
"services" : "00000001",
"lastsend" : 1376872856,
"lastrecv" : 1376872692,
"conntime" : 1376872691,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80176,
"banscore" : 0
}
]


20:44:58

getpeerinfo


20:44:58

[
{
"addr" : "188.165.194.201:44500",
"services" : "00000001",
"lastsend" : 1376873093,
"lastrecv" : 1376873093,
"conntime" : 1376869021,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80119,
"banscore" : 0
},
{
"addr" : "88.195.204.114:47970",
"services" : "00000001",
"lastsend" : 1376873093,
"lastrecv" : 1376873093,
"conntime" : 1376869022,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80119,
"banscore" : 0
},
{
"addr" : "221.215.222.34:50962",
"services" : "00000001",
"lastsend" : 1376873093,
"lastrecv" : 1376873060,
"conntime" : 1376869022,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80119,
"banscore" : 0
},
{
"addr" : "199.180.115.100:54446",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873092,
"conntime" : 1376869022,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "80.229.2.127:7685",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873094,
"conntime" : 1376869027,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "85.228.195.71:7685",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873092,
"conntime" : 1376869028,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "67.167.228.42:7685",
"services" : "00000001",
"lastsend" : 1376873060,
"lastrecv" : 1376873092,
"conntime" : 1376869034,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "188.165.211.202:7685",
"services" : "00000001",
"lastsend" : 1376873060,
"lastrecv" : 1376873092,
"conntime" : 1376869051,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "50.137.233.14:7685",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873092,
"conntime" : 1376869091,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "92.5.104.42:5649",
"services" : "00000001",
"lastsend" : 1376873094,
"lastrecv" : 1376873093,
"conntime" : 1376869096,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "217.169.211.146:59127",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873060,
"conntime" : 1376869101,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80120,
"banscore" : 0
},
{
"addr" : "107.217.208.215:51060",
"services" : "00000001",
"lastsend" : 1376873093,
"lastrecv" : 1376873093,
"conntime" : 1376869155,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80121,
"banscore" : 0
},
{
"addr" : "223.64.63.17:11337",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873060,
"conntime" : 1376869285,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80122,
"banscore" : 0
},
{
"addr" : "174.52.220.23:56882",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873093,
"conntime" : 1376869371,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80123,
"banscore" : 0
},
{
"addr" : "99.227.137.145:55732",
"services" : "00000001",
"lastsend" : 1376873093,
"lastrecv" : 1376873093,
"conntime" : 1376869550,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80125,
"banscore" : 0
},
{
"addr" : "37.229.117.57:7685",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873060,
"conntime" : 1376869804,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 80128,
"banscore" : 0
},
{
"addr" : "192.241.222.16:40518",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873093,
"conntime" : 1376870314,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80136,
"banscore" : 0
},
{
"addr" : "200.8.23.64:52146",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873060,
"conntime" : 1376871220,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80154,
"banscore" : 0
},
{
"addr" : "192.95.37.194:62616",
"services" : "00000001",
"lastsend" : 1376873060,
"lastrecv" : 1376873092,
"conntime" : 1376871574,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80159,
"banscore" : 0
},
{
"addr" : "186.91.190.123:49213",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873093,
"conntime" : 1376871916,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80156,
"banscore" : 0
},
{
"addr" : "171.37.45.111:39176",
"services" : "00000001",
"lastsend" : 1376873092,
"lastrecv" : 1376873060,
"conntime" : 1376872691,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80176,
"banscore" : 0
}
]


But my client is in sync with Block Crawler at 80182

That is not what I want to see but so far no issues both nodes staying on track and cap.coinmine.pl as well staying on course

I have also noticed the number of connections rising as well from around 20 to over 30 now