<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.