<jberman> @rucknium:monero.social available?

I couldn't see the usual "meeting in 1 hour" announcement ...

<jberman> Hm, and he didn't make the usual Meeting issue: github.com/monero-project/meta/issues

<jberman> Hope Ruck is alright

Yeah, pretty unusual

<sgp_> Hopefully they are okay

<jberman> rbrunner: do you want to lead a meeting w/same topics from last week?

<kayabanerve:matrix.org> 😱

Hmm, maybe you are a better moderator here?

<kayabanerve:matrix.org> They did thumbs up my message from a few days ago, IIRC.

<mayhem69:matrix.org> I had DMs with them yesterday around this time so I can confirm they were alive then

<kayabanerve:matrix.org> Or actively impersonated around then

<kayabanerve:matrix.org> Has anyone asked Mr. Plum if they were in the Library last night?

<jberman> Sure, I'll moderate

<jberman> 1. Greetings

<articmine> Hi

Thanks!

<sgp_> hello

<kayabanerve:matrix.org> 👋

<rucknium> Hi. Sorry I'm late.

<spirobel:kernal.eu> hi

Last week's topic list: monero-project/meta #1281

<hinto> hello

<kayabanerve:matrix.org> Rucknium and/or impersonater!

<rucknium> I can PGP sign if you require

<rucknium> 2. Updates. What is everyone working on?

<syntheticbird> hi

<kayabanerve:matrix.org> Returned from a conference, oxide, book, Serai, trying to merge the first FCMP++ lib into oxide and oxide's BBP.

<vtnerd> Me: official lws docker builds for stable and master are published and use the ci process. Like to get cosign with static key working eventually. Now doing further testing of subaddresses with carrot, specially incoming only accounts

<jberman> me: we released v1.3 of the FCMP++ & Carrot alpha stressnet which included a number of Quality of Life improvements, continuing stressnet debugging / investigating, and close to continuing reviewing p2p ssl (probably continuing in earnest today)

<rucknium> me: Increased CPU and RAM efficiency of monerod-monitor github.com/rucknium/monerod-monitor , which runs stressnetnode1.moneronet.info . Also wrote local deployment instructions so stressnet node operators can run it with their own node. Node operators can also just collect the performance data in a DB instead of displaying it in charts, too.

<sgp_> cool vtnerd; I'll make sure the truenas app is updated to use your official one. MAGIC had just shy of 2k installs of our unofficial docker image for lws

<kayabanerve:matrix.org> FYI, oxide has received 166 reports with 12 paid with some reward (sometimes just a small amount as a tip, not an acknowledged bug with the full kebab) since launching, what, a couple months ago?

<kayabanerve:matrix.org> A month and a half ago.

<vtnerd> The readme for lws contains url/path info for docker

<articmine> I am reviewing the proposed weights based upon roughly total transaction size and it can be the basis for a solution

<sgp_> 12 interesting reports is pretty good

<kayabanerve:matrix.org> 12 reports either valid, or we try to reward anything invalid we still make improvements due to, even if just a basic documentation update.

<syntheticbird> how much of the interesting reports were powered by ✨️Web 4.0 Quantum AGI ✨️

<kayabanerve:matrix.org> One noted we allocate and could OOM, and was a bullshit report because of course allocating functions allocate, but we still offered a small amount because I noted that function could be written to not allocate _and_ we could've included a sanity check to prevent allocating more than a few bytes (even though we allocated less memory than given to us as input).

Me: post-quantum Jamtis, research phase/feasibility study

<kayabanerve:matrix.org> @syntheticbird:monero.social: what's 166 - 12 or so

<rucknium> 3. Security proofs for GBP

<rucknium> > Hello, I [ @kayabanerve:matrix.org ] reached out to Cypher Stack to request they review the security proofs for GBPs. While Goodell reviewed Aaron's proofs prior, Aaron updated the protocol to a prior draft due to it being a more efficient variation (a few hundred bytes) at my request. Goodall, while reviewing the proofs, n [... too long, see mrelay.p2pool.observer/e/pM-xs8EKVTNZYTFW ]

<kayabanerve:matrix.org> My point was it's gotten a lot of attention and has yielded credible improvements. Some of those 154 reports simply weren't valid, but weren't absolute spam, and I look forward to the FCMP++ libraries also being covered as part of ensuring the hard fork's security.

<kayabanerve:matrix.org> I don't have more to add other than boog900 reviewed the library, pending its merge into FCMP++, and signed off pending just a few nits. The only blocker is confirmation of the academia.

