15:41:05 Ik it's been one day but has there been any submissions to the contest yet ? 16:26:50 is that really necessary? kiss solution would be to base on total bytes of tx 16:27:04 is that really necessary? kiss solution would be to base the fee on total bytes of tx 16:29:49 not yet 16:33:26 "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 16:35:09 this comment here discussing a proposed approach includes a table showing size relative to verification time: https://github.com/seraphis-migration/monero/pull/26#discussion_r2057203539 16:36:37 nice post. so the factor is known 16:50:06 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 16:51:23 up until now the consensus was that the fees are too low to prevent people from spamming right? 17:03:32 agree it's complex, I couldn't come up with a simpler approach that maintains the desired properties 17:04:51 "up until now the consensus was that the fees are too low to prevent people from spamming right?" yes 17:05:02 sort of 17:05:26 maybe a loose feeling I'd say 17:11:03 low in fiat high in xmr 17:11:26 and you can't change as fiat price changes 17:22:25 even a 10x in price and the transaction fee is still below 1 cent 17:23:06 looking at eip 1559 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md 17:23:54 the discussion seems to be mostly around reducing congestion. same for the addition of the priority fee to solana 17:25:49 Monero tx fees haven't been based solely on bytes for years. I believe the change was made when Bulletproofs was introduced. 17:26:10 See Zero to Monero 2.0, fee section. 17:31:20 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. 17:33:49 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. 17:34:06 seems like this is mostly downstream from wallet code 17:34:36 its not like end users will pick and choose to save a tenth of cent 17:34:45 its not like end users will pick and choose to save a tenth of a cent 17:35:51 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. 17:36:41 IMHO, verification time is probably a larger threat to network stability than tx size. 17:36:59 So maybe base weight entirely on verification time! :D 17:37:39 what would the largest possible transaction cost? 17:38:45 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. 17:45:32 https://matrix.monero.social/_matrix/media/v1/download/kernal.eu/JLDJHLQFIjCkxOCIMKrVsOuy 17:48:42 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. 17:50:02 looked at my own transactions 17:51:12 I need to learn the secret of going below the min tx relay fee 👀 17:51:44 yeah you are right it would be 7 or 8 cents 17:52:04 so current fees seem about right 17:53:25 this seems like a rabbit hole 17:54:25 all of this just so the user sees a fee at the end that is below 1 cent 17:55:04 (with transaction creation hardcoded in the wallet library, so no choice in any case) 17:55:56 Developers can and have made custom tx construction code that use nonstandard fees. 17:57:40 For example: https://github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees#tabulated-data 17:59:40 good argument for why it should be simplified: it reduces users privacy if there is too much ability to mess up 18:00:50 ^ This is the planned simplification. 18:01:09 as an economist: would you say these developers acted as economic agents? 18:01:59 As rational agents? Yes they did. Path of least effort. And the vast majority of users don't notice and/or care. 18:02:14 I had to report Exodus's mistake to them. 18:02:38 They were one of the wallets that charged nonstandard fees. 18:03:24 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. 18:03:54 And, anyway, a business is not a unitary actor :D 18:04:15 i.e., developer workers do not always do what is best for the company they work for. 18:05:07 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? 18:07:05 That's an idea from Solana, right? 18:08:14 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. 18:09:30 tbh their priority fee thing feels bolted on 18:12:08 A lot of the complexity of smart contract chains' fee policy comes from "sniping" in DeFi, right? Monero doesn't have that. 18:15:23 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. 18:16:13 Automated market makers introduce an economic incentive to create congestion so it just forces the issue 18:16:37 but you also see that in bitcoin 18:16:58 (even long before L2 defi shenanigans) 18:17:37 normal transaction volume during silkroad 2 days was enough to make transactions take days 18:17:39 tx verification CPU time and tx storage are externalities. You don't need competition to have a need to limit the production of externalities. 18:20:09 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 18:49:56 "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 uld render the hard-coded scaling factors invalid 18:53:43 I don't think it's thaaat complex as implemented. And even python/js support bitwise ops 18:57:57 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. 18:57:58 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. 18:59:16 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.