<sgp_> "Simple Market-Based Monero Fee Proposal" monero-project/research-lab #152

<namenet:matrix.org> @sgp_: @articmine:monero.social I'd love to hear your perspective on this proposal

<3

<ofrnxmr> At first glance, some of it sounds logical, but capping growth at 10% per year doesnt follow moores law and is incredibly low

<torir:matrix.org> The current block size algorithm is also designed to accomodate short-term surges. It would be bad if our blockchain couldn't handle holiday spending surges.

<ofrnxmr> Essentially capping tps for no reason, and to much less than 7tps, doesnt make sense

<ofrnxmr> But thats more of an issue with paramrters than the actual concept

(removed)

(removed)

(removed)

(removed)

<blurt4949:matrix.org> @sgp_:monero.social: Am I understanding correctly that this would allow transactions to be effectively free (1 pico is negligible) up to 400kb blocks? I see no reason to allow people to perpetually spam the network for ~$0. At scale this wouldn't be as much of an issue since spam will be priced out, but we've basically guarant [... too long, see mrelay.p2pool.observer/e/k5qEmMMKQ0M5aTQ0 ]

<sgp_> Yes it would allow for the base space to be consumed for effectively zero cost, but only if there is no other demand for it.

<sgp_> Setting a higher price that "feels" right runs the other risk, that is XMR becomes valuable, the minimum fee is way too expensive.

<sgp_> This proposal says "we don't want to incur more chain growth than this" and then lets the market do its thing

<sgp_> @ofrnxmr: Each year of the blockchain does not exist in isolation. If a blockchain has been around for 2 years, where for year 1 it grows at 1 GB and for year 2 grows at 1.1 GB, then the growth for year 2 is over 50%, not 10%. Even for Monero a decade on, the natural growth at the same rate is still around 10%, and this is atop that.

<sgp_> In any case, 10% is a configurable parameter, but I personally consider setting it to something like 50% is way too aggressive

<sgp_> @torir:matrix.org: This proposal does not include any additional allowance for "holiday surges", since while that sounds nice in theory, I think it's a large potential risk of spam in practice. During holiday surges, the market will quickly confirm the most economically significant (highest fee) transactions and confirm th [... too long, see mrelay.p2pool.observer/e/_fjyocMKMHJzVTBI ]

<sgp_> The proposal is quite restrictive on purpose, be a use I personally think the scaling parameters that Monero has allowed were way too generous, and the spam helped demonstrate that.

<sgp_> However, if you disagree with me on that, the proposal could have the 10% flex space growth parameter bumped to e.g. 25%

<torir:matrix.org> It just reminds me of the Bitcoin scaling arguments--which have led to a Bitcoin today with transaction fees that are consistently too high to reasonably buy a coffee with (when compared to the low-fee cryptos I could be using instead). Perhaps a future like that is unavoidable for Monero, but if it is at all possible, I want [... too long, see mrelay.p2pool.observer/e/rev5osMKOGlrX2gy ]

<torir:matrix.org> Of course, I absolutely don't want to go too far in the other direction and do BSV with its unreasonably sized blocks that has resulted in very high node centralization.

<torir:matrix.org> I feel like I would want to wait for the L2 to be developed and see if we can avoid the issues the Lightning Network has, and if the L2 is actually good, then yes, let's keep the scaling parameters small since fees will be less of an issue.

<torir:matrix.org> TL;DR: We need block scaling parameters that ensures that fees remain relatively reasonable for small everyday transactions, but no more scaling than that, since a big blockchain leads to centralization.

<torir:matrix.org> Maybe I'm in favor of the proposal then, but I would need to be convinced that we won't have fee price surges like Bitcoin and Ethereum have. That's just a bad experience for everyone.

hello

test

<sgp_> @torir:matrix.org: I'm not sure how to ensure you get everything you want, WITHOUT manual intervention on the fee (hard forks) all the time.

<sgp_> By acknowledging that too big of blocks cause scaling/centralization issues, that accepts that there's a possible scenario where there truly is a lot of organic, "real" demand, more than is feasible to scale with. So fees will shoot up