<sgp_> on topic 3, this is a blocker that stands in the way of other GBP review (likely from zksecurity), so it should be supported and completed asap imo

<kayabanerve:matrix.org> @jberman:monero.social: Thoughts?

<jberman> all sgtm

<sgp_> did CS provide an ETA on delivery for this? is this something that they can work on in the immediate term?

<kayabanerve:matrix.org> I think the amount is incredibly low, especially given it directly coves the code

<jberman> > <@kayabanerve:matrix.org> Hello,I reached out to Cypher Stack to request they review the security proofs for GBPs. While Goodell reviewed Aaron's proofs prior, Aaron updated the protocol to a prior draft due to it being a more efficient variation (a few hundred bytes) at my request.Goodall, while reviewing the proofs, no [... too long, see mrelay.p2pool.observer/e/-p3Os8EKUzdIdm5v ]

<jberman> This original post got 7 thumbs up, so seems it has good support

<kayabanerve:matrix.org> Should only be a week or two, I believe, but I'd have to check

<kayabanerve:matrix.org> *the code in relation to the protocol. I don't present it as an audit of the rust

<jberman> I guess 1 q, would we maybe want zksecurity to start on divisors sooner and not be blocked?

<kayabanerve:matrix.org> I don't think this will take so long to complete it's posited as a blocker

<sgp_> I'll aim to get a combined quote for discussion in time for the meeting of November 5th, ideally covering both scopes. If GBP isn't ready yet, then it may be pushed to the following. If it's any longer than that, then yes I agree it makes sense to take out GBP and start with just divisors

<rucknium> Can you explain more what the 0 and 1 indexing issue is about?

<rucknium> Juts informational

<rucknium> just*

<kayabanerve:matrix.org> There's a list of commitments to a polynomial, where the polynomial is indexed from 0.

<rucknium> I know what 0 and 1 indexing is, but how does it affect the work here?

<kayabanerve:matrix.org> The original BP protocol committed commuting to 0th coefficient because it was 0 and inherent.

<kayabanerve:matrix.org> GBP sets it to a non-zero value and must commit to it, communicating and summing the commitment when doing the maths.

<kayabanerve:matrix.org> I knew that and explicitly made that change, and immediately answered when Goodell asked about it.

<kayabanerve:matrix.org> I just don't know why I knew that, as apparently that wasn't reflected in the formalizations 🤔

<kayabanerve:matrix.org> Presumably a DM with Aaron

<kayabanerve:matrix.org> It will update the proofs to some degree as this value is communicated now but wasn't prior, and that may not have been accurately reflected?

<kayabanerve:matrix.org> But I believe Goodell believes the implemented protocol will work out. This discrepancy just needs to be written out (vastly simplifying, of course)

<rucknium> Not the first confusion with 0 and 1 index. And won't be the last (in the world).

<kayabanerve:matrix.org> *omitted commuting to the 0th coefficient

<kayabanerve:matrix.org> **omitted committing

<kayabanerve:matrix.org> I'm so sorry, autocorrect 😅

<kayabanerve:matrix.org> Yeah, the formalization just updates communicate 1 to end to 0 to end. The proofs... bla bla bla

<rucknium> Is action needed at this meeting, or are you still working out the work scope and quote?

<kayabanerve:matrix.org> Approval, it's a request from the research fund was has MRL oversight

<kayabanerve:matrix.org> *which has

<rucknium> Any more questions from anyone here about the quote and scope of work?

<rucknium> Any more discussion or any objections to the quote and scope of work?

<jberman> I support

Sound good, yes

<rucknium> It sounds good to me.

Such 0-1 stuff can be tricky

<rucknium> I see loose consensus in favor of expending 8000 USD equivalent for Cypher Stack's work on security proofs for Generalized Bulletproofs.

<kayabanerve:matrix.org> Thank you!

<rucknium> 3. Proof-of-Work-Enabled Relay ("PoWER"). monero-project/research-lab #133

<hinto> I noted a point from the last meeting: monero-project/research-lab #133#issuecomment-3423958055

<hinto> Both @boog900:monero.social and @jeffro256:monero.social's proposals sound good to me, although they take different tradeoffs (maybe others can weigh in here). I think PoW per connection for P2P/ZMQ and PoW per TX for RPC could be an alternative, other than that I don't have anything else to add.

