**Rough Draft** for automated client upgrades via data feeds

It is important that client upgrades occur in a timely manner, particularly when they contain protocol changes. It is also critically important that individuals control what updates they receive. If we centrally pushed client updates it would put the entire network at risk to the scenario that the person controlling the updates would make a mistake, or that they would be coerced into pushing an update that is not in shareholder’s best interests. On the other hand, individual shareholders are frequently not paying attention to upgrades offered or simply don’t want to take the time to upgrade when they would happily accept an upgrade if it didn’t take their time or attention.

There is a way to provide automatic client updates without the use of a central authority via data feeds. Just as in version 0.5.3 shareholders can subscribe to any data feed they like to define their vote, shareholders could also use a data feed of their own choosing to either notify them when an upgrade is needed or to alternatively automatically install it. Automatic installation should be the default behavior. Eventually, a default data feed provider would be chosen at first install somewhat randomly but in proportion to the present popularity of each data feed. An exact method for determining the popularity of various data feeds is still in being devised, but I digress.

There are a number of specifics to be worked out, like what the best method is for effecting an automatic update. There will also need to be new RPCs to support this. I’m hoping someone on our team or someone who would like to become part of the team will take the time to define these specifics and finalize the motion. Otherwise, hopefully I will eventually have time to finalize the motion, but I doubt it will be soon.


One thing I think is important is that the client allows you the chance to backup your NBT/NSR wallets before the update takes place, just in case something were to go wrong.


That’s a good suggestion, @Sentinelrv. Thank you.

1 Like

@Sentinelrv One thing I think is important is that the client allows you the chance to backup your NBT/NSR wallets before the update takes place, just in case something were to go wrong.
I fully agree with you and in fact it should be set in stone

Instead of a data feed would it not be possible to build a messaging system into the wallet where critical messages like updates could be sent to all wallets or is this a big job.Also a suggestion for the wallet would be due to the amount of cash value held in some to build a 2FA system into it?

I’ve often considered what would be needed to augment the Nu wallet with 2FA, and I’m hoping that once the next major release is completed that there will be some interest from community members with the technical skills to make it happen.

if I remember right the airbitz wallet has one touch 2FA for its mobile wallet and I am sure a crypto coin has 2FA for its desktop wallet.Wonder if any of the code is open source

Regarding MFA/2FA (multi-factor/2-factor authentication):

Classical approaches to MFA won’t work for us because unlocking your 1Password data is not about authenticating to some service. So sure we could add an authenticator for using 1Password.app itself, but it wouldn’t actually provide any real additional security. It would be just for show.

Instead we would need a key splitting approach, […]


They have discussed it a bit over at AgileBits. Not sure it applies to your ideas, but thought you should know.