Escrowed marketplace tx have 4 steps: buyer makes purchase order, vendor fulfills it, buyer completes payment (partially signs multisig tx), vendor finishes signing tx to accept payment. There is a huge lag between buyer making a purchase order, and buyer partially signing the payment tx. This means if the list of ring members is chosen at checkout, its age will be obvious to an analyst (the delta vs block

time stamp). However, if the list is chosen at 'completes payment' (the gap would be much smaller, albeit still meaningful depending how fast the vendor 'accepts payment') then this is after the commit-and-reveal step of multisig signing. What I'm concerned about is the security implications of affecting the signature's content after commit-and-reveal. Adding additional steps would be horrible to the UX, so

must we accept the age heuristic, or are my concerns unwarranted?

Of course the fees have to be chosen at 'completes payment', although as long as they are not too granular (add some rounding) there shouldn't be a problem. All signing keys are one time use anyway (or at most ~4 time use in extreme situations).

ArticMine: is there a chance fees could become too volatile since they depend on the short term median? In only 50 blocks the median could fall below the default penalty free zone, and if it was originally 200x that default (hypothetically) then minimum fees will increase 200x over just 2hrs. I imagine many tx would get stuck, not just long-term ones like for a marketplace.

Or would miners start spamming the chain to maintain volume so the short term median doesn't fluctuate?

Oh, maybe in a surge environment only the penalty free zone increases in size, while the penalty zone remains static. To increase the penalty zone, it depends on the long term median. Hmmmm

And fees only depend on long term median (plus rounding, which directly causes a binning effect)

I kind of like this, scale penalty free zone with short term median, and scale penalty zone (and fees) with long term median. Reduces minimum fee fluctuation by a LOT, while still making it costly for the short term median to bounce around so miners will still want to smooth out block weights.

And reflects tx urgency, since in the short term you might need a high fee to push up the short term median, but once it's higher then low priority tx will fit in.

UkoeHB The fees are based upon the effective short and long term medians which cannot go below the penalty free block weight of 300000 bytes

yes imagine the long term median gets to 200x the default penalty free zone, then suddenly short term median collapses back to 300kB

Then the fees are based on 300000 bytes. This is necessary to prevent the short term median from getting stuck

I feel like the long term median should actually be long term average, since if short term median collapses then after 35 days the long term median will abruptly change by a large factor

yes so Im saying scale the penalty free zone by the long term median

and fees as well, so fees always match the penalty zone* (not penalty free zone sorry)

penalty free zone may change in size rapidly, while penalty zone slowly changes as the long term median changes

I feel the assumption transactions are constructed soon before being published is untenable

Fees are currently based upon the penat one only

penalty

Yes, the penalty zone is the same size as penalty free zone currently. Im saying changing the fee algorithm should coincide with changing the penalty zone.

to escape the volatility problem which would make tx get stuck if short term median collapses for some reason

in high adoption scenario

That is why the current fee uses the minimum of the long term and short term medians

Right, so if the long term median gets really big then if short term median suddenly becomes very small, minimum fees will increase substantially. Tx made before the short term median falls will get stuck

The point of including the long term medium in the calculation of fees is to prevent fees from going down not from going up

Even high priority fees will not be enough if the short term median falls enough

e.g. when the volatility is beyond 25x

The Dec 25th scenario

this is more like a catastrophe scenario, when some world event shocks the tx volume into short term free fall

although normal fluctuations could have the same effect idk

Im guessing tx volume suffers around hard forks too

Hi

When were subaddresses enabled?

It's not listed in the changelog at github.com/monero-project/monero

so probably v6 or v7

v7

Thank you UkoeHB_

v6 came out in september 2017