04:00:11 Is cutting the block times in half really necessary under PoP? I feel like if you develop a significant enough lead either way most likely already have enough HR to do a 51% attack. 07:36:11 And is there a more fleshed out update on the finalty layer? 07:42:10 Like will it at the very least have slashing for example 08:12:24 <0xfffc> https://github.com/monero-project/monero/pull/9933#issuecomment-3273821910 11:29:22 @0xfffc: great! 12:57:22 the CSV list with orphans, https://irc.gammaspectra.live/2990a5684cf1c5a5/qubic-blocks-epoch177.csv 12:57:22 If trying to filter for the area of interest that @rucknium:monero.social looked at, filter by address for 176 it being 49heVqhSznN9eoatkooNJLHHsRV6XiitDeW4J92cgney8BFfuacZGmzSA3fRKEHooC7X9xzCP9VXN6uK7XrpoXF35FXfQCP 14:48:18 DataHoarder: Thank you. I created the "Paths to majority hashpower" plots for this newest data (Qubic epoch 177): https://gist.github.com/Rucknium/fb9a02fbd89c8d93e0d9f48fbc470e05 15:03:12 No table? :) 15:03:26 MRL meeting in this room in two hours 15:04:47 DataHoarder: What were the marathon times for epoch 177? 15:05:24 Wed 03 12:00 UTC to Wed 10 12:00 UTC 15:05:27 oh 15:05:35 Same as every epoch 15:06:25 Same days of the week, every week? Alright. 15:06:51 So Thu 04 12:00 to Fri 05 12:00, then Sat 06 12:00 to Sun 07 12:00, then Mon 08 12:00 to Tue 09 12:00 15:07:03 Yeah. It's hardcoded in their qubic node code 15:07:41 The variable mining depends on their ticks, but the marathon is hardcoded to switch at tick switch edge, dependent on local time 15:11:54 DataHoarder: Done 15:20:03 Not local time, UTC time. But yes, it can be affected by an incorrectly set local clock 17:00:18 Meeting time! https://github.com/monero-project/meta/issues/1266 17:00:26 1. Greetings 17:00:30 waves 17:00:33 Hi 17:00:38 <0xfffc> Hi everyone. My apologies. I will absent from today’s meeting, have to take care of a personal business. 17:00:38 <0xfffc> 9933 is ready. 17:00:58 Hi 17:01:27 Hi from IRC 17:01:41 Hello 17:01:50 Hi 17:01:52 Howdy 17:02:15 hi (its gingeropolous) 17:02:16

