Topic: [ANN] Lebowskis [LBW] - *Updated Client and Seednode* - page 8. (Read 65059 times)

ok, well, could someone just hand out blockchain files for download that are on the valid blockchain, this is probably the easiest and most convenient way to fix this


[
{
"addr" : "70.98.114.237:7245",
"services" : "00000001",
"lastsend" : 1380023607,
"lastrecv" : 1380023607,
"conntime" : 1380021997,
"version" : 60006,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 87752,
"banscore" : 0
},
{
"addr" : "216.158.85.123:7245",
"services" : "00000001",
"lastsend" : 1380023607,
"lastrecv" : 1380023607,
"conntime" : 1380022014,
"version" : 60006,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 87752,
"banscore" : 0
},
{
"addr" : "74.207.225.170:7245",
"services" : "00000001",
"lastsend" : 1380023607,
"lastrecv" : 1380023607,
"conntime" : 1380022020,
"version" : 60006,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 87752,
"banscore" : 0
}
]

Are we OK now?

Would be handy if the *coind source had a function to temporarily ban peers if certain parameters are off, such as presenting a block count that's significantly different to our own (assuming everything is synced), or offering a block hash from an unwanted chain. In addition the client would TELL the other client that it's banning them, so that if this happens enough times the operator is alerted to something being amiss.

Even automated fork detection would be handy, although I guess it's not always black and white.


edit: I removed peers.dat and addnode'd 3 IPs which were on the higher block chain, but a couple of minutes after restarting my client has already found nodes on the other chain. Back to the exact same position, stuck on block 84072.

Is there a way to manually ban peers, tell the client to ignore the peers that appear to be on the wrong chain?


edit #2: deleting the block db and restarting seems to have kicked it back into gear; now at height 85138 with all 5 connected peers within a few blocks of each other.

Well, I think there is a bug in client in counting the blocks. I think it counts only PoW ones. My client shows 84908 in peers, by 85021 in itself. But it sees blocks from peers which is impossible in case we are in different chains.

I repeat. I think the best way to solve the fork is to pick the most lengthy chain and mine it. Cause the 84908 chain is already the most mineable one.

According to my client there's 84072 blocks, with the last block having a time of about 17 1/2 hours ago. There are several peers connected and most have block numbers much higher than this, but 84072 isn't anywhere near the 'other' chain either (currently @79430). Does this mean my client has realised there's a fork and has been hiding its head in the sand for the past 17 1/2 hours, hoping that some outside force will resolve things, rather than trying to decide which chain is the correct one by itself?

peer 1: 79430  <-- chain 1?
peer 2: 79430
my client: 84072  <-- ? ? ?
peer 3: 84254  <-- chain 2?
peer 4: 84933  <-- chain 3?
peer 5: 84937
peer 6: 84937

I'm with 4 other guys now in branch that has 84906 blocks

"addr" : "69.147.229.226:7245",
"startingheight" : 84906,

"addr" : "74.207.225.170:7245",
"startingheight" : 84907,

"addr" : "216.158.85.123:7245",
"startingheight" : 84908,

I'd suggest  everyone who want to resolve this fork to sync with theese nodes and mine that chain. Even if you have only CPU on difficulty 550-600 (in CGMiner) it should solve a dosen blocks a day.

no

Restarted the client, startingheight is a lot more varied this time...


        "startingheight" : 79388,
        "startingheight" : 79403,

        "startingheight" : 84254,
        "startingheight" : 84254,

        "startingheight" : 84564,
        "startingheight" : 84566,
        "startingheight" : 84566,

I've rearranged them into chronological order. Note the 312 block difference between 84566 and 84254. Then there's still 79388. Do we now have 3 forks???

Thanks. I think i'm on the other chain now indeed. I had to restart the Lebowski client a couple of time, but it seems my client is up to date now.


 


Thanks! I've got them. Do you want them back?


However, this still means that I haven received my coins of Digger's pool (http://lbw.ltcoin.net/) ;\

Just send it to you ( block 84298)

Delete everything in appData folder apart from wallet.dat. Then your client should download the most 'popular' chain.

I've mined roughly 200 blocks in 82k chain. But now I have only 2 peers connected. Is that so little people here or i'm in a limb again?

How to solve this? Or how to switch chains with my client? i'm obviously on the wrong one, cuz I haven't received any Lebowski from my pool mining.

