Need solution to better decoy selection for non-rct

[iamsmooth]

The existing code from upstream uses the old triangular distribution with recent zone method which is rather poor especially as the chain gets older, albeit slightly better than the even worse previous methods.

The gamma-distribution method is only used for rct, and in any case is a poor fit for AEON due to the lower chain usage (many empty blocks) and the overweighting of outputs (mostly coinbase outputs) from small blocks. Apart from that issue, attempting to implement it with non-rct would be complicated due to the presence of different size outputs in each block.

[iamsmooth]

I believe this method is acceptable and better than what is already being done.

1. Sample from existing implemented gamma distribution using the existing parameters (output is a timestamp or equivalently a block number)
2. Rescale this time or block number by the number of outputs of the desired size, resulting in an output index. For example, a time 50% into the history would scale to an output index 50% into the list.
3. Use output index from 2

[iamsmooth]

I believe this is doing something similar with rct monero-project@f04b3a7

[stoffu]

monero-project#5389 computes the average of time intervals between outputs over the previous one year, which can be easily computed thanks to the cumulative distribution function of rct outputs stored in the daemon's database. Currently the database doesn't store such data for non-rct outputs IIRC, and doing so will require quite some coding and DB format changes which may not worth the bother (surely implementable though).

An easier alternative is to compute the average over the entire chain history which I think is reasonable.

[iamsmooth]

@stoffu I believe get_output_distribution works for non-rct and takes a from_height argument. It is currently used for the 1.8 day recent zone but could be used to get the number of outputs in the past year (or some other interval).

This isn't all that efficient (runs linearly through the output list and counts) but it could be made more efficient if needed later. If I'm not mistaken it is already doing this linear scan anyway for the recent zone.

Using the entire history is somewhat okay (but has some undesirable effects for AEON specifically since there were a huge number of outputs in the first few months due to the very poor early pool implementation, I believe vastly higher than what has been typical since).

[stoffu]

#115

[BigslimVdub]

Can you please close this since the underlying code was merged to master?