<kayabanerve:matrix.org> @rucknium:monero.social: that is #4

<jberman> > PoW per connection for P2P/ZMQ and PoW per TX for RPC

<jberman> This sounds ok to me. Then in some future optimization, there could be PoW per connection for RPC implemented as well, though probably won't end up worth the hassle

<rucknium> @kayabanerve:matrix.org: If the agenda items are indexed from 0, then it's item 3 :P

<kayabanerve:matrix.org> Except GBPs also had 3 :p

<jberman> PoW per tx for RPC shouldn't have the issue of expiring PoW that needs to be updated

<hinto> Yup, just a required PoW field added to existing TX relay endpoints

<jberman> Could probably just use the most recent block hash too?

<jberman> allowing a window of 2 blocks

Almost sounds a little than the "pay with hashes" system of yesteryears, from moneromooo ...

*a little like

<hinto> Ok, seems similar to the original proposal, I think we could figure out those details in the PR

<jberman> (just to clarify, I meant could use most recent block hash for RPC PoW per tx, but challenge/response still makes sense for p2p connections)

<hinto> @boog900:monero.social @jeffro256:monero.social: if there are no objections then I'll be starting the implementation assuming PoW per TX for RPC

<jeffro256> Sounds good to me

<articmine> Sounds fine to me

<rucknium> 5. Transaction volume scaling parameters after FCMP hard fork. Revisit FCMP++ transaction weight function. github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-07.pdf seraphis-migration/monero #44

<jberman> I think makes sense to continue to next topic while we wait to hear from boog on above^ thank you for pushing this forward hinto :)

<jberman> nice

<jberman> Repeating from an earlier message:

<jberman> Here is a simple proposal to make tx weight roughly equal to byte size with justification: seraphis-migration/monero #44#issuecomment-3423391977

<jberman> Of note, you can still calculate tx weight in an offline context with just n inputs, n outputs, and extra length.

<jberman> Considering the ongoing difficulty to reach rough consensus on the FCMP++ tx weight calculation, I figure this would be a simple solution that has the smallest surface for disagreement. Imo it's easiest to justify

<articmine> I believe that this is a viable approach. We are setting fixed weights for the whole transaction except for TX extre

<articmine> Extra

<jeffro256> Tx extra should be included in the byte size / weight calculation AFAIK

<jeffro256> There would be 3 paramaters to weight calculation: # ins, # outs, # extra bytes

<articmine> Of course, but not in the fixed weight

<jeffro256> What do you mean by "fixed weight"?

<articmine> Extra bytes being TX extrea

<jberman> @kayabanerve:monero.social: you may have thoughts on calculating weight roughly equal to byte size, but with constant 8 bytes for the fee, and constant 7 layers assumed in the tree to allow calculating weight from # ins, # outs, # extra bytes

<jberman> (meant to tag @kayabanerve:matrix.org )

<articmine> The one concern I have heard here is people stuffing data into various parts of the TX

<jeffro256> With the current consensus rules, AFAICT, you can't really add any extra data into a transaction outside of the tx_extra field and have the transaction still verify

<articmine> Then this should be fine.

<articmine> As for the fixed 7 layers that is a must for scaling

<articmine> Are there any objections to this approach

<jeffro256> I support weight appriox eq to byte size approach

<spirobel:kernal.eu> +1

<spirobel:kernal.eu> kiss

<spirobel:kernal.eu> this is a much better approach. The complexity seemed to get out of hand before

<kayabanerve:matrix.org> I explicitly don't as it encourages large-input TXs, they aren't even equally considered.

<kayabanerve:matrix.org> But I agree it should be a formula solely derivative of inputs, outputs, and extra length.

<articmine> @kayabanerve:matrix.org: My take is that the quadratic penalty will penalize large transactions at node relay.

<kayabanerve:matrix.org> Sorry, which quadratic penalty is this?

<kayabanerve:matrix.org> I stepped away for a moment and only returned to the proposition roughly equal to byte size.

<articmine> Block weight scalung

<kayabanerve:matrix.org> That seems indirectly relevant to the TX fees users pay at best

<articmine> Penalty to increase the block weight above the short term median

<kayabanerve:matrix.org> I'd support a flat cost for the next power of two for inputs, outputs, before corresponding to bytes fwiw

<jberman> What do you mean they aren't equally considered? > <@kayabanerve:matrix.org> I explicitly don't as it encourages large-input TXs, they aren't even equally considered.

