13:57:00 Proposing an idea to solve qubic saga and make p2pool more rbust for long term 13:57:01 Creating an option on p2pool to donate a chosen % of the mining rewards to use it as an extra mining reward on p2pool. 13:57:03 Assuming there's enough miners who care more about decentralization then short term profit (enough to create bigger subsidies then qubic) then we can end this saga, and make p2pool stronger for long term. 13:57:05 . 14:08:27 That isn't a solution, albeit it's a feature request for sech1. 14:11:47 Why isn't it a solution? 14:13:43 Because it's a potential improvement based on voluntary subsidiaries to combat other pools from offering subsidies, not a fundamental solution. 14:15:02 ^ as I see it within p2pool workings someone's share could "opt" to some degree into being provided to current PPLNS range 14:15:36 that way it can get seen in the regular scan for earnings/transaction building for rewards 14:16:05 so it's not giving anything more like they "donate" their share weight to others 14:16:24 would require p2pool changes ofc 14:16:49 the alternative is, you can get current miner addresses on p2pool, and, just mine on p2pool yourself on those addresses 14:17:55 that works today, and xvb already does that 14:25:42 if there will be enough subsidies from donated mining rewards we can make future attacks harder. Not a fundamental solution but a good temporarily solution that can also be used in future events ("good" miners will increase the % of donated reward every time a centralized pool gets too big) 14:41:54 DataHoarder: you can just only submit a fraction of the shares you actually mine. 14:42:10 that too 14:42:34 you can do it today, as described ^ 14:45:47 @fullninja:matrix.orgif you are positive that the attacker mines empty blocks only, choosing a higher fee tier will do no harm other than reducing your privacy a little. 14:46:13 they mine all 14:46:18 sometimes they mine empty 14:47:22 it was mentioned here, as they disconnect from network to do selfish they run out of mempool and high blocks in their attempts end up empty 14:55:44 You can get a list of p2pool wallet addresses, and either send XMR to them directly, if you wish so, or mine to their wallets 14:57:10 ... then feed your LLM to brag about it :) 15:01:16 MRL meeting in this room in two hours. 15:23:51 FYI, I am considering drafting a CCS on a finality layer and would have to prioritize: 15:23:53 A) The design and documentation 15:23:55 B) A proof of concept finality binary, which if necessary, could be immediately deployed using Ethereum as the finality layer 15:23:57 C) The implementation of my nominated consensus algorithm, which is the part that'll likely take the longest to competently do 15:23:59 I'm sure this'll be discussed during the meeting (one of the bullets is my meta-issue), but I wanted to raise this question *a bit* beforehand to give people some time to think/get any basics out of the way. I'm sure I'll restate all relevant parts during the meeting to ensure everyone is up to speed though. 15:25:42 At first glance, C seems like a horrible option. The reason it's present as an option is because if Monero ever deployed a BFT finality layer, the consensus algorithm used is largely independent from how it's glued into Monero (which is what A is). They're two parallel tracks BUT most of the time on auditing, performance, p2p networking, would be spent on the consensus algorithm ( hence why it arguably should be done first). 15:26:08 But all of this would be to begin development on a potential future choice, and we'll have the best education and discussions with option A. 15:31:11 Unfortunately, I won't be present, but I wish everyone who will participate a good meeting. 15:42:06 Regarding the BFT layer, i think the main concern is how to choose the validators. I guess thats part if A)? 15:42:10 *of 15:50:02 Technically, any method of 'stake' would work in a decentralized fashion, yet the proposals have been blocks mined or XMR. The former doesn't work _well_. It either has too long a window, and requires anyone who mines a block also runs a node for a year, or too short a window, and doesn't protect against 51% attacks which can be sustained for a few weeks. 15:50:55 Or they've been unquantifiable concepts like a node's reputation, or centralized such as 'the Monero team'. 15:53:28 *I'm not asking for feedback on a CCS which doesn't exist. I'm trying to take a temperature check to decide if I should submit a CCS and if so, how. 15:54:00 Sorry if this is too vague at this time 15:54:47 Though that'd be its own form of feedback 🤔 16:04:05 What is the Main reason of the proposed bft algorithm? 16:04:05 I guess it should be quantum safe and asynchronous? 16:04:07 Couldnt narwhale also fit this? 16:05:53 Can some of ETH‘s Casper FFG be introduced 16:15:02 Tusk isn't PQ. Ethereum's consensus isn't formally proven (though some derivatives are). 16:15:45 (Tusk assumes a random coin, and practically, random coins are done via BLS. While there are PQ random coins, to integrate them into Tusk successfully would be its own commentary). 16:16:43 I believe there's enough unknowns and discussions that if I was to make a CCS, it'd be best to be *my* presentation and analysis of options as leading to *a potential scheme* that everyone could discuss and contribute to before taking further actions. 16:30:14 I am just a bit scared of the cubic communication complexity 16:31:44 <17lifers:matrix.org> cubic communication complecity, also known as C3 16:31:55 <17lifers:matrix.org> cubic communication complexity, also known as C3 16:41:41 Practically ideally, we'd have quadratic. 16:42:24 (Avalanche claims constant, but with many issues elsewhere. Algorand published an interesting paper on asynchronous consensus with sub-quadratic complexity though...) 16:43:08 kayabanerve: Can I stop you there and wait until the meeting, which starts in 20 minutes? It can get messy when discussion before the meeting bleeds into the meeting. You can continue in #monero-research-lounge:monero.social . And I have a proposal. 16:43:21 This may be an unusual meeting. On the agenda is PoW mining pool centralization: https://github.com/monero-project/meta/issues/1254 16:43:39 This topic is fundamental to the Monero project. I will request more structure than usual for that agenda item. 16:43:44 The purpose of the discussion at _this_ meeting is not to decide any changes to Monero's consensus protocol and blockchain security model, but to start to plot out an Research & Development plan toward addressing weaknesses, both theoretical and empirical. 16:44:12 I propose that the structure of the discussion on the mining centralization agenda item be: 16:44:35 1) I anticipate that there may be more readers and writers than at a usual MRL meeting. Therefore, start by stating your relationship to the Monero project and areas of knowledge/expertise (if any). "Ordinary user" is a fine response. Participation by new participants is fine and encouraged. 16:44:48 2) State what you consider to be the major problem(s) with Monero's consensus protocol and blockchain security model, if you think there are any problems. This includes problems that have actually occurred and theoretical problems that are possible but have not yet occurred. Do not respond to each other at this point in time. 16:44:59 3) State what you consider to be Monero's ideological and ethical principles, especially as they are relevant to potential solutions to mining pool centralization. Feel free to rank the importance of these principles. Again, don't respond to each other at this point in time. 16:45:11 4) General open-ended discussion on potential solutions to the mining pool centralization problem. 16:45:22 (Don't post these now. Wait until the mining centralization agenda item comes up.) 16:46:24 If anyone has suggestions for this structure, please suggest them. 16:46:52 Of course Rucknium: 16:53:01 I would suggest that we separate the discussion between: 16:53:03 1) Improvements and fixes to the existing POW., both at consensus and node relay 16:53:05 2) The introduction of non POW consensus mechanisms such as but not limited to 16:53:07 Trusted Execution Environments 16:53:09 Proof of Stake Hybrid solutions 16:53:11 Other non POW consensus solutions 16:53:25 2) Is way more controversial than 1) 16:53:45 So we should start with 1) 16:54:37 ArticMine: That sounds great to me. Can I insert your two bullet points into my #4 above? 16:54:50 Of course 17:00:22 Meeting time! https://github.com/monero-project/meta/issues/1254 17:00:24 1) Greetings 17:00:40 Hi 17:00:43 hi 17:00:49 Hello 17:01:21 hello 17:01:29 hi 17:01:31 Hello 17:01:33 Hi 17:01:40 Hi 17:02:02 hello 17:02:57 👋 17:03:06 2) Updates. What is everyone working on? 17:03:55 me: Improvements to https://moneroconsensus.info/ , which monitors orphaned blocks and mining pool centralization. Writing up simulation results for questions on review of PR #9939 "p2p: Improved peer selection with /24 subnet deduplication to disadvantage 'spy nodes'" https://github.com/monero-project/monero/pull/9939 (Will post an hour or two after the meeting). 17:04:14 hello 17:05:06 Greetings. Looking forward to the meeting discussion. 17:05:10 Me working on the fee calculations. 17:05:45 The results are posted after the size estimates 17:06:20 3) [Transaction volume scaling parameters after FCMP hard fork](https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf). 17:07:22 https://github.com/seraphis-migration/monero/issues/44 17:07:50 I posted the link s to the fee results here 17:09:10 bug hunting & testing some fcmp stuff 17:09:15 The enforcement of the requirement that all transactions are economical to mine regardless of size is the basis for the calculations 17:09:55 We have to take into account the quadratic nature of the penalty 17:10:30 my kiss take on fcmp fees/scaling: for fcmp fees i think we should do.. same 300kb standard median. larger txs mean fees will bump up to "normal" tier more often. Unimportant fee = 0.00002xmr per (input+output), other tiers same multipliers as current 17:10:33 This more than compensates for the verification time costs 17:11:00 The verification is linear per input afaict 17:11:30 Keeping the median unchanged failed in 2017 17:11:48 Long-time XMR user here. By XMR user, I mean I actually use it as a currency. I also mine. I have also attended Monerotopia. I typically take a hands-off approach, but in this instance, I'd be remiss not to speak up for other silent XMR users and encourage cypherpunk and decentralized values. It's easier to keep liberty we have, than to regain it once it's lost. I look forward to hearing 17:11:54 everyone out. That is all. 17:12:41 wrong chat 17:12:46 => #monero 17:13:09 maybe wrong agenda item 17:13:12 This would be the right chat if it were during the mining centralization item, which comes later 17:13:49 mea culpa all rights to the moderator, Rucknium our supreme leader 17:14:00 sorry. Please continue 17:14:01 wdym? 17:14:56 In 2017, didnt tx sizes decrease? I dont recall the history of the median changes 17:14:57 This? https://www.getmonero.org/2017/12/11/A-note-on-fees.html 17:15:23 The transactions were to big to scale so were stuck. A second hard fork was needed to fix the issue 17:16:08 I'm running fcmp right now with 8mb blocks (15mb at peak) 17:16:38 Basically if one increases the tx size by a factor of 3 then the base has to increase by a factor of 3. Fees then stay the same 17:16:48 Was it that a large tx could not fit in a block when the block size median had not been raised yet? 17:17:13 The fees get very high 17:17:55 This is good to know 17:18:42 It means that the proposal increase in the base median makes sense 17:20:16 Take a look at the 128 input TXs to see what I meam 17:20:55 The key ratio is tx weight/ long term median 17:22:20 I will keep the meeting moving... 17:22:25 4) [FCMP alpha stressnet planning](https://github.com/seraphis-migration/monero/issues/53#issuecomment-3053493262). 17:23:00 AFAIK, ofrnxmr has been trying to trigger bugs on his private testnet. 17:23:15 So that an alpha stressnet can begin. 17:23:53 Will the alpha stressnet fork from the public testnet, like the last stressnet, or start from genesis? 17:24:32 I think for the "public stressnet", fork from testnet would be good because performance issues could develop when the blockchain already has some GB in it. 17:25:43 jberman and jeffro256 aren't here right now to give an idea of how they view the exact launch process. But ofrnxmr could take the lead maybe. That would take some labor off their shoulders. 17:26:22 Oops sorry, thanks for the ping 17:26:43 This also impacted the fee discussion 17:27:24 I haven't looked at Artic's recent comments on the tx weight GH issue, but I'm going to do that today. 17:28:51 Rn I'm reviewing and testing the 128-in FCMP++ PR, seems good so far. The contest code is more or less ready to go for usage in the stressnet. I think that we could start planning the date for the stressnet now, but I might hold off until j-berman is here 17:29:43 "Will the alpha stressnet fork from the public testnet, like the last stressnet, or start from genesis?" << mine starts from genesis, _but_ the fees are different pre-tail emission 17:31:12 There was a major spike in fees in 2017 with the introduction of ring ct 17:31:50 Tx size ~13500 bytes for 2 in 2 out 17:32:06 Ok. The stressnet launch planning discussion can occur outside of the meeting time, especially so jberman can give input. 17:32:24 Jeffro, i'm also running the 128in pr. I think this shoukd definitely be included in stressnet 17:32:44 Forking from an existing network would yield more accurate DB migration times, more accurate FCMP tree handling times, etc. However, it might be an overhead that outweights its benefits 17:33:21 sorry, to chime in.. but it burns to ask.. was it not decided to restrict 8-in, 8-out (fan-in/fan-out) for FCMP? why these 128-in fee calcs? please ignore if it's out of place 17:33:33 Rucknium: at what chain size would it not be worth it in your opinion to use an existing network ? 17:33:38 I'm going to get my blocks up to ~20+mb and then share my binaries so rucknium and others can try it out 17:34:23 Jeffro, testnet is only abt 7gb iirc. My db is around 1gb currently 17:35:00 (But those 7gb take like 12hrs to sync.. ) 17:35:36 What seems to be a rough agreement right now is to allow >8-in/8-out txs at the consensus level, but require PoW to *relay* larger txs in the mempool 17:35:51 jeffro256: I don't know. I like forking from testnet since as ofrnxmr said, the fees and scaling, etc. And it was not difficult to do it last stressnet (but the code has changed a lot with FCMP, of course). 17:35:57 Probably b/c there are hardly any peers 17:36:09 no, due to checkpoints 17:36:32 Lack-of* 17:36:34 Or lack thereof? 17:36:42 Didn't new testnet checkpoints get added? 17:37:01 Not to the monero-project. We only added them to the stressnet 17:37:04 Okay let's do that 17:38:00 5) [Spy nodes](https://github.com/monero-project/research-lab/issues/126). 17:38:10 That's interesting, I wouldn't have thought that it would take that long to verify 7GB worth of tx proofs, but I haven't ever actually profiled it 17:38:31 jeffro256: had a question about simplification of the code in github.com/monero-project/monero/pull/9939 to have the "already-connected" subnet qualification to be made at the `/24` subnet level instead of the current `16` level. According to my simulations, it makes very little difference given the current network structure, assuming the spy nodes found by boog900 17:38:34 (for testnet w/o checkpoints at least) 17:38:57 its all the PoW hashes too 17:38:59 When honest nodes have the default 12 outbound connections, setting the "already-connected" subnet qualification to the `/16` subnet level gets you an average of 1.048 connections to the spy nodes. When it is `/24`, the average is 1.064. A very small increase. 17:39:04 I will post teh write-up and code on the PR 17:39:17 TIA 17:40:32 Like I said before the meeting, I want some structure in the next agenda item on mining pool centralization. 17:40:56 The purpose of the discussion at _this_ meeting is not to decide any changes to Monero's consensus protocol and blockchain security model, but to start to plot out a Research & Development plan toward addressing weaknesses, both theoretical and empirical. 17:41:05 But there is also geographical distribution concerns also, not related to spy nodes. How does going from /16 to /24 affect that? A less diverse set of already-connected peers might slow down tx&block propagation for those farthest away from the "center" of the node graph 17:41:55 jeffro256: I can look into that. I have the actual IP addresses of a network scan, so I can translate that into geography 17:41:57 Thanks 17:42:06 For the next agenda item: 17:42:13 1) I anticipate that there may be more readers and writers than at a usual MRL meeting. Therefore, start by stating your relationship to the Monero project and areas of knowledge/expertise (if any). "Ordinary user" is a fine response. Participation by new participants is fine and encouraged. 17:42:22 Thank you for doing that 17:42:25 2) State what you consider to be the major problem(s) with Monero's consensus protocol and blockchain security model, if you think there are any problems. This includes problems that have actually occurred and theoretical problems that are possible but have not yet occurred. Do not respond to each other at this point in time. 17:42:45 3) State what you consider to be Monero's ideological and ethical principles, especially as they are relevant to potential solutions to mining pool centralization. Feel free to rank the importance of these principles. Again, don't respond to each other at this point in time. 17:42:59 4) General open-ended discussion on potential solutions to the mining pool centralization problem. The discussion will proceed: 17:43:09 1) Improvements and fixes to the existing POW., both at consensus and node relay 17:43:13 2) The introduction of non POW consensus mechanisms such as but not limited to A) Trusted Execution Environments, B) Proof of Stake Hybrid solutions, C) Other non POW consensus solutions 17:43:27 Agenda item: 17:43:29 6) PoW mining pool centralization. [Monero Consensus Status](https://moneroconsensus.info/). [Bolstering PoW to be Resistant to 51% Attacks, Censorship, Selfish Mining, and Rented Hashpower](https://github.com/monero-project/research-lab/issues/136). [Mining protocol changes to combat pool centralization](https://github.com/monero-project/research-lab/issues/98). 17:43:40 could we agree on @jeffro256:monero.social proposed changes now ? 17:44:27 The context of this is Qubic's selfish mining strategy where they have perfromed a few blockchain re-organizations recently. One was 7 blocks deep. 17:44:50 FCMP++ R&D 17:44:51 Serai Developer 17:44:53 PoW vulnerability to coordinated actors at scale risking double spends and censorship. 17:44:55 Decentralization and privacy. 17:45:43 I have been involved with the Monero project since 2014 and with POW mining since 2011 Have worked on Monero scaling and have been on the core team since 2016 17:46:34 1) Me: I have been providing research analysis for Monero's privacy and security for about four years. I am an empirical microeconomist. My areas of knowledge are statistics, economics, and game theory. I have chaired the weekly MRL meetings for a while. 17:47:10 1] Monero Research Lab regular and researcher of blockchain technologies in general. 17:47:29 1) Monero dev since 2017. Chair of the weekly Monero Tech Meetings. Frequent poster in the Monero subreddit. 17:47:37 1. ofrnxmr. Monero abuser 17:47:39 2. ability to invalidate txs w/ a deep enough reorg, and no "rules" or protections against it. Exampke: we have a 10 block lock, but there is no enforcement that 10 blocks are actually final 17:47:41 3. payments. reliable and immutable. 17:48:15 2] I see two factors regarding Monero's current consensus that create a problem: 1) the mining algorithm is geared toward general-purpose hardware which is easy to access/rent, 2) the reward issuance in dollar terms is currently low both relative to other cryptos and the global availability of general-purpose hardware. these make attacks in the Nakamoto consensus (e.g. selfish min 17:48:17 ing, or a 51% attack,) more feasible than desired. 17:48:44 I see the Qubic situation as an attack on Monero's decentralization. There is also a lot of history since the principals in Qubic were also related to Bytecoin, an over 83% pre mine from which Monero was forked in 2014 17:49:07 There is a lot of history and bad blood here 17:49:20 2) Problems: Low security budget at the current real purchasing power of 1 XMR. Behavior of individual miners to concentrate in a few pools (unclear why this occurs). Using a "flow" to protect a "stock", i.e. only a flow of PoW rewards protects the stock of the value that users keep in the XMR in their possession. 17:49:25 1] scientist: physical modeling with recursive filter networks 17:49:27 is there a reasonably good writeup of the reorgs and, in particular, the contents of the reorgs and transaction equivalency (or lack thereof)? 17:49:38 Longtime user 17:49:39 I wish to keep the majority of Monero's PoW advantages and ethos, while strategically mitigating some of the most significant downsides of pure nakamoto consensus. Notably, these are decentralization, accessibility, censorship resistance, and fair issuance. 17:49:41 I do not believe PoW "tweaks" will address the most significant issues of nakamoto consensus in Monero. I believe that a TFL approach is most likely to yield the best tradeoffs. 17:50:34 2) The main problem I see is that Monero is too small, simply put. 17:50:39 3 The above says it very well 17:51:03 I have been asked to pass this message from discord: "I think I speak for a lot of people here saying the issue of mining pool centralization is quite concerning & requires immediate attention since a successful attack on the network would result in the loss of trust in the ecosystem and once lost, it'll be nearly impossible to get back. At the 17:51:03 time of writing, a 6-7 block reorg was demonstrated to have happened in the past few days thanks to rucknium's amazing tools & work with the help of other devs. A solution to this problem is needed yesterday & frankly monero should've addressed this issue a long time ago considering the historical progress in this field of research." 17:51:09 sgp_: TFL = Trailing Finality Layer? 17:51:26 kanzure: The tx contents of the re-orged blocks did not change. You can check this with `print_pool_stats` in your `monerod` console. No double spend txs attempted. 17:51:56 thank you rucknium. that is interesting. 17:52:01 3) Principles: Privacy, decentralization, accessibility, fungibility. 17:52:38 ordinary user, somewhat technical background and somewhat studied monero technicals. also, sporadic donor 17:52:39 2. 17:52:41 - double-spend attacks if >51% is reached, less likely since there the attacker would be known to be affiliated with the majority block producer. would presumably give way to legal recourse since this would be plain theft 17:52:43 - censorhip, restricting txs somehow. this is also the reason why i think that any finality might come short of mitigation since nothing can be finalized what wasn't accepted by a centralized PoW provider 17:52:57 3] principles: 17:52:57