<sgp_> I've tried to strike the best balance that has the first priority of making sure the network can "survive" the scaling, and then given that, scale as much as possible to put a downward pressure on fees

<torir:matrix.org> I feel like this will lead to a bunch of bikeshedding if we don't have any concrete data on how much scaling is enough. What numbers led to 10% per year increase?

<sgp_> In theory, if PoS is used with a finality layer, the PoS could be permitted governance to vote on increasing/decreasing these parameters. Kick the problem to them, and by doing so acknowledge that a reactive policy is best in practice. But that's several layers removed now and just an example, not an actual proposal

<sgp_> I picked 10% because I perceived that everyone here would probably agree that it's "safe" for the network to scale at that speed, even if it's conservative. Maybe the highest consensus "safe" value is the best starting point

<sgp_> Eg if there's consensus that 0-32% is safe from a network perspective (just as an example), maybe pick the max 32%

<torir:matrix.org> I feel like before we get a functioning L2, that we still need short-term surge scaling. Fee surges are an awful experience and are the main reason I abandoned Bitcoin (besides the obvious lack of privacy thing). Surge scaling could be capped though. It shouldn't be unbounded.

<torir:matrix.org> I feel like high fees were a big contributer to Bitcoin's transition towards being used as a store of value rather than as currency. Everyone wanting to spend money went to coins with cheaper fees. If we value utility, low fees are part of that. I have to think about this, maybe write a fee simulation or something. I need data to figure out the best block scaling algorithm.

<sgp_> It's tough because there's very little direct value in low fee trasactions.

<sgp_> I'm open to ideas of how to best add burst scaling to my proposal, but it'll take some convincing for me to think it's a good idea

<namenet:matrix.org> @sgp_: Is it possible to make this 10% value dynamic depending on how the blockchain is growing over a window of X amount of blocks?

<sgp_> Yeah, but my main concern would be that this incentivizes and rewards short term spam bursts

<sgp_> And let's say Black Friday starts at 0 UTC, and utilization jumps from 10% to 500%. It'll still take time to adjust up with a lagging indicator (eg looking back 100 blocks). So in that example, it needs to permit quite "bursty" behaviors (which look like spam). Or people need to wait anyway

<ofrnxmr> Like, we could have 5 active zones.

<ofrnxmr> mrelay.p2pool.observer/p/y-_kpMMKaEYwdkhM/1.txt (code snippet, 5 lines)

<ofrnxmr> if a zone is sustained for 720 blocks, it should become z1. Example, if z3 was sustained for 720 blocks, then z0 would become 2000kb, z1 4000.[... more lines follow, see mrelay.p2pool.observer/e/y-_kpMMKaEYwdkhM ]

<sgp_> This could partially work @ofrnxmr:monero.social , but it would still allow for miners to pack blocks with spam at no cost. So the network would leave a relatively wide window open for abuse

<namenet:matrix.org> @sgp_: Could we use a slow-moving 100-block average for the base value, but layer on a faster-reacting "circuit breaker" that triggers if utilization jumps by, say, 200% in just 10 blocks. That would allow for planned bursts but penalize sudden, manipulative ones

<sgp_> How would we "plan" for a black Friday instant sale though? Would it not look sudden?

<namenet:matrix.org> I'll see if I can get a simulation running maybe it will help

<torir:matrix.org> Unless the sale occurred without warning, I'm pretty sure transactions will pick up before the sale to some extent. People moving funds between wallets in preparation.

<ofrnxmr> @sgp_: theyd have to pack blocks for a whole day, and spend potentially 2700 xmr (for the top zone)

<ofrnxmr> But ig if they spammed in zone2, its "only" gross 172xmr per day to move the zone

<articmine> NACK > <@sgp_> I have a radically simple fee proposal that I can organize if there's interest. The highlights are:

<sgp_> Personally I prefer the simplicity of a single flex zone sized appropriately, but I would consider another flex zone atop it if it makes sense

<articmine> This is a prescription to completely destroy the use of Monero as peer to peer electronic cash

