<a​rticmine:monero.social> kayabanerve: After reviewing your post on FCMP++ costs and transaction sizes, I do have a way to simplify things.

<a​rticmine:monero.social> 1) Use two FCMP++ transaction types with pre-defined weights. 4 in and 4 out, this should cover over 90% of the transactions., and 8 in 8 out for the rest of the transactions. With compute 4, which I consider optimal this will lead to predefined weights of 6750 bytes for 4/4 and 9750 bytes for 8/8. For the initial scaling calculations, if the actual size is within 10% of the defi<clipped messag

<a​rticmine:monero.social> ned weights it should be fine.

<a​rticmine:monero.social> 2) TX extra. Include a field of the same size in all transactions. I would keep the size not larger than 256 bytes. The actual size to be chosen by community consensus. 0 bytes if the community chooses to get rid of this.

<a​rticmine:monero.social> 3) Move the recent median change adjustment currently 10 blocks from the wallet fee code to the daemon node relay code.

<a​rticmine:monero.social> The only variable left for the base fee calculation then is the Long Term Median ML which is consensus. The other fees are a multiple of the base fee. I am proposing to go back to linear fee scaling. The base fee becomes a pre-defined constant for each of the two FCMP++ transaction types in XMRBytes which when divided by ML will yield the base fee in XMR.

<a​rticmine:monero.social> If we proceed with a non FCMP++ transaction type for coinbase transaction consolidation then the fee for this transaction can be calculated by dividing 4/4 fee by the 4/4 weight and multiplying by the actual transaction size.

<a​rticmine:monero.social> The idea is that the tx weights will remain the same if the sizes of the various proofs change.

<a​rticmine:monero.social> The idea here is to make a wallet fee calculation idiot proof as much as possible.

<a​rticmine:monero.social> The main change to accommodate the above is to increase the minimum penalty free zone to 1000000 bytes and the reference transaction size to 10000 bytes.

<a​rticmine:monero.social> I will be writing this up

<a​rticmine:monero.social> By the way: I do not see growth in the size of the FCMP++ size down the road to be an issue at all even if it diverges significantly from the pre-defined weights.

<o​frnxmr:monero.social> Why would we need 4 out? 3 and 4 are rarely used.

<o​frnxmr:monero.social> i'd think 2/2 covers more than 90%

<o​frnxmr:monero.social> And multi-out, id think 4/16 would be more realistic (and much more common) than 8/8 or even 4/8. consuming 1 input per output seems like an oddity for multi-output transactions.

<o​frnxmr:monero.social> maybe i'm missing something specific about fcmp tx construction(?)

<a​rticmine:monero.social> I believe kayabanerve covered this. The idea is to reduce the number of different transaction types to maximize privacy

<o​frnxmr:monero.social> Than 4/4 amd 8/8 are both poor choices imo

<o​frnxmr:monero.social> 4/4 is wasteful and 8/8 is unrealistic

<a​rticmine:monero.social> Why

<o​frnxmr:monero.social> Because 4 input tx are extremely rare, as are 3+ output

<a​rticmine:monero.social> We must keep in mind how FCMP++ scales with number of inputs and outputs

<o​frnxmr:monero.social> 2/2 should be standard for the vast majority of tx. 1 dust + 1 partial consume for the input, and for output 1 recipient + change

<o​frnxmr:monero.social> And for larger tx, most 16 outs dont have many inputs, but and most large inputs dont have many outs

<o​frnxmr:monero.social> A 146 in is usually 2 out, and a 16 out is usually 2 in

<a​rticmine:monero.social> Have you looked at kayabanerve 's cost analysis for the different transaction types

<o​frnxmr:monero.social> no sir

<o​frnxmr:monero.social> I'm late to the party, apologies

<a​rticmine:monero.social> Initially I was skeptical myself, but after close examination I really likey his approach.

<a​rticmine:monero.social> The extra inputs can be used for ongoing wallet maintenance, by passing the need for large wallet consolidation transactions. The extra outputs can be used to mitigate 10 block hold issue.

