<k​ayabanerve:matrix.org> dave.jp: No, for technical limitations.

<k​ayabanerve:matrix.org> 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.

<d​ave.jp:matrix.org> 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?

<k​ayabanerve:matrix.org> dave.jp: Read my post.

<d​ave.jp:matrix.org> 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?

<o​frnxmr:monero.social> Yeah, its actually a functional 100kb, 66% or 2/3 of 220inouts (146 inputs). I don't know why its limited to 66% though

<a​rticmine:monero.social> 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.

<a​rticmine:monero.social> The reason for the above is to keep fees approximately where they are now

<a​rticmine:monero.social> If the community wishes to increase fees this can be done at node relay by increasing minimum node relay fee

<a​rticmine:monero.social> 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.

<a​rticmine:monero.social> 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

<a​rticmine:monero.social> In lay person terms if we want large transactions we have to accept larger blocks to accommodate them.

<a​rticmine:monero.social> 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

<s​gp_:monero.social> 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<clipped message>

<s​gp_:monero.social> e, even if transactions will become larger

<o​frnxmr:monero.social> Higher fees in xmr terms dont make sense.

<o​frnxmr:monero.social> They _only_ make sense if you value xmr in fiat bucks

<o​frnxmr:monero.social> Xmr brags all the time abt low fees, but fees are only low in fiat. They arent low in xmr

<s​gp_:monero.social> Unfortunately, the cost to attack the network doesn't need to be paid in XMR

<o​frnxmr:monero.social> raising xmr fees stunts usage and encourages mining pools attacking the network themselves

<s​gp_:monero.social> 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

<o​frnxmr:monero.social> 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

<o​frnxmr:monero.social> Example: we were able to continuously spam the neteork bcuz the spammer was earning back their tx fees

<a​rticmine:monero.social> There is a fee market in Monero.

<o​frnxmr:monero.social> Xmr fees should _not_ be tied to USD. Should we hard fork to adjust fees everytime the price changes significantly? No. Thats absurd

<s​gp_:monero.social> Monero has a fee market but it's currently very primitive compared to Bitcoin

<s​gp_:monero.social> I'm not saying to tie them to USD, which is impossible since we can't predict the future

<o​frnxmr:monero.social> Youre literally suggesting to adjust them to usd right now

<o​frnxmr:monero.social> Which implies thst we would have to readjust later

<a​rticmine:monero.social> Actually it is the Bitcoin fee market that is primitive not the Monero one.

<s​gp_:monero.social> Moving more of the fee selection to a competitive market is different than anchoring to a USD value

<o​frnxmr:monero.social> its not more competitive if it becomes prohibitive

<s​gp_:monero.social> fees are prohibitive by design, they need to be

<o​frnxmr:monero.social> Sech1

<s​gp_:monero.social> that's their entire purpose

<o​frnxmr:monero.social> no, their purpose is network security

<o​frnxmr:monero.social> And should be balanced with the block reward

<o​frnxmr:monero.social> And the dynamic block size

<o​frnxmr:monero.social> Should not be 1xmr in fees per block just bcuz it only 160usd

<a​rticmine:monero.social> ... based upon the cost of bandwidth in 2010.

<s​gp_:monero.social> 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

<s​gp_:monero.social> a bit of a hybrid. I don't advocate hardcoding many values

<o​frnxmr:monero.social> Sure. 0.00003 sounds good to me

<o​frnxmr:monero.social> Just need to penalize the block reward more aggressively.

<s​gp_:monero.social> 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

<o​frnxmr:monero.social> Maths sgp. Unless youre mining snd earning all of your fees back, you will burn out all of your inputs

<s​gp_:monero.social> think like what bitcoin is doing, except allow for conservative growth not 0 growth

<o​frnxmr:monero.social> Unless you use elevated fees, the block size wont grow enough and your tx will be dropped or never confirm

<o​frnxmr:monero.social> If the tx are dropped, the cost is 0.

<o​frnxmr:monero.social> If you use elevated fees, you burn your supply

<a​rticmine:monero.social> What Bitcoin is doing with scaling is a complete failure

<o​frnxmr:monero.social> Imo, block reward should be penalized down to 0 if fees exceed the reward

<a​rticmine:monero.social> It is

<a​rticmine:monero.social> If you double the blocksize

<a​rticmine:monero.social> This has been the case since the launch of Monero

<o​frnxmr:monero.social> we had 5000+tx/block and the reward was still like 0.58xmr iirc

<o​frnxmr:monero.social> Rucknium:

<o​frnxmr:monero.social> Those tx had a normal fee

<a​rticmine:monero.social> Sure if you scale slowly

<o​frnxmr:monero.social> And block size like 8mb

Block reward goes to 0 if you go double the median block size

It's a relative measure, not an absolute one

5000 tx/block can give you 0.6 XMR if the median is large enough

<a​rticmine:monero.social> The current surge in the short term median is 50. It will be reduced to 16

