- Porting to QT5 and making a static build is not hard to do.
What does QT5 bring in advantage?
- Checkpoints need improvements current checkpoints are badly chosen. This would probably decrease wallet launch time.
I'm not sure on that. I just traced wallet launch time today, and its bottleneck seems to be loading blocks from file to memory on startup (not even the extra calculations it does for POS after loading the blockchain). But I don't know if we're using the latest blockchain file format from bitcoin, or just an older shitty one. Maybe file format might be changed to whatever's the norm now, or maybe it's just that we have too many blocks to sustain it.
- Staking can be perhaps made better with only one change. Combine/split stake could be changed to a larger number. That would reduce "dust" - very small stakes/mints.
We had discussed this with the devs previously. Although defining combine threshold would have its benefits, there are some security concerns with it -- the network has to be big enough (otherwise there is a risk that everyone generates all their possible stakes, and network cannot find any more stakable TXs (until up to 20 days pass), resulting in inability to confirm transactions). The other point (it's current state) is that not everyone might be able to generate stake (because there is a fixed number of blocks per year, and every staking TX needs its own block with the current state).
I don't believe size of the network grew sufficiently in the last 1-2 months to support combining transactions, but some statistics might be created on the blockchain to see what the possibilities are.
None of those changes does not require a fork.
The big question is, who is going to put hes/her free hours in to it?
In future perspective, i would suggest porting mintcoin code to newer protocol. This means a lot of changes. Probably around 2 days work at least.
Any examples on newer protocol, what do you mean? This might have implications such as backwards compability or mintcoinj.