Warn when the wallet is likely on a fork

[denravonska]

<@Erkan_Yilmaz> a simple heuristic to see if something is wrong is:
<@Erkan_Yilmaz> "How do you know something is wrong ?
<@Erkan_Yilmaz> your "PoR Difficulty" in the client is very low, e.g. <1 values (e.g. 0.4)
<@Erkan_Yilmaz> you stake too fast blocks"
<@Erkan_Yilmaz> https://steemit.com/gridcoin/@erkan/out-of-sync-in-gridcoin-3-5-8-8
<+[-SaRaFiNa-]> Linked by Erkan_Yilmaz -  out-of-sync in Gridcoin 3.5.8.8 ? — Steemit
<@Erkan_Yilmaz> and look out for the net weight
<@Erkan_Yilmaz> before the probs began, we had like net weight values from 70-150 mio
<@Erkan_Yilmaz> so, once it tends to fall down, you can also keep alert

We could use this information in the lowlevel code to push a "fork probability" value up to the UI. When it reaches a certain threshold the UI could issue a warning, show an icon or make some text red to notify the user that he or she needs to take actions.

[iFoggz]

not a bad idea, using the existing information we have in client and building on the informatiom to warn users of potential problems.

[philipswift]

I'm bringing up user compliance again. Only 20% or thereabouts, of Windows non power users will make an action. Putting text in red is a no no. It has the opposite to the desired affect. Users can see normal case, font informational OK but most will read it but be worried enough to do nothing, the reasons they cite are bizarre such as 'well I didn't want to break it' through to 'well how do I know its legit'. This idea is most excellent but the output should not go graphical unless it is under a 'advanced' power user area. Please try and walk a mile in the shoes of a basic user who has small to medium IT literacy and has accessibility issues. The same thing goes for warnings or exclamations etc; they often do not work and can make things worse.

[tomasbrod]

So what do you suggest @philipswift ? yeah Red text might not be the best. We expect our users to at least be able to read. Understand that we need to tell users that something is wrong.

[denravonska]

It absolutely needs to go in the front of the wallet in one way or another, or we might as well just make it an RPC command. The idea is to help non-technical people get off a fork if they're on it by maybe taking them to a synchronisation wizard. If possible we should of course try to resync automatically without any user interaction :)

[ceo75]

How about a simple notification that informs the user they are on a fork? Perhaps it could provide a pointer to a help dialog within the application that will guide them through getting back on the correct chain? An automatic re-sync would be best but there should be a way to disable auto-sync for the subset that don't like automatic updates.

[grctest]

Perhaps also, when (POS difficulty | Stake weight) is too low, an additional warning is shown when the user is attempting to send a transaction? It could prevent users sending funds to exchanges/services during times of instability?

[ceo75]

Oh! How about a simple exclamation mark ( '!' ) behind the block count if it detects it's on a fork? The '!' could be a link to prompt the user to initiate a sync? Perhaps gives them a short dialog stating they appear to be on a fork, click OK to begin a sync of all blocks?

It wouldn't be intrusive, it wouldn't be a big scary warning. It's just a simple '!' notifying that attention is needed.