<a​rticmine:monero.social> When it comes to consolidating large numbers of coinbase transactions l suggest a special in the clear tx for this

<a​rticmine:monero.social> I believe there is an issue for the coinbase tx consolidation. I have to find it.

<o​frnxmr:monero.social> The extra inputs don't need extra outputs though.

<o​frnxmr:monero.social> I agree that coinbase consolidations could probably be their own tx type.

<o​frnxmr:monero.social> but on a high lvl, w/o knowing details of how it all works, i would still propose 2/2

<o​frnxmr:monero.social> (pressed send too soon. 1 sec)

<o​frnxmr:monero.social> while i'm typing, i sincerely feel that 6.7kb for the lowest size is much too big. Thats over 4x the current size of a 1/2 and 3x a 2/2

<k​ayabanerve:matrix.org> Sorry, are you proposing transaction uniformity *now* ArticMine: ?

<k​ayabanerve:matrix.org> Also, NACK to TX extra becoming fixed size. Also, NACK to 256 bytes as wallet2 *without cramming in additional data* can already use almost double that due to wallet data.

<k​ayabanerve:matrix.org> I am not advocating uniformity now yet keeping it in mind during current decisions.

<k​ayabanerve:matrix.org> I disagree in introducing coinbase consolidation TXs.

<a​rticmine:monero.social> I see a case of moving towards uniformity.

<a​rticmine:monero.social> For example a 2 in 2 out tx with compute factor 4 is ~ 5000 bytes. There are diminishing returns here. I mean if people want to keep 2 in 2 out tx fair enough. What I don't want to see is many different in efficient combinations, as is the case now.

<a​rticmine:monero.social> Realistically we should be able to reduce the number of transaction types.

<a​rticmine:monero.social> As for tx extra if we can fit almost 500 bytes without additional data, are we better off just getting rid of the extra field entirety rather than making it variable? I am fine with getting rid of this extra field.

<a​rticmine:monero.social> With regards to coinbase consolidations l am actually neutral

Cheap coinbase consolidation TXs are important for p2pool adoption

<a​rticmine:monero.social> What I would prefer to see is a limited number of transaction types with pre-defined weights. This would make the base fee only dependent on ML

<a​rticmine:monero.social> My question becomes: How many different transaction types do we really need?

<a​rticmine:monero.social> Also do we want 2 in 4 out, 2. In 8 out etc?

<k​ayabanerve:matrix.org> ArticMine: we can't get rid of extra. Wallets use it. we literally can't get rid of it and maintain a functioning protocol without defining new output types and adopting a new wallet protocol.

<k​ayabanerve:matrix.org> Wallets use those hundreds of bytes. The ability to cram arbitrary data in it is after the fact a 16-out transfer will use > 500 bytes in TX extra.

<k​ayabanerve:matrix.org> I also am not immediately advocating for transaction uniformity. I'm solely advocating for max ins/max outs and a new weight formula for fees of base_weight + (in * in_weight) + (out * out_weight) + tx_extra_len, with maybe a clawback clause or two for when in/out isn't a power of two.

<k​ayabanerve:matrix.org> I don't advocate for MAX_INPUTS to be less than MAX_OUTPUTS as that allows an adversary to send you outputs faster than they can be accumulated (arguably pointless as it still only incurs a logarithmic latency). That suggests we should set both to 8.

<k​ayabanerve:matrix.org> We also can't have MAX_OUTPUTS be less than 3 under Carrot.

<k​ayabanerve:matrix.org> 3 <= MAX_OUTPUTS <= MAX_INPUTS <= 8, except there's no real benefit to 3 so it may as well be 4, though I have to remind everyone it's infeasible to set MIN_INPUTS at this time so that should remain 1.

<k​ayabanerve:matrix.org> I don't advocate for ANY input uniformity at this time (even just requiring powers of two) unless we have solved dummy inputs.

