00:51:16 "Simple Market-Based Monero Fee Proposal" https://github.com/monero-project/research-lab/issues/152 03:18:42 @sgp_: @articmine:monero.social I'd love to hear your perspective on this proposal 03:24:19 <3 04:44:10 At first glance, some of it sounds logical, but capping growth at 10% per year doesnt follow moores law and is incredibly low 05:06:27 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. 05:14:08 Essentially capping tps for no reason, and to much less than 7tps, doesnt make sense 05:14:54 But thats more of an issue with paramrters than the actual concept 05:57:49 (removed) 05:57:49 (removed) 05:57:49 (removed) 05:57:49 (removed) 06:29:21 @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 https://mrelay.p2pool.observer/e/k5qEmMMKQ0M5aTQ0 ] 12:07:02 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. 12:07:02 Setting a higher price that "feels" right runs the other risk, that is XMR becomes valuable, the minimum fee is way too expensive. 12:07:02 This proposal says "we don't want to incur more chain growth than this" and then lets the market do its thing 12:10:58 @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. 12:10:58 In any case, 10% is a configurable parameter, but I personally consider setting it to something like 50% is way too aggressive 12:14:10 @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 https://mrelay.p2pool.observer/e/_fjyocMKMHJzVTBI ] 12:20:51 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. 12:20:51 However, if you disagree with me on that, the proposal could have the 10% flex space growth parameter bumped to e.g. 25% 12:51:00 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 https://mrelay.p2pool.observer/e/rev5osMKOGlrX2gy ] 12:51:00 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. 12:51:00 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. 12:52:49 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. 12:53:41 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. 13:13:57 hello 13:14:10 test 13:21:17 @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. 13:21:17 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 13:22:24 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 13:24:58 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? 13:25:11 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 13:26:29 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 13:29:29 Eg if there's consensus that 0-32% is safe from a network perspective (just as an example), maybe pick the max 32% 13:31:21 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. 13:37:09 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. 13:49:02 It's tough because there's very little direct value in low fee trasactions. 13:49:02 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 13:51:42 @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? 13:53:13 Yeah, but my main concern would be that this incentivizes and rewards short term spam bursts 13:54:53 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 13:55:09 Like, we could have 5 active zones. 13:55:09 https://mrelay.p2pool.observer/p/y-_kpMMKaEYwdkhM/1.txt (code snippet, 5 lines) 13:55:09 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 https://mrelay.p2pool.observer/e/y-_kpMMKaEYwdkhM ] 13:56:31 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 13:56:34 @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 13:58:15 How would we "plan" for a black Friday instant sale though? Would it not look sudden? 13:58:17 I'll see if I can get a simulation running maybe it will help 13:59:03 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. 13:59:05 @sgp_: theyd have to pack blocks for a whole day, and spend potentially 2700 xmr (for the top zone) 14:00:16 But ig if they spammed in zone2, its "only" gross 172xmr per day to move the zone 14:00:34 NACK > <@sgp_> I have a radically simple fee proposal that I can organize if there's interest. The highlights are: 14:00:52 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 14:01:41 This is a prescription to completely destroy the use of Monero as peer to peer electronic cash 14:03:25 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 14:04:02 BS companies 14:04:20 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 14:04:34 @hbs:matrix.org: "not an actual proposal" 14:08:00 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 14:08:39 I mean please do the math here. 14:08:39 Monero transactions are 20x Bitcoin transactions. So after allowing for 2 min. vs 10 min blocks there is a factor of 4. 14:08:39 So a 400000 byte block in Monero is equivalent to a 100000 byte block in Bitcoin 14:08:57 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++ 14:09:19 We all know what Bitcoin has become This proposal is far worse 14:10:32 The only reason why BS got off the ground is because of the 1 MB block size limit in Bitcoin 14:11:27 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 14:12:16 I also now the two of us are not going to come to agreement in this chat; our views are too different 14:12:40 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 14:13:53 @sgp_: We are not fixing a minimum fee This has never been the case 14:14:16 What we are doing is threatening power 14:16:52 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 14:17:56 I think my proposal might address the cost issues if we changed 720 blocks to like 14 days 14:18:43 1 GB of data at the end of this year is equivalent to 1MB of data when the Bitcoin whitepaper was released in 2008 14:19:49 What does not scale is BS 14:20:01 IMO the current scaling makes us vulnerable, monerod cannot support infinite scaling 14:20:49 It is not infinite. 14:20:49 Its alright saying storage and bandwidth have scaled but they were never the bottleneck to begin with 14:21:23 There is always a max blocksize at a given point in time 14:22:14 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 14:22:38 With a hard fork like Bitcoin 14:23:47 I am not wasting any more time on this proposal to keep BS alive 14:23:50 ... and we can cap it to Nielsen's law 14:27:53 @sgp_: Yeah I am for less aggressive scaling 14:30:15 @boog900: I will be proposing a less aggressive scaling with the addition of a sanity median 14:31:42 That is actually tied to the historical growth rate of bandwidth 14:33:02 Btw, Bitcoin has recently reduced the min fee to 0.1 sat/vbyte. 14:33:42 What I will not support is destroying the use of Monero as peer to peer electronic cash at a scale competitive with card payments 14:34:22 I just don't see that as realistic.... Monero's technology today would literally break :/ 14:34:39 @sgp_: It is very realistic 14:34:42 I would rather Monero survive at all than die because we had 20 chain splits trying to handle all those txs 14:35:00 @articmine: stressnet says no 14:35:03 Yeah.. we should be working on improving verification, efficient networking, etc. Not crippling the growth or forcing centralization onto l2s 14:35:41 I agree but we should get the improvements in and see the limits of the system first 14:35:42 @boog900: I disagree. Stressnet says monerod is inefficient, borderline broken 14:36:18 Way more realistic that today's VISA transactions rate when I was two years old 14:36:32 @boog900: before putting scaling code on mainnet that could break monero in weeks if someone spammed sufficiently 14:36:38 grampa time 14:36:41 imo pushing limits is how we fix them. Capping at 10% is just avoiding the hard work 14:37:19 @ofrnxmr: pushing limits should not be done on mainnet IMO 14:37:25 Efficiency improvements will also allow for updates to that parameter later 14:37:36 As stressnet has shown, a 10x increase is more than realistic w/o a huge increase in volume 14:38:06 @sgp_: No Bitcoin has proven this 14:38:37 It is called politics and entrenched power 14:38:41 @boog900: if we had caps already, we would never fix anything 14:39:06 because we'd never know what the breaking point is 14:39:13 @ofrnxmr: there are caps everywhere within the codebase and we just don't think about it 14:39:49 @syntheticbird: you can get blocks up to (and above afaict) 40mb w/o breaking anything 14:39:59 @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 14:40:09 @ofrnxmr: not on mainnet AFAIK 14:40:19 But as recently discovered during my private testnets, the txpool breaks, wallets die, nodes fall out of sync 14:40:20 maybe on stressnet with the fixes 14:40:36 There are caps. Why do you think that Monero was not spammed like ZCash? 14:40:46 Monero was spammed.... 14:41:07 @sgp_: Barely. Tx count didnt even get above litecoins 14:41:12 No where near like ZCash 14:41:36 @articmine: yes it costs to break Monero, but the fact we can put a cost on it is bad 14:41:45 @ofrnxmr: Never even filled the txpool 14:41:49 Monero does not have strong protections that prevented the spam from escalating 14:42:05 @sgp_: It does 14:42:13 @articmine: stressnet says no 14:42:17 @sgp_: The spam cant escalate unless they pay to escalate it 14:42:24 it does in your opinion, and not in my opinion 14:42:54 @ofrnxmr: miners can just mine blocks 14:43:15 @boog900: The current scaling parameters for escalation are, imo, too soft. It doesnt cost me very much to produce 15mb blocks 14:43:26 @sgp_: I am well aware of you position 14:43:31 Your 14:45:30 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 14:45:36 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 14:45:42 I am getting really tired of this. What is everyone's here relationship to the Blockchain Surveillance industry? 14:47:28 I will start with mine. Helping the defense in a court case fight for false accusations the BS companies made against a defendant 14:49:34 @articmine:monero.social: to #monero-research-lounge:monero.social 16:43:08 was 142 addressed / decided on? https://github.com/monero-project/research-lab/issues/142 to either use the double call to elligator2 (unbiased_hash_to_ec) or to use the standardized version? 18:00:04 DataHoarder: plan is to use two maps of the first and second half of a single blake2b-512 18:00:26 so existing unbiased_hash_to_ec and not standardized one, ok 18:01:05 I think it was discussed again a few times but no conclusion was posted in the PR/Issue 19:14:27 > <@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 https://mrelay.p2pool.observer/e/iO_1rcMKdWRhbW00 ] 19:14:27 > Eliminate minimum fee (technically, it lowers it to the smallest XMR unit 1 piconero, or 0.000000000001 XMR). 19:14:27 > this seems perfect for a chain analytics company to spam the chain for cheap 19:14:47 hard no for me on this proposal. There needs to be a sane base fee to prevent spam 19:21:44 @spirobel:kernal.eu: If a chain analytics company can spam for cheap, so can someone else? 19:24:01 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. 19:26:30 I don't like the idea of hard coding values in general. Ideally, the fee system should be entirely dynamic 19:28:12 @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? 19:31:24 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 19:39:24 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 19:39:45 people can only spam for cheap if there is no other demand for the base space 19:40:16 and they can only spam a small amount of total size, well within reason without causing network harm 19:41:51 so what I' trying to say is a "reasonable" minimum base fee needs to be continuously adjusted as the price changes 19:43:30 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 19:50:05 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 https://mrelay.p2pool.observer/e/r774rsMKQTdZNkpQ ] 19:53:24 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) 19:55:04 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 19:55:57 You cannot set fixed fees and expect the scaling penalty to work. 19:56:00 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 19:56:28 (that comment wasn't specifically directed at you ArticMine) 19:58:30 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. 19:59:09 @namenet:matrix.org: What does the supply curve of this market look like? 20:00:02 @rucknium: I'm not sure I'm not an economist 20:00:40 If it is peer to peer expect as ~200x increase in blocksize. If it is banking expect fees to skyrocket 20:01:29 I would start with basic economics such as the equation of exchange 20:01:35 @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 20:02:01 MV = PQ 20:02:31 @namenet:matrix.org: I am one. "Just let the market decide" does not make sense with block space. 20:02:34 Oh wow 20:03:13 You may first notice that the costs of block space are externalities. 20:03:57 There is not universal way to deal with externalities. Anyway, my line of thought is better for #monero-research-lounge:monero.social 20:04:12 @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 20:04:35 @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 20:05:19 @rucknium: I'll continue the conversation there 20:06:22 We have to break Q into QC (on chain, peer to peer) and QB (Bank) 20:07:25 QC if the use case does not change is proportional to the blocksize. QB is not 20:07:57 Bitcoin by restricting QC forced the economic activity oon QB 20:08:09 Sorry what is QC? 20:08:24 On chain economic activity 20:09:04 as opposed to banibg 20:09:10 Banking 20:12:00 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 20:12:25 Which defeats the entire purpose of Monero 22:23:25 Requiring nodes to be dedicated servers makes Monero centralized and therefore also defeats the purpose of Monero 22:23:42 Which, at those very high block sizes, is exactly what you're doing. 22:23:52 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. 22:25:54 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. 22:28:00 Monero block wars 22:28:15 How about this: we can release 2 haes forks. One with 10% yearly scaling, and one without 22:28:22 Let the best chain win 22:28:39 s/haes/hard 22:29:21 10% yearly scaling is essentially btc core w/o segwit, but still pushing centralized ln 22:29:49 And absolutely nobody is proposing entirely unchained block growth 22:30:06 agreed but that doesn't mean we should go the BSV route 22:30:58 @blurt4949:matrix.org: absolutely nobody is proposing we do that 22:31:31 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 22:31:58 10% yearly growth brings us from 0.25 to 0.65 tps over 10 years. for comparison, 1mb bitcoin does 7tps 22:31:59 That's equivalent to 400 BTC blocks which for all intents and purposes is a BSV-type network 22:32:06 400mb BTC blocks* 22:32:39 yeah so lets not do 10% then, but let's also not allow hundreds of mb blocks maybe? 22:33:39 100s of mb blocks isnt possible in the short term with current scaling 22:34:05 We have limits, or rather, dampers or retardation 22:34:07 I'm aware but it shouldn't be possible in the medium/moderate long-term either. 22:34:45 if the 6x per year figure is accurate, that's 3 years, which is not a long time 22:34:53 Blocksize growth cant exceed certain parameters 22:36:25 And even blocks of a few mb would be a problem in the short term but that's not the point 22:36:28 @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 22:36:58 With fcmp, its more like 1.4mb 22:36:59 stressgguj7ugyxtqe7czeoelobeb3cnyhltooueuae2t3avd5ynepid.onion 22:37:11 Wouldn't that be 1.4mb blocks with FCMP? 22:37:11