17:02:25 <br-m> <jberman> @rucknium:monero.social available?
17:03:05 <rbrunner> I couldn't see the usual "meeting in 1 hour" announcement ...
17:03:54 <br-m> <jberman> Hm, and he didn't make the usual Meeting issue: https://github.com/monero-project/meta/issues
17:04:37 <br-m> <jberman> Hope Ruck is alright
17:04:53 <rbrunner> Yeah, pretty unusual
17:05:07 <br-m> <sgp_> Hopefully they are okay
17:05:16 <br-m> <jberman> rbrunner: do you want to lead a meeting w/same topics from last week?
17:05:35 <br-m> <kayabanerve:matrix.org> 😱
17:05:39 <rbrunner> Hmm, maybe you are a better moderator here?
17:05:43 <br-m> <kayabanerve:matrix.org> They did thumbs up my message from a few days ago, IIRC.
17:05:55 <br-m> <mayhem69:matrix.org> I had DMs with them yesterday around this time so I can confirm they were alive then
17:06:21 <br-m> <kayabanerve:matrix.org> Or actively impersonated around then
17:06:45 <br-m> <kayabanerve:matrix.org> Has anyone asked Mr. Plum if they were in the Library last night?
17:06:50 <br-m> <jberman> Sure, I'll moderate
17:06:53 <br-m> <jberman> 1. Greetings
17:07:01 <br-m> <articmine> Hi
17:07:03 <rbrunner> Thanks!
17:07:03 <br-m> <sgp_> hello
17:07:06 <br-m> <kayabanerve:matrix.org> 👋
17:07:13 <br-m> <rucknium> Hi. Sorry I'm late.
17:07:16 <br-m> <spirobel:kernal.eu> hi
17:07:28 <rbrunner> Last week's topic list: https://github.com/monero-project/meta/issues/1281
17:07:32 <br-m> <hinto> hello
17:07:38 <br-m> <kayabanerve:matrix.org> Rucknium and/or impersonater!
17:07:58 <br-m> <rucknium> I can PGP sign if you require
17:08:18 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:08:30 <br-m> <syntheticbird> hi
17:08:52 <br-m> <kayabanerve:matrix.org> Returned from a conference, oxide, book, Serai, trying to merge the first FCMP++ lib into oxide and oxide's BBP.
17:10:14 <br-m> <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
17:10:47 <br-m> <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)
17:11:27 <br-m> <rucknium> me: Increased CPU and RAM efficiency of monerod-monitor http://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.
17:12:55 <br-m> <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
17:13:11 <br-m> <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?
17:13:35 <br-m> <kayabanerve:matrix.org> A month and a half ago.
17:14:01 <br-m> <vtnerd> The readme for lws contains url/path info for docker
17:14:01 <br-m> <articmine> I am reviewing the proposed weights based upon roughly total transaction size  and it can be the basis for a solution 
17:14:21 <br-m> <sgp_> 12 interesting reports is pretty good
17:14:48 <br-m> <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.
17:15:03 <br-m> <syntheticbird> how much of the interesting reports were powered by ✨️Web 4.0 Quantum AGI ✨️
17:16:08 <br-m> <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).
17:16:21 <tevador> Me: post-quantum Jamtis, research phase/feasibility study
17:16:29 <br-m> <kayabanerve:matrix.org> @syntheticbird:monero.social: what's 166 - 12 or so
17:17:21 <br-m> <rucknium> 3. Security proofs for GBP
17:17:36 <br-m> <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 https://mrelay.p2pool.observer/e/pM-xs8EKVTNZYTFW ]
17:17:44 <br-m> <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.
17:19:56 <br-m> <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.
17:20:57 <br-m> <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
17:24:05 <br-m> <kayabanerve:matrix.org> @jberman:monero.social: Thoughts?
17:24:20 <br-m> <jberman> all sgtm
17:25:00 <br-m> <sgp_> did CS provide an ETA on delivery for this? is this something that they can work on in the immediate term?
17:25:11 <br-m> <kayabanerve:matrix.org> I think the amount is incredibly low, especially given it directly coves the code
17:25:25 <br-m> <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 https://mrelay.p2pool.observer/e/-p3Os8EKUzdIdm5v ]
17:25:25 <br-m> <jberman> This original post got 7 thumbs up, so seems it has good support
17:25:28 <br-m> <kayabanerve:matrix.org> Should only be a week or two, I believe, but I'd have to check
17:25:39 <br-m> <kayabanerve:matrix.org> *the code in relation to the protocol. I don't present it as an audit of the rust
17:26:29 <br-m> <jberman> I guess 1 q, would we maybe want zksecurity to start on divisors sooner and not be blocked?
17:26:52 <br-m> <kayabanerve:matrix.org> I don't think this will take so long to complete it's posited as a blocker
17:28:38 <br-m> <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
17:28:52 <br-m> <rucknium> Can you explain more what the 0 and 1 indexing issue is about?
17:28:59 <br-m> <rucknium> Juts informational
17:29:04 <br-m> <rucknium> just*
17:29:43 <br-m> <kayabanerve:matrix.org> There's a list of commitments to a polynomial, where the polynomial is indexed from 0.
17:29:55 <br-m> <rucknium> I know what 0 and 1 indexing is, but how does it affect the work here?
17:30:00 <br-m> <kayabanerve:matrix.org> The original BP protocol committed commuting to 0th coefficient because it was 0 and inherent.
17:30:26 <br-m> <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.
17:30:45 <br-m> <kayabanerve:matrix.org> I knew that and explicitly made that change, and immediately answered when Goodell asked about it.
17:31:00 <br-m> <kayabanerve:matrix.org> I just don't know why I knew that, as apparently that wasn't reflected in the formalizations 🤔
17:31:09 <br-m> <kayabanerve:matrix.org> Presumably a DM with Aaron
17:31:35 <br-m> <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?
17:32:01 <br-m> <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)
17:32:12 <br-m> <rucknium> Not the first confusion with 0 and 1 index. And won't be the last (in the world).
17:32:15 <br-m> <kayabanerve:matrix.org> *omitted commuting to the 0th coefficient
17:32:24 <br-m> <kayabanerve:matrix.org> **omitted committing
17:32:32 <br-m> <kayabanerve:matrix.org> I'm so sorry, autocorrect 😅
17:33:04 <br-m> <kayabanerve:matrix.org> Yeah, the formalization just updates communicate 1 to end to 0 to end. The proofs... bla bla bla
17:33:18 <br-m> <rucknium> Is action needed at this meeting, or are you still working out the work scope and quote?
17:33:55 <br-m> <kayabanerve:matrix.org> Approval, it's a request from the research fund was has MRL oversight
17:33:58 <br-m> <kayabanerve:matrix.org> *which has
17:34:50 <br-m> <rucknium> Any more questions from anyone here about the quote and scope of work?
17:35:55 <br-m> <rucknium> Any more discussion or any objections to the quote and scope of work?
17:36:14 <br-m> <jberman> I support
17:36:31 <rbrunner> Sound good, yes
17:36:37 <br-m> <rucknium> It sounds good to me.
17:36:58 <rbrunner> Such 0-1 stuff can be tricky
17:39:20 <br-m> <rucknium> I see loose consensus in favor of expending 8000 USD equivalent for Cypher Stack's work on security proofs for Generalized Bulletproofs.
17:39:57 <br-m> <kayabanerve:matrix.org> Thank you!
17:40:15 <br-m> <rucknium> 3. Proof-of-Work-Enabled Relay ("PoWER"). https://github.com/monero-project/research-lab/issues/133
17:40:34 <br-m> <hinto> I noted a point from the last meeting: https://github.com/monero-project/research-lab/issues/133#issuecomment-3423958055
17:40:34 <br-m> <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.
17:41:08 <br-m> <kayabanerve:matrix.org> @rucknium:monero.social: that is #4
17:43:54 <br-m> <jberman> > PoW per connection for P2P/ZMQ and PoW per TX for RPC
17:43:54 <br-m> <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
17:44:08 <br-m> <rucknium> @kayabanerve:matrix.org: If the agenda items are indexed from 0, then it's item 3 :P
17:44:36 <br-m> <kayabanerve:matrix.org> Except GBPs also had 3 :p
17:45:32 <br-m> <jberman> PoW per tx for RPC shouldn't have the issue of expiring PoW that needs to be updated
17:46:38 <br-m> <hinto> Yup, just a required PoW field added to existing TX relay endpoints
17:46:59 <br-m> <jberman> Could probably just use the most recent block hash too?
17:47:56 <br-m> <jberman> allowing a window of 2 blocks
17:48:43 <rbrunner> Almost sounds a little than the "pay with hashes" system of yesteryears, from moneromooo ...
17:49:01 <rbrunner> *a little like
17:49:17 <br-m> <hinto> Ok, seems similar to the original proposal, I think we could figure out those details in the PR
17:50:31 <br-m> <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)
17:51:36 <br-m> <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
17:52:22 <br-m> <jeffro256> Sounds good to me 
17:53:20 <br-m> <articmine> Sounds fine to me 
17:55:01 <br-m> <rucknium> 5. Transaction volume scaling parameters after FCMP hard fork. Revisit FCMP++ transaction weight function. https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf  https://github.com/seraphis-migration/monero/issues/44
17:55:05 <br-m> <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 :)
17:55:22 <br-m> <jberman> nice
17:55:59 <br-m> <jberman> Repeating from an earlier message:
17:56:08 <br-m> <jberman> Here is a simple proposal to make tx weight roughly equal to byte size with justification: https://github.com/seraphis-migration/monero/issues/44#issuecomment-3423391977
17:56:16 <br-m> <jberman> Of note, you can still calculate tx weight in an offline context with just n inputs, n outputs, and extra length.
17:56:17 <br-m> <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
17:57:20 <br-m> <articmine> I believe that this is a viable approach. We are setting fixed weights for the whole transaction except for TX extre
17:57:29 <br-m> <articmine> Extra
17:58:01 <br-m> <jeffro256> Tx extra should be included in the byte size / weight calculation AFAIK 
17:58:32 <br-m> <jeffro256> There would be 3 paramaters to weight calculation: # ins, # outs, # extra bytes
17:58:33 <br-m> <articmine> Of course, but not in the fixed weight
17:59:40 <br-m> <jeffro256> What do you mean by "fixed weight"?
17:59:43 <br-m> <articmine> Extra bytes being TX extrea
18:00:34 <br-m> <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
18:00:52 <br-m> <jberman> (meant to tag @kayabanerve:matrix.org )
18:01:40 <br-m> <articmine> The one concern I have heard here is people stuffing data into various parts of the TX
18:02:52 <br-m> <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 
18:03:41 <br-m> <articmine> Then this should be fine. 
18:04:17 <br-m> <articmine> As for the fixed 7 layers that is a must for scaling 
18:05:39 <br-m> <articmine> Are there any objections to this approach 
18:06:31 <br-m> <jeffro256> I support weight appriox eq to byte size approach 
18:06:57 <br-m> <spirobel:kernal.eu> +1 
18:07:01 <br-m> <spirobel:kernal.eu> kiss 
18:08:09 <br-m> <spirobel:kernal.eu> this is a much better approach. The complexity seemed to get out of hand before 
18:08:34 <br-m> <kayabanerve:matrix.org> I explicitly don't as it encourages large-input TXs, they aren't even equally considered.
18:09:06 <br-m> <kayabanerve:matrix.org> But I agree it should be a formula solely derivative of inputs, outputs, and extra length.
18:10:14 <br-m> <articmine> @kayabanerve:matrix.org: My take is that the quadratic penalty will penalize large transactions at node relay.
18:10:30 <br-m> <kayabanerve:matrix.org> Sorry, which quadratic penalty is this?
18:10:51 <br-m> <kayabanerve:matrix.org> I stepped away for a moment and only returned to the proposition roughly equal to byte size.
18:10:53 <br-m> <articmine> Block weight scalung
18:11:15 <br-m> <kayabanerve:matrix.org> That seems indirectly relevant to the TX fees users pay at best 
18:11:44 <br-m> <articmine> Penalty to increase the block weight above the short term median 
18:11:51 <br-m> <kayabanerve:matrix.org> I'd support a flat cost for the next power of two for inputs, outputs, before corresponding to bytes fwiw
18:12:48 <br-m> <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.
18:13:01 <br-m> <articmine> @kayabanerve:matrix.org: I am actually supported of that
18:13:16 <br-m> <articmine> It is easy to implement 
18:13:34 <br-m> <kayabanerve:matrix.org> jberman: One 128-byte transaction is what, 10x cheaper 64 2-input TXs?
18:13:59 <br-m> <kayabanerve:matrix.org> *one 128-inout transaction
18:14:05 <br-m> <kayabanerve:matrix.org> *cheaper than
18:14:21 <br-m> <kayabanerve:matrix.org> Sorry, I'm a bit distracted by a saucepan boiling over right now...
18:14:45 <rbrunner> Put a range proof on it
18:14:48 <br-m> <articmine> I do not see how > <@kayabanerve:matrix.org> jberman: One 128-byte transaction is what, 10x cheaper 64 2-input TXs?
18:15:21 <rbrunner> Simply by being 10 times less bytes, presumably?
18:15:25 <br-m> <jberman> 64-2 is 78132 bytes, 128-2 is 150133 bytes. 2x 64-2 = 156624
18:15:57 <br-m> <kayabanerve:matrix.org> @jberman:monero.social: 64x2 though
18:16:21 <br-m> <jberman> oh misread
18:16:45 <br-m> <kayabanerve:matrix.org> Isn't it ~500k bytes, so that case, 3x 128-inputs, despite having significantly better computational performance?
18:17:37 <br-m> <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.
18:17:38 <br-m> <jberman> ya ~500k bytes for 64x 2-in/2-out, versus ~150k bytes for 128-in/2-out 
18:17:54 <br-m> <kayabanerve:matrix.org> I don't like that :C
18:18:15 <br-m> <kayabanerve:matrix.org> You can introduce a log2(i) scaling factor so 128 has a 7x though, while 2-in is 1x
18:18:19 <br-m> <jberman> That creates 126 more outputs that are going to be spent in FCMP++ proofs...
18:18:21 <rbrunner> Even if taking PoWER into account?
18:19:00 <br-m> <kayabanerve:matrix.org> And those 126 outputs are reflective of ~300 FCMP inputs? Because that how it corresponds to 128-2
18:19:19 <br-m> <kayabanerve:matrix.org> *ceil(log2(i))
18:19:36 <br-m> <jberman> I don't follow
18:20:16 <br-m> <kayabanerve:matrix.org> You noted 126 more outputs, for a difference in weight of 350kb.
18:20:25 <br-m> <articmine> @kayabanerve:matrix.org: So if I understand this correctly you would want the 128-2; to pay a higher fee
18:20:28 <br-m> <kayabanerve:matrix.org> In those 350kb, I could fit 2.33x 128-2 TXs.
18:20:56 <br-m> <kayabanerve:matrix.org> That's approximately 300-5 being treated equivalent to 0-126 w.r.t. weight
18:21:59 <br-m> <articmine> Enforcement of the scaling requirements at node relay, my original proposal would take care of that
18:22:56 <br-m> <jberman> Ok I see your point. Trying to identify a path to rough consensus here
18:23:28 <br-m> <kayabanerve:matrix.org> Linear cost to inputs, outputs, or scaling factor of ceil(log2(i))?
18:24:26 <br-m> <articmine> Just use the quadratic penalty formula for scaling and fees. No need to change the weights 
18:25:19 <br-m> <articmine> We can keep the linear weight approach and be stricter on node relay
18:26:30 <br-m> <articmine> Which by the way prevents uneconomic transactions to mine as spam
18:28:02 <br-m> <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?
18:28:25 <br-m> <articmine> Not at all 
18:29:18 <br-m> <kayabanerve:matrix.org> I'm concerned about annoying users, not malicious miners, primarily
18:29:41 <br-m> <kayabanerve:matrix.org> Users who create large-input transactions create annoying transactions and are annoying users
18:30:15 <br-m> <kayabanerve:matrix.org> @jberman:monero.social: Can you achieve consensus if you ignore me, or do you agree I raised a valid criticism?
18:30:26 <br-m> <kayabanerve:matrix.org> I get I'm in a minority here and don't intend to be a blocker
18:30:46 <br-m> <articmine> @kayabanerve:matrix.org: I am not so sure
18:31:22 <br-m> <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 
18:31:49 <br-m> <articmine> @spirobel:kernal.eu: It is not
18:33:11 <br-m> <articmine> It actually solves a concern without adding complexity 
18:33:21 <br-m> <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)
18:34:17 <br-m> <articmine> @jberman: Actually using your proposal works for the issue that was raised
18:34:47 <br-m> <articmine> We simply enforce the scaling requirements on large transactions 
18:35:13 <br-m> <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 
18:36:07 <br-m> <jeffro256> We pay FCMP CPU cost 1 time (0 if checkpointed), but pay cost of storage in perpetuity 
18:36:40 <br-m> <articmine> @jeffro256: At the point of the scaling penalty or before reaching the penalty?
18:36:50 <br-m> <articmine> There is a big difference 
18:37:17 <br-m> <articmine> Or we compromise somewhere in between 
18:40:06 <br-m> <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 
18:40:40 <br-m> <jeffro256> The minimal fee should factor in what the penalty would be if this transaction were to be included
18:40:49 <br-m> <articmine> This is what we have