Quote from: btc4ever on October 01, 2014, 06:37:59 PM

My concern is that if I (or anyone) go to the work to fix it and submit a patch, it won't get accepted, due to core team resistance.

Am I wrong?

Well, do something different than all the previous "enterprise" programmers. There was a common thread in all the "enterprise" patches submitted to the core team: they interfered with or completely destroyed the blockchain reorganization behavior. I'm on the record disagreeing with various technical issues regarding Bitcoin Core client, but I fully support the Bitcoin Core developers in their insistence on preserving the fundamental properties of the Bitcoin protocol: the global consensus is achieved through a somewhat random convergence that could involve orphaning some blocks.

The list of things you seem to be missing is actually longer:

1) The coin-selection is a non-trivial problem that is NP-complete in a general case (I've already mentioned that the current solution is a stochastic approximation, which is non-monotonic and therefore breaks the code like yours)

2) Bitcoin wallet isn't static while your code snippets are running, new blocks can appear randomly and change the coin selection both by adding and removing coins from it. (This is the most common mistake in the various "enterprise" patches that I've seen: mishandling of orphan blocks)

3) After you correctly solve the first two problems there is an issue of repeated greedy local optimization leaving wallet full of near-dust coins, so the optimization needs to be upgraded to some non-local, near-global or at least allow for optimizing coin selection for a set of transactions.

4) After you correctly solve problem (3) you need to provide a solution for the common operational requirement of keeping 2 wallets: hot and cold, and manage the coin transfers between the two of them that fulfill the non-scalar optimization goal of maximizing security and minimizing fees.

I hope that the above list helps you understand the true "enterprise" requirements and why your proposal is nothing more than a short-sighted temporary hack.

From myself I'll add that any true "enterprise" solution would obey http://en.wikipedia.org/wiki/Two-phase_commit_protocol and will easily integrate with any of the available http://en.wikipedia.org/wiki/Transaction_processing_system . From your insistence on using unstructured RPC calls I surmise that you have neither "enterprise" coding experience nor even plain multi-threaded development.

Quote from: btc4ever on October 01, 2014, 06:37:59 PM

So what technical reason prevents that capability from being exposed at the RPC API level?

The technical reason is called "inversion of control" (i.e. server calling client to make a decision). Again this was discussed on this forum many times, at least since the wx->Qt UI transition. Use the search function.

Quote from: btc4ever on October 01, 2014, 06:37:59 PM

You seem to be missing the point that this is a sharp pain point for developers and businesses.

If it is really such a "sharp pain point" then you are better off basing your work on a different code that Bitcoin Core and submit raw transactions to be reference implementation.