+1 on everything except even a hint of Java. It's been almost 20 years, and the security issues come out more often than the fixes. Java might be useful for toys, games, and tightly controlled embedded systems, but I'd rather post my private keys on the forums than trust my money to anything based on Java.
SPV would be nice, but only as a default. Users should have the option to operate a full node, but would use SPV until it was sync'ed.
I like the idea of supporting multiple currencies. I would suggest that every currency be supported via a plugin. Client devs might work on supporting the highest-volume coins, but devs on new altcoins could create their own plugins.
A plugin architecture could be extended to also work with a headless client.
It might also be worth considering incorporating bitmessage support. This could be used for developers to announce updates, new plugins, and help users find each other on the 'net.
libtorrent could be used to allow updates and plugins to allow for p2p distribution of updates and plugins.
Topic: - (Read 1733 times)
I'm not entirely sure how 2FA (in the sense of Google Authenticator and similar apps) would work in this scenario. GAuth requires a shared secret between user and the service. In this case the service is the wallet program that runs on the users computer. Consequently, the secret has to be accessible there and has to be accessible by the wallet software without any additional authentication (after all, the 2FA is supposed to work in conjunction with a regular password). So if the users computer is compromised by malware or something similar, the 2FA secret is exposed as well, rendering the whole 2FA scheme ineffective.
Well you have to separate the JVM (a just in time compiler and class library), from Java the language, from Java the failed attempt to sandbox downloadable code.
The JVM is not very interesting, it's just a big runtime library. There are techniques for making it much smaller. For instance Avian (http://oss.readytalk.com/avian/) shows how to make GUI apps that compile down to standalone executables that are less than a megabyte in size, no dependency on having Java installed. Unfortunately it can be a pain to compile on modern MacOS versions, but obviously the binaries work.
If you work in any kind of modern language you'll end up needing a big runtime library anyway. This is true of apps written in Python or using Qt as well.
Java the language is mediocre at best. It's main redeeming feature is that it's simple and old so everyone knows it. But you don't have to use Java to access libraries written in it. You can write code in JavaScript, Ruby, Python (2.7), Lisp, and a lot of more modern languages like Kotlin, Scala or Ceylon that have lots of interesting features and type systems.
Then there's the failed attempt to do sandboxing (applets). Well, basically every attempt at this has gone badly wrong. Web browsers still routinely have serious exploits in their rendering engines, that's why Chrome sandboxes the sandbox! But for writing regular apps this doesn't really matter to you - applets can be completely disabled and it makes no difference.
So if you wrote your own wallet on top of bitcoinj, what would it mean?
- You could write your code in lots of modern languages (but not C/C++/Objective-C without binding work).
- Your app can be standalone and look/feel like a normal app. See JWrapper for a tool that makes native installers for each platform.
- The end user never needs to know that there's any Java under the hood.
The JVM is not very interesting, it's just a big runtime library. There are techniques for making it much smaller. For instance Avian (http://oss.readytalk.com/avian/) shows how to make GUI apps that compile down to standalone executables that are less than a megabyte in size, no dependency on having Java installed. Unfortunately it can be a pain to compile on modern MacOS versions, but obviously the binaries work.
If you work in any kind of modern language you'll end up needing a big runtime library anyway. This is true of apps written in Python or using Qt as well.
Java the language is mediocre at best. It's main redeeming feature is that it's simple and old so everyone knows it. But you don't have to use Java to access libraries written in it. You can write code in JavaScript, Ruby, Python (2.7), Lisp, and a lot of more modern languages like Kotlin, Scala or Ceylon that have lots of interesting features and type systems.
Then there's the failed attempt to do sandboxing (applets). Well, basically every attempt at this has gone badly wrong. Web browsers still routinely have serious exploits in their rendering engines, that's why Chrome sandboxes the sandbox! But for writing regular apps this doesn't really matter to you - applets can be completely disabled and it makes no difference.
So if you wrote your own wallet on top of bitcoinj, what would it mean?
- You could write your code in lots of modern languages (but not C/C++/Objective-C without binding work).
- Your app can be standalone and look/feel like a normal app. See JWrapper for a tool that makes native installers for each platform.
- The end user never needs to know that there's any Java under the hood.
So it's Java/Multibit-based? I can't wish non java? 
I vote for:
+ privacy (maybe try implement Dark Wallet system, when the specs are out)
+ multicurrency (maybe even plugin type model or a config system, like that you can setup any Litecoin clone you want, as they share all same codebase)
+ 2FA obvious
+ Dongle support: Trezor, YubiKey, and so on
+ Consolidation Button
0 for Grab Bitcoin Pricing
(doesnt seem to be important, most people have an bitcoin price ticker in there menu bar)
maybe the option to display show the bitcoin price in the 2 fiat currencies always not only the price section, anywhere in the client
+ backup scheduling
+ backup verifying
+ possibility to delete addresses from wallet
+ the option to color addresses in the wallet address list
+ the option to PIN/"sticky" addresses in the wallet address list
+ multilanguage support
I vote for:
+ privacy (maybe try implement Dark Wallet system, when the specs are out)
+ multicurrency (maybe even plugin type model or a config system, like that you can setup any Litecoin clone you want, as they share all same codebase)
+ 2FA obvious
+ Dongle support: Trezor, YubiKey, and so on
+ Consolidation Button
0 for Grab Bitcoin Pricing
(doesnt seem to be important, most people have an bitcoin price ticker in there menu bar)
maybe the option to display show the bitcoin price in the 2 fiat currencies always not only the price section, anywhere in the client
+ backup scheduling
+ backup verifying
+ possibility to delete addresses from wallet
+ the option to color addresses in the wallet address list
+ the option to PIN/"sticky" addresses in the wallet address list
+ multilanguage support
Wishlists are easy, writing the code - that's more work 
At any rate, since spring of 2013 SPV wallets that don't rely on Electrum servers but which use the regular P2P network are basically as fast as other kinds of wallet. They don't need to download the whole block chain any more and typically can sync in a few seconds. So you can write an SPV wallet now quite easily in a whole lot of languages, any language that can run on the JVM can be used to build a cross-platform wallet app. It only takes a few lines of code to get started and then you can add whatever features you want on top.
At any rate, since spring of 2013 SPV wallets that don't rely on Electrum servers but which use the regular P2P network are basically as fast as other kinds of wallet. They don't need to download the whole block chain any more and typically can sync in a few seconds. So you can write an SPV wallet now quite easily in a whole lot of languages, any language that can run on the JVM can be used to build a cross-platform wallet app. It only takes a few lines of code to get started and then you can add whatever features you want on top.
Jump to: