01:29:26 I still think that deliberately limited precision for fees would be cool :) 01:29:45 neptune helped me update the Konferenco plots with more recent data 01:29:53 https://usercontent.irccloud-cdn.com/file/Rt1KQLAQ/monero_fees_1.png 01:30:16 Still a lot of different stuff going on 01:31:03 If we retroactively apply a "one significant figure" filter (in decimal) it looks like this 01:31:12 isthmus: btw I was thinking maybe your fee/byte plots are off if you aren't taking into account the bulletproof clawback 01:31:13 https://usercontent.irccloud-cdn.com/file/NaUyHYTB/monero_fees_2.png 01:31:29 might be off* 01:31:50 These ones or from Konferenco? 01:32:01 Could be, I literally just took the fee amount and divided it by the transaction size in kB 01:34:01 RE clustering, I chucked 500,000 recent transactions into HDBSCAN and it did a half way decent job right out of the gate 01:34:01 both, yeah dividing by tx size directly doesn't work any more 01:34:09 Ah good I'll need to update that then 01:34:13 https://usercontent.irccloud-cdn.com/file/dy4JFVeu/hdbscan 01:34:23 Did a halfway decent job without tuning 01:34:58 That's just me messing around this afternoon, a competent adversary would spend time tuning it to get better classifications :- P 01:35:12 @UkoeHB what calculation should be used for that moving forward? 01:35:51 HDBSCAN is really cool by the way, I think it will have a lot of applications for unsupervised labeling of fungibility defects https://pberba.github.io/stats/2020/01/17/hdbscan/ 01:36:25 isthmus: you can use this algorithm except replace 6 with 9 https://github.com/UkoeHB/monero/blob/242d7e3f089062cf0b348b414180690ad3e93d4c/src/seraphis/tx_misc_utils.cpp#L92 01:36:43 not sure where the equivalent computation is in the main code.. 01:37:41 there is `get_transaction_weight_clawback()` also 01:39:38 isthmus: what if we did a power of 2 rounded to 2 significant figures? that would give a better UX without creating a ton of dust 01:40:05 although you still get the manual entry issue... 01:40:11 Could be a good filtering function 01:40:25 wait do you mean power of two rounded to two decimal sig figs? 01:40:33 lol yeah 01:40:47 I'm trying to think of a solution that gives better gradations as you increase fees 01:40:59 8->9->10->20 is kind of awkward 01:41:21 Oh yea I see what you mean 01:41:33 hmmm 01:42:40 Zcash did this thing for denominations where you rolled the exponent and mantissa separately 01:42:50 I went down a rabbit hole with it for a bit 01:42:56 Trying to think if a related approach could be used here 01:47:03 I feel resistance to giving up 1 significant decimal digit because... it is by far the easiest for writing unit tests. 01:48:34 Yea. There are solutions that might seem more natural mathematically (like a log scale) but I think 1 sig fig is the most straightforward 01:52:15 it's interesting how even with the 1 sig fig filter, there are still a ton of different real outcomes 01:52:47 Mmhmm I was actually surprised when I generated the plot with 1 sig fig 01:52:54 I thought it'd be a bit more sparse 01:53:51 (referring to the second plot I posted today) 01:54:38 However I think it's sparse enough that forcing everybody into 1 sig fig lanes (with wide empty spaces between) screws up density based clustering 01:55:42 What about 1 significant binary figure? 01:56:01 Ah wait, that's probably too big a jump for good UX 01:57:24 it kinda results in a lot of dust being thrown around, which adds up across many users and miners 01:57:54 How does fee denomination impact dust? 01:58:14 dust just in the sense of many low digits in your balance 01:58:23 maybe it's not that important... 01:58:36 I don't see the connection yet 01:58:50 low sig figs != low digits? 01:59:52 Hmm, what about this though... (I think that 1 sig fig is better than this idea, but I'll still throw it out there) 02:00:29 Fees must be valued floor(b^k) 02:00:39 (atomic fee value) 02:01:01 Where `b` is the scaling basis (like 1.001 or 1.01 depending on desired resolution) and `k` is some integer 02:01:43 This is how Uniswap v3 works under the hood, there's integer "tick" values managed by the smart contract, which map to price like: price = 1.0001 ^ tick 02:03:02 It's extremely clever in terms of having scaling that feels intuitively both mathematically (log-like) and for people (the price moves up in increments of 0.1% and down in increments of 0.1%) 02:03:19 and it's pretty gas efficient 02:07:05 1 significant binary figure would have many nonzero low decimal digits, that's all 02:11:57 Wait 02:11:58 woah 02:12:00 https://usercontent.irccloud-cdn.com/file/BO34nVxz/image.png 02:12:05 Haha I didn't know that was a thing 02:12:06 isthmus: I will bring up this topic at the next MRL meeting, and mention your idea as well 02:13:40 lol leave it to isthmus to visualize nonzero digits of a binary power :) 02:14:53 Hahahaha yea that's how I roll. Gotta see everything with my own eyes 02:15:59 I'll play around with adding exponential filters to the code that generated the above plots 02:16:09 sweet 02:45:19 okay here's my rounding lambda `basis ** floor(math.log(fee, basis))` 02:46:25 applying this to the chain with basis 1.5 turns this: 02:46:28 https://usercontent.irccloud-cdn.com/file/UPXbywth/image.png 02:46:36 into this: 02:46:38 https://usercontent.irccloud-cdn.com/file/ks8nvQF7/image.png 02:47:41 Above is with basis=1.5, here it is with basis=1.2 02:47:43 https://usercontent.irccloud-cdn.com/file/lqwHivUL/image.png 02:48:26 For comparison, here's 1 sig fig on the same dt 02:48:30 https://usercontent.irccloud-cdn.com/file/o4Lp9FKp/image.png 03:02:19 from a visual point of view, the multiples of 1.5 is appealing 03:27:14 If you round the multiples of 1.5 to 1 sig fig, it doesn't even seem that bad. There are some gaps as expected, but each power of 10 has 5 or 6 members. 13:27:59 https://decrypt.co/98023/monero-faithful-threaten-bank-run-on-centralized-exchanges 18:27:32 Hard-fork/tag date has been announced, see here for the checklist around the fork: 18:27:32 https://github.com/monero-project/meta/issues/690 21:56:15 Dumped code for the newer fee analysis and above plots in a repo: 21:56:17 https://github.com/Mitchellpkt/fees_data_and_design/blob/main/monero_fee_analysis.ipynb 21:57:14 Shoutout to Neptune for the data 22:00:12 cool thanks isthmus 22:02:07 isthmus: btw your 'rounded to 1.5' labeled plot is the 'rounded to 1.2' plot 22:05:17 (the scatter plot, idk about the other ones) 22:27:38 Oh I see what happened, it fell back to a default 22:27:43 I'll fix it up in a jiffy 22:27:44 good eye 22:36:38 Hmm if fees were to be selected from `floor(1.5^k)` or something like that, could we save a bit of space by just recording the exponent `k` explicitly in the transaction instead of the fee value? 22:36:50 Or does it end up being roughly the same, storing an integer? 22:39:27 @UkoeHB - just pushed an update passing through the variable so that it renders with the basis matching the label (1.5) 22:47:37 isthmus: we could record it with just 1 byte, which would save like 4-6 bytes :) 23:14:59 isthmus: oh, some of the fan-out in fees could be due to small differences in tx sizes caused by varints (I think at one point we switched from per-kB fees to per-byte fees), in addition to the bulletproof clawback. 23:17:11 I really want to just ignore varints/serialization completely for consensus/fee-related tx sizes/weights. This will make everything easier.