@gmaxwell, it's hard for there to be meaningful contributions back when most alts are stuck on ancient versions of the code base! But even without contribution back, minimizing the code difference between alts makes it easier for maintainers to rebase against newer versions of Bitcoin Core, which increases the security of the greater crypto currency ecosystem. But as you say, the greatest contribution to bitcoin specifically is enforcing some type safety for monetary values.

@leofidus, I'm not sure you understand what this change does or the context in which the code executes, as using `ToInt64()` would not fix the problem and would in fact make it worse. That's alright; let's walk through it:

The original line of code above fills in a hidden column with the left-padded string representation of the output's value, in units of 1e-8 bitcoin. So for example, three outputs with the values 5btc, 0.2btc, and 1mbtc would have the following values for this field:

    000000500000000
    000000020000000
    000000000100000

When you request a numeric sort based on the output value field, what it actually does is do a string sort over this hidden field, which is why the left-padding is necessary. (I've used '0' as the padding character where the code actually uses ' ' [space], just for clarity's sake on Github.)

Now there are two Bitcoin-specific assumptions here: (1) monetary values are integers, and (2) no output will ever have more than 15 digits of absolute precision. These are not universally valid assumptions, and either or both of them might be invalidated on a side chain. Side chains don't exist yet so we must look to alts for examples: Dogecoin and Freicoin invalidate one and both, respectfully.

One of the goals of this pull request is to minimize the number of lines of code which are sensitive to these assumptions, and to make the format assumptions explicit when it is necessary (e.g. `ToInt64()`). So if we do not assume that CMoney is implemented with an integer, and that the dynamic range of monetary values may be more than 15 decimal digits on an absolute scale, how do we still carry out this string-sorting hack for the GUI tables?

What the updated code does is use another cool little hack: it turns out that because IEEE floating point is designed in a particular way, you can sort non-negative floats or doubles as if they were integers and get the same result. There's a little bit of bit-flipping magic that makes this work for negative values as well, and that's what `EncodeDouble` does. So the new code does this:

1. It converts from whatever the native CMoney format is to 64-bit IEEE floating point, in the process rounding to approximately 16 decimal digits of precision - this is safe to do for bitcoin values in non-consensus code, since `MoneyRange` restrictions ensure this is a 1:1 function with stable round-trip transformations, at least without FPU bugs or compiler optimizations.

2. It uses the new utility function `EncodeDouble` to map the `double` to `uint64_t` in another 1:1 transformation, doing some bit-flipping magic so for any non-NaN floating point values a and b, if `a < b` then `EncodeDouble(a) < EncodeDouble(b)`.

3. It then does the exact same print-integer-with-left-padding trick to fill the column, except it pads to 20 bytes instead of 15 to capture the entire range of `uint64_t`.

The end result is that no matter the internal representation of CMoney, the hidden column will be filled with a twenty-character string representation of the value, which preserves sorting order for up to 16 decimal digits of *relative* precision. This is in every way better than the current implementation, and fully generic - it does not care what internal representation is used.