<k​ayabanerve:matrix.org> That's the infeasible part. It's solved in theory but we haven't demonstrated it/benchmarked it and it's nontrivial.

<k​ayabanerve:matrix.org> I really don't want to complicate the HF with it, nor new output structures, nor new uniformity rules, at this time.

<k​ayabanerve:matrix.org> Even if we had new output structures, removing the necessity of extra, removing extra isn't necessarily a good idea. Removing it leads to spam by anyone who wants to add data as they're forced into output steganography. That suggests we should make extra fixed size and that leads to its own discussion.

<a​rticmine:monero.social> So we are left with:

<a​rticmine:monero.social> 1/4,, 2/4, 3/4, 4/4

<a​rticmine:monero.social> 1/8, 2/8, 3/8, 4/8, 5/8, 6/8, 7/8, 8/8

<a​rticmine:monero.social> In/out

<a​rticmine:monero.social> Plus a variable TX extra field

<a​rticmine:monero.social> The dominant are 1/4 and 2/4

<a​rticmine:monero.social> Any max size on TX extra?

<k​ayabanerve:matrix.org> I think that doubles the amount of outputs 90% of the time? And the per-TX limit of no more outputs than inputs isn't inherently sensical to me. Users can have a ton of inputs but only want a few outputs.

<k​ayabanerve:matrix.org> Can we kick this to the existing transaction uniformity issue for long-term discussion?

<k​ayabanerve:matrix.org> Also, yes, a relay rule was added several months ago to limit TX extra

<a​rticmine:monero.social> . but we cannot allow 2 outputs and there is no point in 3 outputs.

<a​rticmine:monero.social> We can allow also 5/4, 6/4, 7/4 and 8/4.

<a​rticmine:monero.social> I don't see what is left?

<k​ayabanerve:matrix.org> We can't allow a MAXIMUM of two outputs if we still want to achieve a logarithmic time bound to payment fulfillment.

<k​ayabanerve:matrix.org> A maximum.

<k​ayabanerve:matrix.org> We can still allow 2 as the minimum.

<a​rticmine:monero.social> So x/2 is still good?

<k​ayabanerve:matrix.org> There's effectively no value to a 3 output limit as 4 is largely as computationally expensive.

<k​ayabanerve:matrix.org> Yes

<k​ayabanerve:matrix.org> FYI, there's multiple GitHub issues and MRL meetings with background on all of this.

<k​ayabanerve:matrix.org> That's why I'm asking to kick it back to the transaction uniformity MRL issue if you want to discussing uniformity. There's a ton of prior commentary not represented here.

<a​rticmine:monero.social> .. sure but we can work for now with x/2, x/4 and x/8 for 24 combinations in total and push the rest of the discussion down the road

<k​ayabanerve:matrix.org> I don't support that at this time.

<k​ayabanerve:matrix.org> It can be a proposal. It isn't one I support or care to spend the time on. You do you and we'll see what happens.

<k​ayabanerve:matrix.org> I don't have a fundamental objection to that policy alone. I just don't advocate that complexity at this time.

<a​rticmine:monero.social> What I need to know is the maximum parameters

<a​rticmine:monero.social> It comes to what we are allowing now

<a​rticmine:monero.social> For this HF

<a​rticmine:monero.social> I mean if we allow 1/2 and 2/2 for the HF those are the critical parameters for scaling

<k​ayabanerve:matrix.org> My advocacy is a max of 8 for each but it's not yet fully decided.

<k​ayabanerve:matrix.org> It's an active MRL topic.

<a​rticmine:monero.social> I understand. Anything greater than 8/8 is really a non issue for scaling so I am not going to worry about it.

<a​rticmine:monero.social> To update the scaling I am going to focus on 2/2 4/4 and 8/8 with a compute factor of 4 and fixed weights for the proofs as the number of outputs in the blockchain grows.

<a​rticmine:monero.social> As for the proposed weight formula for fees. I am fine with that. The only variable that needs to be introduced into the fee calculation is ML which is consensus. The rest is a constant that can be calculated once.