Hi 17:02:51 2. Updates. What is everyone working on? 17:03:52 me: continuing on PR 81 wallet2 FCMP++ refresh refactor updating for jeffro's review comments (PR update incoming today), implemented multithreaded FCMP++ batch verification in the daemon (for txs in a single block), then planning to debug an FCMP++ consensus bug both jeffro and ofrn encountered after the recent round of changes 17:04:14 Me: reviewed @j-berman's seraphis-migration PR #81 and am working on reorg handling fixes for multisig wallets on upstream. Hopefully improves UX in Haveno 17:04:36 Me: knocked out some lws+lwsf bugs, still have to fix auto fee in lwsf. Otherwise been working on carrot in lws, and luckily little changed in the libs such that fcmp++ branch is already compiled and linked into lws. Much work to do with carrot though 17:04:36 monerosim - got monero's native p2p discovery working on a simulated internet, txs relaying, can run xmrchain after a sim and browse the blockchain. ramping up to that 1k node mark. 17:04:49 me: Empirical analysis of risks of rolling DNS checkpoints ("Paths to majority hashpower": https://github.com/monero-project/monero/issues/10064 and https://gist.github.com/Rucknium/fb9a02fbd89c8d93e0d9f48fbc470e05 ). Working on a transaction spamming library for stressnet. 17:05:07 I am working on oprions for the fee scaling and addition of the sanity median. Should have something by the end of this week. Also reviewing POS attacks especially related to cost of capital Also preparing for a talk this Friday. 17:05:41 Hit 40mb blocks on an fcmp testnet 17:06:36 I announced monero-oxide and the $100,000 bug bounty for it, and the Monero FCMP++ testnet will use the monero-oxide repository for the FCMP++ libraries 🎉 17:07:26 (advertisement for people to come take Power Up Privacy's money by breaking monero-oxide) 17:07:46 kayabanerve: Have a link? 17:08:05 @kayabanerve:matrix.org: (repeating from NWLB, this means tx construction time for large input txs will have the latest faster impl, where higher n inputs takes n times as long to construct) 17:09:19 rbrunner: To monero-oxide or the $$$? 17:09:31 3. Carrot follow-up audit (https://gist.github.com/jeffro256/12f4fcc001058dd1f3fd7e81d6476deb). 17:09:33 Why not both? :) 17:10:13 https://github.com/monero-oxide/monero-oxide 17:10:13 https://immunefi.com/bounty/monero-oxide 17:10:33 Thanks! 17:11:43 Not much to report about the Carrot follow-up audit, Cypherstack hasn't responded last week 17:12:05 Will probably ping them in the next couple days 17:12:33 I believe the plan is a response later today, but let me verify 17:13:00 Awesome, thanks a lot @freeman:cypherstack.com! 17:13:29 4. Transaction volume scaling parameters after FCMP hard fork (https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf). 17:13:49 If no objection, I will limit discussion of this item to 30 minutes. 17:14:39 I expect to have options for this later this week based upon keeping the minimum penalty block weight at 1 MB 17:15:48 Going to raise this point I raised in NWLB again: voicing my own support for ArticMine 's latest fee proposal to scale fee by tx byte size alone without considering verification time, considering tx size as a whole actually does increase a significant amount as n inputs increases beyond just membership proofs size 17:16:23 I should point out that large transactions are a problem. for example 50% of the ZM we are looking at 25% of the block reward to scale and 50% if they are competing with smaller transaction in the same fee tier 17:17:51 I would argue that we should charge by input count instead of byte size, which (to end user) makes 1 inout vs 128 input scale linearly, but to node runners / miners, it means higher per-byte fee for higher input txs 17:18:02 We can to a degree factor in verification time, but the reality is that when transactions are over 4% of ZM thinng do start to break down 17:18:36 The penalty does not see number of inputs it only see weight 17:18:47 @kayabanerve:monero.social raised objection to this in favor of instead implementing an approach that incentives multiple lower input over single high input txs (with the underlying goal being to nudge the ecosystem toward low input uniform txs), and stated satisfaction with no incentive either way toward low input or high input (i.e. perfectly linear weight increase) 17:18:57 Ultimatly the penalty drives fees 17:19:24 ArticMine: Yes miners only care about weight, but weight can defined however we want it to be 17:19:30 Yes this is an option 17:19:46 for example incentivzing up to 8 inputs 17:20:27 Incentivizing chain bloat doesnt make sense to me. 17:20:34 It is the 32+ inputs that start to be a problem 17:21:28 The idea is to incentivise wallet maintenance with say 4 inputs etc. It is something I support 17:21:41 its not something i support at all 17:21:45 From the perspective of minimizing chain size and verification time, 32+ input txs are strictly better than 4+ 8-input txs 17:21:58 I can only reach 40mb blicks easily by abusing 2input txs 17:22:02 ArticMine: is this 4% of Zm figure coming from the fact that it starts to be very profitable to start solving the discrete optimization problem for transaction inclusion versus approximating it? > We can to a degree factor in verification time, but the reality is that when transactions are over 4% of ZM thinng do start to break down 17:22:12 Shure but they simple do not scale 17:22:34 Yes that is part of it 17:23:06 incentives to force merchants, exchanges, or users to make excessivelt large txs makes no sense to me 17:23:19 What is the other part? 17:24:14 If i can send 128input tx at say, 1.5kb per input, why should i be forced to split that up into 2.5+ kb/input? thats just bloat for no reason. Sure it charges more money, but its huge 17:24:31 but even simple approximations to optimize discrete optimization problem come in. Fore example priortizing small transaction wtihin a fee tier 17:24:47 You can charge more per-byte for large input txs by "simply" charging "static" fees per input 17:25:33 If we set a fixed weight for the proofs that is what we are doing 17:25:55 We need that anyway for FCMP+ 17:26:26 I mean 128 input tx can be an attack vector 17:26:28 Has anyone stated an explicit objection toward linear increasing weight (i.e. 128 input has ~128x the weight of 1-input)? 17:27:05 I prefer that at the moment 17:27:31 Seems the approach that's most likely to get consensus imo 17:27:50 You want to apply this to the membership proof? 17:28:07 It can be done 17:29:05 It probably makes more sense to be applied toward tx weight as a whole, because tx weight overall is where incentives apply 17:29:42 ... but we still have to pay the higher fee rate at least above 8in 17:29:54 we have to deal with the penalty 17:30:11 I disagree with a 1MB penalty free zone. That's unnecessarily large. 17:30:27 I say b/c of all the battling interests and opinions, we go with the simplest reasonable weighting system (linear wrt input count roughly following byte count). 17:30:33 There is a lot of evidence it is not 17:30:48 Starting with fees vs adoption 17:31:17 if we increase the tx wieght by a factor of 4 we need to increase the penalty free zone 17:31:33 it actually shoud be 1.2 MB 17:31:57 Before bulletproofs, we had much larger transactions and a much smaller penalty free zone. 17:32:00 I still don't understand why, though 17:32:19 ... and adoption was lover by a factor of 5 17:32:38 on chain adoption 17:33:01 That's what the dynamic scaling is for. 17:33:26 A large penalty free zone invites spam. 17:33:31 No if you start with very hign fees that merket just walks away 17:33:51 Why does a 4x increase in transaction weight necessitate a ~3.33x increase in the minimum penalty free zone? The median transaction size will still be significantly smaller than the minimum penalty free zone 17:34:42 ArticMine: You said last meeting that you would also want an increase in fees 17:34:45 https://bitinfocharts.com/comparison/monero-transactions.html#log&alltime Just take a look at the evidence 17:34:52 Last meeting I calculated a tx fee of $0.03 with a penalty free zone of 600KB. That's not very high. 17:35:29 Actually at the height of the recnet bul market is is highe 17:35:38 and transaction barely scale 17:36:14 and how many txs fit in 600 kb? 17:36:27 That is not the point. 17:36:44 it is the fee that have to be paid to scale 17:36:51 ~80 17:37:04 We can adjust the long term median at hardfork to match the historic tx volume with the new reference tx size. 17:37:06 but we avg abt 40tx/block atm 17:37:17 95 1-in/2-out, if going purely off raw byte size 17:37:25 as it is we are barely able to scale and there was an attack recently to prove that 17:38:22 barely able to scale as in the dynamic blocksize didn't kick in? 17:38:35 Wen we kept ZM at 300000 bytes after bulletproofs adoption increased by a factor of 5x 17:39:07 I fail to see the causal connection. 17:39:13 correlation is not causation. 17:39:24 I mean Please take a look at the blocksize evidence 17:39:31 it is not casual 17:39:52 there is also evidence of a small drop in adoption after the last fee increase 17:40:11 The blocks didnt grow during the spam attack due to the auto-fee not using the "normal" fee tier 17:40:55 Which means that the minimalistc fee calculated at 600000 ZM does not work 17:41:11 the unimportant fee tier (afaik) isnt supposed to trigger scaling 17:41:12 Look at what happened to zcash with their generouly low fee policy. 17:41:36 Zcash is totaly broken. Monero is not 17:41:47 We have tight pricing 17:41:56 I think it simply means that it was a bug in the wallet, not a protocol issue. It does matter what dynamic sizing policy we have in place if wallet2 screws it up lol 17:42:26 If "drop in adoption" means "less spam", then I take it as a success. 17:42:40 That was part of it. the bug was that the wallent did not incentivse an increase in fees 17:43:33 not is not less spam is is real adoption. this is acompetiive market 17:43:38 Yes, that's another issues. AFAIK wallet2 does not look into the tx pool at all when estimating the required fee. 17:43:52 it does @tevador 17:44:02 It is very much related 17:44:09 IMO, we can keep tight pricing by not increasing the minimum penalty free zone, while always still allowing it to scale if people are willing to pay the fees to offset block reward. I don't really care if fewer people are putting <1 US cent microtransactions on the L1 b/c the fee is now 3 cents 17:44:19 It checks if there is > 0 blocks backlog, or if recent blocks are >80% of the penalty free zone 17:44:51 It is more like 0.10 USD minimum 17:45:02 It should also take into account the fees in the tx pool. 17:45:27 In fact if we want to increase fees increasing the scaling rate to 2 % is a uch better way to go 17:45:32 If there was a backlog e.g. at the high fee level, it makes no sense to send a tx with the a normal priority fee. 17:45:49 it does @tevador, thats how it calc the backloh 17:45:52 People do this 17:46:32 OK, then the dynamic scaling should be able to kick in when needed. 17:47:03 30 minutes have elapsed since discussion started on this item. It will be discussed next week. Moving to next agenda item: 17:47:08 5. FCMP alpha stressnet planning (https://github.com/seraphis-migration/monero/issues/53#issuecomment-3053493262). 17:47:36 In any case I am not supporting less that 1 MB for ZM 17:47:48 there simly is not the case for this 17:47:48 Fcmp repo is a bit broken right now, so probably after its fixed :P 17:48:22 As jberman noted in his opening statement 17:49:03 I learned in Monday's meeting that PR #81 is a quite complex affair 17:49:04 Re: alpha stressnet. Aiming to get 81 in today, then will debug the current consensus failure. Considering the scope of current changes, once 81 is in and bug is solved, I would feel more comfortable with giving ofrn a couple more days to continue on his stressnet, to make sure everything is smooth on top of that latest state 17:49:26 Sorry, wrt 81, I'm aiming to have it ready for jeffro's review today* 17:50:41 81 has become a bit of a beast, and we'll want to be sure it's totally smooth before rolling out the stressnet 17:52:29 One bright side to this is that the functional tests have been beefed up quite a bit for wallet sync testing 17:53:14 @ofrnxmr:monero.social and I are working on separate transaction spamming codebases. It's sort of redundant work, but it helps exercise different code paths in the node and wallet especially. 17:53:48 @rucknium:monero.social i'm using wallet-rpc with 30 wallets and can definitely not produce >5mb blocks within 2mins 17:54:19 at best, i think i can produce about 2mb per min 17:54:31 My dev & testing has been with ordinary RingCT testnet so far. 17:55:36 It could be useful to spread the spammers to even more machines. Last stressnet last year, some participants were asking how they could do their own spamming. At that time, the answer was "write your own spammer". 17:55:37 http://stressgguj7ugyxtqe7czeoelobeb3cnyhltooueuae2t3avd5ynepid.onion/block?id=4592 17:56:10 (block explorer for my stressnet) 17:56:23 I took what I wrote last year and I'm making it more production-ready. Handling crashes & restarts, etc. That way, ordinary users could potentially use it. 17:56:58 Or, at least, there will be less manual management if I'm the only one using it. 17:57:30 Anything more on stressnet? 17:58:29 what block explorer code is that? haven't seen that format before 17:58:39 thats duggavo's 17:58:45 @duggavo:matrix.org 17:58:51 cool 17:59:19 https://github.com/duggavo/MoneroBlock 17:59:33 6. Mining pool centralization: Temporary rolling DNS checkpoints (https://github.com/monero-project/monero/issues/10064) and Publish or Perish (https://github.com/monero-project/research-lab/issues/144). 17:59:52 Wonder whether that will get updated for FCMP++, that block explorer ... 18:00:01 Or does it work already with that? 18:00:06 rbrunner: already 18:00:09 That is fcmp 18:00:18 Ah, of course. Dumb question. 18:00:37 It just uses rpc to ask for info from each block 18:01:07 It doesnt show any tx details, nor have pagination. Very bare bones, but good enough for now 18:01:53 With DataHoarder 's helped, I pulled together data to get an idea of how much hashpower share Nanopool, MoneroOcean, SupportXMR, and Hashvault have during Qubic's activities. The plots are in issue #10064 18:02:13 For dns checkpoints: i'll probably push a draft pr with some proposed changes. Hopefully we can build on it and get it ready for merge 18:03:04 The non-code issues need to be stored out, namely depth of checkpoints and how many to store. 18:03:04 My acronym for these four pools is "NOSH". In 2023, the NOSH mining pools changed their block template config to help confirm transactions more quicky. 18:03:33 Therefore, they may be open to enforcing rolling DNS checkpoints. 18:04:06 p2pool also changed recommendation to enforce checkpoints 18:04:12 However, their combined hashpower is barely above a majority at certain times. The safety margin may be uncomfortably thin. 18:04:21 P2Pool v4.10.1 was released including Monero block broadcast for non-p2pool blocks https://github.com/SChernykh/p2pool/releases https://www.reddit.com/r/Monero/comments/1ncde8h/psa_p2pool_v410_update_will_speed_up_the_whole/ 18:04:21 This will help broadcast all blocks faster across Monero (and in some cases help push alternate chains) 18:04:59 Anyone know what happens when p2pool miners in a single side chain (e.g. main, mini, or nano) mine on top of different alt chains? 18:05:05 this is effectively a faster block propagation network, no need to mine to use this both for receiving or sending blocks founds 18:05:28 @rucknium: that can happen due to normal reasons (specially with laggy miners) so it shows a warning to them and others 18:05:41 if they diverge too many heights they get "banned" by peers 18:06:04 And what happens in the side chain? Side chain accepts or rejects these "conflicting" shares? 18:06:34 if they are too stale or diverging the peer is banned (and share not accepted) 18:06:49 10 blocks I believe from checking the code 18:07:11 Whether p2pool miners enforce DNS checkpoints depends on the monerod node config, not on the actual p2pool software config AFAIK. (Saying for clarity) 18:07:18 correct. 18:07:54 each peer mines on their own or with agreeing peers 18:07:56 proposed changes: 18:07:56 1. 300 seconds check 18:07:56 2. BFT consensus (2/3 +1) 18:07:56 3. Ban time reduced to 5mins 18:07:58 It's hard to recruit p2pool in DNS checkpointing, ironically due to its decentralized nature. 18:08:19 p2pool has more hashpower than MoneroOcean and C3Pool 18:08:28 we updated recommendations, and defaults in the Docker setup 18:08:50 people can make some noise, but even today there's people running old p2pool versions :) 18:09:04 We might be able to get c3pool on board as well 18:09:15 the majority of miners updates within a few days (software wise) but some major ones lag a few versions behind 18:10:47 @ofrnxmr:monero.social: Another possible change is nodes remembering or forgetting DNS checkpoints that are no longer in the set of active DNS records. 18:11:03 AFAIK, now node remember the checkpoints (until restarted). 18:11:07 the majority of p2pool miners are running any of the recent versions in the past weeks 18:11:10 They remember, yeah 18:11:15 It has its advantages and disadvantages 18:11:30 alternatively for the remember issue the opposite checkpoints could be set to "delete" old ones if this is supported 18:11:57 Do we have 7 domains? For 5/7 checkpoint consensus. 18:12:07 Disadvantage: Edits to DNS records cannot change the chain fork that the enforcing nodes are on. If something goes wrong, it is hard to back out 18:12:58 /say // return false if adding at a height we already have AND the hash is different 18:12:58 if (m_points.count(height)) 18:13:04 no checkpoints cannot be taken back ^ 18:13:07 Advantage: Because it is nearly impossible to back out of a defense, a selfish miner may be more hesitant to launch a big attack. 18:13:16 it errors with "Checkpoint at given height already exists, and hash for new checkpoint was different" 18:13:17 moneropulse.ch, moneropulse.de, moneropulse.co, moneropulse.se, moneropulse.org, moneropulse.net, moneropulse.fr 18:13:33 note if setup well the subdomain keys can be split from main one ^ 18:13:45 so full control of main domain is not necessary for the checkpointing system 18:13:52 @rucknium: Similar to the logic of https://en.wikipedia.org/wiki/Dead_Hand 18:14:04 Who controls these domains? 18:14:13 Binaryfate 18:14:48 It would be better if it wasn't a single person controlling all 7. 18:15:03 > The purpose of the Dead Hand system, as described in the book of the same name,[8][9] was to maintain a second-strike capability, by ensuring that the destruction of the Soviet leadership would not have prevented the Soviet military from releasing its weapons.[2] 18:15:26 Right? 😁 we can always add / remove some 18:15:28 DataHoarder had an idea to delegate and disperse DNS record management. 18:16:23 I made this draft diagram of how the system could work (click the arrows at the bottom to page through the "slides"): https://cryptpad.disroot.org/diagram/#/3/diagram/view/6ab5ffc35d0775e5216a179a42bcd1e2/embed/ 18:16:26 not just management (ownership) but using DNS delegation for the checkpointing subdomain, the main domain can be kept well secured, while updates to the checkpointing subdomain can be done offline -> then pushed to DNS secondary servers that do not have the keys 18:16:50 Qubic is clearly willing and able to rent large amounts of hashpower for a few hours. Rolling DNS checkpoints could lead to very deep reorgs so long as Qubic could get enough HP so that NOSH has <50%. 18:16:58 using such a system refresh times can be lower than 10 seconds, but I wouldn't recommend a lower TTL than 5 minutes due to DNS 18:17:03 DataHoarder suggested that the big "secure server" in the middle of the diagram could be separate secure servers 18:17:07 Even if they lose the fork eventually, i wouldn't put it past them to do it just for fun 18:17:08 @rucknium: @rucknium:monero.social the link isn't a share link 18:17:15 you need to use the share function, @rucknium 18:17:23 no? 18:17:25 @blurt4949:matrix.org: Theyd have to sustain that >50% indefinitely 18:18:15 I believe this is the diagram https://cryptpad.disroot.org/diagram/#/2/diagram/view/glZWi196m1pxGKKdZZKC66exXJAm9WiJsQvN8kJutOM/ 18:18:25 the view key changes once loaded 18:18:32 That link used to work AFAIK. Try this: https://cryptpad.disroot.org/diagram/#/2/diagram/view/glZWi196m1pxGKKdZZKC66exXJAm9WiJsQvN8kJutOM/ 18:19:08 @blurt4949:matrix.org: Yes. This makes me nervous. 18:19:26 @ofrnxmr:monero.social: no, I mean they rent enough hashpower to get non-DNS above >50%, get a selfish mining start to fork the DNS and non-DNS network, then maintain the fork for a few hours. After their rental is over, likely another few hours for the DNS side to catch up, and suddenly we're looking at 8 hour reorgs. 18:19:37 As shown last time I have been running my own direct DNS server for checkpointing subdomains https://git.gammaspectra.live/P2Pool/monero-highway#cmd-dns-checkpoints with a list of necessary setup 18:19:58 Note this software is NOT necessary, it was written to ensure quick replication and limited subset to support DNSSEC 18:20:24 An alternate DNS server can be used like bind, to then push records to secondaries or serve DNS queries on its own 18:20:30 DataHoarder: I was able to follow your steps and set up delegated DNS checkpointing for testnet 18:21:44 @blurt4949:matrix.org: Because of the risk, DNS checkpoints could be set up to only activate if there were an attempted 10+ block re-org. Then, Qubic can do what it wants below 10 block re-orgs. 18:22:45 It would be risky on both sides for Qubic to re-org above 9 blocks, because of the DNS checkpoint punishment strategy. 18:22:46 the possible damage / marketing would already be done at that point, unless the checkpoints are issued immediately (automated) in case such a reorg is detected 18:22:56 @rucknium:monero.social: okay? So they attempt to selfish mine a 10 block alt chain, then release it, and do the same procedure as before 18:22:59 then kept forever afterwards 18:23:27