00:36:31 ofrnxmr: re: "it sounds like "pow is just for show now..."" 00:36:31 blocks finalized by a finality layer would still need to be valid, built by miners, satisfying PoW difficulty and all other existing requirements. validators are constrained in what they can finalize. to cause reorgs in such a setting, you'd need a large share of the hash rate _and_ control >33% of the stake (so that the honest stake can't finalize). a more probable attack/failure 00:36:33 would be if, for any reason, >33% of the stake stayed inactive. there you'd have an interim period where the chain would work as it does now. inactive validators would lose some of their stake for missing rounds and, if they missed too many, get automatically ejected from the validator set. both would increase the ratio of active stake until it'd hit 67% and finalization could re 00:36:35 sume. 02:16:42 hey has anyone had success with darkirc? the connections keep droppping on me 02:51:14 [#monero-offtopic:monero.social](https://matrix.to/#/%23monero-offtopic:monero.social) 02:51:24 #monero-offtopic 03:27:36

with hybrid pow / pos you can relax some requirements such as having a minimum number or stakers. the threshold to get stake started with only 5-10% network would be fine because you would also need to control the pow network to actually double spend beyond a single block. 11:08:16 The issue I see is that certain solutions are very controversial because they involve drastic changes to the Monero social covenant. 11:08:17 In order of the least controversial to the most I see 11:08:19 1) Solutions that keep the existing Random X POW consensus as the sole consensus solution 11:08:21 2) Solutions that introduce other POW consensus mechanisms involving ASICs 11:08:23 3) Hybrid solutions that include POS but require to POW to function. 11:08:25 4); Solutions that are POS only or have been identified by other projects as a pathway to a POS only solution. 1) For example POS finality layers. This has been identified as a pathway to a POS only solution by ZCash. 11:08:27 By their very nature 2, 3 and 4 are long term only since they involve hard fork(s). 11:30:25 I kinda like the idea of hybrid pow/pos with no block reward for pos blocks, and it does not affect the social covenant. I'd place this as 1.5 because 2 does affect that covenant. 11:34:18 (to be clear, the idea behind no block reward for pos is that holders' benefit would be a bulwark against attack; a defense against monetary loss rather than a monetary gain). 11:35:10 What if stakers received transaction fees only? 11:36:09 How would the penalty work on POS blocks? 11:36:59 I have no idea. I purposefully ignored that issue in my impl :) 11:37:01 the you still have the trouble with long range attacks / more complexity. 11:37:58 that is addressed somewhat in hybrid pow pos. 11:38:10 then you still have the trouble with long range attacks / more complexity. 11:38:19 Am I correct that "long range attack" is basically "create a long pos only chain strting from long ago" ? 11:39:20 because there is not cost in pos to makeup an alternative chain, there is an incentive for an attacker to make up chains where they mess slightly with the rewards so that they capture them all 11:39:27 because there is no cost in pos to makeup an alternative chain, there is an incentive for an attacker to make up chains where they mess slightly with the rewards so that they capture them all 11:39:31 *no cost 11:40:16 I can see how the attack would work 11:41:18 that is really the strongest argument for pow that this is not possible, because there is a real cost to consuming energy. 11:42:18 (leaving aside the question how future proof that is, as energy costs and semiconductor production costs will continue to decline as technology progresses) 11:43:25 https://www.energy.gov/articles/doe-releases-new-report-evaluating-increase-electricity-demand-data-centers 11:43:49 The report finds that data centers consumed about 4.4% of total U.S. electricity in 2023 and are expected to consume approximately 6.7 to 12% of total U.S. electricity by 2028. The report indicates that total data center electricity usage climbed from 58 TWh in 2014 to 176 TWh in 2023 and estimates an increase between 325 to 580 TWh by 2028. 11:44:17 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/RfAsUfuxhovCLFvtoaCIRQyL 11:44:37 Well, I will assume the answer to my question is "yes", then. So I believe that type of attack is mitigated by the way difficiulty is calculated, as it favors chains with equal numbers of pow and pos blocks. So do pos only (or pow only) and you'll lose out to a similar chain composed of ~50% of each. The longer the chains, the stronger the effect. 11:45:07 How well mitigated is left as an exercise for the statistician though. 11:50:58 TFL looks really nice in theory too. Could it be that the pos/pow asymmetry can be fixed by having pow finalize something made mostly of recent pos blocks and vice versa ? This might prevent this fear of it being a pathway to pos only. 11:51:56 That is, whether pos or pow finalizes that height H depends on the composition of the most recent blocks. 11:52:09 *at height H 11:52:52 I did not read the theory beind TFL though, just the zcash article vague overview, sorry. 12:24:39 Hi Rucknium 12:24:39 I created an issue and linked it to the meeting, however, I just learned that my github account is being shadow-banned (showing 404 for others) since I only signed up for it now (with a vpn). Support at github is open. In the meantime, I post the content of my issue below: 12:24:41 One thing to highlight about the Selfish-Mine exploit is that an attack is seen by the network in real-time prior to the inevitable re-org. This is due to the fact that the side-chain has two parts, a hidden tail and the published branch which is continuously being ignored by the miners trapped in the losing branch because of matching cumulative difficulty and the first_seen rule 12:24:43 and the reactivity nature of selfish-mine. The trapped miners are modeled by (1-γ) where γ "denotes the ratio of honest miners that choose to mine on the pool’s block" (citation from the infamous paper, Majority is not enough - Bitcoin is vulnerable, referred to as 'the paper' from here). 12:24:45 It seems therefore strictly better to free the trapped miners (collapse the two public branches into one) as soon as possible by choosing deterministically which branch to mine on (implemented within stratum, no protocol change). This fixes γ to 0.5 and the pareto front (Fig. 3 of the paper) shows that you need a pool share α > 0.25 to be profitable. On first glance, it doesn't 12:24:47 seem promising on it's own since γ relies on additional effort of employing sensors and skew the first_seen metric to your favor. With a high enough γ you can currently profit with even less than 25% hashrate share. If your share is > 25% you don't need to rely on luck or sensors anymore and you profit even more if you had previously a γ below 0.5. 12:24:49 However, I think the upside of collapsing the branch as quickly as possible is bigger here. I propose a further adjustment in which it does not matter from a reward perspective which branch is ultimately adopted. What matters is that the partitioning of the honest hashrate by γ bands together and we free our friends quickly. The further adjustment is quite drastic but effective: 12:24:51 - we have an additional field "donation" (not sure if that can be a stealth address or not). To account for p2pool, this should allow lists of addresses with percentage 12:24:53 - block rewards are paid out by the subsequent block (N+1) based on that donation field 12:24:55 - rewards would be given to all competing blocks (uncles) uniformly. This needs to parent (N-1) + uncles from N-2. Since the branch point is one block earlier 12:24:57 outside of protocol, in stratum: 13:03:01 title was: Countering Selfish-Mine 13:03:44 under PoW: Long-term fix 13:04:35 but it's idea-stage. if at all valid, certainly needs to be fleshed out 14:08:03 i dunno if i'll be around at meeting time, but hopefully the folks associated with the 2 things i put in the lab meeting issue may be around to discuss 15:01:00 MRL meeting in this room in two hours. 16:38:34 venture: Can you give your idea a name besides "Countering Selfish-Mine"? 16:39:49 Countering Selfish-Mine: Promote orphans to uncles (equal pay) and choose deterministically (in stratum) who becomes father :) 16:50:15 https://github.com/monero-project/meta/issues/1256#issuecomment-3207233765 some thoughts on meeting items 5. and 6. ... maybe we can reach some rough consensus on which questions the community wants answers to for the TFL work. 16:51:28 I had a question regarding TFL, but I'm probably wrong: It is my understanding (or hunch) that a finality layer would completely override the longest/heaviest chain rule from the underlying PoW, similar as checkpoints would? Once finality is required by exchanges miners will always jump ship and mine on any branch endorsed by that layer. 16:51:55 I will be commenting on the block signing remix. 16:51:55 With a minimum of 1% of the block reward before penalty or fees in a single transaction signed. 16:51:57 As an option 10% of the total block reward in multiple transactions could also be allowed 16:52:20 Block signing is included in one of the listed proposals 16:54:46 I am currently working on a write-up for this 16:58:58 The sub-items I have for mining pool centralization: https://github.com/monero-project/meta/issues/1256#issuecomment-3207278521 16:59:53 can you add the two questions from my comment to the TFL subpoint? 17:00:26 Can you type them here? Your comment is long 17:00:30 jbermans comment has some good thoughts as well. maybe we can condense those into questions and add them too 17:00:39 Meeting time! https://github.com/monero-project/meta/issues/1256 17:00:44 Howdy 17:00:48 A) How low can the staked percentage of the total marketcap be, to achieve the same cost that is needed for an attacker to shut off our current PoW system consistently over time? 17:00:49 B) The second question I am interested in is how higher stake behaves during real outages. 17:00:51 1) Greetings 17:00:59 hello 17:01:03 Hello 17:01:06 *waves* 17:01:17 Hello 17:01:21 hai 17:01:23 hi 17:01:37 Hi 17:01:39 hi 17:01:45 Hi 17:02:53

