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