very interesting initial results?!?!?!?!

you tease!

I want to do a second check!

nonsense. n of 1. throw more cores at it. paralallalalieze

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

I imagine around 1-2 day fee binning would be enough.

does this become moot when tail emission kicks in?

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

don't think so, since fees also depend on block weight

but fees depend on the _long term block weight_ so that feature has quite a slow development

also in our current era where blocks never leave the penalty free zone, block weights have no impact on fees

@UkoeHB_ like this?

yeah

I like your idea of binning

Hmm, as long as bin_width >> average residence time in the mempool

it wouldn't completely get rid of the problem, since at bin edges the delay will be somewhat apparent

Suppose bins go midnight-to-midnight UTC

at 23:45h I generate a transaction, and broadcast it 20 minutes later at 00:05h

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

Under current system, an observer could see that 00:05h txn and calculate, ah, that transaction came from about 20 minutes ago

under the bin, the observer could only say "ah, that came from some time in the last day"

'it's at least 5 mins old, perhaps as much as 24hrs 5mins'

^ exactly

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

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

or the estimated delay*

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

changing the minimum fee infrequently sounds good to me. it is basically arbitrary anyway

one day monero may be a case study in over engineering 😅

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)

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

output mean driven up by exchange payouts?

dummy outs likely

e.g. 0-value dummy outs?

but exchanges do pretty regular 16-out txs

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

do you know when this idea of signing for excess was first published?

probably Shen Noether's ringct (MRL 0005) that I linked before; this is a citation to the same thing in the MW whitepaper eprint.iacr.org/2015/1098.pdf

generally 'follow the citations' tracks pretty well :p

breaking news: monero travels back in time to invent mimblewimble

Hello all

I'm working on chain-scale verification timing stuff for new protocols, wooo

woooooo!!!!!!!!

I'll have the size numbers shortly

!bet 100 triptych

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

Ooh, sorry, the winner for size is multi-input RCT3

are u running current protocol alongside for comparison?

I ran an estimate starting at block 1788000 (where the new RCT format was enabled/required)

cool

This is simplified and assumes no extra data, but does assume multiple tx pubkeys, for uniformity

So take it with a grain of salt

Here are the size estimates for block 1788000 to the present, if different protocols were used (in GB)

excluding coinbase

MLSAG 7.51

CLSAG 5.26

RCT3-single 6.60

RCT3-multi 4.36

Triptych-single 5.56

Triptych-multi 4.46

that's for ring size 16

(where CLSAG/MLSAG still make sense)

(insert zoolander - are-these-rings-for-ants.gif)

heh

I'm pulling up the non-MLSAG/CLSAG numbers for bigger rings now

I'll post a more complete write-up later, for easier comparison of course

Here are numbers for ring size 128:

RCT3-single 7.49

RCT3-multi 4.77

Triptych-single 6.91

Triptych-multi 5.52

aaaaand just for fun:

MLSAG 41.08

CLSAG 22.05

wow

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

No other protocols have such requirements

Range proof do require padding, but that's already accounted for (and happens now anyway)

does the same distribution occur with larger ringsizes? (i.e., 1028)

Here are the numbers for N=512 (where initial verification estimates looked pretty reasonable):

RCT3-single 8.09

RCT3-multi 5.04

Triptych-single 7.81

Triptych-multi 6.23

MLSAG 156.18

CLSAG 79.6

I'll toss the numbers into a graph for easier visual comparison

hold plz

thats pretty awesome

As well as post code that lets you modify the transaction format and run your own numbers

Note that this assumes the actual chain distribution of I/O counts

Which may or may not be reasonable for future estimates

Curious about verfication times

which one is the current protocol?

MLSAG

BUT

that's not the actual chain growth size

that's an idealized estimate assuming the same kind of transaction uniformity as the newer protocols

n3ptune is fetching the actual tx sizes, which account for things like extra field

so u created artificial ring sigs that match the existing transactions?

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

including MLSAG, the current protocol

It seemed a reasonable way to do the comparisons

yeah. awesome stuff

really awesome

Great work!

Still working on the batch verification numbers, which are a bit trickier to work out

RCT3-multi will suffer a bit in that area

as will CLSAG/MLSAG, which only support batching across range proofs

So anyway, take these numbers with a heaping tablespoon of salt

but thanks to n3ptune for providing the data

it's great to get numbers that try to account for real chain behavior

Again, I'll post the complete code later so you can tinker with the transaction structure and run your own numbers

My initial takeaway is that, as expected, size performance is at least reasonable across larger ring sizes

If there's other data anyone wants me to run while I'm at it, let me know

I'm doing verification assuming both per-block batching and fixed-size batching

(right now batching of range proofs is done per block)

^ plot of chain growth

(I can post a version with different line types, in case anyone has trouble viewing the colors)

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

Right, but verification scales linearly-ish, not logarithmically

(also note the only tested values were powers of 2; I used smooth lines for clarity)

Chain data on verification will help illustrate this size/time tradeoff

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

Depends on I/O structure

The RCT3-multi space savings arise from an assumption of particular inner-product proof padding