would it be possible in coin control to somehow enable batch selecting of inputs? if you have thousands of small blocks selecting them one by one can be a bit tedious
I am not sure, I will merge in all CC-related changes and it's improvements I am aware of. However, I am going to implement the maximum PoS block reward: many of you are merging all their coins into a single input and running a wallet once a month or even more rare. According to the statistics I collected, presently only 1/3 of existing supply is participating in PoS generation on a regular basis. This is not good for the network security at all. At the same time I did a few optimizations to the PoS generation code to make it even less energy consuming than before (and thus faster and less CPU intensive) to compensate the need to have more than 1 input in your wallet. These optimizations are being tested presently. Also, the automatic low inputs merging policy is under reconsideration now.
Apart from other things I am going to introduce in the coming hard fork, I am seriously thinking on switching hashing function. There is a number of reasons, the most important of which is the time necessary to validate a block received from the network. First, I believe that memory-intensive algorithms like Scrypt-N are not serving their purpose anymore: there are Scrypt ASIC miners on the market, so apparently the memory is not a barrier for ASIC developers. From the other hand, although there are many different options like X11, X... I think it is an overkill for purpose to make the coin ASIC resistant. At least it makes block validation quite CPU-time expensive. After looking at spectrum of different hashing functions already implemented and adapted by different coins I picked the hashing function used by the JackpotCoin, the Jackpotcoin Hash Algorithm V2 (
https://bitcointalksearch.org/topic/annjpcmake-jackpotcoin-great-again-584481). This is a combination of a single keccak512 transformation followed by eight rounds of random selection (based on current internal state of the hashing 'engine') of groetsl512, skein512, blake512 and jh512 transforms.
The plain C implementation of this algorithm is 30 times faster than SSE2-optimized version of the Scrypt, thus it is 30 times more energy efficient in terms of CPU computations on Intel platform (for the GPU I see the four times higher hashrate and two times drop of consumption at the wall compare to Scrypt on R9-290 and R9-280X, the
Nvidia chipsets produce better ratio though). From the other hand, it is quite complex to be implemented in the silicon in the nearest future. Please share your thoughts on this.