<articmine> @kayabanerve:matrix.org: I am actually supported of that

<articmine> It is easy to implement

<kayabanerve:matrix.org> jberman: One 128-byte transaction is what, 10x cheaper 64 2-input TXs?

<kayabanerve:matrix.org> *one 128-inout transaction

<kayabanerve:matrix.org> *cheaper than

<kayabanerve:matrix.org> Sorry, I'm a bit distracted by a saucepan boiling over right now...

Put a range proof on it

<articmine> I do not see how > <@kayabanerve:matrix.org> jberman: One 128-byte transaction is what, 10x cheaper 64 2-input TXs?

Simply by being 10 times less bytes, presumably?

<jberman> 64-2 is 78132 bytes, 128-2 is 150133 bytes. 2x 64-2 = 156624

<kayabanerve:matrix.org> @jberman:monero.social: 64x2 though

<jberman> oh misread

<kayabanerve:matrix.org> Isn't it ~500k bytes, so that case, 3x 128-inputs, despite having significantly better computational performance?

<rucknium> IMHO, the encouragement of large-input txs won't affect behavior much for anyone except p2pool miners. Solution: transparent consolidation for coinbase tx. Save a lot of fees.

<jberman> ya ~500k bytes for 64x 2-in/2-out, versus ~150k bytes for 128-in/2-out

<kayabanerve:matrix.org> I don't like that :C

<kayabanerve:matrix.org> You can introduce a log2(i) scaling factor so 128 has a 7x though, while 2-in is 1x

<jberman> That creates 126 more outputs that are going to be spent in FCMP++ proofs...

Even if taking PoWER into account?

<kayabanerve:matrix.org> And those 126 outputs are reflective of ~300 FCMP inputs? Because that how it corresponds to 128-2

<kayabanerve:matrix.org> *ceil(log2(i))

<jberman> I don't follow

<kayabanerve:matrix.org> You noted 126 more outputs, for a difference in weight of 350kb.

<articmine> @kayabanerve:matrix.org: So if I understand this correctly you would want the 128-2; to pay a higher fee

<kayabanerve:matrix.org> In those 350kb, I could fit 2.33x 128-2 TXs.

<kayabanerve:matrix.org> That's approximately 300-5 being treated equivalent to 0-126 w.r.t. weight

<articmine> Enforcement of the scaling requirements at node relay, my original proposal would take care of that

<jberman> Ok I see your point. Trying to identify a path to rough consensus here

<kayabanerve:matrix.org> Linear cost to inputs, outputs, or scaling factor of ceil(log2(i))?

<articmine> Just use the quadratic penalty formula for scaling and fees. No need to change the weights

<articmine> We can keep the linear weight approach and be stricter on node relay

<articmine> Which by the way prevents uneconomic transactions to mine as spam

<spirobel:kernal.eu> the goal is to disincentivize spam. How much would a high input transaction currently cost? is it really 10x cheaper after adding in the quadratic penalty? > <@kayabanerve:matrix.org> jberman: One 128-byte transaction is what, 10x cheaper 64 2-input TXs?

<articmine> Not at all

<kayabanerve:matrix.org> I'm concerned about annoying users, not malicious miners, primarily

<kayabanerve:matrix.org> Users who create large-input transactions create annoying transactions and are annoying users

<kayabanerve:matrix.org> @jberman:monero.social: Can you achieve consensus if you ignore me, or do you agree I raised a valid criticism?

<kayabanerve:matrix.org> I get I'm in a minority here and don't intend to be a blocker

<articmine> @kayabanerve:matrix.org: I am not so sure

<spirobel:kernal.eu> @kayabanerve:matrix.org: maybe the quadratic penality is also over complex. we could add a tx size limit that is reasonable and then just make a fee per inputs and outputs

<articmine> @spirobel:kernal.eu: It is not

<articmine> It actually solves a concern without adding complexity

<jberman> "Can you achieve consensus if you ignore me" -> I think probably. "do you agree I raised a valid criticism?" -> I think there's pros/cons to every approach. I think simple on this front is nice and has major pros (e.g. while yes, you can create more high input txs instead of creating many low input txs, this does also mean you're creating fewer outputs which will then go on chain with more proofs)

<articmine> @jberman: Actually using your proposal works for the issue that was raised

<articmine> We simply enforce the scaling requirements on large transactions