<articmine> The only people I can see benefiting from this are the Blockchain Surveillance (BS), who unlike the Monero network have a very serious scaling problem

<articmine> BS companies

<hbs:matrix.org> Are you suggesting a MoneroDAO? 🤮 > <@sgp_> In theory, if PoS is used with a finality layer, the PoS could be permitted governance to vote on increasing/decreasing these parameters. Kick the problem to them, and by doing so acknowledge that a reactive policy is best in practice. But that's several layers removed now and just an example, not an actual proposal

<sgp_> @hbs:matrix.org: "not an actual proposal"

<sgp_> Bitcoin currently has a 1 sat/vbte fee and has been low like this for a while. I argue that despite some lessons learned from them, it does still function as peer electronic cash (although I agree, not particularly well at certain points). We can borrow the best parts of their model while improving it

<articmine> I mean please do the math here.

<articmine> Monero transactions are 20x Bitcoin transactions. So after allowing for 2 min. vs 10 min blocks there is a factor of 4.

<articmine> So a 400000 byte block in Monero is equivalent to a 100000 byte block in Bitcoin

<sgp_> re the blockchain surveillance comment, I don't think that bloating the blockchain in an attempt to make surveillance hard is a remotely good idea, especially after fcmp++

<articmine> We all know what Bitcoin has become This proposal is far worse

<articmine> The only reason why BS got off the ground is because of the 1 MB block size limit in Bitcoin

<sgp_> I'm deeply concerned with the scaling parameters you suggest, and the concept of fixing a minimum fee to an implied XMR/USD value. If XMR goes up in price, it'll be too costly (way more than BTC transactions currently; your proposal for the min fee is already roughly in-line with the current BTC fee). If XMR goes down in price, the security assumption is substantially decreased

<sgp_> I also now the two of us are not going to come to agreement in this chat; our views are too different

<articmine> We are not bloating the blockchain. What we are doing is allowing the use of Monero as peer to peer cash at scale. This is very threatening to many powerful people

<articmine> @sgp_: We are not fixing a minimum fee This has never been the case

<articmine> What we are doing is threatening power

<sgp_> Even accepting Bitcoin's current "failing" transaction throughput, we would be scaling the Monero blockchain at 20x faster than Bitcoin is for the same throughput (per your 20x above). That's a lot of cost, and I think we need to take that far more seriously

<ofrnxmr> I think my proposal might address the cost issues if we changed 720 blocks to like 14 days

<articmine> 1 GB of data at the end of this year is equivalent to 1MB of data when the Bitcoin whitepaper was released in 2008

<articmine> What does not scale is BS

<boog900> IMO the current scaling makes us vulnerable, monerod cannot support infinite scaling

<articmine> It is not infinite.

<boog900> Its alright saying storage and bandwidth have scaled but they were never the bottleneck to begin with

<articmine> There is always a max blocksize at a given point in time

<sgp_> Bear in mind that my simple proposal still scales 10% per year (and it could be configured for more); I'm for scaling, just not massively aggressive scaling

<articmine> With a hard fork like Bitcoin

<articmine> I am not wasting any more time on this proposal to keep BS alive

<articmine> ... and we can cap it to Nielsen's law

<boog900> @sgp_: Yeah I am for less aggressive scaling

<articmine> @boog900: I will be proposing a less aggressive scaling with the addition of a sanity median

<articmine> That is actually tied to the historical growth rate of bandwidth

Btw, Bitcoin has recently reduced the min fee to 0.1 sat/vbyte.

<articmine> What I will not support is destroying the use of Monero as peer to peer electronic cash at a scale competitive with card payments

<sgp_> I just don't see that as realistic.... Monero's technology today would literally break :/

<articmine> @sgp_: It is very realistic

<boog900> I would rather Monero survive at all than die because we had 20 chain splits trying to handle all those txs

<boog900> @articmine: stressnet says no

<ofrnxmr> Yeah.. we should be working on improving verification, efficient networking, etc. Not crippling the growth or forcing centralization onto l2s