So you're basically starting the client fresh so that all connections are new, then use startingheight as an indicator of which chain they're on? My mix is not on the fence like yours:

        "startingheight" : 84068,
        "startingheight" : 84068,
        "startingheight" : 84068,
        "startingheight" : 84069,
        "startingheight" : 84069,
        "startingheight" : 84069,
        "startingheight" : 84069,
        "startingheight" : 84069,

I did getpeerinfo a few times and did see one at 79379, but that disappeared a few seconds later.

edit: going by the heights from your post roughly 8 hours ago...

79335 (then), 79379 (now)
83627 (then), 84068 (now)

First chain has only advanced about 44 blocks, whilst the second has advanced 441 over the same period.

This assumes that the peer which appeared briefly @79379 had the complete chain (even if it was the wrong one)

I see this picture now


> getinfo
{
"version" : "v1.0.0.0-g32a928e-dude-abides",
"protocolversion" : 60006,
"walletversion" : 60000,
"balance" : 1012.89809700,
"newmint" : 0.00000000,
"stake" : 40.15227200,
"blocks" : 79338,
"moneysupply" : 1581363.25251100,
"connections" : 5,
"proxy" : "",
"ip" : "128.68.38.185",
"difficulty" : 0.00781238,
"testnet" : false,
"keypoololdest" : 1374757052,
"keypoolsize" : 102,
"paytxfee" : 0.00000000,
"errors" : ""
}

> getpeerifo


[
{
"addr" : "198.50.233.21:7245",
"services" : "00000001",
"lastsend" : 1379741639,
"lastrecv" : 1379741639,
"conntime" : 1379741292,
"version" : 60006,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 79335,
"banscore" : 0
},
{
"addr" : "70.98.114.237:7245",
"services" : "00000001",
"lastsend" : 1379741971,
"lastrecv" : 1379741971,
"conntime" : 1379741299,
"version" : 60006,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 83627,
"banscore" : 0
},
{
"addr" : "216.158.85.123:7245",
"services" : "00000001",
"lastsend" : 1379741971,
"lastrecv" : 1379741971,
"conntime" : 1379741349,
"version" : 60006,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 83628,
"banscore" : 0
},
{
"addr" : "198.199.83.168:7245",
"services" : "00000001",
"lastsend" : 1379741639,
"lastrecv" : 1379741639,
"conntime" : 1379741355,
"version" : 60006,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 79335,
"banscore" : 0
},
{
"addr" : "198.211.116.19:7245",
"services" : "00000001",
"lastsend" : 1379741971,
"lastrecv" : 1379741971,
"conntime" : 1379741428,
"version" : 60006,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 83629,
"banscore" : 0
}
]

So there are 2 chains, half of the peers support one of them, the other half another. Now we are to decide which one is correct. Then mine it with all you got and most of clients will follow. Do this or Donnie died in vain.

How do you tell when a fork happens?

My client is currently showing block 83321 with a hash of 00000001d38fa9e7a43c129e2c6fdc27223bb366dc647c9511f968f1a0ab3d85

If this is the correct chain you want (ie you DON'T have this block) then let me know.

Can you get onto the right chain by forcing connect to a specific node?

Well i finally got around to working on this again last night I had done the initial fixes a few weeks ago but was waiting for a response from coins-e

I got it past the initial forks and fixed the self forking issue with POS. But now it appears there is another drastic fork about 2k blocks ago. I cant seem to get on the right side of. If anyone is synced past block 81484 and on what appears to be the correct height of 82910 could you possibly send your appdata folder Minus you wallet.dat to [email protected]

Just your debug.log would be helpfull but due to the lack of explorer I will need a full copy of the chain to get the full hash for the good block as well as stake modifiers

Here is the repo but it still needs this final fork resolved

https://github.com/Mullick/coins

Thanks to balthazar again for his help with caps which is making this possible

It looks like my client does synch, from about 400 blocks till 0. But after that there are about 3400 blocks remaining, which can't be synched or something. Does someone have a solution for this?

Just recive some coin,it look my client is fine
Status: 30 confirmations
Date: 2013/9/20 14:25
From: unknown
To: 68JZK4UfpGXCaBkTkQrRQVx1fYMrJZb9iK (own address)
Credit: 10000.00 LBW
Net amount: +10000.00 LBW
Transaction ID: 36272559c4f49f5e1bf581633ef1ed35b72b338c9bf0e11ed7b214abcce66b11

Thanks for that. It seems that my client is stuck now (while synching). How can I fix this? Can I re-install my wallet or will I loose my LBW's then?