<s​yntheticbird:monero.social> Ik it's been one day but has there been any submissions to the contest yet ?

<s​pirobel:kernal.eu> is that really necessary? kiss solution would be to base on total bytes of tx

<s​pirobel:kernal.eu> is that really necessary? kiss solution would be to base the fee on total bytes of tx

<j​berman:monero.social> not yet

<j​berman:monero.social> "is that really necessary? kiss solution would be to base the fee on total bytes of tx" -> as inputs increase, verification times get much slower relative to how much larger the proofs get, so there is a real cost to nodes that isn't accounted for when only basing on bytes

<j​berman:monero.social> this comment here discussing a proposed approach includes a table showing size relative to verification time: seraphis-migration/monero #26#discussion_r2057203539

<s​pirobel:kernal.eu> nice post. so the factor is known

<s​pirobel:kernal.eu> imho it seems more complex than it needs to be to base the fee calculation on that. Would be interested to know how other projects handle this discussion

<s​pirobel:kernal.eu> up until now the consensus was that the fees are too low to prevent people from spamming right?

<j​berman:monero.social> agree it's complex, I couldn't come up with a simpler approach that maintains the desired properties

<j​berman:monero.social> "up until now the consensus was that the fees are too low to prevent people from spamming right?" yes

<j​berman:monero.social> sort of

<j​berman:monero.social> maybe a loose feeling I'd say

low in fiat high in xmr

and you can't change as fiat price changes

<s​pirobel:kernal.eu> even a 10x in price and the transaction fee is still below 1 cent

<s​pirobel:kernal.eu> looking at eip 1559 github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md

<s​pirobel:kernal.eu> the discussion seems to be mostly around reducing congestion. same for the addition of the priority fee to solana

<r​ucknium:monero.social> Monero tx fees haven't been based solely on bytes for years. I believe the change was made when Bulletproofs was introduced.

<r​ucknium:monero.social> See Zero to Monero 2.0, fee section.

<r​ucknium:monero.social> AFAIK, the plan is now, at least, to have the same fee for all txs that have the same inputs, outputs, and tx_extra length. That simplifies things for developers. Now, developers don't know what the standard fee should be, because there can be small differences in bytes even with the same in/out/tx_extra.

<s​pirobel:kernal.eu> is there proof that it incentivizes or disincentives anything? it might be a distraction from the real topic which is congestion and how to ensure acceptable UX when there is one.

<s​pirobel:kernal.eu> seems like this is mostly downstream from wallet code

<s​pirobel:kernal.eu> its not like end users will pick and choose to save a tenth of cent

<s​pirobel:kernal.eu> its not like end users will pick and choose to save a tenth of a cent

<r​ucknium:monero.social> I don't know of any actual analysis that suggested the implied conversion rate of bytes to cryptographic operations in the tx_weight formula. I would agree that this is understudied.

<r​ucknium:monero.social> IMHO, verification time is probably a larger threat to network stability than tx size.

<r​ucknium:monero.social> So maybe base weight entirely on verification time! :D

<s​pirobel:kernal.eu> what would the largest possible transaction cost?

<r​ucknium:monero.social> Largest minimum, you mean? IIRC, when blocks are at maximum capacity, the min fee to get in a block is the highest fee tier, of the 4 fee tiers.

<s​pirobel:kernal.eu> matrix.monero.social/_matrix/media/…/kernal.eu/JLDJHLQFIjCkxOCIMKrVsOuy

<r​ucknium:monero.social> How do you get this? I get about 7 USD cents for a 1in/2out tx if the exchange rate of Monero appreciates by 10x against the USD.

<s​pirobel:kernal.eu> looked at my own transactions

<r​ucknium:monero.social> I need to learn the secret of going below the min tx relay fee 👀

<s​pirobel:kernal.eu> yeah you are right it would be 7 or 8 cents

<s​pirobel:kernal.eu> so current fees seem about right

<s​pirobel:kernal.eu> this seems like a rabbit hole

