01:37:45 very interesting initial results?!?!?!?! 01:37:47 you tease! 01:38:19 I want to do a second check! 01:38:52 nonsense. n of 1. throw more cores at it. paralallalalieze 01:42:03 what do you all think about doing some kind of rounding on the minimum fee? currently it is recalculated on a per block basis, which directly leaks the time delta between tx construction and inclusion in a block. @ArticMine 01:43:53 I imagine around 1-2 day fee binning would be enough. 01:46:04 does this become moot when tail emission kicks in? 01:46:07 @n3ptune and @Isthmus I imagine you could calculate that delta for all tx that use the fee priorities (see my email with pseudocode for calculating fee Isthmus) 01:46:23 don't think so, since fees also depend on block weight 01:47:25 but fees depend on the _long term block weight_ so that feature has quite a slow development 01:49:27 also in our current era where blocks never leave the penalty free zone, block weights have no impact on fees 04:12:10 * Isthmus hears a ping and dips in for 30 sec 04:12:18 @UkoeHB_ like this? 04:12:19 https://usercontent.irccloud-cdn.com/file/4SMYpo99/image.png 04:12:59 yeah 04:13:28 I like your idea of binning 04:13:43 Hmm, as long as bin_width >> average residence time in the mempool 04:14:27 it wouldn't completely get rid of the problem, since at bin edges the delay will be somewhat apparent 04:15:11 * Isthmus ponders 04:15:19 Suppose bins go midnight-to-midnight UTC 04:15:54 at 23:45h I generate a transaction, and broadcast it 20 minutes later at 00:05h 04:16:14 maybe update the minimum fee every 720 blocks (one day, for example), so the window of blocks considered for median (and the base block reward used) shifts forward every 720 blocks 04:16:55 Under current system, an observer could see that 00:05h txn and calculate, ah, that transaction came from about 20 minutes ago 04:17:07 under the bin, the observer could only say "ah, that came from some time in the last day" 04:17:24 'it's at least 5 mins old, perhaps as much as 24hrs 5mins' 04:17:34 ^ exactly 04:17:43 To be clear: I have given approximately 0 thought to what a good bin size should be, was just using 24 hours to be illustrative :- ) 04:18:11 * Isthmus shuffles off to start cooking dinner 04:19:56 the long term median can rise only 0.5% in one day (takes 69 days to rise 1.4x), and it's probably similar for base block rewards, so the day-to-day fee would only deviate by a small amount; data on the actual spread of tx delays would be illuminating 04:20:19 or the estimated delay* 04:24:05 although fees do increase when the short term median rises (it's based on min(short term, long term)) so maybe we'd need ANOTHER median term median (oh god), which is the median block weight over the last fee_window 04:24:54 changing the minimum fee infrequently sounds good to me. it is basically arbitrary anyway 04:27:14 one day monero may be a case study in over engineering 😅 04:31:06 this idea came up while thinking about escrowed marketplaces, where it is VERY useful to create partial transactions on checkout that only get signed after a product is delivered (fees can be chosen when buyer decides to pay, but then there is a delay before the vendor signs that tx for the blockchain) 04:41:58 Oh yea and idk who asked, but [since 1978433] the mean number of inputs is 2.2 and mean number of outputs is 2.3 07:21:30 output mean driven up by exchange payouts? 08:11:17 dummy outs likely 08:12:14 e.g. 0-value dummy outs? 08:12:26 but exchanges do pretty regular 16-out txs 09:57:03 i see section 5.6.2 has MW's tx excess as a commitment to 0 that can be signed for. So this is very close to MW. only diff is that in MW the excess is a 2-of-2 between sender and receiver 09:58:34 do you know when this idea of signing for excess was first published? 10:48:46 probably Shen Noether's ringct (MRL 0005) that I linked before; this is a citation to the same thing in the MW whitepaper https://eprint.iacr.org/2015/1098.pdf 11:08:40 generally 'follow the citations' tracks pretty well :p 12:30:14 breaking news: monero travels back in time to invent mimblewimble 17:37:59 Hello all 17:39:25 I'm working on chain-scale verification timing stuff for new protocols, wooo 18:15:07 woooooo!!!!!!!! 18:15:23 I'll have the size numbers shortly 18:15:50 !bet 100 triptych 18:15:53 But I also want to run the verification times, especially because one version of RCT3 requires some input padding that could have big effects on verification 18:16:56 Ooh, sorry, the winner for size is multi-input RCT3 18:17:25 are u running current protocol alongside for comparison? 18:17:37 I ran an estimate starting at block 1788000 (where the new RCT format was enabled/required) 18:17:45 cool 18:18:10 This is simplified and assumes no extra data, but does assume multiple tx pubkeys, for uniformity 18:18:18 So take it with a grain of salt 18:18:44 Here are the size estimates for block 1788000 to the present, if different protocols were used (in GB) 18:18:57 excluding coinbase 18:19:14 MLSAG 7.51 18:19:17 CLSAG 5.26 18:19:22 RCT3-single 6.60 18:19:28 RCT3-multi 4.36 18:19:32 Triptych-single 5.56 18:19:38 Triptych-multi 4.46 18:19:44 that's for ring size 16 18:19:57 (where CLSAG/MLSAG still make sense) 18:20:24 (insert zoolander - are-these-rings-for-ants.gif) 18:20:39 heh 18:20:49 I'm pulling up the non-MLSAG/CLSAG numbers for bigger rings now 18:21:19 I'll post a more complete write-up later, for easier comparison of course 18:21:28 Here are numbers for ring size 128: 18:21:39 RCT3-single 7.49 18:21:44 RCT3-multi 4.77 18:21:49 Triptych-single 6.91 18:21:56 Triptych-multi 5.52 18:22:00 aaaaand just for fun: 18:22:04 MLSAG 41.08 18:22:06 CLSAG 22.05 18:23:01 wow 18:23:06 The reason I want to more closely examine how batching would apply across actual blocks is because RCT3-multi has the padding requirement, which for larger input counts could carry a significant computational overhead 18:23:21 No other protocols have such requirements 18:23:35 Range proof do require padding, but that's already accounted for (and happens now anyway) 18:24:10 does the same distribution occur with larger ringsizes? (i.e., 1028) 18:24:34 Here are the numbers for N=512 (where initial verification estimates looked pretty reasonable): 18:25:12 RCT3-single 8.09 18:25:16 RCT3-multi 5.04 18:25:22 Triptych-single 7.81 18:25:27 Triptych-multi 6.23 18:25:34 MLSAG 156.18 18:25:37 CLSAG 79.6 18:26:19 I'll toss the numbers into a graph for easier visual comparison 18:26:21 hold plz 18:26:48 thats pretty awesome 18:26:48 As well as post code that lets you modify the transaction format and run your own numbers 18:27:04 Note that this assumes the actual chain distribution of I/O counts 18:27:16 Which may or may not be reasonable for future estimates 18:27:26 Curious about verfication times 18:27:27 which one is the current protocol? 18:27:32 MLSAG 18:27:34 BUT 18:27:40 that's not the actual chain growth size 18:27:53 that's an idealized estimate assuming the same kind of transaction uniformity as the newer protocols 18:28:16 n3ptune is fetching the actual tx sizes, which account for things like extra field 18:28:24 so u created artificial ring sigs that match the existing transactions? 18:29:02 For each txn on the real chain, I got the input/output structure from n3ptune's data and used it to produce size estimates for the equivalent transaction in different tx protocols of interest 18:29:10 including MLSAG, the current protocol 18:29:23 It seemed a reasonable way to do the comparisons 18:29:33 yeah. awesome stuff 18:29:40 really awesome 18:29:57 Great work! 18:30:03 Still working on the batch verification numbers, which are a bit trickier to work out 18:30:10 RCT3-multi will suffer a bit in that area 18:30:23 as will CLSAG/MLSAG, which only support batching across range proofs 18:30:36 So anyway, take these numbers with a heaping tablespoon of salt 18:30:43 but thanks to n3ptune for providing the data 18:30:55 it's great to get numbers that try to account for real chain behavior 18:31:17 Again, I'll post the complete code later so you can tinker with the transaction structure and run your own numbers 18:32:49 My initial takeaway is that, as expected, size performance is at least reasonable across larger ring sizes 18:34:45 If there's other data anyone wants me to run while I'm at it, let me know 18:35:00 I'm doing verification assuming both per-block batching and fixed-size batching 18:35:12 (right now batching of range proofs is done per block) 19:08:19 https://usercontent.irccloud-cdn.com/file/7GeWoq4V/chain-growth.png 19:09:11 ^ plot of chain growth 19:10:24 (I can post a version with different line types, in case anyone has trouble viewing the colors) 19:29:01 looks like larger ring sizes wouldn't effect much the blockchain size with rct3-multi. For example from 500 to 750 there is almost no difference in the chart. Cool 19:31:42 Right, but verification scales linearly-ish, not logarithmically 19:33:10 (also note the only tested values were powers of 2; I used smooth lines for clarity) 19:33:59 Chain data on verification will help illustrate this size/time tradeoff 20:28:31 I think unless verification times are very similar then the faster scheme will win (assuming integration doesn't encounter roadblocks). Storage is much more flexible for users than computational power 20:33:03 Depends on I/O structure 20:33:24 The RCT3-multi space savings arise from an assumption of particular inner-product proof padding