Are you seriously considering not allowing more than 8 inputs? What if I need to spend 10 XMR and I have 10x1 XMR inputs?

<a​rticmine:monero.social> In the above example two transactions would be needed

<a​rticmine:monero.social> It is not the end of the world.

<j​ack_ma_blabla:matrix.org> what if i am merchant who sells 0.1xmr worth of goods to 1000 ppl, and need to pay my vendor 100xmr ?

What if I'm p2pool miners who got 512 inputs and needs to consolidate them? It will be 64+8+1 transactions, and over 30 blocks worth of waiting.

<j​ack_ma_blabla:matrix.org> Dont tell me FCMP cant scale

Right now the number of inputs is only limited by the max tx size, and max 8 inputs will be huge downgrade and will hurt usability

<j​ack_ma_blabla:matrix.org> so many extra txs, doesnt it just bloat the chain ?

<j​ack_ma_blabla:matrix.org> just doesnt hurt, it will be devastating; exchangers won't be able to handle this coin management crap and just delist anywhere we are left

<a​rticmine:monero.social> Exchange wallet maintenance can actually be handled on the fly with 8/8 txs, preventing the buildup of dust

<a​rticmine:monero.social> The p2p pool issue is a separate matter.

What do you mean on the fly? It's still a lot of transactions to consolidate a lot of inputs

Regular users will find it very hard to manage if they can't just spend their 10+ small inputs in a single payment

<j​ack_ma_blabla:matrix.org> thousands of deposits, consoldiations; payments to send ; just see the above example of 1000*0.1

Unless the default wallet can create chained TXs (chaining will be possible, right?) to handle big consolidation automatically, it will be just too cumbersome for an average user/exchange without dedicated XMR team

<o​frnxmr:monero.social> I fell asleep

<o​frnxmr:monero.social> I would still propose

<o​frnxmr:monero.social> - n/2out as standard/minimum.

<o​frnxmr:monero.social> - n/16(?) as max?

<o​frnxmr:monero.social> - n = 2, 4, 8, 16, 64, 256? (would any of these under fcmp exceed the 100kb packet and tx size limits?)

<o​frnxmr:monero.social> low limits on inputs hurt usability for consolidations or sweeps (often 2 out, but still necessary for pay-to-many).

<o​frnxmr:monero.social> 16 out seems arbitrary but might still be a good midpoint.

<o​frnxmr:monero.social> And this goes back to tx uniformity mrl discussions, i just imagine that the sizes of these tx might alter the available options.

<o​frnxmr:monero.social> we currently allow 1 input tx, but we prefer 2 inputs if it is possible to fully consume a dust input. So 2 input tx currently have worse privacy in the short term, but protect from massive dust consolidations later on

<o​frnxmr:monero.social> (this would get rid of 3-15 outs, limiting to 2 and 16)

"<m-relay> <a​rticmine:monero.social> It is not the end of the world." Strong disagree. Monero UX is already bad. We don't need to be moving backwards here.

if there's limits because of the efficiency of the proofs we're using, okay, but from reading through this it feels like the emphasis on transaction uniformity of really misplaced under fcmps

If done automatically by the wallet I suppose it would be ok. In case the user has to manually make two transactions though it would definitely be detrimental to UX

I could support the automated case if making two transactions is somehow more efficient in terms of space or compute

in terms of privacy and transaction uniformity, if we are think uniformity is that important which I'm not convinced of, chaining a bunch of transactions to merge outputs seems like it would be just as if not more damaging from a privacy perspective

<a​js_:matrix.org> There will be a MoneroKon Assembly @ 38th Chaos Communication Congress 27-30 Dec 2024 in Hamburg, Germany

<a​js_:matrix.org> We are looking for Monero related presentation/workshops. Limited free tickets available.

<a​js_:matrix.org> Submit proposals under “MoneroKon” track: pretalx.riat.at/38c3/submit

<a​js_:matrix.org> Deadline 7th December