hi 17:02:58 2) Updates. What is everyone working on? 17:03:29 me: final tasks in prep for the FCMP++ alpha stressnet (reviewed 9473, tested forking from testnet). All code right now for the alpha stressnet is in review. I spun up the current testnet, forked it locally, and found/patched a couple bugs. We should be good to go forking from current testnet once the fixes are merged 17:04:00 I am working on the block signing remix proposal and also doing research on Proof of Stake in general 17:04:14 me: ironing out monerosim 17:04:19 me: updated/rebased existing prs, bug fix for lwsf tx construction, read a few papers on selfishing mining mitigation/prevention, etc 17:04:55 Veridise is nearing completion of their research on the Helios/Selene pair, as part of the FCMP++ work. The formal verification of the library will follow that 17:05:17 trying to reproduce an issue i had with big blocks. Issue disappeared when the txpool expired 17:05:34 me: Performed some network construction simulations to help analyze "p2p: Improved peer selection with /24 subnet deduplication to disadvantage 'spy nodes'" https://github.com/monero-project/monero/pull/9939 . See my comments in that PR. Looking at research literature on hardening PoW against attackers. Helping test rolling DNS checkpoints on the public testnet with ofrnxmr , vtnerd , and tevador . Visualizations (4 different subdomains): https://testnetnode{1,2,3,4}.moneroconsensus.info/ 17:06:04 Trying to hit back review backlog for both FCMP++ and the core repo, and working on integrating tevador's double hashing idea 17:06:08 wrote out a framework for judging the relative security of pow / pos / pow-pos hybrid solutions. https://github.com/monero-project/meta/issues/1256#issuecomment-3207233765 and took a look at the monero-oxide audit / started migrating to the crate 17:07:19 embarrassed myself with a very naive idea with outlandish numbers and that would have let to bifurcations, thankfully the community was there :) Researched more on countering selfish-mine 17:08:56 3) Transaction volume scaling parameters after FCMP hard fork. https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf 17:10:55 One of the considerations here is that regardless of the valuation of verification time, we must allow the weight s to scale for large weight transactions 17:11:43 Otherwise it is possible to launch a zero cost DDOS attack on the nodes 17:12:39 I don't understand why charge more for larger txs, when smaller txs are better to attack with. Makes sense (to me) to not discriminate against any of them (page 2) 17:12:42 I followed up on that here: https://github.com/seraphis-migration/monero/issues/44#issuecomment-3187685572 17:13:38 If the tx is ultimately invalid, then the fees dont matter (do they? Im assuming the fees are irrelevant because an invalid tx wont be mined). For a valid tx, the fees should be inline with cost oer input on lower input txs 17:13:54 I will provide a response in the thread on this. 17:14:15 if tx is invalid, fees don't matter 17:14:17 The response does not address this issue 17:14:33 ArticMine: somewhat related, do you happen to know why the transaction weight limit was changed from (block weight minimum - coinbase_size) to (block weight minimum / 2 - coinbase_size) in hard fork v8 ? 17:14:54 If the tx does not get mined feed don't matter 17:15:57 Do you mean for node relay? 17:16:04 Fees 17:16:07 A 128-in FCMP++ can be bigger than 120kb, which is more than half of the block penalty-free zone (unless we change that in the next HF). I was wondering if there would be any downsides if txs above 1/2 the penalty-free zone were allowed? 17:16:35 ArticMine: that tx weight limit is a consensus rule 17:16:41 (*150kb) 17:16:59 Sorry, yes that was a typo. 150kb 17:18:24 So 50% of the penalty free zone 17:19:31 Yes I supported that since it mitigates somewhat my concern over a DDOS attack with un economical transactions 17:19:35 > One of the considerations here is that regardless of the valuation of verification time, we must allow the weight s to scale for large weight transactions 17:19:35 After thinking about this for a few weeks, I'm not quite convinced that this is true anymore. Like ofrn is saying, you can split the tx into smaller parts, pay a smaller fee, but the change to the block reward penalty would be the same. The additional marginal fee to be imposed by a tx really is a function of the sum total size of the mempool, not any individual tx 17:21:16 One can split up a tx and pay lower fees because it attracts a lower penalty for each split tx. This is a given 17:21:48 When it really gets down to it, it's a discrete optimization problem, so optimally it's a function of individual txs, but that's a different discussion. I'm talking about approximations 17:21:54 the cost to perform a ddos attack could be increased by having the proposing nodes sign transactions with a bond and slash that bond if they propose tons of invalid transactions 17:21:58 But i can ddos better with smaller txs, at a lower cost, and higher size 17:22:07 The issue is a spam attack with large weight TXs where the spam TXs do not get minef 17:22:18 /my 17:22:26 But it's the same penalty diff for the sum of those 2 txs 17:22:37 The fee doesn't matter in that case 17:22:41 its really the verification cost of invalid transaction that could become a ddos concern, right? 17:22:57 The two TXs can be in different blocks 17:23:41 So the higher penalty rate is never paid 17:23:41 ofrnxmr: the fee still matters. We're talking about valid-proof txs, where the relay fee is less than what would make it economical to mine 17:23:47 This is not about invalid transactions 17:24:01 That's different from the discussion where a verification-time DoS is performed with invalid txs. The fee makes no difference in that case 17:24:36 how can the verification cost of valid transactions ever be an issue for ddos? if thats the case the fees are too low in general 17:25:09 It isn't, but you don't know if it's invalid or not until you validate it 17:25:13 This is not about verification t 17:25:20 Time 17:25:38 I will address this in my response in the thread 17:25:46 On GitHub 17:27:29 Is there any else on this topic? 17:28:19 4) [FCMP alpha stressnet planning](https://github.com/seraphis-migration/monero/issues/53#issuecomment-3053493262). 17:28:20 on scaling in general I would recommend people to read up on the research about tachyaction. other than that no 17:28:22 > The two TXs can be in different blocks 17:28:23 > So the higher penalty rate is never paid 17:28:25 By that same logic, you can wait until the mempool is more empty to mine the bigger one too and not pay the higher penalty rate 17:29:18 True. This is why we have not yet had a problem with this 17:29:21 > on scaling in general I would recommend people to read up on the research about tachyaction. other than that no 17:29:21 That's more related to cryptography / data availability and not traditional fee markets though. But yes, an interesting topic for sure 17:29:23 spirobel: This one, right? https://seanbowe.com/blog/tachyon-scaling-zcash-oblivious-synchronization/ 17:30:21 AFAIK, final bugs that would affect alpha stressnet are being squashed. 17:30:31 This I have to read especially after the brutal attack on ZCash 17:30:38 (holding on stressnet until above discussion is finished) 17:31:07 yes I posted about this before a while ago in the community workgroup channel. the tldr is that it will change node requirements in the sense that not all key images will have to be kept in memory for verification. so ram requirments get decoupled from archiving the blockchain. 17:31:30 ok, I have 3 items to raise for FCMP++ alpha stressnet: 17:31:36 1) Set a fork date. 17:31:49 - As proposed in a past meeting, it would fork from current testnet. So get your testnet nodes synced up and ready to go. 17:31:49 - I would prefer to have all code merged before announcing the official start date and releasing instructions on how to join the stressnet. 17:31:51 - I would hope to target this coming Tuesday (Aug 26th), but that depends on our ability to get the code merged beforehand. 17:31:53 - Blocking code is linked here: https://github.com/seraphis-migration/monero/issues/53#issuecomment-3053493262 17:32:57 IMHO, it's best to wait until the code is 100% ready before setting a date. 17:33:18 Ok 17:33:24 In summary, the blockers now are the PRs created in the wake of the other stressnet, and a wallet sync speedup PR. Nothing super FCMP++ related 17:33:31 Do we need to announce anywhere except here? Isn't there a non-alpha stressnet planned for more community participants? 17:34:20 2) Here is a draft post written and ready to blast out: https://paste.debian.net/1392565/ 17:34:26 - It includes instructions (borrowed from jeffro) on how to build monerod, CLI, RPC, and GUI using the expected alpha stressnet code. 17:34:27 - The code would live on a new branch called "fcmp++-alpha-stressnet" in the seraphis-migration repo. 17:34:38 Then we'll need to set some roles/rules. I, for example, will volunteer to run a seed node. i think we might have to have controlled mining due to the speed (lack of) of generating txs 17:35:04 I figured it would be good to make a reddit post 17:35:07 What do you mean by "controlling mining"? 17:35:08 *controlled 17:35:13 Imo, it needs a paragraph on top to remind people what FCMP++ is, in ELI5 language 17:35:31 i mean, i have a script that only starts mining under certain conditions 17:35:44 Instead of every 2mins, since i cant fill blocks that fast 17:35:51 > Do we need to announce anywhere except here? Isn't there a non-alpha stressnet planned for more community participants? 17:35:51 Rucknium : probably the stressnet Matrix room I would think 17:35:58 Difficulty will fall off fast you that is done 17:36:04 fast if* 17:36:35 For building stressnet - we should release binaries. Building shouldnt be necessary, but of course people can build if they choose to 17:37:03 Thats fine. My diff is at 2 and i oroduce blocks every 20mins :P 17:37:16 They are ~17mb, spamming from 4 wallets 17:37:28 I think I can probably use the testnetnode1.moneroconsensus.info nodes as seed node, too. 4 nodes. 17:37:41 ofrnxmr: perhaps I could add a tool which re-uses EC blinds and speeds up stressnet tx creation 17:37:55 Discussed binaries briefly with jeffro. We haven't messed with GUIX building yet, so not sure how that'll go. I pinged tobtoht on it too for thoughts 17:37:58 Obviously, you wouldn't want to ever, ever use that for production 17:38:11 I can manage some spamming from the Monero Research Computing Cluster and maybe some from my seed nodes. 17:38:16 Depends works 17:38:28 Guix not ready afaict 17:38:44 Blinds construction is fast now with fabrizio's code merged. It's prove() that's the bottleneck: https://github.com/kayabaNerve/fcmp-plus-plus/issues/34 17:39:00 yes I posted about this before a while ago in the community workgroup channel. the tldr is that it will change node requirements in the sense that not all key images will have to be kept in memory for verification. so ram requirements get decoupled from archiving the blockchain. 17:39:22 Oh, you're right.. 17:39:32 Nvm 17:40:29 I think we should see how things go at normal mining speed at first and then adjust if necessary. 17:40:33 I'm fine with releasing binaries too. I have some reservation on it because it might end up a little annoying if people start doing stuff like using the wrong node/wallet and report bugs from that, and so requiring building at least raises the bar somewhat 17:41:38 But, if no one shares that concern, then we can do binaries 17:41:50 Perhaps we could switch to a fixed difficulty at some point 17:42:17 Is that easy to do? Don't all nodes on the network need to agree for that? 17:42:26 Probably need like 30+ wallets spamming if were actually pushing for large blocks 17:43:00 IIRC, `monerod --version` shows the current commit hash if not a release version, right? 17:43:07 Maybe I can try to Dockerize something :D 17:43:07 I don't really like Docker, but this may be a good usecase. 17:43:16 it uses 100% cpu 17:43:36 We can just ask them what version they're using as the first question 17:43:37 (wallet does) 17:43:52 100% of one thread or 100% of the whole CPU? 17:44:11 > Is that easy to do? Don't all nodes on the network need to agree for that? 17:44:11 Yes, they all need to agree on that. It can be supplied with a CLI argument 17:45:08 The new MRC box has 256 threads and 1TB RAM 17:45:18