<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