00:51:36 <koe> hi, was the output selection algorithm from https://arxiv.org/pdf/1704.04299/  ever implemented? This ridiculous function wallet2::get_outs still mentions a triangular distribution.
00:53:58 <sarang> A variation of the exponential-gamma distribution is used, to account for variations in block weight
00:54:41 <koe> where was it implemented?
00:57:18 <koe> is it this gamma_picker function?
00:57:26 <koe> class*
00:57:38 <sarang> I believe so
01:31:25 <koe> in gamma_picker::gamma_picker what is the point of this line? The division should evaluate to 1 from what I can tell.
01:31:26 <koe> average_output_time = DIFFICULTY_TARGET_V2 * blocks_to_consider / outputs_to_consider;
01:43:53 <moneromooo> A block contains many outputs, typically.
01:50:40 <koe> 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?
01:51:28 <moneromooo> Output indices IIRC.
01:58:34 <koe> Im stuck on this: isn't rct_offsets.back() == rct_offsets.size()?
01:58:55 <moneromooo> No. back is the last element. size is the number of elements.
01:59:30 <koe> if the offsets are just indices, isn't it just 1,2,3, etc? what am I missing here?
02:03:22 <moneromooo> That a block contains many outputs, typically.
02:03:57 <moneromooo> IIRC this is a list of how many outputs there are per block. Incrementally IIRC.
02:05:29 <koe> The function is wallet2::get_rct_distribution but I don't understand what it's doing.
02:06:17 <moneromooo> It gets the number of rct outputs per block.
02:13:58 <koe> 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)
02:14:41 <koe> Is .back() - .front() ~= .size()?
02:14:48 <moneromooo> No.
02:15:02 <moneromooo> Well, for testnet, yes :)
02:16:02 <koe> wait, .back() - .front() ~= .size() is false?
02:16:13 <moneromooo> (since current monero has one ouput per coinbase, which is treated as rct despite being cleartext)
02:16:29 <moneromooo> In general, .back() - .front() ~= .size() is false.
02:19:34 <koe> That would mean this line https://github.com/monero-project/monero/blob/b4e1dc83d275f8ee9a8c12615cf952f05161c7a3/src/wallet/wallet2.cpp#L1010
02:19:53 <koe> is always either blocks_per_year, or .size()
02:20:04 <koe> actually not, um
02:20:19 <koe> either blocks_per_year, or .size() + .front()
02:20:23 <koe> which seems weird
02:20:43 <koe> unless .front() is 0
02:20:55 <koe> in which case .back() == .size()
02:21:01 <koe> which you said is false
02:22:07 <moneromooo> If you have a small array [8, 30], size is 2, back()-front() is 22. Definitely not about equal.
02:24:38 <koe> 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!
02:26:17 <moneromooo> I just looked at the code that calculates outputs_to_consider:
02:26:47 <moneromooo> rct_outputs is the cumulative amount of rct outputs per block.
02:27:07 <moneromooo> The code subtracts the number of cumulative rct outputs a year ago to the one now.
02:27:31 <moneromooo> So the result is the number of rct outs in a year. Modulo block time variance, possibly off by one block, etc.
02:27:56 <koe> ok that makes sense then
02:32:34 <sarang> 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
02:32:51 <sarang> It smooths over variances in the output density
02:34:38 <sarang> Using many blocks to compute the average time reduces short-term block density effects
02:38:02 <koe> ok I see it now; only thing I'm wondering is if there are checks to prevent duplicate ring members, have not found any
02:44:03 <Isthmus> Apparently duplicate ring members aren't allowed after v6
02:44:19 <Isthmus> (I think enforced in the protocol, but somebody else should confirm)
02:49:31 <moneromooo> Protocol, yes.
04:45:04 <koe> prior to the current 11-only ring size, where all outputs from a transaction required to have the same mixin?
04:45:12 <koe> were
04:54:59 <koe> e.g. could there be a RCTTypeSimple transaction with output1: 8 ring members, output2: 22 ring members?
05:52:37 <koe> Isthmus just saw your conference presentation, very nice work!
09:22:51 <koe> saw some other great presentations, very cool
17:59:45 <endogenic> figure i'll post this here. there was just a talk on a xmr-btc atomic swap proposal at c3.. https://github.com/h4sh3d/xmr-btc-atomic-swap
18:15:48 <sarang> Was brought up here a while back by the author
18:16:00 <sarang> It needs a particular zk proof
18:16:42 <sarang> Could be done with bulletproofs (an example SHA circuit's timing data was in the paper)
18:17:15 <sarang> But afaik that circuit has not undergone thorough review
18:36:53 * endogenic adds it to the workshop agenda