00:05:01 dave.jp: No, for technical limitations. 00:05:01 ofrnxmr: I thought it was 100 KB but I double checked the code and only immediately saw the 149400 number. If it's worse IRL, it's worse, and doesn't really change my comments. It means you only get 16 FCMPs if 1 proof per input though. 00:07:40 kayabanerve: what are these technical limitations? In layman terms? Fcmp is not efficient enough? Has there been any discussion done with stakeholders like exchanges and merchants which would be the most affected by such a drastic change? 00:19:48 dave.jp: Read my post. 00:29:47 Above my pay grade, from what I could understand it’s computational issue along with tx uniformity; i guess we will see how it performs on testnet and then finalise this max inputs? 00:30:01 Yeah, its actually a functional 100kb, 66% or 2/3 of 220inouts (146 inputs). I don't know why its limited to 66% though 16:14:26 With FCMP++. The minimum penalty free zone will have to be increased to a minimum of 1000000 bytes. This assumes a compute factor of 4 or greater. So fixed limits based upon the current 300000 byte minimum penalty free zone will become irrelevant at best, and could in some situations cause problems. 16:15:45 The reason for the above is to keep fees approximately where they are now 16:17:04 If the community wishes to increase fees this can be done at node relay by increasing minimum node relay fee 16:22:18 With respect to large transactions, with weights greater than the reference transaction weight, quite apart from the FCMP++ issues, can cause serious problems with scaling. This is especially the case when the short term median is above the long term median. 16:25:07 My recommendation of a 1000000 byte minimum penalty free zone is contingent on the community accepting the maximum 8 for both inputs and outputs recomedation 16:27:13 In lay person terms if we want large transactions we have to accept larger blocks to accommodate them. 16:31:00 I do not want to see a repeat of what happened in 2017 when RingCT was introduced with transactions getting stuck and the blocks not scaling. This had to be somewhat fixed by a hard fork a few months later, and was not really fixed until Bullet Proof. in 2018 17:29:45 Personally I prefer to have significantly higher fees. In my opinion, scaling to larger block sizes should be allowed but should be expensive. Monero should do what it can to have cheap fees, though privacy and efficiency should be higher priorities than keeping fees low, imho. The scaling algorithm is already very aggressive and I prefer that it doesn't become even more aggressiv 17:29:47 e, even if transactions will become larger 17:32:58 Higher fees in xmr terms dont make sense. 17:33:14 They _only_ make sense if you value xmr in fiat bucks 17:33:50 Xmr brags all the time abt low fees, but fees are only low in fiat. They arent low in xmr 17:34:24 Unfortunately, the cost to attack the network doesn't need to be paid in XMR 17:35:50 raising xmr fees stunts usage and encourages mining pools attacking the network themselves 17:36:06 The XMR/USD will always have some practical significance. That's one of the advantages of a fee market like with Bitcoin; people can bid up or down the cost they're willing to pay, anchored in an implied USD value 17:36:10 i think the block reward should be penalized more aggressively tho. On stressnet we barely saw a different in the block reward at 8mb blocks 17:37:10 Example: we were able to continuously spam the neteork bcuz the spammer was earning back their tx fees 17:37:49 There is a fee market in Monero. 17:38:18 Xmr fees should _not_ be tied to USD. Should we hard fork to adjust fees everytime the price changes significantly? No. Thats absurd 17:38:19 Monero has a fee market but it's currently very primitive compared to Bitcoin 17:38:48 I'm not saying to tie them to USD, which is impossible since we can't predict the future 17:39:04 Youre literally suggesting to adjust them to usd right now 17:39:21 Which implies thst we would have to readjust later 17:39:34 Actually it is the Bitcoin fee market that is primitive not the Monero one. 17:39:38 Moving more of the fee selection to a competitive market is different than anchoring to a USD value 17:40:14 its not more competitive if it becomes prohibitive 17:40:42 fees are prohibitive by design, they need to be 17:40:43 Sech1 17:40:45 that's their entire purpose 17:41:02 no, their purpose is network security 17:41:13 And should be balanced with the block reward 17:41:22 And the dynamic block size 17:41:54 Should not be 1xmr in fees per block just bcuz it only 160usd 17:42:03 ... based upon the cost of bandwidth in 2010. 17:43:04 I'm not saying pick a fixed size and stick with it permanently. I'm saying pick some values, make them flexible (at a high cost, but not insurmountable) and let the fee market handle the rest 17:43:25 a bit of a hybrid. I don't advocate hardcoding many values 17:43:27 Sure. 0.00003 sounds good to me 17:44:30 Just need to penalize the block reward more aggressively. 17:44:36 set the minimum network fee to a very small number but then set the penalty zone low as well, and then allow conservative expansion. That's better than trying to predict future use, price, etc. People will pay as appropriate to get in if demand is high, and they'll pay very little (with a low cost to the network at small block sizes) when demand is low 17:44:57 Maths sgp. Unless youre mining snd earning all of your fees back, you will burn out all of your inputs 17:45:05 think like what bitcoin is doing, except allow for conservative growth not 0 growth 17:45:25 Unless you use elevated fees, the block size wont grow enough and your tx will be dropped or never confirm 17:45:31 If the tx are dropped, the cost is 0. 17:45:40 If you use elevated fees, you burn your supply 17:45:58 What Bitcoin is doing with scaling is a complete failure 17:46:29 Imo, block reward should be penalized down to 0 if fees exceed the reward 17:46:49 It is 17:47:10 If you double the blocksize 17:47:44 This has been the case since the launch of Monero 17:47:47 we had 5000+tx/block and the reward was still like 0.58xmr iirc 17:47:51 Rucknium: 17:48:07 Those tx had a normal fee 17:48:15 Sure if you scale slowly 17:48:17 And block size like 8mb 17:48:53 Block reward goes to 0 if you go double the median block size 17:49:01 It's a relative measure, not an absolute one 17:49:20 5000 tx/block can give you 0.6 XMR if the median is large enough 17:49:35 The current surge in the short term median is 50. It will be reduced to 16 17:50:12 Is there a document for the proposed next round of fee/scaling changes? 17:50:16 What I never understood about the fee formula, is why it goes down quadratically as blocks grow. The total amount of tx fees per block will then go down linearly as blocks grow 17:50:21 That's a problem for miners 17:50:55 At some point (around 40 MB blocks), total tx fees per block will be almost 0 17:51:00 That will also be changed back to linear 17:51:27 good 17:51:33 Rucknium should have the numbers, but iirc the block reward was strangely not being reduced as i thought it would be 17:52:25 The short term medians were exceeded greatly, and spammed with normal fee lvl to get there (not slow) 17:52:37 I'm not sure if we hit long term medians 17:52:51 block reward also goes down quadratically, so it drops very slowly in the beginning 17:53:02 but more steeply as block size approaches median*2 17:53:33 https://github.com/spackle-xmr/chaindata_graphics/blob/main/stressnet%2F2_month_block_sizes.png 17:53:33 That is appropriate 17:55:08 https://github.com/spackle-xmr/chaindata_graphics/blob/main/stressnet/stressnet_animation_month2.gif 17:55:14 Still we have to allow for a relative seasonal retail surge comparable to what VISA has historically experience d 17:55:42 So a factor of 16 is as low as possible 17:56:10 In the surge during December 17:57:50 I discussed this at both MoneroKon 2013 and 2014 17:58:16 23 and 24 :P 17:58:42 Yes of course 18:00:30 The other idea that was discussed is the introduction of a sanity median with a 1000000 blocks 18:01:31 With a growth factor receptor 2 this will follow Neilsen' Law of Bandwidth 18:08:03 Increasing the growth factor of ML from 1.7 to 2 is necessary to allow for the drop in the surge in MS from 50 to 16 18:09:26 When the sanity median is factored in this is less aggressive. 18:11:21 The sanity median will target a current high end residential or small business internet connection. I currently have 5 Gbps over fiber symmetrical 18:12:17 its going to take a WHILE before 5 Gbps is going to be the standard 18:12:27 We must keep in mind that there is a 2 year delay in the sanity median 18:12:42 for germany, id say we have large scale 1 Gbps (non symetrical) by 2030 18:13:37 then again, i know someone who signed a contract nearly 5 years ago and they still dont have it 18:14:00 so 2030 is optimistic 18:14:32 Non symmetrical is almost always Cable or DSL 18:15:21 Here in Canada the standard for fibre is 1. Gbps 18:15:28 Symmetrical 18:19:07 The cable companies can lobby all they want. They will have to accept the reality of fibre or become irrelevant 18:23:54 In 2022 I also showed a case of a house with a list price of ~20,000,000 USD where the best upload bandwidth was about 100Mbps 18:24:32 So there will be an edge case 18:25:08 Or two 18:25:35 I believe that neighborhood now has fibre 19:56:22 hi 19:56:24 something cool 19:56:25 https://github.com/cypherstack/carrot-audit 20:05:55 Diego Salazar: Can the release tag be updated to include the PDF please? 20:14:56 done 20:23:54 ofrnxmr If you were watching the monitor, the graph showed total reward to miner including fee: https://github.com/Rucknium/monerod-monitor/blob/main/server.R#L176 20:24:29 I just noticed that these docs are misleading: https://docs.getmonero.org/rpc-library/monerod-rpc/#get_last_block_header 20:24:31 > reward - unsigned int; The amount of new atomic-units generated in this block and rewarded to the miner. 20:24:50 Some of those coins are not new, but are recycled fees 20:26:19 There was a period after the spam when the share of outputs produced by 16-out txs was high. But the share of txs that are 16-out and the share of outputs that were produced by 16-out txs is a different number. 20:27:29 Each 2-out tx contributes 2 outputs to the aggregate number of outputs. And each 16-out tx contributes 16 outputs to the aggregate number of outputs. But each 2- and 16-out tx contribute only one to the aggregate number of trasnactions. 20:31:54 Mods above, please make sure Matrix users can join this MRL room without an invitation: https://libera.monerologs.net/monero-community/20241125#c464140 20:52:08 link in README.md doesn't work, afaict it should be https://github.com/cypherstack/carrot-audit/blob/main/latex/Carrot-final.pdf (change ".../blob/upload/..." to ".../blob/main/...") 21:40:11 Mods, please make rucknium admin here 21:40:29 xmrscott: charuto: 22:06:38 Why more mods here? 22:06:50 binary, selsta and luigi are already opped 22:16:11 Thats on irc 22:16:28 On matrix ifs xmrscott and charuto, and they have the room set to invite only 22:17:40 Fair enough 22:18:02 Maybe check if rucknium wants to be a matrix mod though. 22:53:44 Rucknium hosts the mrl meetings, and has to ask (for months, and months) for mods to change things 22:54:45 Theres 0 reason why scott or charuto should have control over who is allowed in this room, or emoji reactions. 22:54:47 ruck asked for months for emojis and it was only recently reversed. Now hes asking for the invite-only to be removed 22:55:39 If ruck wants the room open, it should be open, and he shouldnt have to ask some mods who have nothing to do with mrl