<s​gp_:monero.social> Is there a document for the proposed next round of fee/scaling changes?

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

That's a problem for miners

At some point (around 40 MB blocks), total tx fees per block will be almost 0

<a​rticmine:monero.social> That will also be changed back to linear

good

<o​frnxmr:monero.social> Rucknium should have the numbers, but iirc the block reward was strangely not being reduced as i thought it would be

<o​frnxmr:monero.social> The short term medians were exceeded greatly, and spammed with normal fee lvl to get there (not slow)

<o​frnxmr:monero.social> I'm not sure if we hit long term medians

block reward also goes down quadratically, so it drops very slowly in the beginning

but more steeply as block size approaches median*2

<o​frnxmr:monero.social> github.com/spackle-xmr/chaindata_gr…stressnet%2F2_month_block_sizes.png

<a​rticmine:monero.social> That is appropriate

<o​frnxmr:monero.social> github.com/spackle-xmr/chaindata_gr…snet/stressnet_animation_month2.gif

<a​rticmine:monero.social> Still we have to allow for a relative seasonal retail surge comparable to what VISA has historically experience d

<a​rticmine:monero.social> So a factor of 16 is as low as possible

<a​rticmine:monero.social> In the surge during December

<a​rticmine:monero.social> I discussed this at both MoneroKon 2013 and 2014

<o​frnxmr:monero.social> 23 and 24 :P

<a​rticmine:monero.social> Yes of course

<a​rticmine:monero.social> The other idea that was discussed is the introduction of a sanity median with a 1000000 blocks

<a​rticmine:monero.social> With a growth factor receptor 2 this will follow Neilsen' Law of Bandwidth

<a​rticmine:monero.social> 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

<a​rticmine:monero.social> When the sanity median is factored in this is less aggressive.

<a​rticmine:monero.social> The sanity median will target a current high end residential or small business internet connection. I currently have 5 Gbps over fiber symmetrical

<m​onerobull:monero.social> its going to take a WHILE before 5 Gbps is going to be the standard

<a​rticmine:monero.social> We must keep in mind that there is a 2 year delay in the sanity median

<m​onerobull:monero.social> for germany, id say we have large scale 1 Gbps (non symetrical) by 2030

<m​onerobull:monero.social> then again, i know someone who signed a contract nearly 5 years ago and they still dont have it

<m​onerobull:monero.social> so 2030 is optimistic

<a​rticmine:monero.social> Non symmetrical is almost always Cable or DSL

<a​rticmine:monero.social> Here in Canada the standard for fibre is 1. Gbps

<a​rticmine:monero.social> Symmetrical

<a​rticmine:monero.social> The cable companies can lobby all they want. They will have to accept the reality of fibre or become irrelevant

<a​rticmine:monero.social> 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

<a​rticmine:monero.social> So there will be an edge case

<a​rticmine:monero.social> Or two

<a​rticmine:monero.social> I believe that neighborhood now has fibre

<d​iego:cypherstack.com> hi

<d​iego:cypherstack.com> something cool

<d​iego:cypherstack.com> github.com/cypherstack/carrot-audit

<k​ayabanerve:matrix.org> Diego Salazar: Can the release tag be updated to include the PDF please?

<d​iego:cypherstack.com> done

<r​ucknium:monero.social> ofrnxmr If you were watching the monitor, the graph showed total reward to miner including fee: github.com/Rucknium/monerod-monitor/blob/main/server.R#L176

<r​ucknium:monero.social> I just noticed that these docs are misleading: docs.getmonero.org/rpc-library/monerod-rpc/#get_last_block_header

<r​ucknium:monero.social> > reward - unsigned int; The amount of new atomic-units generated in this block and rewarded to the miner.

<r​ucknium:monero.social> Some of those coins are not new, but are recycled fees

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> Mods above, please make sure Matrix users can join this MRL room without an invitation: libera.monerologs.net/monero-community/20241125#c464140

<s​needlewoods:monero.social> link in README.md doesn't work, afaict it should be github.com/cypherstack/carrot-audit/blob/main/latex/Carrot-final.pdf (change ".../blob/upload/..." to ".../blob/main/...")

<o​frnxmr:monero.social> Mods, please make rucknium admin here

<o​frnxmr:monero.social> xmrscott: charuto:

Why more mods here?

binary, selsta and luigi are already opped

<o​frnxmr:monero.social> Thats on irc

<o​frnxmr:monero.social> On matrix ifs xmrscott and charuto, and they have the room set to invite only

Fair enough

Maybe check if rucknium wants to be a matrix mod though.

<o​frnxmr:monero.social> Rucknium hosts the mrl meetings, and has to ask (for months, and months) for mods to change things

<o​frnxmr:monero.social> Theres 0 reason why scott or charuto should have control over who is allowed in this room, or emoji reactions.

<o​frnxmr:monero.social> ruck asked for months for emojis and it was only recently reversed. Now hes asking for the invite-only to be removed

<o​frnxmr:monero.social> 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