<boog900> I agree but we should get the improvements in and see the limits of the system first

<ofrnxmr> @boog900: I disagree. Stressnet says monerod is inefficient, borderline broken

<articmine> Way more realistic that today's VISA transactions rate when I was two years old

<boog900> @boog900: before putting scaling code on mainnet that could break monero in weeks if someone spammed sufficiently

<syntheticbird> grampa time

<ofrnxmr> imo pushing limits is how we fix them. Capping at 10% is just avoiding the hard work

<boog900> @ofrnxmr: pushing limits should not be done on mainnet IMO

<sgp_> Efficiency improvements will also allow for updates to that parameter later

<ofrnxmr> As stressnet has shown, a 10x increase is more than realistic w/o a huge increase in volume

<articmine> @sgp_: No Bitcoin has proven this

<articmine> It is called politics and entrenched power

<ofrnxmr> @boog900: if we had caps already, we would never fix anything

<ofrnxmr> because we'd never know what the breaking point is

<syntheticbird> @ofrnxmr: there are caps everywhere within the codebase and we just don't think about it

<ofrnxmr> @syntheticbird: you can get blocks up to (and above afaict) 40mb w/o breaking anything

<boog900> @ofrnxmr: I do agree but I think that should change, mainnet should not be vulnerable to someone who can spam/mine for a few weeks

<boog900> @ofrnxmr: not on mainnet AFAIK

<ofrnxmr> But as recently discovered during my private testnets, the txpool breaks, wallets die, nodes fall out of sync

<boog900> maybe on stressnet with the fixes

<articmine> There are caps. Why do you think that Monero was not spammed like ZCash?

<sgp_> Monero was spammed....

<ofrnxmr> @sgp_: Barely. Tx count didnt even get above litecoins

<articmine> No where near like ZCash

<boog900> @articmine: yes it costs to break Monero, but the fact we can put a cost on it is bad

<ofrnxmr> @ofrnxmr: Never even filled the txpool

<sgp_> Monero does not have strong protections that prevented the spam from escalating

<articmine> @sgp_: It does

<boog900> @articmine: stressnet says no

<ofrnxmr> @sgp_: The spam cant escalate unless they pay to escalate it

<sgp_> it does in your opinion, and not in my opinion

<boog900> @ofrnxmr: miners can just mine blocks

<ofrnxmr> @boog900: The current scaling parameters for escalation are, imo, too soft. It doesnt cost me very much to produce 15mb blocks

<articmine> @sgp_: I am well aware of you position

<articmine> Your

<ofrnxmr> I think my mini-proposal above might also be too soft on the higher end, but caps/recalculates scaling on a daily basis instead of 100 blocks

<sgp_> I'd like to ideally have a more civil discussion on this than "Justin's methods do nothing but benefit blockchain surveillance companies and will kill all peer to peer transactions", which I think is a wild over-exaggeration for a proposal that still includes scaling just not as much as you want

<articmine> I am getting really tired of this. What is everyone's here relationship to the Blockchain Surveillance industry?

<articmine> I will start with mine. Helping the defense in a court case fight for false accusations the BS companies made against a defendant

<sgp_> @articmine:monero.social: to #monero-research-lounge:monero.social

was 142 addressed / decided on? monero-project/research-lab #142 to either use the double call to elligator2 (unbiased_hash_to_ec) or to use the standardized version?

<kayabanerve:matrix.org> DataHoarder: plan is to use two maps of the first and second half of a single blake2b-512

so existing unbiased_hash_to_ec and not standardized one, ok

I think it was discussed again a few times but no conclusion was posted in the PR/Issue

<spirobel:kernal.eu> > <@blurt4949:matrix.org> @sgp_:monero.social: Am I understanding correctly that this would allow transactions to be effectively free (1 pico is negligible) up to 400kb blocks? I see no reason to allow people to perpetually spam the network for ~$0. At scale this wouldn't be as much of an issue since spam will be priced ou [... too long, see mrelay.p2pool.observer/e/iO_1rcMKdWRhbW00 ]

