04:43:19 I have uploaded the updated transaction weight files Discussion and links are here: https://github.com/seraphis-migration/monero/issues/44 15:32:17 MRL meeting in this room in 1.5 hours. 16:40:49 @rucknium:monero.social: for the Helios-Selene topic, there's no need for discussion time on that during the meeting, though more discussion does need to happen there in general. I'll just post an update during the meeting and then you can continue with the other topics. Thanks! 16:43:51 https://gist.github.com/tevador/4524c2092178df08996487d4e272b096?permalink_comment_id=5772654#gistcomment-5772654 17:00:34 Meeting time! https://github.com/monero-project/meta/issues/1272 17:00:38 1. Greetings 17:00:48 Hi 17:00:56 Hello 17:00:59 Howdy 17:01:04 hullo 17:01:10 Hello 17:01:29 Here for moral support, have a great meeting! 17:01:40 Hi via IRC 17:02:04 waves 17:02:25 Hi 17:02:54 2. Updates. What is everyone working on? 17:04:11 me: completed PR refactoring wallet2 refresh for FCMP++, opened draft PR to persist dest addrs when updating wallet from pre-FCMP++ to FCMP++, opened draft PR for documentation on the FCMP++ integration, some small cleanup PR's, reviewed some of jeffro's PR's 17:04:14 hi: me: working on carrot/fcmp stuff mostly (and some bug fixes). Spent some time diving into curve-trees to figure out how lws was going to handle. likely going to “punt” and giveaway privacy details to monerod (at least for first cut) 17:04:38 the problem is potential memory usage in tree_cache and otherwise having to duplicate the db from monerod into lws 17:04:41 me: Analysis of respend behavior of outputs in invalidated txs after 18-block reorg: https://github.com/monero-project/monero/pull/10085#issuecomment-3313627068 . Rolling DNS checkpoints "formal" protocol as flowcharts (click arrows at bottom to see more flowcharts): https://cryptpad.disroot.org/diagram/#/2/diagram/view/yI43W1 [... too long, see https://mrelay.p2pool.observer/e/iYW6sbgKXzB4VEdJ ] 17:04:49 Me: Responding to the Veridise audit of Helios/Selene and working on a selfish mining mitigation proposal (work in progress). 17:05:00 Me: Wrote a Rust library for CARROT (https://github.com/jeffro256/carrot-rs) and finished reviewing https://github.com/seraphis-migration/monero/pull/81. Personally excited for alpha stressnet 17:05:04 supporting DNS checkpoints testing as needed, looking at ZMQ behavior during reorgs for p2pool mining specifically 17:06:15 Completed a new weight formula for transactions to address the issues with transaction weights and the penalty 17:06:24 DataHoarderdid you spot any other issues than the one in the pr? 17:07:22 believe it or not the PR one was not related, we found it by chance by testing subaddress payouts on P2Pool. 17:07:22 I have noticed that when switching to a shorter altchain (checkpointed one) ZMQ updates are not sent properly to P2Pool, or P2Pool ignores them 17:08:29 I cannot confirm yet if other block/chain ZMQ messages are sent when switching to a shorter chain, noticed it when mining with p2pool on testnet and the network reorg'd against my longer chain (monero switched chain, but p2pool was left behind, and I saw no logs of ZMQ message being received for miner data) 17:08:36 hmm this could theoretical happen if the zmq buffer was full, but that is unlikely 17:08:43 @jeffro256:monero.social: Would you have time to review a draft of the tx invalidation blog post, just to check correctness? Probably have the draft ready for review in 6-24 hours. 17:09:15 it's not a blocker (p2pool could workaround this) but I'll post in lounge about it if I can confirm the issue again with more logging in place 17:09:17 Yes! Send me a DM whenever 17:09:36 I mean correctness as "does Rucknium understand this technical point correctly?" 17:09:42 @jeffro256:monero.social: Thanks! 17:10:23 3. Carrot follow-up audit (https://gist.github.com/jeffro256/12f4fcc001058dd1f3fd7e81d6476deb). 17:11:41 I'm sorry for the delay, I brought up some input pretty late into the discussion; we're going back over some finer points of their report 17:11:47 Not much else to report 17:12:41 4. Proof-of-Work-Enabled Relay ("PoWER") (https://github.com/monero-project/research-lab/issues/133). 17:13:37 I updated the proposal to account for the latest discussion: 1) Equi-X (instead of RandomX), and 2) PoW once per connection, rather than per tx 17:14:11 FYI, Equi-X is about to be upgraded to v2 due to some issues with v1. 17:14:33 It's being coordinated with Tor. 17:14:59 (I received a dm for someone interested in taking on PoWER so I wanted to have the proposal reflect the latest state) 17:15:16 are the issues public? 17:15:27 Not public yet. 17:15:41 got it, thank you 17:16:03 By "taking on PoWER" do you mean someone who wanted to implement it (write the code)? 17:16:09 yes 17:18:46 I would think an Equi-X v2 would be a drop-in replacement for v1, and the vast majority of code implemented on the Monero side would be unchanged 17:18:58 Will we have to write a C++ implementation of Equi-X ourselves? 17:19:59 I assume it would be used as an external submodule same way RandomX is used today 17:20:08 I mean the core algorithm. Guess somebody wrote that already 17:20:26 Yes, EquiX v2 will have the same interface as v1. 17:20:49 tevador wrote it in C: https://github.com/tevador/equix 17:21:19 Ah yes, thanks. 17:21:20 @jeffro256:monero.social: you raised some pushback against PoW per connection, in case you want to re-raise that point 17:22:36 I will also raise pushback on this 17:23:07 what is your argument? 17:23:40 Yes, I think that A) PoW per connection is much more complicated, adding a lot of unnecessary technical debt to our connection code, and B) that PoW should be reusable per-tx 17:23:52 User POW can be very harmful in hot climates, mobile devices etc 17:24:40 so generate pow once, then it can be re-broadcast with same pow? > B) that PoW should be reusable per-tx 17:24:48 It is a myth that POW heat is irrelevant 17:24:49 It should be reusable per tx to enable transaction propagation to be faster with new node connections 17:25:05 DataHoarder: Yes 17:25:26 @jeffro256: I don't see the argument that this slows propagation 17:25:36 Still it can be a barrier 17:25:51 you don't make new connections on tx broadcasts you use existing connections 17:26:12 if anything needing to verify PoW on every hop would slow propagation 17:26:30 To minimize technical debt, it could be expected on first tx w/>8-inputs, and then the connection is verified for future txs. Would be a simple boolean per connection to keep track of 17:26:37 @boog900: For new connections. If PoW is reusable per-TX, then a node can flood the network with that TX instantly, whereas if PoW is done per-connection, then a node is "locked in" to its existing connections for TX propagation 17:27:14 Also PoW per-connection opens the door to DoS against honest broadcasters 17:27:38 @jeffro256: locked in in the sense that they need to do PoW to open more connections .... they still have their current connections tho 17:28:00 new connections aren't broadcasted to anyway 17:28:02 Yes 17:28:10 we only broadcast to current connections 17:28:36 I mean can the spam farm not be set up in some cold part of Canada or Russia? 17:28:46 If it's per tx, you have to deal with txs sitting in the pool longer than 10 blocks, which is arguably a significant area of technical debt that is likely more significant than a per-connection PoW 17:28:48 @boog900: New connections ask for mempool contents, which would also ostensibly be PoW enabled 17:28:58 I also don't really see the technical debt argument they are both added complexity 17:29:26 @jeffro256: only when finished syncing IIRC 17:29:59 You still have the 10 block problem with PoW-per-connection though? How is it avoided? 17:30:24 @boog900: Which is most nodes 17:30:25 @jeffro256: you don't need a timeout on the PoW? 17:30:52 @jeffro256: no I mean it only happens once a node syncs up not after 17:31:13 like a synced node doesn't just a node which has finished syncing 17:33:07 "User POW can be very harmful in hot climates, mobile devices etc" -> honest devices constructing the tx in the first place is expected to be more CPU/work intensive than the PoW calculation. the PoW calculation is to raise the cost for malicious users who craft invalid txs at no cost 17:33:23 @boog900: You do still need a "timeout" or at least bind the PoW to some provably recent random data or a "challenge", so an attacker can't build up PoW for connections 17:33:47 @jeffro256: yes but it is per connection .. you don't need to repeat it 17:34:05 with per tx after 10 blocks you can no longer send the tx to anyone 17:34:14 without doing the PoW yourself 17:34:20 ^ 17:34:59 Why would the PoW timeout for per-TX necessarily be 10 blocks? 17:35:21 That's how I had it in the original proposal 17:35:40 If it's a lot longer, then the attacker can collect PoW hashes for a longer period of time 17:35:54 @jeffro256: because you can compute loads in reserve and flood all at once 17:36:04 > <@jberman> "User POW can be very harmful in hot climates, mobile devices etc" -> honest devices constructing the tx in the first place is expected to be more CPU/work intensive than the PoW calculation. the PoW calculation is to raise the cost for malicious users who craft invalid txs at no cost 17:36:04 So the malicious user sets up the spam farm in some cold part of Canada. The malicious use uses the attack POW heat for space heating. There is no cost 17:36:29 @articmine: the cost is time 17:36:32 that's definitely added cost over 0 17:36:47 -40 = zero spam cost 17:37:00 they can't just send bytes they have to find a PoW solution to send it 17:37:07 better than no cost 17:37:57 -49 C or F 17:38:15 articmine: Not zero cost. They could be mining Monero instead of spamming. Opportunity cost. 17:38:25 At least, there is an opportunity cost of not mining Monero blocks. 17:39:00 https://github.com/monero-project/monero/blob/8d4c625713e3419573dfcc7119c8848f47cabbaa/src/cryptonote_protocol/cryptonote_protocol_handler.inl#L2442 17:39:05 It is not the same because the amount is so sma 17:39:09 Snall 17:39:13 @jeffro256:monero.social: do you see the argument in favor of per connection PoW? if not, I think we should table the discussion, and at least come to agreement that it makes sense for wallet API to allow specifying a max input so the other dev can start on this task? 17:39:22 @boog900: only once per run of monerod it seems 17:41:30 @jberman: I see the argument, I don't know if I'm entirely convinced, but yeah I can definitely start on that wallet API point 17:42:30 I think that may be a good task to pass over to the other dev, but your call, we can discuss later 17:43:06 Perhaps you can let the aforementioned dev working on per-connection first, and both if he/she has the time, and then we can compare what the actualized complexity is 17:43:28 that sgtm 17:43:51 Slightly related note: Have we considered having a special connection type for block relay only? Those would not need any PoW. Bitcoin has it. Low-end devices could then still connect to the network. 17:44:56 IIRC, by default bitcoin has 8 outbound connections for block + tx relay and 1-2 additional connections for block-only relay. 17:45:04 Now that is an interesting idea 17:45:26 The PoW per connection could be an optional thing done per connection, and if done, enables sending txs with >8 inputs over the connection 17:45:39 via tx relay 17:46:34 @jberman: This is how I imagined it, but there's still the issue of mempool fetching. Does that force the responder to upgrade the connection by doing PoW? 17:46:38 It is certainly better if it is done by the node 17:47:05 @jeffro256: seen as thats a response, no IMO 17:47:26 you can't exactly spam txs with that 17:47:47 But then that allows the responder to dump a load of invalid high-input txs to the requester 17:48:01 Ostensibly, the requester would try validating at least 1 17:48:30 @jeffro256: the node ignores the rest if any 1 is invalid 17:48:40 shouldn't be a DoS 17:50:08 Assuming you can't trigger a node to make that request with high frequency 17:50:40 @jeffro256: current code wont, we just need to keep it in mind for future changes 17:52:00 5. Transaction volume scaling parameters after FCMP hard fork (https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf). Revisit FCMP++ transaction weight funcion (https://github.com/seraphis-migration/monero/issues/44). 17:52:41 I will limit discussion of this item to 30 minutes maximum, unless there is an objection. 17:54:21 The major change is the overall weight applied to the transaction to mitigate the impact of the penalty. 17:54:21 The reasonable weights based number of inputs work very well 17:55:15 So we can easily have fees that are close to proportional to number of inputs or verification time 17:55:43 It is a major change in how WWE charge fees 17:56:23 So now the fee depends on the square of the weight 17:57:07 The next step is t get the size and verification times for all the peoofs 17:57:20 Any qt? 17:57:29 Questions? 17:58:41 I have the data for the membership proof weight formula already 17:59:20 So the proposed weights for this proof are in the latest proposal 17:59:57 Sorry, but at the moment, I NACK making the fee a non-linear function of the weight. That has the same effect as making the weight a function of the square of the number of inputs, which we previously agreed that the weight of the tx should be a linear function of the number of inputs 17:59:58 I included the SAL proofs as well in the latest update to that comment 18:00:50 The penalty is non linear 18:01:12 The end fee is linear with the number of inputs 18:02:16 Agreed on the penalty being non-linear. But the penalty isn't quadratic in the weight of 1 transaction, it is quadratic in the total size of all transactions in a block 18:03:03 The base fee-per-vbyte should be calculated as a square of the backlog IMO, not as a square of the 1 tx weight 18:03:08 That way scaling works it is quadratic on each transaction. That is the point 18:03:52 It amounts to the same thing 18:04:56 It doesn't amount to the same thing, especially when the penalty free zone isn't saturated. A 2-in tx should not cost 4x as a 1-in tx when the marginal penalty difference for both is 0. 18:04:58 The penalty for adding a transaction is quadratic with the TX weight 18:05:39 It doesn't cost 4x. It is linear 18:06:11 Because the weight goes as the square root 18:06:33 The latter is the point 18:06:40 The penalty is not quadratic in the single TX weight, its quadratic in the total TX weights for that block, which results in different calculations for individual txs based on on-chain activity 18:07:09 You mentioned that fee is a function of the square of the weight in your latest proposal, yes? 18:07:28 Iit is a simple formula for the additional penalty 18:07:47 Oh so you're proposing weight be a function of the square root of the number of inputs? 18:07:55 Correct 18:08:06 That is the point 18:08:17 Why that change? 18:08:59 Versus keeping both linear 18:09:02 So that after the quadratic penalty is applied you get linear with the number of inputs 18:09:52 You mean changing the penalty to linear 18:10:08 I looked at that 18:11:10 This works better because it incentivizes effective block construction by the miner 18:12:22 The penalty has never been linear 18:12:33 I meant weight function and fee function by "both", not changing the penalty function 18:12:54 It doesn't work 18:13:49 The quadratic penalty is in-between the weight function and the fee function 18:16:00 So apply square root weight, then quadratic penalty , then quadratic fee 18:16:12 Okay I think I see the fundamental disagreement. You believe that the marginal loss of block emission due to the penalty is a quadratic function of each transaction weight. I believe that the marginal loss of block emission due to the penalty is a quadratic function of the total transaction weights in a block. Is this a correct assessment? 18:16:55 Yes 18:17:21 It is the difference in penalty 18:17:29 That matters 18:18:18 Apply the penalty right at the start of scaling 18:18:19 What would it take to convince you that the marginal loss of block emission due to the penalty is a quadratic function of the total transaction weights in a block, and that the base fee-per-vbyte should be a quadratic function of that value, instead of being quadratic in the weight of one transaction? 18:18:43 @articmine: I disagree, this doesn't make sense for 99% of cases 18:18:56 It only works in the worst case 18:19:41 You have to look at the game theory of the interaction between miners and users 18:20:24 Assume enlightened best interest 18:21:36 So yes the worst case controls 18:23:35 So people should be paying fees 100% of the time as if they were pushing up the dynamic block size ? 18:24:02 Correct 18:24:23 This is a bad idea IMO. That means that there's no downwards price incentive for keeping the block small 18:24:30 The lowest fee pays the marginal penalty 18:24:42 People should be rewarded for not increasing the block size 18:25:37 @jeffro256: You mean rewarded for not using Monero? 18:27:19 For not making spam, yes. There is still a driving incentive for people to use Monero, which is its monetary and transactional utility over other currencies. But there needs to also be an incentive to not make unnecessary transactions 18:27:42 rucknium: It has been 30 minutes. 18:28:12 6. FCMP alpha stressnet planning (https://github.com/seraphis-migration/monero/issues/53#issuecomment-3053493262). 18:29:27 The blocker PR 81 has been accepted (thank you jeffro!), ofrn is now doing final testing with the latest state of that PR 18:30:11 Once I get a green light from ofrn, I'll make the PR setting alpha stressnet dates 18:30:34 (by setting hf blocks on testnet) 18:31:42 Thinking I'll write up a shareable post in that PR description, and we can share that post in the stressnet room, and reddit? 18:31:48 once the PR is accepted 18:32:35 And as per prior discussion, will target 7 days from the time of acceptance 18:32:47 That should do IMHO 18:33:47 Note: I think as of today, the default decision will be to release my tx spamming code as open source. That lowers the barrier a little for a malicious actor to spam mainnet, but all my CCS work is supposed to be published open source. If that default choice should change, it could be discussed. 18:34:56 7. Mining pool centralization: Temporary rolling DNS checkpoints (https://github.com/monero-project/monero/issues/10064), Publish or Perish (https://github.com/monero-project/research-lab/issues/144), and Lucky transactions (https://github.com/monero-project/research-lab/issues/145). 18:35:49 There is a bug that can occur in rare cases that will get a node stuck if it is enforcing DNS checkpoints. AFAIK, @0xfffc:monero.social and @ofrnxmr:monero.social are investigating it. 18:36:28 binaryFate has activated the checkpointer of testnet for the seven moneropulse domains: testpoints.moneropulse.xxx 18:36:54 @0xfffc:monero.social is trying to fix the logic that caused reorged checkpointed nodes to get stuck. Will test one more time with the moneropulse domains, and if i break that checkpointer again, we'll switch back to ruckniums domains to speed up the testing 18:37:25 s/one more time/until it breaks again/ 18:38:12 I tested DNS resolver latency (important for agreement between the 7 records of the 7 domains). My preliminary results say that there is good performance when one of several specified DNS resolvers are used. There are mixed results when a machine's own default DNS resolver is used. It is easy to change resolvers for monerod with a terminal environmental variable. 18:39:33 Do we have info about mining pools' willingness to turn on checkpoints? At least anything that can be shared publicly? 18:40:38 I created a set of flow charts that provides a "formal" specification of the rolling DNS checkpoint protocol: https://cryptpad.disroot.org/diagram/#/2/diagram/view/yI43W1RWom0yoODUJzvAB5vAc9X9ujFVAsxGAxgMMyE/embed/ 18:41:04 Click the arrows that appear at the bottom of the pages to go to the next page. 18:42:02 Once everything is finalized, there will be this flowchart and a narrative. And I hope some FAQs, too. The protocol helps users understand the proposal and how exactly it works. 18:42:36 Anything more on temporary rolling DNS checkpoints, specifically? 18:43:59 I already enabled dns checkpoints on my node, even though not active yet. Just to note, I got 18:43:59 [RPC0] ERROR cn src/cryptonote_core/cryptonote_core.cpp:1262 Transaction not found in pool 18:43:59 quite regularly afterwards.. I don't think this was the case before 18:44:15