search

Erkan-Yilmaz / Gridcoin-tasks

tasks, wishes, ideas, ... for the Gridcoin project
26 stars 1 forks source link

25k GRC bounty -> finding additional root causes & delivering solutions (e.g. users being out-of-sync) #96

Closed Erkan-Yilmaz closed 7 years ago

Erkan-Yilmaz commented 7 years ago

situation now:

denravonska commented 7 years ago

I believe that the current sync issues could be a result of us testing if some nodes allowed blocks from other nodes with old beacons, see my comment about this. It seems that the offending blocks are forks in the road and reported as being created by different users on the block explorers. At least one of those blocks (854420?) is tagged with a beacon >6 months old.

I'm not sure what the solution could be that doesn't end up with us forking ourselves into oblivion. An idea could be to test a solution where if a node receives a block with a height <855000 and the beacon is missing in the node's application cache, the node should scan the chain backwards for the missing beacon, but that might even make things worse.

Another thing we can try is to have nodes detaching from other nodes which are sending blocks created using old (basically unknown) beacons if within a certain height span. That way the stuck nodes will eventually find their way to the correct chain.

We should also check if one of the major nodes or explorers carries an incorrect hash for the offending blocks and see if we can update them so they don't continue to spread it.

grctest commented 7 years ago

@denravonska Do you think removing the beacon age, or loading all beacons into memory as discussed https://github.com/gridcoin/Gridcoin-Research/issues/246#issuecomment-289277589 would be a good idea? There was talk of dumping it to disk so that on next startup it wouldn't take as long, and it could be distributed within snapshots.

denravonska commented 7 years ago

@grctest I think loading them all in the current way is out since it's far too slow. Storing them or block pointers to them in a separate file would probably be better. A slow startup once but then it's zippy. Another option is to do the scan in the background once the wallet has been launched. There's probably no need to wait for it before doing the rest of the wallet work.

skcin commented 7 years ago

Hey, looking at robs fix. He changed the grandfather block to 854400. So before that block no CPID check is performed, right? After block 855000 the 3.5.8.7 nodes disconnect from all nodes with older versions. That leaves us with the blocks in between where old nodes can advertise blocks with expired cpids. So I think if more nodes upgrade the problem should go away.

jimbo-slice commented 7 years ago

Regarding this: "2 users where it did not fix the situation for them (perhaps wrong way of the howto was applied? they try the howto in their old 3.5.8.6 version? ...)"

I was one of these users and the problem was in fact something I did wrong: https://github.com/gridcoin/Gridcoin-Research/issues/254#issuecomment-290553334

I'm now in sync using the unofficial snapshot.

denravonska commented 7 years ago

This is always going to be an issue since blocks have been signed with age old beacon. So how about this solution. If a wallet's height is less than 855000 it always loads all the beacons from the wallet. Out of sync wallets will have a slower startup until they can get back in sync.

@skcin The blocks are already created but neither old nor new wallets can verify them since the beacons are "gone". Downloading an updated snapshot or using a v3.5.8.6 wallet from block 0 should help people get in sync, but it's far from convenient.

denravonska commented 7 years ago

See https://github.com/gridcoin/Gridcoin-Research/pull/256 for a possible fix.

grctest commented 7 years ago

I pledge 25k to anyone that can deliver a solution which fixes the current issues we're experiencing re: syncing/beacons/bad-cpids.

If multiple users collaborate, it can be split up between them. 25k GRC at $0.008977ea = ~$224.425

philipswift commented 7 years ago

How about creating a tracer that can be tracked rather than swimming back upstream?. This would give a set behaviour that could be used in A/B comparisons. I don't think it' s possible to do this in a live environment due simply down to large number of variables. Ideally we need a sandpit, where there is more controls and less variables. We will surely all get a brain-fart if we carry on in the live environment. Hard to swallow but it may be the only way, especially as we can't be sure there is not any Testnet contamination.

grctest commented 7 years ago

20k to @denravonska TX: a3829f2228ff3d447896f2516246545f7c0df2d9b68268d46263c6588e4c74ca-000 2.5k to @Dantali0n & @tomasbrod for helping development: https://github.com/gridcoin/Gridcoin-Research/pull/256

denravonska commented 7 years ago

@grctest Oh crap, thanks! I'll split that with @skcin.