<spirobel:kernal.eu> > Eliminate minimum fee (technically, it lowers it to the smallest XMR unit 1 piconero, or 0.000000000001 XMR).

<spirobel:kernal.eu> > this seems perfect for a chain analytics company to spam the chain for cheap

<spirobel:kernal.eu> hard no for me on this proposal. There needs to be a sane base fee to prevent spam

<namenet:matrix.org> @spirobel:kernal.eu: If a chain analytics company can spam for cheap, so can someone else?

<spirobel:kernal.eu> yes its true. shouldnt have mentioned this example. Blockspace needs to have a price. It should be reasonably low, but it should have a price.

<namenet:matrix.org> I don't like the idea of hard coding values in general. Ideally, the fee system should be entirely dynamic

<namenet:matrix.org> @spirobel:kernal.eu: In a rare scenario where XMR's price increases to $100k like BTC, how would the minimum blockspace price affect fees, and would they become as prohibitive as Bitcoin's?

<namenet:matrix.org> As I'm relatively new to Monero's fee structure, I may be missing some details, but what I appreciate about sgp_'s proposal is that it enables the market to determine a dynamic fee cost. Consequently, even if Monero's price were to become very high, transaction fees would scale accordingly

<sgp_> That price change is a major risk imo. If we set the base fee to $0.10 today, then that might be $1 or $10 next year, and it needs to be re-adjusted. Or the price falls and it needs to be raised. We're basically guessing what the USD price is

<sgp_> people can only spam for cheap if there is no other demand for the base space

<sgp_> and they can only spam a small amount of total size, well within reason without causing network harm

<sgp_> so what I' trying to say is a "reasonable" minimum base fee needs to be continuously adjusted as the price changes

<sgp_> or, we can say "screw it" and allow spam in that free space, if no one else wants to pay more than the spammer for that space, with low harm to the network. We let the free market do its thing like with Bitcoin

<sgp_> The mindset for the free space is basically this: It will always be used by someone, like with Bitcoin blocks. What's variable is the fee that's paid. It will be near-0 with low demand, or high (with the flex space serving as a downward fee pressure) if the demand is high. If there is demand, then there is no incremental risk [... too long, see mrelay.p2pool.observer/e/r774rsMKQTdZNkpQ ]

<sgp_> I know it seems silly on the surface to offer space for free, but it prevents us from picking a price that becomes outdated, and we instead focus on making sure that the block space doesn't cause network harm (due to the free space's small size)

<namenet:matrix.org> Having a minimum base fee allows those with the biggest voice to set and change it, turning Monero into a centrally planned economy beholden to a dictator. The best fix is to let the market decide > <@sgp_> so what I' trying to say is a "reasonable" minimum base fee needs to be continuously adjusted as the price changes

<articmine> You cannot set fixed fees and expect the scaling penalty to work.

<sgp_> I do think it is somewhat ironic to be worried about 400kB of spam (maximum, assuming no other demand for the space) while allowing 6x block size growth a year, which has a much higher potential for network harm

<sgp_> (that comment wasn't specifically directed at you ArticMine)

<articmine> As for what happens if the price reaches 100000 2025 USD this depends on where the economic activity is happening. Peer to peer or banks.

<rucknium> @namenet:matrix.org: What does the supply curve of this market look like?

<namenet:matrix.org> @rucknium: I'm not sure I'm not an economist

<articmine> If it is peer to peer expect as ~200x increase in blocksize. If it is banking expect fees to skyrocket

<articmine> I would start with basic economics such as the equation of exchange

<sgp_> @rucknium:monero.social: in my example, the supply is 1) free space fixed at 400 kB at no additional cost, and 2) the flex space, use of which incurs opportunity cost of the block reward, and which grows over time

<articmine> MV = PQ

<rucknium> @namenet:matrix.org: I am one. "Just let the market decide" does not make sense with block space.

<namenet:matrix.org> Oh wow

<rucknium> You may first notice that the costs of block space are externalities.