<jeffro256> @kayabanerve:matrix.org: I think you raise a valid criticism, but I'm not very worried about people creating compact, if heavy to verify, valid high-input TXs, as long as they are correctly subsidizing their marginal cost to block emission by being included in a block

<jeffro256> We pay FCMP CPU cost 1 time (0 if checkpointed), but pay cost of storage in perpetuity

<articmine> @jeffro256: At the point of the scaling penalty or before reaching the penalty?

<articmine> There is a big difference

<articmine> Or we compromise somewhere in between

<jeffro256> IMO There should be a minimal fee for spam prevention even when no penalty is applied, but a transaction should also pay for its marginal cost when the penalty is applied

<jeffro256> The minimal fee should factor in what the penalty would be if this transaction were to be included

<articmine> This is what we have

<articmine> The point of disagreement is on what size of the transaction are we enforcing this

<articmine> 1 in 2 out or 128 in 16 out?

<articmine> It is not the same fee per byte.

The fee rate is calculated from a reference size. If we calculate the scaling fee from the actual size, then a 150 KB transaction would need to pay 1/4 of the block reward in fees.

<articmine> correct

<rucknium> Ready to discuss stressnet?

<jeffro256> IMO We should enforce it for whatever weight a transaction is, there shouldn't be a "reference tx size". We should take expected sum total tx size in next block (including this tx) -> calculate penalty -> amortize fee across that set of txs

<articmine> ... but if people are concerned about the large transactions we can take a portion of the extra and enforce that

<articmine> @jeffro256: This does not work because of the game theory

<articmine> Between the miner and the user

<jeffro256> Why would a miner not want to increase their net reward?

<jeffro256> If my fee for my tx is greater than its marginal cost, a rational miner would include it, no?

<articmine> The miner included the highest paying transactions first before reaching the penalty

<jeffro256> Yes, I'm talking about minimum fees

<articmine> So there is always a profit for the miner over the penalty

<articmine> The minimum fees are based on the reference transaction size currently 3000 bytes

<articmine> For FCMP++ proposal is 10000 bytes

<articmine> Just larger than 2 in 2 out

It depends if we want to discourage 150 KB transactions. Nobody will pay a 0.15 XMR fee for it. It will be much cheaper to submit 64 2/2 transactions.

<articmine> There is an in-between

<jeffro256> Right, I'm saying that the minimum fee shouldn't be based on a reference transaction size when the size of an FCMP++ transaction can vary wildly. Actually calculating expected marginal penalty loss will give you a closer estimate to the tipping point where a miner will include a transaction in a block over A) assuming small re [... too long, see mrelay.p2pool.observer/e/gpKStsEKSXM5X2VO ]

<articmine> So you are now saying that the minimum fee per byte for a transaction should depend on the transaction weight?

<articmine> I have to leave in 4 minutes

<articmine> We can discuss this after the meeting

<jeffro256> @articmine: Ideally, yes, as it gives the closest approximation to whether a miner will include it or not.

<jeffro256> Fair enough, we can move to the next item.

(late and out of order) hi, implemented carrot/FCMP++ partial view-only functions and wallet for both legacy and new wallets on go p2pool code; plus confirmed a few parts of how it's preferable to work under p2pool after network upgrade; nothing else to add besides:

adding the regular reminder that P2Pool sweeps can be 100+ inputs for aggregate value of ~0.04 XMR total like on mini.p2pool.observer/transaction-lo…abdcc62bcc8351a96a035263a9bff69e903 so if fees are going to be this big, maybe monero-project/research-lab #108 can be discussed

at a later point

<rucknium> 6. Stressnet

I upgraded to v1.2 and it kept 12-9 peers all the time, before it was at most 3 if not disconnected. Running v1.3 now and looks happy

<jeffro256> Has anyone else observed any differences, positive or negative, with v1.3?

it has not OOM'd recently, neither did v1.2. I will test some p2pool mining with it to see if it improved submit_block -> ZMQ mining data wise

<jberman> Overall status report on stressnet: it's progressing well. We've identified and fixed some FCMP++ & Carrot integration bugs in every release, we've identified and fixed monerod issues in every release, and we've made improvements both to existing monerod/wallet code and to the integration in every release

<jberman> Actually all the integration bug fixes have been FCMP++ integration related, not Carrot

<rucknium> Any specific requests to stressnet node operators? tx volume has been low. Do you want it increased again?

<jberman> Update to v1.3 first and foremost. And then perhaps wait 24 hours for others to update too, and start ramping up the stress again