(Sorry for multiple replies. I'm at work and my mind is coming up with things as I work.)

[denravonska]

I agree with @ceo75. Hovering it could give the user a quick explanation while clicking on it could show a resolution dialog.

[iFoggz]

i understand how a ! could be uneasy for the inexperienced. But the sooner we end forks the sooner things could return to normal.

I like @ceo75 dialog idea as well

if we do that and it does goto a prompt you should also mention if they are unsure... they can seek help from the gridcoin community help (forums/irc) or a web page with detailed understanding written in a way low experienced people could understand with examples, etc before continuing. If we going to do something that could remotely make someone unsure then I think it is important there be least a resource link with information for the end user or as @ceo75 mentioned some form of help dialog. I think the going blindly when not knowing anything about what your gonna commit to would be the more uneasy then a ! to the end user.

You look at software out there and when somethings wrong there is access to information directly at the end users finger tips without them having to physically find the time to search the information out and research the information. This cuts down the barrier and time involved in the user making a decision as it helps them to be informed more efficiently and more effectively. This is no different then someone with a language barrier and if the information they need is not easily accessible then it could become overwhelming.

Regardless something needs to be done for the health of the chain. Helping the end user understand should help the process in doing so.

Also automatic syncing is a concern to me. Unless we find a way to make sure that the client can determine what the correct chain is. This could be a disaster if we had a ton of clients making incorrect decisions as it'd be like waging a block war on the network and could form the shape of the future on its own. No i will not say like skynet thou it did cross my mind for a laugh haha!

Just my thoughts on the subject.

[philipswift]

@Foggyx420 totally agree. Some really pertinent points raised.

[ceo75]

After reading @Foggyx420 comments I am leaning away from the auto-sync as well. If there is a possibility of it causing issues on the chain then we should avoid it until such time as a system can be devised that eliminates as much risk as possible.

[caraka]

I am very concerned with talk here regarding being on a fork versus being on the correct chain. By definition, if the chain forks, everyone is on a fork, and there isn't a straightfoward way to be sure which is the 'correct' fork, as to be fair the correct fork is the one that wins. If everyone is prompted to re-sync, whether automagically or via DownloadBlocks, it could well bugger the 'better' fork and produce even more problems, as those nodes fall away and join the out-of-sync scrum, further lowering the difficulty and net weight.

Be very careful what you ask for. In a decentralised, consensus model it is easy to push it into chaos. We need less complexity with our wallet for security, not more complexity.

[skcin]

I agree with @caraka. It is also not that easy to test such a heuristic. We would have to create a forking situation in testnet to test the behaviour and effects.

But maybe we don't need such a complex idea. The recent forks were caused by a bug introduced over 6 month ago, right? It came to light only now because the beacons advertised at that time began to expire. Of course this could have been prevented if we tested the whole process for one year in testnet. The bug would have been discovered in testnet and fixed before going live. But I don't think at the current state of gridcoin such a thorough development/testing is possible or wanted. Maybe we can try to be more careful and the development process @denravonska proposed reflects that.

I believe that at least some of the forking issues were caused by people not upgrading quickly to the newest version of the client. So the first thing we should do is make the wallet notify you if there is a new version.

[philipswift]

@caraka totally agree. We were in chaos and triggered by one small butterfly if you know my meaning. Simple, KISS, clean, elegant code that is secure. The less there is then the fewer options black hats and malignant payloads have to hang on to. We should put Gridcoin into testnet for a year and stop real world fiddling. There are Enterprise level systems and guidelines out there for a reason. 'If something is worth doing, its worth doing well'. User non compliance is a key contributor to increasing the length of time it takes to get of a fork. Expectation management is key here, for all types of user.

[denravonska]

Alrighty, closing as won't fix :)

[Erkan-Yilmaz]

I disagree with closing this as won't fix...

make it an optional feature in the settings, so users can decide to enable or not (standard is then deactive, so people who didn't want this feature originally, still can be happy)

when I am on a fork, I lose time (getting snapshot, applying it, ...) especially for small-balance people also hurtful since they will get "punished" also with delayed reward chance. The sooner they realize this, the better

[denravonska]

@Erkan-Yilmaz What should be the limiting factor when deciding whether to warn or not? Should that be configurable as well?

[Erkan-Yilmaz]

asking the people from yesterday's fork about their perception and wishes:

• Gridcoin users: we need feedback about yesterday's fork situation from you

[Erkan-Yilmaz]

Experience from the past fork situations was:

• a restart helped most often

So, the less intrusive thing seems to:

• just ask the user when the warning criteria (to be defined) are fulfilled to restart her wallet.

(Asking important, so wallet doesn't restart forever)

---

just verified in irc:

• user was for 43 blocks (that is like 1h) on his fork with version 3.5.9.2, and he restarted and he got back on the main chain

[Erkan-Yilmaz]

12 days after last incident:

• a fork happened again: several users reported that (but also gridcoinstats forked)

for 1 specific user:

• he was already for >100 blocks on the fork, but did not restart yet

[Erkan-Yilmaz]

comment by iFoggz:
"It can take some longer before client can realise there on a fork and reorg."

[tomasbrod]

Due to way stake kernel is processed, wallet will likely fail to reorganize more than 16 hours on prod or 1 hour on testnet.

[Erkan-Yilmaz]

2 users on a fork for 2.5h (see here)

• but a client restart DID not fix the situation

[rtennill]

It sounds like a fair number of the forks are due to out-of-date clients. I have been in this boat several times because there isn't any indication in the wallet and auto upgrade doesn't seem to be working anymore. Ideally there would be a button that starts the upgrade process rather than something hidden in the menu.

Wallet with latest version:

Wallet that needs to upgrade:

[denravonska]

Re-closing this as won't fix. Forks are not really an issue anymore and the few forks we have settle within a day.