<rucknium> There is not universal way to deal with externalities. Anyway, my line of thought is better for #monero-research-lounge:monero.social

<sgp_> @rucknium:monero.social: in this case it's a fixed supply. The market decides the demand and thus the price, but has no impact on supply. So the negative externalities are predictable, and for the most part non-variable

<namenet:matrix.org> @articmine: The equation MV = PQ applies perfectly because we can determine the exact supply and velocity of money without relying on data from various financial institutions with Monero. Interesting

<namenet:matrix.org> @rucknium: I'll continue the conversation there

<articmine> We have to break Q into QC (on chain, peer to peer) and QB (Bank)

<articmine> QC if the use case does not change is proportional to the blocksize. QB is not

<articmine> Bitcoin by restricting QC forced the economic activity oon QB

<namenet:matrix.org> Sorry what is QC?

<articmine> On chain economic activity

<articmine> as opposed to banibg

<articmine> Banking

<articmine> This is why a push to keep the blocksize small is nothing more than limiting peer to peer transactions and moving economic activity onto the ledger of banks

<articmine> Which defeats the entire purpose of Monero

<blurt4949:matrix.org> Requiring nodes to be dedicated servers makes Monero centralized and therefore also defeats the purpose of Monero

<blurt4949:matrix.org> Which, at those very high block sizes, is exactly what you're doing.

<blurt4949:matrix.org> There's no clean solution but we don't have to pretend that we need to pick between Luke Dashjr and Craig Wright in terms of blocksize.

<blurt4949:matrix.org> We need strong evidence that the lower % of users running nodes is vastly outweighed by the increase in total users, and at the moment we have none beyond estimations based on vague economic principles.

<ofrnxmr> Monero block wars

<ofrnxmr> How about this: we can release 2 haes forks. One with 10% yearly scaling, and one without

<ofrnxmr> Let the best chain win

<ofrnxmr> s/haes/hard

<ofrnxmr> 10% yearly scaling is essentially btc core w/o segwit, but still pushing centralized ln

<ofrnxmr> And absolutely nobody is proposing entirely unchained block growth

<blurt4949:matrix.org> agreed but that doesn't mean we should go the BSV route

<ofrnxmr> @blurt4949:matrix.org: absolutely nobody is proposing we do that

<blurt4949:matrix.org> If I understand correctly (maybe not, English is not my first language) Artic earlier said that "If it is peer to peer expect as ~200x increase in blocksize" in reference to 400kb blocks. Also even ignoring that we could get there in 4 years anyway with the 6x increase per year

<ofrnxmr> 10% yearly growth brings us from 0.25 to 0.65 tps over 10 years. for comparison, 1mb bitcoin does 7tps

<blurt4949:matrix.org> That's equivalent to 400 BTC blocks which for all intents and purposes is a BSV-type network

<blurt4949:matrix.org> 400mb BTC blocks*

<blurt4949:matrix.org> yeah so lets not do 10% then, but let's also not allow hundreds of mb blocks maybe?

<ofrnxmr> 100s of mb blocks isnt possible in the short term with current scaling

<ofrnxmr> We have limits, or rather, dampers or retardation

<blurt4949:matrix.org> I'm aware but it shouldn't be possible in the medium/moderate long-term either.

<blurt4949:matrix.org> if the 6x per year figure is accurate, that's 3 years, which is not a long time

<ofrnxmr> Blocksize growth cant exceed certain parameters

<blurt4949:matrix.org> And even blocks of a few mb would be a problem in the short term but that's not the point

<ofrnxmr> @blurt4949:matrix.org: if monero went from confirming 25k tx per day to 100k tx per day, thats only 138 tx per block. Currently, thats below 300kb

<ofrnxmr> With fcmp, its more like 1.4mb

<ofrnxmr> stressgguj7ugyxtqe7czeoelobeb3cnyhltooueuae2t3avd5ynepid.onion

<blurt4949:matrix.org> Wouldn't that be 1.4mb blocks with FCMP?

<blurt4949:matrix.org> right

<ofrnxmr> Which is the current confirm rate od the stressnet

lounge please