<s​pirobel:kernal.eu> all of this just so the user sees a fee at the end that is below 1 cent

<s​pirobel:kernal.eu> (with transaction creation hardcoded in the wallet library, so no choice in any case)

<r​ucknium:monero.social> Developers can and have made custom tx construction code that use nonstandard fees.

<r​ucknium:monero.social> For example: github.com/Rucknium/misc-research/t…ero-Nonstandard-Fees#tabulated-data

<s​pirobel:kernal.eu> good argument for why it should be simplified: it reduces users privacy if there is too much ability to mess up

<r​ucknium:monero.social> ^ This is the planned simplification.

<s​pirobel:kernal.eu> as an economist: would you say these developers acted as economic agents?

<r​ucknium:monero.social> As rational agents? Yes they did. Path of least effort. And the vast majority of users don't notice and/or care.

<r​ucknium:monero.social> I had to report Exodus's mistake to them.

<r​ucknium:monero.social> They were one of the wallets that charged nonstandard fees.

<r​ucknium:monero.social> Well, maybe writing custom tx code wasn't the best long-term plan, But once they were there, they didn't bother matching the standard wallet2 behavior.

<r​ucknium:monero.social> And, anyway, a business is not a unitary actor :D

<r​ucknium:monero.social> i.e., developer workers do not always do what is best for the company they work for.

<s​pirobel:kernal.eu> is it possible to just pick one number to rule them all? What would the highest and lowest be? something on the order of 0.1 - 1 cent?

<r​ucknium:monero.social> That's an idea from Solana, right?

<r​ucknium:monero.social> If all txs paid the same amount, restricting the inputs/outputs max count would be very important. Already a lot of people are complaining about the in/out count restriction on txs.

<s​pirobel:kernal.eu> tbh their priority fee thing feels bolted on

<r​ucknium:monero.social> A lot of the complexity of smart contract chains' fee policy comes from "sniping" in DeFi, right? Monero doesn't have that.

<s​pirobel:kernal.eu> the interesting part is how to handle congestion. Introducing economic incentives when there is no competition for resources or a real felt nudge (something more than one tenth of a cent is necessary) just seems like unnecessary complexity.

<s​pirobel:kernal.eu> Automated market makers introduce an economic incentive to create congestion so it just forces the issue

<s​pirobel:kernal.eu> but you also see that in bitcoin

<s​pirobel:kernal.eu> (even long before L2 defi shenanigans)

<s​pirobel:kernal.eu> normal transaction volume during silkroad 2 days was enough to make transactions take days

<r​ucknium:monero.social> tx verification CPU time and tx storage are externalities. You don't need competition to have a need to limit the production of externalities.

<s​pirobel:kernal.eu> yes but if you look a jbermans comment you see its like 2x bytes size 5x verification time. just pick the highest value and use it as a factor on the byte size and be done with it. Maybe the total price is still so low that you can just charge the max value for everyone. But i dont know that. that has to be worked out. :D

<j​berman:monero.social> "just pick the highest value and use it as a factor on the byte size and be done with it" -> I actually did this in one iteration, hard-coding scaling factors. kayaba (imo validly) argued against it because it's fragile. The 5-input verification time may be a fluke and updated with an alternative approach, and/or optimized code could yield distinct scaling factors. Both changes co<clipped messag

<j​berman:monero.social> uld render the hard-coded scaling factors invalid

<j​berman:monero.social> I don't think it's thaaat complex as implemented. And even python/js support bitwise ops

<k​ayabanerve:matrix.org> Clarifying, it's a fluke in that the circuit is intended to pad to powers of two. It's only because there's a base cost, then each input within the circuit, it isn't perfectly at powers of two.

<k​ayabanerve:matrix.org> The fact 5 happens to fit within the smaller power of two (my initial assumption, not confirmed) would be if it fits in extremely marginally. 'Bump the table' and it's gone.

<k​ayabanerve:matrix.org> So the question, if we hard code specific weights, is how annoying are they to specify and how annoying are they to update after even minor changes.