hi, was the output selection algorithm from arxiv.org/pdf/1704.04299 ever implemented? This ridiculous function wallet2::get_outs still mentions a triangular distribution.

A variation of the exponential-gamma distribution is used, to account for variations in block weight

where was it implemented?

is it this gamma_picker function?

class*

I believe so

in gamma_picker::gamma_picker what is the point of this line? The division should evaluate to 1 from what I can tell.

average_output_time = DIFFICULTY_TARGET_V2 * blocks_to_consider / outputs_to_consider;

A block contains many outputs, typically.

is an rct offset a block height? so rct_offsets contains, for block height x, y elements with value x if block x has y rct outputs?

Output indices IIRC.

Im stuck on this: isn't rct_offsets.back() == rct_offsets.size()?

No. back is the last element. size is the number of elements.

if the offsets are just indices, isn't it just 1,2,3, etc? what am I missing here?

That a block contains many outputs, typically.

IIRC this is a list of how many outputs there are per block. Incrementally IIRC.

The function is wallet2::get_rct_distribution but I don't understand what it's doing.

It gets the number of rct outputs per block.

hmm idk if that makes sense, since it returns the vector rct_offsets. The .size() of rct_offsets is definitely the total number of rct outputs in the blockchain (assuming rct start height = 0)

Is .back() - .front() ~= .size()?

No.

Well, for testnet, yes :)

wait, .back() - .front() ~= .size() is false?

(since current monero has one ouput per coinbase, which is treated as rct despite being cleartext)

In general, .back() - .front() ~= .size() is false.

That would mean this line github.com/monero-project/monero/bl…61c7a3/src/wallet/wallet2.cpp#L1010

is always either blocks_per_year, or .size()

actually not, um

either blocks_per_year, or .size() + .front()

which seems weird

unless .front() is 0

in which case .back() == .size()

which you said is false

If you have a small array [8, 30], size is 2, back()-front() is 22. Definitely not about equal.

let's say rct_offsets is [2, 3, 6, 8]; size is 2, back is 8, then outputs_to_consider would be 8! more than size!

I just looked at the code that calculates outputs_to_consider:

rct_outputs is the cumulative amount of rct outputs per block.

The code subtracts the number of cumulative rct outputs a year ago to the one now.

So the result is the number of rct outs in a year. Modulo block time variance, possibly off by one block, etc.

ok that makes sense then

koe: the basic idea is to use the average "output time" to do a scaled exponential-gamma selection, and then redraw uniformly within whatever block contains the selected output

It smooths over variances in the output density

Using many blocks to compute the average time reduces short-term block density effects

ok I see it now; only thing I'm wondering is if there are checks to prevent duplicate ring members, have not found any

Apparently duplicate ring members aren't allowed after v6

(I think enforced in the protocol, but somebody else should confirm)

Protocol, yes.

prior to the current 11-only ring size, where all outputs from a transaction required to have the same mixin?

were

e.g. could there be a RCTTypeSimple transaction with output1: 8 ring members, output2: 22 ring members?

Isthmus just saw your conference presentation, very nice work!

saw some other great presentations, very cool

figure i'll post this here. there was just a talk on a xmr-btc atomic swap proposal at c3.. github.com/h4sh3d/xmr-btc-atomic-swap

Was brought up here a while back by the author

It needs a particular zk proof

Could be done with bulletproofs (an example SHA circuit's timing data was in the paper)

But afaik that circuit has not undergone thorough review