I still think that deliberately limited precision for fees would be cool :)

neptune helped me update the Konferenco plots with more recent data

Still a lot of different stuff going on

If we retroactively apply a "one significant figure" filter (in decimal) it looks like this

isthmus: btw I was thinking maybe your fee/byte plots are off if you aren't taking into account the bulletproof clawback

might be off*

These ones or from Konferenco?

Could be, I literally just took the fee amount and divided it by the transaction size in kB

RE clustering, I chucked 500,000 recent transactions into HDBSCAN and it did a half way decent job right out of the gate

both, yeah dividing by tx size directly doesn't work any more

Ah good I'll need to update that then

Did a halfway decent job without tuning

That's just me messing around this afternoon, a competent adversary would spend time tuning it to get better classifications :- P

@UkoeHB what calculation should be used for that moving forward?

HDBSCAN is really cool by the way, I think it will have a lot of applications for unsupervised labeling of fungibility defects pberba.github.io/stats/2020/01/17/hdbscan

isthmus: you can use this algorithm except replace 6 with 9 github.com/UkoeHB/monero/blob/242d7…/src/seraphis/tx_misc_utils.cpp#L92

not sure where the equivalent computation is in the main code..

there is `get_transaction_weight_clawback()` also

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

although you still get the manual entry issue...

Could be a good filtering function

wait do you mean power of two rounded to two decimal sig figs?

lol yeah

I'm trying to think of a solution that gives better gradations as you increase fees

8->9->10->20 is kind of awkward

Oh yea I see what you mean

hmmm

Zcash did this thing for denominations where you rolled the exponent and mantissa separately

I went down a rabbit hole with it for a bit

Trying to think if a related approach could be used here

I feel resistance to giving up 1 significant decimal digit because... it is by far the easiest for writing unit tests.

Yea. There are solutions that might seem more natural mathematically (like a log scale) but I think 1 sig fig is the most straightforward

it's interesting how even with the 1 sig fig filter, there are still a ton of different real outcomes

Mmhmm I was actually surprised when I generated the plot with 1 sig fig

I thought it'd be a bit more sparse

(referring to the second plot I posted today)

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

What about 1 significant binary figure?

Ah wait, that's probably too big a jump for good UX

it kinda results in a lot of dust being thrown around, which adds up across many users and miners

How does fee denomination impact dust?

dust just in the sense of many low digits in your balance

maybe it's not that important...

I don't see the connection yet

low sig figs != low digits?

Hmm, what about this though... (I think that 1 sig fig is better than this idea, but I'll still throw it out there)

Fees must be valued floor(b^k)

(atomic fee value)

Where `b` is the scaling basis (like 1.001 or 1.01 depending on desired resolution) and `k` is some integer

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

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%)

and it's pretty gas efficient

1 significant binary figure would have many nonzero low decimal digits, that's all

Wait

woah

Haha I didn't know that was a thing

isthmus: I will bring up this topic at the next MRL meeting, and mention your idea as well

lol leave it to isthmus to visualize nonzero digits of a binary power :)

Hahahaha yea that's how I roll. Gotta see everything with my own eyes

I'll play around with adding exponential filters to the code that generated the above plots

sweet

okay here's my rounding lambda `basis ** floor(math.log(fee, basis))`

applying this to the chain with basis 1.5 turns this:

into this:

Above is with basis=1.5, here it is with basis=1.2

For comparison, here's 1 sig fig on the same dt

from a visual point of view, the multiples of 1.5 is appealing

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.

Hard-fork/tag date has been announced, see here for the checklist around the fork:

Dumped code for the newer fee analysis and above plots in a repo:

Shoutout to Neptune for the data

cool thanks isthmus

isthmus: btw your 'rounded to 1.5' labeled plot is the 'rounded to 1.2' plot

(the scatter plot, idk about the other ones)

Oh I see what happened, it fell back to a default

I'll fix it up in a jiffy

good eye

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?

Or does it end up being roughly the same, storing an integer?

@UkoeHB - just pushed an update passing through the variable so that it renders with the basis matching the label (1.5)

isthmus: we could record it with just 1 byte, which would save like 4-6 bytes :)

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.

I really want to just ignore varints/serialization completely for consensus/fee-related tx sizes/weights. This will make everything easier.