<jberman> v1.3 (and v1.2) patched and improved some connectivity issues, so it will be good to observe how nodes hold up with those changes

<jberman> tx relay v2 + avoiding re-validating txs will be the next major improvements that should result in much smoother operation under stress as well

<jberman> I think once we have no more observed integration bugs (maybe for a week?), and we see smooth perf with 300mb pool and 5mb blocks, we can move toward beta stressnet. But for now we're making progress with alpha and can continue with what we're doing

<rucknium> Congrats all around!

<rucknium> Anything more on stressnet?

<jberman> nothing from me

<jberman> a big thank you to participants :)

<rucknium> 7. Mining pool centralization: Temporary rolling DNS checkpoints, Share or Perish, and Lucky transactions.

<jberman> Share or Perish still seems the most promising solution to me and definitely worthy of continued research

Any updates about checkpoints?

work is still blocked on the monero bug

I haven't seen any updates on this since last week

Any qubic news?

Not much from them since last week, quiet on that front, not selfish mining. they sit at 1.3-1GH/s

some of their code is affected by the FourQ Circle library CVE due to lack of full verification of points on decoding

<rucknium> We can end the meeting here. Thanks everyone.

<syntheticbird> thanks

<spirobel:kernal.eu> tevador: it seems like no one is responsible

<spirobel:kernal.eu> I asked the last time and there was no answer

<spirobel:kernal.eu> about fixing the logic issue with the checkpointing rule

<spirobel:kernal.eu> vs longest chain rule

<spirobel:kernal.eu> maybe that is something that @kayabanerve:matrix.org could be interested in as it directly affects the code path that the finality layer would touch

<spirobel:kernal.eu> here is the related issue monero-project/monero #10075

<spirobel:kernal.eu> maybe we can still add this to the meeting notes @rucknium:monero.social so it does not get lost. it seems like it is an important topic. I am wondering why there is not more focus on this. I added some of the MRL conversation chat log from earlier to the end of the issue.

<jberman> I'm personally not interested in focusing on or prioritizing centralized solutions

<boog900> @hinto: Yeah sounds good to me

<boog900> Might be good to include something specific to the node so you can't reuse PoW across multiple nodes RPC

<boog900> Like the nodes address or something

<kayabanerve:matrix.org> Except I have no interest in writing C++ as I haven't for more than ~1 month in total over the past 8 years.

<jeffro256> C++ is so invigorating. Don't you love analyzing each mission-critical line for UB?

<kayabanerve:matrix.org> I spent a few years with Nim, which in hindsight was likely largely wasted.

<kayabanerve:matrix.org> Today, and for the past ~4 years, I've preferred Rust for the exceptionally strong type system which attempts to minimize UB.

<preland> @jeffro256: I like c++, but only when I don’t have to worry about my code actually mattering

<kayabanerve:matrix.org> In a parallel timeline, I only write Haskell and Ada however.

<kayabanerve:matrix.org> In another, Erlang

<articmine> This is actually also my preference since it avoids certain spam attacks based upon un economical for the miner transactions . We have to keep in mind that because of the discrete fee levels currently 4 this has to apply on for ranges of transactions. > <@jeffro256> Ideally, yes, as it gives the closest approximation to whether a miner will include it or not.

<articmine> The current approach has been to do this only for the most common transactions and "fly by the seat of our pants" for the large edge case.

<articmine> For a minimum penalty free zone ZM of 1000009 bytes, and a 1% scaling rate this means 10000 bytes, the reference transaction size.

<articmine> 10000 bytes.

<articmine> We can raise fees and increase the economic scaling level to 2% or 20000 bytes, which I am likely to recommend since I believe that this will attract consensus. This will take care of up to 8 inputs with the weight approximately following the size which seems to have at least loose consensus.

<articmine> At this point we move the conversation to node relay with:

<articmine> 1) Do nothing and "fly by the seat of our pants", the current approach

<articmine> 2) Enforce economic scaling with various levels of minimum node relay fees depending on the transaction weight range.[... more lines follow, see mrelay.p2pool.observer/e/2peSusEKMnpweUMz ]

<articmine> Personally I am neutral to leaning against the large input transactions, but I will support where the consensus ends up.

<jberman> @tevador @boog900:monero.social do either of you guys have thoughts on the proposal to use approximate byte size as tx weight?

<boog900> nope, I haven't really thought about fees at all

<boog900> beyond thinking current fees are too low, although ig that is a different topic to tx weights