Version management of Altcoin wallets

[KleinMatthias]

Hi there,

I would like to ask how version management of Altcoin wallets is currently being handled?

In the last 4 weeks (aka the time I have spent with Altcoins) I have noticed 3 major challenges:

1. New Wallet versions being introduced without everyone upgrading
2. New Wallet versions are sometimes incompatible to the old wallets => people lose their coins
3. Every new altcoin requires its own wallet software (=> issues (1) and (2) get even worse with every wallet installed)

Re 1) Not everyone is as active as you guys. Not everyone knows when his QT wallet must be upgraded. I would like to propose that all QT wallets have an "autoupdate" feature which checks at least once a day if a new version is released. Pretty much like an iPad/iPhone-App or an Adobe/Microsoft/Apple/PrettyMuchEveryOtherSoftwareVendor-application. They all check for updates all the time. Some even allow automatic updates so the user is never bothered with such admin tasks. I think, every wallet should have that feature and it should be activated by default. Advanced user can - of course - switch it off (e.g. by a command like "autoupdate false" or so).

Re 2) Take a look at QBT (or others): when v3 was released, the blockchain of v2 was abandoned. As I said before: not everyone is as active as you. I am sure that there are people out there that invested hard cash into buying v2 QBT, did not realize that they must switch over to v3 within days, and now lost all their money because their v2 coins are useless. Not really sure how to handle this. One way could be a mandatory escrow service accessing the frozen old blockchain to payout to new versions. But I am not sure how that could be enfored in reality.

Re 3) I think one way to solve this is by building a plugin-mechanism with version control for Meta-Wallets. What do I mean by this? Well, instead of installing a completely new wallet software for each altcoin, there should only be 1 single Meta-Wallet that can handle all altcoins (even those that have just been released seconds ago). In my opinion, the best way to deal with this is by means of a plugin-system. So the standard source-code does not only generate the QT and the XXXd file but also the XXXd-plugin (implementing the entire QT minus the GUI, but plus the plugin-interface). This plugin should result in 1 file that is published in the Meta-Wallet-repository. Seconds after this has been done, all Meta-Wallets around the globe can download and install the plugin and handle the new currency. Since that plugin is essentially a QT without a GUI, it can implment all features of the native QT and consequently be part of the network of the respective currency.
The same way, if a new version has to be introduced, the Meta-Wallet-Repo makes sure that it updates automatically. All the devs have to do is to make sure they update the Metawallet-repo whenever they release something new. I am sure they will do that in their own interest because after all, they want everyone to update.

Any thoughs from you?
Do you think that makes sense / is needed / is doable?

Thanks
Matt

[CaptEmulation]

OMG yes

[KleinMatthias]

OK, but how can we make that happen? What would be the first step? :-)

[CaptEmulation]

I've been thinking about this for a little while, before you even asked the question.  The problem with all of the various Qt based wallets floating out there is that the attributes/parameters of the particular coin are baked into the source.  Furthermore, most alt-coins I have inspected have not updated to latest bitcoin sources, and so miss out on the multi-wallet support.  So what needs to happen is that, starting from the multi-wallet codebase, also add parameterized attributes defining a wallet-- seed nodes, genesis block, rewards parameters, etc..  Also, obviously, the client needs to have support for multiple blockchains, and be able to associate these blockchains with their parameters and the wallet. 

I've been thinking about making a generic Qt wallet which supports additional configuration options-- enough options to be able to switch between one alt blockchain to another.  From there, one can then try and support multiple block-chains, and add support for switching between them.

[simbo]

This is kind of what I had been thinking, except for me, is to have a multi-coin wallet with exchange function. That way, not just you can hold any type of coin, but also able to convert into the coin needed to do whatever you need to do.

Regards.

[tk808]

there already is a meta wallet project that needs funding on bitcoinstarter

https://bitcoinstarter.com/projects/419

[CaptEmulation]

Maybe it is just me, but with no credentials, github links or any existing work-- I am hesitant to add any funding to that project.  It would be one thing to have something already, a plan of what needs to be complete, and the kickstarter for the final push.

[markm]

So basically you are proposing updating "multicoin" to the latest bitcoin code?

Which, considering how old a version of Bitcoin multicoin was based on, means pretty much starting from scratch from the new bitcoin code...

-MarkM-

[gweedo]

Re 1) Not everyone is as active as you guys. Not everyone knows when his QT wallet must be upgraded. I would like to propose that all QT wallets have an "autoupdate" feature which checks at least once a day if a new version is released. Pretty much like an iPad/iPhone-App or an Adobe/Microsoft/Apple/PrettyMuchEveryOtherSoftwareVendor-application. They all check for updates all the time. Some even allow automatic updates so the user is never bothered with such admin tasks. I think, every wallet should have that feature and it should be activated by default. Advanced user can - of course - switch it off (e.g. by a command like "autoupdate false" or so).

Please don't add this do you know the security that you are killing by doing this? What if somehow the update server gets hacked and a rogue build is pushed thru then they can steal everyone's coins! Please think before posting.

[markm]

They would have to sign the updates using the keys the client trusts, which would not be on any server unless the developer was part of the gang of crooks in the first place, such as if the developer deliberately put their personal developer key on a third party machine as a way to try to be able to pretend their inside job was a hack.

Basically the key would only exist on each signing developer's own encrypted laptop in their vault, or whatever.

It could still get hacked despite all the airgap etc etc though simply by their distro sending a trojan or being already infected with a trojan.

(Next NSA defector might not whistle-blow, might just make personal use of all those backdoors they put everywhere... Or whatever...)

-MarkM-

[markm]

Yeah but people use websites for money too, so we already know they prefer getting it all stolen regularly for the convenience factor.

Otherwise all the exchanges etc would be running Open Tranactions or having the users use PGP like MPOE does or stuff like that.

The customer is always right and the customers insist on insecure systems.

Banks tell people to use their birthday or social insurance number as their PIN. Its apparently more profitable to write off constant massive theft and pay off the media not to report on its vast scale than to tell grandma its not okay to let the local mugger help her work the confusing ATM machines or whatever.

-MarkM-