<c​haser:monero.social> ofrnxmr: re: "it sounds like "pow is just for show now...""

<c​haser:monero.social> 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<clipped message>

<c​haser:monero.social> 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<clipped message>

<c​haser:monero.social> sume.

hey has anyone had success with darkirc? the connections keep droppping on me

<o​frnxmr:monero.social> [#monero-offtopic:monero.social](https://matrix.to/#/%23monero-offtopic:monero.social)

<o​frnxmr:monero.social> #monero-offtopic

<n​oname-user0:matrix.org> 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.

<a​rticmine:monero.social> The issue I see is that certain solutions are very controversial because they involve drastic changes to the Monero social covenant.

<a​rticmine:monero.social> In order of the least controversial to the most I see

<a​rticmine:monero.social> 1) Solutions that keep the existing Random X POW consensus as the sole consensus solution

<a​rticmine:monero.social> 2) Solutions that introduce other POW consensus mechanisms involving ASICs

<a​rticmine:monero.social> 3) Hybrid solutions that include POS but require to POW to function.

<a​rticmine:monero.social> 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.

<a​rticmine:monero.social> By their very nature 2, 3 and 4 are long term only since they involve hard fork(s).

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.

(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).

<u​ntraceable:monero.social> What if stakers received transaction fees only?

<a​rticmine:monero.social> How would the penalty work on POS blocks?

I have no idea. I purposefully ignored that issue in my impl :)

<s​pirobel:kernal.eu> the you still have the trouble with long range attacks / more complexity.

<s​pirobel:kernal.eu> that is addressed somewhat in hybrid pow pos.

<s​pirobel:kernal.eu> then you still have the trouble with long range attacks / more complexity.

Am I correct that "long range attack" is basically "create a long pos only chain strting from long ago" ?

<s​pirobel:kernal.eu> 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

<s​pirobel:kernal.eu> 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

<s​pirobel:kernal.eu> *no cost

<a​rticmine:monero.social> I can see how the attack would work

<s​pirobel:kernal.eu> that is really the strongest argument for pow that this is not possible, because there is a real cost to consuming energy.

<s​pirobel:kernal.eu> (leaving aside the question how future proof that is, as energy costs and semiconductor production costs will continue to decline as technology progresses)

<a​sdfqwfe:matrix.org> energy.gov/articles/doe-releases-ne…ase-electricity-demand-data-centers

<a​sdfqwfe:matrix.org> 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.

<a​sdfqwfe:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/RfAsUfuxhovCLFvtoaCIRQyL

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.

How well mitigated is left as an exercise for the statistician though.

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.

That is, whether pos or pow finalizes that height H depends on the composition of the most recent blocks.

*at height H

I did not read the theory beind TFL though, just the zcash article vague overview, sorry.

<v​enture:monero.social> Hi Rucknium

<v​enture:monero.social> 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:

<v​enture:monero.social> 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 <clipped message>

<v​enture:monero.social> 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).

<v​enture:monero.social> 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 <clipped message>

<v​enture:monero.social> 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.

<v​enture:monero.social> 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:

<v​enture:monero.social> - 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

<v​enture:monero.social> - block rewards are paid out by the subsequent block (N+1) based on that donation field

<v​enture:monero.social> - 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

<v​enture:monero.social> outside of protocol, in stratum:

<v​enture:monero.social> title was: Countering Selfish-Mine

<v​enture:monero.social> under PoW: Long-term fix

<v​enture:monero.social> but it's idea-stage. if at all valid, certainly needs to be fleshed out

<g​ingeropolous:monero.social> 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

<r​ucknium:monero.social> MRL meeting in this room in two hours.

<r​ucknium:monero.social> venture: Can you give your idea a name besides "Countering Selfish-Mine"?

<v​enture:monero.social> Countering Selfish-Mine: Promote orphans to uncles (equal pay) and choose deterministically (in stratum) who becomes father :)

<s​pirobel:kernal.eu> monero-project/meta #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.

<v​enture:monero.social> 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.

<a​rticmine:monero.social> I will be commenting on the block signing remix.

<a​rticmine:monero.social> With a minimum of 1% of the block reward before penalty or fees in a single transaction signed.

<a​rticmine:monero.social> As an option 10% of the total block reward in multiple transactions could also be allowed

<a​rticmine:monero.social> Block signing is included in one of the listed proposals

<a​rticmine:monero.social> I am currently working on a write-up for this

<r​ucknium:monero.social> The sub-items I have for mining pool centralization: monero-project/meta #1256#issuecomment-3207278521

<s​pirobel:kernal.eu> can you add the two questions from my comment to the TFL subpoint?

<r​ucknium:monero.social> Can you type them here? Your comment is long

<s​pirobel:kernal.eu> jbermans comment has some good thoughts as well. maybe we can condense those into questions and add them too

<r​ucknium:monero.social> Meeting time! monero-project/meta #1256

<j​effro256:monero.social> Howdy

<s​pirobel:kernal.eu> 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?

<s​pirobel:kernal.eu> B) The second question I am interested in is how higher stake behaves during real outages.

<r​ucknium:monero.social> 1) Greetings

hello

<s​gp_:monero.social> Hello

<j​berman:monero.social> *waves*

<v​enture:monero.social> Hello

<s​pirobel:kernal.eu> hai

<g​ingeropolous:monero.social> hi

<b​oog900:monero.social> Hi

<v​tnerd:monero.social> hi

<a​rticmine:monero.social> Hi

<k​ill-switch:matrix.org> hi

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<j​berman:monero.social> 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

<a​rticmine:monero.social> I am working on the block signing remix proposal and also doing research on Proof of Stake in general

<g​ingeropolous:monero.social> me: ironing out monerosim

<v​tnerd:monero.social> me: updated/rebased existing prs, bug fix for lwsf tx construction, read a few papers on selfishing mining mitigation/prevention, etc

<s​gp_:monero.social> 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

<o​frnxmr:monero.social> trying to reproduce an issue i had with big blocks. Issue disappeared when the txpool expired

<r​ucknium:monero.social> me: Performed some network construction simulations to help analyze "p2p: Improved peer selection with /24 subnet deduplication to disadvantage 'spy nodes'" monero-project/monero #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 , <clipped message

<r​ucknium:monero.social> vtnerd , and tevador . Visualizations (4 different subdomains): testnetnode{1,2,3,4}.moneroconsensus.info/

<j​effro256:monero.social> Trying to hit back review backlog for both FCMP++ and the core repo, and working on integrating tevador's double hashing idea

<s​pirobel:kernal.eu> wrote out a framework for judging the relative security of pow / pos / pow-pos hybrid solutions. monero-project/meta #1256#issuecomment-3207233765 and took a look at the monero-oxide audit / started migrating to the crate

<v​enture:monero.social> 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

<r​ucknium:monero.social> 3) Transaction volume scaling parameters after FCMP hard fork. github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-07.pdf

<a​rticmine:monero.social> 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

<a​rticmine:monero.social> Otherwise it is possible to launch a zero cost DDOS attack on the nodes

<o​frnxmr:monero.social> 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)

<j​berman:monero.social> I followed up on that here: seraphis-migration/monero #44#issuecomment-3187685572

<o​frnxmr:monero.social> 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

<a​rticmine:monero.social> I will provide a response in the thread on this.

<j​berman:monero.social> if tx is invalid, fees don't matter

<a​rticmine:monero.social> The response does not address this issue

<j​effro256:monero.social> 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 ?

<a​rticmine:monero.social> If the tx does not get mined feed don't matter

<a​rticmine:monero.social> Do you mean for node relay?

<a​rticmine:monero.social> Fees

<j​effro256:monero.social> 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?

<j​effro256:monero.social> ArticMine: that tx weight limit is a consensus rule

<j​berman:monero.social> (*150kb)

<j​effro256:monero.social> Sorry, yes that was a typo. 150kb

<a​rticmine:monero.social> So 50% of the penalty free zone

<a​rticmine:monero.social> Yes I supported that since it mitigates somewhat my concern over a DDOS attack with un economical transactions

<j​effro256:monero.social> > 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

<j​effro256:monero.social> 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

<a​rticmine:monero.social> One can split up a tx and pay lower fees because it attracts a lower penalty for each split tx. This is a given

<j​effro256:monero.social> 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

<s​pirobel:kernal.eu> 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

<o​frnxmr:monero.social> But i can ddos better with smaller txs, at a lower cost, and higher size

<a​rticmine:monero.social> The issue is a spam attack with large weight TXs where the spam TXs do not get minef

<a​ntilt:we2.ee> /my

<j​effro256:monero.social> But it's the same penalty diff for the sum of those 2 txs

<o​frnxmr:monero.social> The fee doesn't matter in that case

<s​pirobel:kernal.eu> its really the verification cost of invalid transaction that could become a ddos concern, right?

<a​rticmine:monero.social> The two TXs can be in different blocks

<a​rticmine:monero.social> So the higher penalty rate is never paid

<j​effro256:monero.social> 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

<a​rticmine:monero.social> This is not about invalid transactions

<j​effro256:monero.social> That's different from the discussion where a verification-time DoS is performed with invalid txs. The fee makes no difference in that case

<s​pirobel:kernal.eu> 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

<j​effro256:monero.social> It isn't, but you don't know if it's invalid or not until you validate it

<a​rticmine:monero.social> This is not about verification t

<a​rticmine:monero.social> Time

<a​rticmine:monero.social> I will address this in my response in the thread

<a​rticmine:monero.social> On GitHub

<a​rticmine:monero.social> Is there any else on this topic?

<r​ucknium:monero.social> 4) [FCMP alpha stressnet planning](seraphis-migration/monero #53#issuecomment-3053493262).

<s​pirobel:kernal.eu> on scaling in general I would recommend people to read up on the research about tachyaction. other than that no

<j​effro256:monero.social> > The two TXs can be in different blocks

<j​effro256:monero.social> > So the higher penalty rate is never paid

<j​effro256:monero.social> 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

<a​rticmine:monero.social> True. This is why we have not yet had a problem with this

<j​effro256:monero.social> > on scaling in general I would recommend people to read up on the research about tachyaction. other than that no

<j​effro256:monero.social> That's more related to cryptography / data availability and not traditional fee markets though. But yes, an interesting topic for sure

<r​ucknium:monero.social> spirobel: This one, right? seanbowe.com/blog/tachyon-scaling-zcash-oblivious-synchronization

<r​ucknium:monero.social> AFAIK, final bugs that would affect alpha stressnet are being squashed.

<a​rticmine:monero.social> This I have to read especially after the brutal attack on ZCash

<j​berman:monero.social> (holding on stressnet until above discussion is finished)

<s​pirobel:kernal.eu> 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.

<j​berman:monero.social> ok, I have 3 items to raise for FCMP++ alpha stressnet:

<j​berman:monero.social> 1) Set a fork date.

<j​berman:monero.social> - As proposed in a past meeting, it would fork from current testnet. So get your testnet nodes synced up and ready to go.

<j​berman:monero.social> - I would prefer to have all code merged before announcing the official start date and releasing instructions on how to join the stressnet.

<j​berman:monero.social> - I would hope to target this coming Tuesday (Aug 26th), but that depends on our ability to get the code merged beforehand.

<j​berman:monero.social> - Blocking code is linked here: seraphis-migration/monero #53#issuecomment-3053493262

<r​ucknium:monero.social> IMHO, it's best to wait until the code is 100% ready before setting a date.

<j​berman:monero.social> Ok

<j​effro256:monero.social> 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

<r​ucknium:monero.social> Do we need to announce anywhere except here? Isn't there a non-alpha stressnet planned for more community participants?

<j​berman:monero.social> 2) Here is a draft post written and ready to blast out: paste.debian.net/1392565

<j​berman:monero.social> - It includes instructions (borrowed from jeffro) on how to build monerod, CLI, RPC, and GUI using the expected alpha stressnet code.

<j​berman:monero.social> - The code would live on a new branch called "fcmp++-alpha-stressnet" in the seraphis-migration repo.

<o​frnxmr:monero.social> 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

<j​berman:monero.social> I figured it would be good to make a reddit post

<j​effro256:monero.social> What do you mean by "controlling mining"?

<j​effro256:monero.social> *controlled

<s​gp_:monero.social> Imo, it needs a paragraph on top to remind people what FCMP++ is, in ELI5 language

<o​frnxmr:monero.social> i mean, i have a script that only starts mining under certain conditions

<o​frnxmr:monero.social> Instead of every 2mins, since i cant fill blocks that fast

<j​effro256:monero.social> > Do we need to announce anywhere except here? Isn't there a non-alpha stressnet planned for more community participants?

<j​effro256:monero.social> Rucknium : probably the stressnet Matrix room I would think

<r​ucknium:monero.social> Difficulty will fall off fast you that is done

<r​ucknium:monero.social> fast if*

<o​frnxmr:monero.social> For building stressnet - we should release binaries. Building shouldnt be necessary, but of course people can build if they choose to

<o​frnxmr:monero.social> Thats fine. My diff is at 2 and i oroduce blocks every 20mins :P

<o​frnxmr:monero.social> They are ~17mb, spamming from 4 wallets

<r​ucknium:monero.social> I think I can probably use the testnetnode1.moneroconsensus.info nodes as seed node, too. 4 nodes.

<j​effro256:monero.social> ofrnxmr: perhaps I could add a tool which re-uses EC blinds and speeds up stressnet tx creation

<j​berman:monero.social> 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

<j​effro256:monero.social> Obviously, you wouldn't want to ever, ever use that for production

<r​ucknium:monero.social> I can manage some spamming from the Monero Research Computing Cluster and maybe some from my seed nodes.

<o​frnxmr:monero.social> Depends works

<o​frnxmr:monero.social> Guix not ready afaict

<j​berman:monero.social> Blinds construction is fast now with fabrizio's code merged. It's prove() that's the bottleneck: kayabaNerve/fcmp-plus-plus #34

<s​pirobel:kernal.eu> 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.

<j​effro256:monero.social> Oh, you're right..

<j​effro256:monero.social> Nvm

<r​ucknium:monero.social> I think we should see how things go at normal mining speed at first and then adjust if necessary.

<j​berman:monero.social> 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

<j​berman:monero.social> But, if no one shares that concern, then we can do binaries

<j​effro256:monero.social> Perhaps we could switch to a fixed difficulty at some point

<r​ucknium:monero.social> Is that easy to do? Don't all nodes on the network need to agree for that?

<o​frnxmr:monero.social> Probably need like 30+ wallets spamming if were actually pushing for large blocks

<j​effro256:monero.social> IIRC, `monerod --version` shows the current commit hash if not a release version, right?

<r​ucknium:monero.social> Maybe I can try to Dockerize something :D

<r​ucknium:monero.social> I don't really like Docker, but this may be a good usecase.

<o​frnxmr:monero.social> it uses 100% cpu

<j​effro256:monero.social> We can just ask them what version they're using as the first question

<o​frnxmr:monero.social> (wallet does)

<r​ucknium:monero.social> 100% of one thread or 100% of the whole CPU?

<j​effro256:monero.social> > Is that easy to do? Don't all nodes on the network need to agree for that?

<j​effro256:monero.social> Yes, they all need to agree on that. It can be supplied with a CLI argument

<r​ucknium:monero.social> The new MRC box has 256 threads and 1TB RAM

<r​ucknium:monero.social> Can almost run a Qubic node ;)

<j​berman:monero.social> doing things like mixing and matching and not realizing etc.

<r​ucknium:monero.social> ccs.getmonero.org/proposals/gingeropolous_1TB_MRC.html

<o​frnxmr:monero.social> 100% of 8-12cores here

<j​berman:monero.social> binaries are fine with me in any case

<r​ucknium:monero.social> IIRC, no one got confused when binaries were released for the last stressnet last year. Anyone remember anything about that?

<g​ingeropolous:monero.social> yaaas, someone use it!

<o​frnxmr:monero.social> binaries were the main deployment

<o​frnxmr:monero.social> Only issues we had were "idle" users who didnt update, probably at all

<j​berman:monero.social> probably biggest difference is that wallet cache /wallet impl was compatible across versions for that stressnet. the changes for fcmp++/carrot are much more significant

<o​frnxmr:monero.social> [@gingeropolous:monero.social](https://matrix.to/#/@gingeropolous:monero.social) how does mrc work, can you set me up a vm or something i can try to spam from?

<r​ucknium:monero.social> Anything more that we need to discuss here that shouldn't be shifted to #monero-stressnet:monero.social ? ( ##monero-stressnet on IRC, IIRC )

<g​ingeropolous:monero.social> yeah we can figure it out

<j​berman:monero.social> 3rd thing from me:

<j​berman:monero.social> I propose that 9473 (allow unrestricted RPC when pool is >100mb) not remain a blocker for stressnet. It has some issues and I want to give 0xFF time to continue on it. If pools end up exceeding 100mb, we can roll out the patch (or push people to use a restricted RPC instead).

<o​frnxmr:monero.social> Can just use restricted for the time being, thats what we did last time

<j​berman:monero.social> going to remove that as a blocker unless anyone raises objections

<o​frnxmr:monero.social> Even if dynamicbss isnt merged to fcmp++-stage, we should merge it to the stress branch/repo

<j​berman:monero.social> good with me^

<j​berman:monero.social> nothing else from me

<r​ucknium:monero.social> Thanks for making the final checklist and moving alpha stressnet forward, jberman

<o​frnxmr:monero.social> Rucknium, so you have testnet wallets with a lot of outputs? Or only stressnet

<r​ucknium:monero.social> Not so many now, but I will try to mine some.

<r​ucknium:monero.social> On public testnet, fees are lower than a from-genesis private testnet, AFAIK

<g​ingeropolous:monero.social> i should have a testnet wallet somewhere. xmrchain is mining.

<o​frnxmr:monero.social> Yeah, pre-tail, fees are higher

<o​frnxmr:monero.social> But my rewards are in the 100s of xmr :P

<r​ucknium:monero.social> 5) [Spy nodes](monero-project/research-lab #126).

<r​ucknium:monero.social> I ran some network construction simulations to help analyze "p2p: Improved peer selection with /24 subnet deduplication to disadvantage 'spy nodes'" monero-project/monero #9939#discussion_r2285992169

<r​ucknium:monero.social> Some interesting findings: The longest distance between nodes on a realistic network of reachable nodes is 4 hops. Converting that to milliseconds of latency using GeoIP data, it takes a maximum of about 110 milliseconds for a message to originate from one node and arraive at the farthest node, assuming speed-of-light speed, shortest straight-line distance between points on the Ea<clipped message

<r​ucknium:monero.social> rth's surface, and no CPU processing of messages.

<j​effro256:monero.social> Thank you for doing that, Rucknium

<r​ucknium:monero.social> By the way, you could probably get an analytical formula to the number of hops, since the graph is approximately 24-regular (12 outbound connections by each node). Somewhere a paper probably has the formula.

<r​ucknium:monero.social> Anything else on spy nodes?

Yeah, interesting work, as always

<r​ucknium:monero.social> My pleasure :)

<j​effro256:monero.social> Switching "already" connected subnet filtering from /16 to /24 doesn't seem to change eccentricity very much, which is good

<a​ntilt:we2.ee> is there something else to review ?

<r​ucknium:monero.social> On the PR? I don't know. I commented where I thought I could contribute.

<j​effro256:monero.social> That was my main concern with /16 to /24 already connected change, so I don't have any major criticisms after that

<j​effro256:monero.social> (for the moment)

<a​ntilt:we2.ee> @jeffro256

<a​ntilt:we2.ee> tx

<r​ucknium:monero.social> For the next agenda item, I gathered a list of possible proposals to organize the discussion: monero-project/meta #1256#issuecomment-3207278521

<r​ucknium:monero.social> We will open the floor for discussion of any type of proposal after we have walked through this specified list.

<r​ucknium:monero.social> 6) PoW mining pool centralization. [Monero Consensus Status](moneroconsensus.info). [Bolstering PoW to be Resistant to 51% Attacks, Censorship, Selfish Mining, and Rented Hashpower](monero-project/research-lab #136). [Mining protocol changes to combat pool centralization](monero-project/research-lab #98).

<r​ucknium:monero.social> ## Short-term

<r​ucknium:monero.social> **Rent hashpower to increase honest hashpower share. (HF not required)**

<r​ucknium:monero.social> miningrigrentals.com/rigs/randomx

<r​ucknium:monero.social> i.imgur.com/MQZcVC8.png (Chart by Eddie )

<r​ucknium:monero.social> xcancel.com/xenumonero/status/1957403356462268705

<s​pirobel:kernal.eu> just wanted to add one thing on the topic of spynodes

<s​pirobel:kernal.eu> If I remember correctly from the cuprate meeting on the cuprate tor implementation, boog mentioned there is trouble accepting p2p nodes over tor, because it is too cheap to make new tor hidden service addresses. (so there is the risk of eclipse attacks if tor peers are accepted.) The block lists on spy nodes seem to operate on ip addresses as well. Is there a similar concern or do<clipped message>

<s​pirobel:kernal.eu> they also contain hidden service addresses?

<r​ucknium:monero.social> The ban lists do not contain onion hidden service nor I2P addresses. Only clearnet IPv4

<s​pirobel:kernal.eu> This ties into the proposed TFL work on number 6. Could the stake be used as a way to mitigate against the costless creation of spy nodes / eclipsing peers? could that potentially help to reduce our reliance on the cost of acquiring ip addresses to mitigate these issues and we could allow nodes to completely operate behind tor more safely?

<r​ucknium:monero.social> There is some speculation about if renting hashpower from miningrigrentals (MRR) actually contributes hashpower or if it is just re-distributing honest hashpower.

<j​effro256:monero.social> Let's wait to discuss that spirobel

<o​frnxmr:monero.social> rucknium, in addition, i also think qubic hash is available to rent

<v​enture:monero.social> increase honest hashpower share might be counter-productive. Honest miners are being duped by first_seen and depending on connectivity might even fuel any attack

<r​ucknium:monero.social> IIRC, sech1 said he rented hashpower from MMR during the approach of MineXMR to majority hashpower a few years ago. I wonder if he has any information that could shed light on this question.

<v​enture:monero.social> imho

<s​gp_:monero.social> Does anyone support the monero core team renting hashrate? I'm not sure if this is an idea with supporters or just an idea

<o​frnxmr:monero.social> IIUC, MRR can shoe the current hashrate of unrented miners, assuming they arent idle

I did, but I don't know where the rigs are mining when not rented

<g​ingeropolous:monero.social> i should just setup an account and put my hashrate up for rent and see if it switches me between "mining for me" and "mining for the bidder".

<r​ucknium:monero.social> Simply based on observed prices, I think the MRR rigs are not mining when not rented. If they were mining, I would expect that the price would be lower.

<o​frnxmr:monero.social> Honestly, imo, no

<o​frnxmr:monero.social> It does

<o​frnxmr:monero.social> [@gingeropolous:monero.social](https://matrix.to/#/@gingeropolous:monero.social) kawaii did exactly that

<g​ingeropolous:monero.social> oh, then, there yah go

<r​ucknium:monero.social> I think tevador and myself showed tentative support for the idea of Core renting hashpower.

<o​frnxmr:monero.social> x.com/kawaiicrypto/status/1950967882747134402

<o​frnxmr:monero.social> xcancel.com/kawaiicrypto/status/1950967882747134402

<j​effro256:monero.social> I think about renting hashpower the same way that Qubic uses their coin to subsidize rewards to spur a higher hashrate: you are infusing external rewards to incentivize participants that wouldn't otherwise be mining without the incentive. Except, ostensibly, you wouldn't donate to a selfish miner

<v​enture:monero.social> is that not valid? happy to be wrong..

<o​frnxmr:monero.social> Jeffro, qubic could very well be the entity that you are renting from, at 40% surcharges

If qubic approaches or exceeds 50%, it can help to rent some hashrate.

<r​ucknium:monero.social> Qubic had its coin emission "halving" today, by the way: qubic.org/halving

<j​effro256:monero.social> > Does anyone support the monero core team renting hashrate? I'm not sure if this is an idea with supporters or just an idea

<j​effro256:monero.social> @sgp_ no since it's a slippery slope and the optics lead people to believe that we've more or less given up on PoW as a secure consensus mechanism

<r​ucknium:monero.social> Possibly, the halving means that Qubic has less money to subsidize miners in its pool.

<r​ucknium:monero.social> And rbrunner seems to have lost the bet to no one.

<o​frnxmr:monero.social> example, i saw rentals from from 0.7ltc per mh to 0.95, and while qubic was doing "4gh" xenus rentals were underperforming

Right!

<v​enture:monero.social> no one?

<o​frnxmr:monero.social> Go from*

<g​ingeropolous:monero.social> in general I don't think its a great first option, but it makes sense to have it as a last resort... though there's no way to tell if we'd be just inadvertently putting money into qubic

<r​ucknium:monero.social> No one took to opposing side of the bet, for 0.1 XMR. The bet that Qubic wouldn't actually halve.

<o​frnxmr:monero.social> Its a smart business model, for them to rent their hashrate at exotic prices during their marathons

<v​enture:monero.social> i should take the handle "no one". I said I take it, question was only how to verify.. than it got lost in chatter

<v​enture:monero.social> but i don't claim it

<v​enture:monero.social> *then it got lost in chatter

<r​ucknium:monero.social> If the Qubic halving has a negative effect on their hashpower, the period of maximum risk have have now passed.

<a​rticmine:monero.social> So the threat to Monero with its tail emission has dropped by 50%

<r​ucknium:monero.social> may have now passed*

<j​effro256:monero.social> Not necessarily, the price per unit of Qubic has gone up in the last 3months

That "halving" is a bit murky anyway

If I understand correctly, issue continues, but burning intensifies: qubic.org/blog-detail/qubic-s-epoch…nderstanding-its-role-in-tokenomics

<j​effro256:monero.social> Also, the rewards for XMR haven't halved, so I think the threat is definitely not reduced by 50%

<r​ucknium:monero.social> We have a lot of items. Any important points remaining on this idea?

<a​ntilt:we2.ee> I think checkpointing should deliver an organized PR blow to Q* - is this the next item ?

<a​rticmine:monero.social> The price of Qubic in terms of Monero is the critical parameter here

Renting hashrate is the exact opposite of giving up on PoW.

<a​rticmine:monero.social> The other critical parameter is the ratio of the emission rates

<s​pirobel:kernal.eu> the tokenomics of this marketing project with a blockchain are wild. so many billions

trillions

<r​ucknium:monero.social> **Follow DNS checkpoints by default (HF not required)**

<r​ucknium:monero.social> docs.getmonero.org/infrastructure/monero-pulse

<s​pirobel:kernal.eu> the question is really what the TAM is for their marketing campaign. by know everyone who could possible hear about it has probably been exposed to this

<s​pirobel:kernal.eu> the question is really what the TAM is for their marketing campaign. by now everyone who could possible hear about it has probably been exposed to this

<s​pirobel:kernal.eu> the question is really what the TAM is for their marketing campaign. by now everyone who could possibly hear about it has probably been exposed to this

<g​ingeropolous:monero.social> How often would these checkpoints be checked by monerod?

<r​ucknium:monero.social> Like I said in my update, ofrnxmr , vtnerd , tevador and myself have been testing following rolling DNS checkpoints to avoid deep re-orgs.

<o​frnxmr:monero.social> tristate is doing 2mins. Mainnet selsta proposed 5min. I dont know what is a safe number due to performance hit

<o​frnxmr:monero.social> Testnet* is doing 2mins. @ginger

<r​ucknium:monero.social> Mechanically, it seems to work ok, but some problems to smooth out. Philosophically is a different question.

<v​enture:monero.social> yeah, it's akin to trusted seed nodes.. right?

<j​effro256:monero.social> I abhor the idea of DNS checkpoints by default. Perhaps a knee-jerk reaction, but the centralization of that approach is unpalatable to me. And "HF not required" is not quite accurate. Every single time a checkpoint is pushed, a new hard fork is created. Ideally, this hard fork is not contentious, non-disruptive, and retroactive, but it is technically a hard fork

This was proposed as an emergency measure in case qubic gets to 51% and starts orphaning everyone, as they announced.

<o​frnxmr:monero.social> i think the main thing here is to not enforce by default

<o​frnxmr:monero.social> And to allow mining pools to opt-in

<r​ucknium:monero.social> You would want good, reliable DNS propagation. We observed a lot of peer banning when our simulated attack occurred. On mainnet, those net fissures could heal, but it is hard to know how quickly and easily. Monero nodes _love_ banning each other.

<j​berman:monero.social> on fluffy's proposal, I brought up the idea of requesting >50% of hash rate defend the network by not mining on top of the attacker's blocks

<j​berman:monero.social> I would probably prefer that to checkpoints. But that would not work if the attacker has >50% of the hash rate

<o​frnxmr:monero.social> dns blocklist doesnt work for >50% either

<o​frnxmr:monero.social> But should work for selfishmining deep reorgs

DNS checkpoints work for >50%

<o​frnxmr:monero.social> only if enforced on everyone

<r​ucknium:monero.social> ofrnxmr: It does work in that case, but only for the subset of nodes who have enabled DNS checkpoint enforcing.

<r​ucknium:monero.social> technically

Yes, it's essentially a hard fork that nodes would need to join. Either that or follow the 100% qubic fork.

<o​frnxmr:monero.social> The main chain wouldnt be able to overtake an attacking chain with >50%, so those nodes wouldnt switch back

<g​ingeropolous:monero.social> I definitely feel the philosophical clash, but moneropulse was meant as training wheels... the ability of the stewards of the project to keep the network healthy as it grows

<o​frnxmr:monero.social> yeah

<g​ingeropolous:monero.social> the problem is our little network still needs to grow

<o​frnxmr:monero.social> Less than 50% is _my_ goal for dns checkpoints. It makes qubic choose to mine honestly, or at mininum, keep reorgs to a low depth

<r​ucknium:monero.social> Before this month, CfB (major person in Qubic) announced that they would try to selfish mine Monero for the month of August. Maybe in Sepetmber they will stop.

<a​ntilt:we2.ee> PR: we should get the word out on twitter that the option exists; that their are wasting their time; futile; running against a firewall; etc

In any case, if we do something stupid that makes their win of prestige and attention even larger

<o​frnxmr:monero.social> The option doesnt work properly as-is, imo, due to the 1hr interval to check. that would revery 1hr worth of blocks and invalidate a lot of txs

<r​ucknium:monero.social> DNS checkpoints are a break-glass-in-case-of-emergency countermeasure. I don't see an emergency yet, but it could happen. I want to keep testing its behavior so the available options are known.

<g​ingeropolous:monero.social> and *why* it hasn't grown is a fun rabbit hole of price suppression conspiracy. there are a lot of headwinds, and using this tool to plow forward (if necessary) seems fine. its not a permanent change to anything. it can get turned off. thats not the same as other solutions being proposed

tbh they don't rent on MRR, at least the majority of their hashrate comes from datacenters. AWS or Google cloud

<o​frnxmr:monero.social> Sech1, i meant they lease their hashrate out on mrr

<o​frnxmr:monero.social> During their marathons

<r​ucknium:monero.social> selsta said in #monero-dev:monero.social : "we can reduce the DNS checkpoint load frequency from 1h to like 5min, but i don't think there will be consensus for enabling DNS checkpoints by default, too risky"

<o​frnxmr:monero.social> I think thats probably sane, and to recommend miningpools enable the enforcement option, just in case

<r​ucknium:monero.social> That is in regards to the next version release of Monero, coming very soon.

<g​ingeropolous:monero.social> yeah regardless of whether it will be used, we should definitely figure out if we can use it

+1

<r​ucknium:monero.social> IIRC, DataHorader complained that the DNS checkpoint network call was "blocking", i.e. other node operations were paused while it completed. Maybe that could be fixed.

<o​frnxmr:monero.social> The other thing that needs to be set/changed if its to be enforced, is reducing the ban time

<r​ucknium:monero.social> rbrunner: which statement did you +1?

ginger: find out whether we can use it

<r​ucknium:monero.social> DataHoarder*

correct. that's why it's disabled in recommended p2pool config

<o​frnxmr:monero.social> Could be ok if the whole network doesnt ban itself, but probably not ideal to 86400second ban all of your peers that werent using the checkpoints

<j​effro256:monero.social> ofrnxmr: what would reducing the ban time do in this scenario? If there is a network split b/t nodes which did not implement DNS checkpoints we can merge together again quicker?

<j​effro256:monero.social> Ah ok

<o​frnxmr:monero.social> yes

it blocks operations for a certain number of time, increasing latency for block data

<v​enture:monero.social> I think a short-term fix against deep-reorgs at least, is to choose on stratum deterministically which branch to adopt.

<v​enture:monero.social> it frees trapped hashrate and would prevent deep reorgs. incentive-wise..i don't know. it fixes gamma to 0.5.

(it should be done asynchronous from main logic)

<r​ucknium:monero.social> Ok I will keep experimenting with it. I have testnetnode4.moneroconsensus.info set to follow rolling DNS checkpoints on testnet and testnetnode 1 - 3 not following. I will probably change #3 to follow checkpoints to have half of them following.

DNS checkpoints are the nuclear option. If we are ready to "press the button", it might be enough to discourage the attack.

<r​ucknium:monero.social> _How I learned to stop worrying and love the DNS checkpoints_

Maybe. Attacking and then not succeeding might not cost them much either way.

<r​ucknium:monero.social> **Detective mining (HF not required)**

<r​ucknium:monero.social> monero-project/research-lab #140

<r​ucknium:monero.social> eprint.iacr.org/2019/486

<r​ucknium:monero.social> ceur-ws.org/Vol-3304/paper15.pdf

<a​ntilt:we2.ee> yep, psychology is part of it

<v​enture:monero.social> "and immediately mines a "counter" child block on top" <-- doesn't this need to have valid PoW, ie takes time?

<a​rticmine:monero.social> This falls in my view into the category of low impact mitigations and as such should be supported

Detective mining won't work against >50%, it's only against selfish mining strategies.

<g​ingeropolous:monero.social> well, you can still have >50%. it would prevent the attacker from using the 51% nefariously... maybe?

<v​enture:monero.social> tevador I learned your proof, anything that fixes 50% is not PoW anymore :)

<a​rticmine:monero.social> While an individual low impact mitigation may have a limited impact on the attacker, the cumulative impact of multiple low impact mitigations can effectively block an attack.

<g​ingeropolous:monero.social> just because you have a majority of the hashrate doesn't mean you are going to find all the blocks, unless you selfish mine. probabilistic random blah blah

<v​enture:monero.social> question is do we want that protection or encourage mining adoption.

<r​ucknium:monero.social> sech1 had thoughts on detective mining. (Just trying to ping sech1 )

Either I don't understand something, or it won't do anything against the current attack. I commented there.

<r​ucknium:monero.social> sech1 : I agree that there is a risk when the attacking chain gets long.

<j​berman:monero.social> On first pass, detective mining seems sensible to attempt me assuming hash rate <50% is willing to implement. If >50% is willing, then I think ignoring the attacker's blocks is optimal. I'll respond to fluffy in a second

<v​enture:monero.social> to prevent long growing attacking chains, I think a short-term fix against deep-reorgs at least, is to choose on stratum deterministically which branch to adopt. It frees trapped hashrate and would prevent deep reorgs. incentive-wise..i don't know. it fixes gamma to 0.5.

I also have doubts about it. I think it's a good strategy to detect a potential attack, but probably not a practical defense. On a related note, it might be a good idea to put an explicit block height into the hashing blob at the next HF.

<g​ingeropolous:monero.social> as mentioned, it seems low-impact, otherwise benign

<r​ucknium:monero.social> Isn't an attacking chain with parity to the main chain usually last-seen? And when it has +1 advantage over the main chain, it will be chosen to mine on top of anyway?

<g​ingeropolous:monero.social> and it falls mostly on pool-ops to implement, and they should be incentivized because they are losing block rewards.

<s​gp_:monero.social> I'm certainly interested in a no/low-downsides way to make selfish mining worse, even if it doesn't address 51%+. I haven't had enough time with the proposal to really think about what the potential downsides could be. I think this proposal warrants continued discussion/research

<r​ucknium:monero.social> With a hard fork, you could require the RandomX hash to start with the whole block, right? Then mining pools would have to send the whole block and a "detective" would have the block in plaintext.

<r​ucknium:monero.social> That would reduce the incentive to produce high-tx blocks, however, I think.

<j​effro256:monero.social> This approach simply seems like a much, much more complicated scheme of just not mining on newly encountered alt chains. Selfish mining alt chains will almost propagate after "honest" alt chains, so if miners don't switch chains up to a certain depth, I would think that you can achieve almost the same effect without all the detective work

<v​enture:monero.social> that is the re-org point.

<v​enture:monero.social> and no, it's not always last-seen. depending on gamma (connectivity of the selfish pool to honest miners), it traps honest ppl onto mining their chain and leaves less hashpower to original one

rucknium: No, the pool would just send the Blake2b midstate, which is ~200 bytes.

<v​enture:monero.social> gamma will reduce over time, or the majority will anyways catch-up, that's when they publish all and do the re-org

<r​ucknium:monero.social> tevador: Thanks.

<g​ingeropolous:monero.social> jeffro256: , but how do you distinguish between that and a re-org. I guess the case of a netsplit and recover is the only case perhaps.

tevador no, not if the whole block is the RandomX input

<s​gp_:monero.social> fwiw, my understanding is that this proposal would not discourage selfish mining by an entity that doesn't solicit hashrate from the public. afaik. So there's limited potential benefit

<j​effro256:monero.social> gingeropolous: You don't, or you could allow very shallow re-orgs (1 to 2 blocks). But if majority does the same, then you don't lose funds from building "behind"

If the nonce field comes before the block data, you can't use a midstate. If it comes after, you can.

<g​ingeropolous:monero.social> sgp_: but its potentially the most relevant. idle hashpower is sorta the problem here.

<g​ingeropolous:monero.social> forcing an attacker to build datacenters is sorta the juice of PoW IMO

<g​ingeropolous:monero.social> juice = essence.

<s​gp_:monero.social> I think it's hard to definitively say it's the most relevant. If it is expected to be profitable, an attacker could rent private servers and still selfishly mine on their own

<a​rticmine:monero.social> It is part of it

<g​ingeropolous:monero.social> thats the same sgp_

<r​ucknium:monero.social> Is Diego Salazar from Cypher Stack here?

<d​iego:cypherstack.com> always

<r​ucknium:monero.social> Are you still considering looking into this issue? Maybe we could divide-and-conquer the vast literature on this topic.

<d​iego:cypherstack.com> Yes, we've already done several days of research here.

<r​avfx:xmr.mx> y

<r​ucknium:monero.social> And I will use this opportunity to share some big-picture papers that I have tentatively put on my reading list:

<r​ucknium:monero.social> Zhang, R., Preneel, B. (2019) "Lay down the common metrics: Evaluating proof-of-work consensus protocols’ security." doi.org/10.1109/SP.2019.00086

<r​ucknium:monero.social> Azouvi, S., Hicks, A. "Sok: Tools for game theoretic models of security for cryptocurrencies." arxiv.org/abs/1905.08595

<r​ucknium:monero.social> Judmayer et al. (2021) "SoK: Algorithmic Incentive Manipulation Attacks on Permissionless PoW Cryptocurrencies" eprint.iacr.org/2020/1614.pdf

<r​ucknium:monero.social> Andrew Lewis-Pye, Tim Roughgarden (2024) "Permissionless Consensus" arxiv.org/abs/2304.14701

<r​ucknium:monero.social> Eric Budish, Andrew Lewis-Pye, Tim Roughgarden (2024) "The Economic Limits of Permissionless Consensus" arxiv.org/abs/2405.09173

<r​ucknium:monero.social> Budish, E. (2025). "Trust at Scale: The Economic Limits of Cryptocurrencies and Blockchains" moneroresearch.info/101

<d​iego:cypherstack.com> Luke Szramowski: Rigo Salazar ^

<d​iego:cypherstack.com> cuz

<r​ucknium:monero.social> The Azouvi & Hicks paper is (2020)

<r​ucknium:monero.social> Someone can decode the computer science jargon and I can decode the game theory jargon.

<r​ucknium:monero.social> ## Medium-term

<r​ucknium:monero.social> **N-block rolling checkpoint (HF recommended)**

<r​ucknium:monero.social> blog.bitmex.com/bitcoin-cash-abcs-rolling-10-block-checkpoints

<r​avfx:xmr.mx> Diego Salazar Focus follow Mouse, it moved into the matrix window... The "y" was ment for the package manager... just did not want to pollute more the room with edit because we have IRC.

<r​ucknium:monero.social> This is a rule that nodes don't re-org if the proposed alt chain is longer than N blocks

<s​pirobel:kernal.eu> Rucknium: there is also this papers.ssrn.com/sol3/papers.cfm?abstract_id=4727999 compares cost of attack on eth vs btc

<d​iego:cypherstack.com> k

<v​enture:monero.social> I'm sorry Rucknium did anyone comment on my short term proposal? just the stratum determinist mining

<v​enture:monero.social> *proposal as in mentioned here in the meeting while this agenda short term fix was brought up

<r​ucknium:monero.social> I did, but maybe the relationship was not clear.

Here is a consensus mechanism specifically designed to prevent selfish mining, might be worth reading: eprint.iacr.org/2016/916

<v​enture:monero.social> anyways, seems not catching on. ok

<d​iego:cypherstack.com> We're looking into things, obviously, but I'd like to say something about this whole shebang. PoW and PoS has been debated for years at this point. Yes there's new research, but pretty much all this research is going to come with tradeoffs to the current social contract that many will find unacceptable.

<d​iego:cypherstack.com> There's very little "new" in any of our debates or research here.

<r​ucknium:monero.social> tevador: I have a newer, better proposal later on the agenda that builds on Fruitchains.

<d​iego:cypherstack.com> At some point, somebody is going to have to take lead on something and code it up for discussion. Someone gotta take charge a bit.

<d​iego:cypherstack.com> The transition from full PoW, if that is what is decided, is going to be painful, and we will lose people. And where we end on the spectrum from PoW to PoS is honestly kind of irrelevant.

<s​gp_:monero.social> I might prefer dns checkpoints to n-block rolling checkpoints, honestly :/ at least those won't cause a chain split among adopted nodes

<d​iego:cypherstack.com> Every step along the spectrum has its own trade-offs, with the either end of the spectrum generally requiring the least centralization

<d​iego:cypherstack.com> things like DNS checkpoints and other stuff more towards the middle require more centralization

<r​ucknium:monero.social> Diego Salazar: I don't know what the literature says, so it's still new to me. And the big-picture articles I shared were released in the last few years. Some of those are "top-down" theorem-building. Different from specific protocols.

<d​iego:cypherstack.com> anyways, that's my thoughts. I'm done.

I just wanted to note that several proposal in #136 were marked as "needing a soft fork". Soft forking requires the majority of the hashrate to start following the new rule, so it can't work against a >50% attacker. It would have to be a hard fork.

<d​iego:cypherstack.com> We're trying to go over newest literature now, but there's nothing new under the sun.

<r​ucknium:monero.social> More on N-block rolling checkpoint?

I wouldn't recommend rolling checkpoints due to chain split concerns.

<a​ntilt:we2.ee> iirc rolling checkpoints can be gamed (comment in #136)

<r​ucknium:monero.social> I think the concern with forcing a netsplit when releasing a N-block alt chain at exactly teh right time could be fixed by deterministic chain tip selection (based on hash) for only that 10-block re-org threshold. Maybe.

<r​ucknium:monero.social> **Shorten target block time interval (HF required)**

<r​ucknium:monero.social> bitcoincashresearch.org/t/lets-talk-about-block-time/471

<r​ucknium:monero.social> blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times

<r​ucknium:monero.social> > The conclusion of all this is simple: faster block times are good because they provide more granularity of information. In the BFT [Byzantine Fault Tolerant] security models, this granularity ensures that the system can more quickly converge on the "correct" fork over an incorrect fork, and in an economic security model this means that the system can more quickly give notificati<clipped message

<r​ucknium:monero.social> on to users of when an acceptable security margin has been reached.

<r​ucknium:monero.social> By the way, I put these two in "medium-term", because they require a hard fork, but not much code-writing.

<b​lurt4949:matrix.org> tevador: they could also be done with a UASF, a hard fork is not necessarily required even assuming we have <50% honest hashrate

<g​ingeropolous:monero.social> the simplicity of "shorten target block time" is impressive.

<s​gp_:monero.social> back to 1 minute block times #thankfulfortodaywasright

<g​ingeropolous:monero.social> and this could be in addition to whatever else ends up getting implemented.

<s​pirobel:kernal.eu> Diego Salazar: agree somewhat. the literature can only get us so far. academics are only mere mortals after all. Rucknium regarding big picture theory building there seem to be not much out there. Building a reading list for this category seems helpful. The only one I came across was this one by Roughgarden (one of the authors of the papers that you mentioned) arxiv.org/pd<clipped message>

<s​pirobel:kernal.eu> f/2304.14701 after reading it I am a bit skeptical its helpful. We should really do a critical reading of those and not accept them at face value.

USAF is essentially a hard fork because it can cause a chain split, unlike a mining-majority soft fork.

<r​ucknium:monero.social> Agree on critical reading.

<s​gp_:monero.social> I'm ultimately for whatever block time makes sense, I don't really care. I just know this won't address selfish mining on its own

<r​ucknium:monero.social> ## Long-term

<r​ucknium:monero.social> **Require Blocks be Signed by the Miner's Key (HF required)**

<r​ucknium:monero.social> monero-project/research-lab #136

1 minute block time was abandoned for a reason - high orphan rate.

<r​ucknium:monero.social> > With a minimum of 1% of the block reward before penalty or fees in a single transaction signed. As an option 10% of the total block reward in multiple transactions could also be allowed

<a​ntilt:we2.ee> stupid question: how would 1min blocktime that hinder Qubic?

<r​ucknium:monero.social> ArticMine is writing a formalization of this

<r​ucknium:monero.social> Didn't the high orphan rate happen because Fluffy Blocks weren't implemented yet?

<s​gp_:monero.social> I'm against this one unless I'm missing something major. It seems to do nothing afaict

<j​effro256:monero.social> The orphan rate for 1-minute blocks will probably only get worse under FCMP++ unfortunately because of higher bandwidth and computation requirements for txs

<g​ingeropolous:monero.social> but healthy orphans are fine, right?

<v​enture:monero.social> it's still wasted hashrate

<j​effro256:monero.social> I'm not convinced that a lower block time helps the state converge when one of the participants is purposefully withholding state information like in a selfish mining scheme

<g​ingeropolous:monero.social> i wonder if it could be coupled with uncle blocks

<r​ucknium:monero.social> AFAIK, uncle blocks make selfish mining worse.

<v​enture:monero.social> 😅 oh shit

<r​ucknium:monero.social> Check the Selfish Mining Re-examined paper

<r​ucknium:monero.social> **Construct RandomX cache by selecting random parts of the blockchain (HF required)**

<r​ucknium:monero.social> monero-project/research-lab #98

<o​frnxmr:monero.social> i commented there, but this essentially cuts out thr majority of gupax users

<s​gp_:monero.social> (gupax defaults to using a remote node fwiw)

<o​frnxmr:monero.social> Which is probably only like 15mh.. but is also probably 90% of the vocal minority

<a​ntilt:we2.ee> +1 if drop in HR is no concern. Major re-org of network topology

15 MH is almost nothing, but it would hurt centralized pools and hashrate rental services hard.

<r​ucknium:monero.social> Reachable node will probably be hit with a big increase of their inbound connections.

<g​ingeropolous:monero.social> it seems like something we should move towards. hard to see it as a binary switch. maybe there's a transition period where n% of blocks require it ?

<o​frnxmr:monero.social> The mh is nothing, but its potentially 1000+ users

Centralized pools are also thousands of users.

<a​ntilt:we2.ee> no way to phaze this in slowly... ?

<o​frnxmr:monero.social> thousands of p2pool users*

<s​gp_:monero.social> I think this proposal will mostly harm small miners who will no longer be able to mine (in practice) without a node. Yes they're a minority of total network hashrate, but it does substantially deviate from a goal of "anyone can mine". That said, I do see the arguments for, even if I think they are somewhat marginal (large miners still have incentives to use pools, and the costs ar<clipped message>

<s​gp_:monero.social> e constant not scaling with hashrate)

<g​ingeropolous:monero.social> in qubics case, they would just having to spin up a node doing this, some pool software, and then find a way to get the blockchain data to their workers... really fast?

<o​frnxmr:monero.social> a good chunk of p2pool mini are gupax users

It would be possible to slowly decrease the RandomX epoch from the current 2048 block down to the proposed 64 blocks.

<r​ucknium:monero.social> ofrnxmr: Source on that data?

<o​frnxmr:monero.social> "i made it up" @rucknium

<b​lurt4949:matrix.org> Not sure if anyone else sees this is as a serious threat especially given the current pressing Qubic situation, but fwiw this proposal would obviously decrease total hashrate by a lot, making us more vulnerable to coordinated attackers (institutional, nation-state, etc)

<o​frnxmr:monero.social> the opposite is likely more true. (almost) all gupax users are on -mini, but not all -mini users are gupax users

<a​ntilt:we2.ee> might actually put Qubic (AWS) in an advantage

<s​gp_:monero.social> I think this proposal will cause a net decrease in the total hashrate, with most of the drop contained to small miners

Any PoW change will likely decreased the hashrate temporarily.

<g​ingeropolous:monero.social> what would an attacker have to do if we had this protocol

<o​frnxmr:monero.social> right. This hurts pools and unattended botnets, but not necessarily qubic, who has 700 nodes with 2tb ram. Can probably afford the bandwidth

<s​gp_:monero.social> I think it'll be a net decrease at equilibrium

<g​ingeropolous:monero.social> does anyone know? has there been a paper on this?

<o​frnxmr:monero.social> So this could, in theory.. lead to qubic (immediately) having a (much) larger %

<g​ingeropolous:monero.social> well it depends if they can get the data from a blockchain quick enough right?

<o​frnxmr:monero.social> Any pow change at all will knock botnets offline for a while, but not qubic

<b​lurt4949:matrix.org> ofrnxmr: I think that is most likely. I think the average Qubic hash/sec is more likely to run a node than the average honest hash/sec

Probably 80% of the honest hashrate comes from the top 20% largest miners, who can easily afford to run a node and join p2pool. I don't see a reason for a large permanent drop in hashrate. Qubic's distribution is likely very similar.

<r​ucknium:monero.social> **Countering Selfish-Mine: Promote orphans to uncles (equal pay) and choose deterministically in stratum) who becomes father (HF required)**

<r​ucknium:monero.social> libera.monerologs.net/monero-research-lab/20250820#c568556-c568579

<o​frnxmr:monero.social> I think 80% of "honest" hashrate is botnets, who would drop off

<s​gp_:monero.social> I agree the largest miners will be essentially unaffected

<o​frnxmr:monero.social> Again, i dont have a source for my thoughts

It would be a big win if 80% of the hashrate migrated to p2pool.

<v​enture:monero.social> i guess this agenda can be skipped. didn't know uncles make it worse. i checked the paper quickly, not sure that they do make it worse in combination of a join (banded together) mining strategy (stratum)

<v​enture:monero.social> with an orphan / uncle and re-org: avg payout would be 0.5.

<v​enture:monero.social> either 0.5 + 0.25 (if branch was chosen)

<v​enture:monero.social> or 0.25 (if branch was not chosen)

<v​enture:monero.social> avg: 0.5

<v​enture:monero.social> the point is, it collapses the 2 branches into one as quickly as possible

<v​enture:monero.social> *joined

<a​ntilt:we2.ee> I doubt, that uncle rewards change the way Qubic operates. Switching miners (~5%) does not seem relevant at large.

<r​ucknium:monero.social> **Friction (HF required)**

<r​ucknium:monero.social> "Amends fork choice rule to give greater weight to blocks produced by miners that have a history of mining"

<s​gp_:monero.social> I think the most realistic outcome is that the largest miners will continue to use pools. It's simpler (and potentially even cost effective) to have the pools deduct the bandwidth costs from payouts for these large miners than the cost for the miners to need their own nodes (storage and local bandwidth costs)

<r​ucknium:monero.social> I think gingeropolous know info about this Friction idea

<g​ingeropolous:monero.social> here's the bat bones

<g​ingeropolous:monero.social> 100% human generated

<g​ingeropolous:monero.social> github.com/Gingeropolous/friction/blob/main/batbones.md

<s​gp_:monero.social> Wouldn't this encourage people to join the largest pool, to ensure the blocks mined there have the greatest "weight" (friction?)

<g​ingeropolous:monero.social> yeah its not anti-pool, its mostly anti selfish mining

sgp_: I'm not convinced that the costs of running a node are higher than the bandwidth costs for mining at a centralized pool + the pool fee.

<a​ntilt:we2.ee> "the secret"... whats that, again ?

<g​ingeropolous:monero.social> which i view as the main fulcrum of the current attack

<g​ingeropolous:monero.social> but in general, friction doesn't affect honest mining

<r​ucknium:monero.social> **Proportional Reward Splitting (HF required)**

<r​ucknium:monero.social> Paper claims that Proportional Reward Splitting can defeat a selfish miner that has up to 38% of hashpower

<r​ucknium:monero.social> arxiv.org/abs/2503.10185

<r​ucknium:monero.social> I haven't finished reading this paper, but I like it because it's recent (2025) and actually claims to have computed the Nash equilibrium game theory of the proposed protocol.

Is this the paper that builds on fruitchains?

<v​tnerd:monero.social> most likely, it mentions it in the abstract

<r​ucknium:monero.social> I think there could be some downside (the paper states that the "optimal" and "practical" parameter values are different), but I haven't gotten there yet.

<v​tnerd:monero.social> er maybe not

<r​ucknium:monero.social> tevador: yes

<r​ucknium:monero.social> It says FruitChains had some problems. This protocol fixes them.

<a​ntilt:we2.ee> tldr; not wort the efford

<r​ucknium:monero.social> Might not be worth the effort of coding and testing. Right.

<a​ntilt:we2.ee> *h -- it redestributes rewards ok (nice to have) but works for >51% only. Very complex to implement.

<r​ucknium:monero.social> But. To compete with this proposal I would prefer novel proposals on selfish mining to try to quantify their benefit.

<r​ucknium:monero.social> Works for >51% of miner adoption? This is a consensus change, not opt-in.

<a​ntilt:we2.ee> of hash power

<s​pirobel:kernal.eu> the paper seems complex and math heavy. the consensus should be as simple as possible so that people can trust it and it stays easy to reason about

<s​pirobel:kernal.eu> would the implementation mirror this complexity?

<r​ucknium:monero.social> I don't think I like a weak protocol that is easy to reason about instead of a strong protocol that is difficult to reason about.

<r​ucknium:monero.social> Anyway, the selfish mining attack is against the Nakamoto "simple" protocol.

<r​ucknium:monero.social> The paper has a lot of jargon that is not necessarily needed.

<r​ucknium:monero.social> Because it's formal

<a​ntilt:we2.ee> may be not so complex to implement, but I dont understand their criticism/weakness of fruitchanes tbh

<s​pirobel:kernal.eu> problem with complexity is, it is harder to judge if its actually stronger or not.

<r​ucknium:monero.social> If you have a mathematical proof, that's the reasoning.

<r​ucknium:monero.social> We are at the last specified sub-item (open floor discussion can continue after).

<r​ucknium:monero.social> **Finality Layer (HF required)**

<r​ucknium:monero.social> monero-project/research-lab #135

<r​ucknium:monero.social> repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604

<r​ucknium:monero.social> kayabanerve: This is the Trailing Finality Layer discussion.

<g​ingeropolous:monero.social> is this like if the N-block rolling consensus was conscious? had human input?

<a​ntilt:we2.ee> a long term efford, tbs

<v​enture:monero.social> not sure about these fruits, and what they abstract. but they do have the concept of uncle-fruits, claiming nash equilibrium because of the reward allocation. so my 2 cents, the existence of uncle blocks alone does not necessarily mean they benefit selfish mine

<a​ntilt:we2.ee> yep, iiuc

<a​ntilt:we2.ee> also envisioned as a separate binary/p2p net (?)

<r​ucknium:monero.social> I am lukewarm (pun not intended) toward this TFL CCS proposal because I think it's a few weeks premature and kayabaNerve obviously has a high opportunity cost of his time.

<r​ucknium:monero.social> I say premature because the whole space of countermeasures and alternative proposals has barely had its surface scratched. The high opportunity cost is reflected in the budget of the proposal.

It introduces PoS, which might be opposed by some people as being against the ethos of Monero.

<v​enture:monero.social> TFL question, would a finality layer completely override the longest/heaviest chain rule from the underlying PoW? Because, to me, once finality is required (eg, by exchanges) miners will always jump ship and mine on any branch endorsed by that layer.

<r​ucknium:monero.social> I'm not against it. I think more research is good. Just lukewarm on it.

<s​pirobel:kernal.eu> i think we should at least reach consensus on which questions we want answered

IMO, a good way forward would be: (1) Test the DNS checkpointing as an emergency short-term measure. (2) Research a consensus protocol that works with PoW (assuming >50% of honest hashrate) and fixes selfish mining.

<g​ingeropolous:monero.social> im not a fan of how it seems to be PoS-like

<a​ntilt:we2.ee> yes, we should subdevide the topic. BFT has many many options

<g​ingeropolous:monero.social> yeah i think we have 2 issues. 1. selfish mining 2. mining centralization.

<a​ntilt:we2.ee> ... and I like recursive elements (including friction :)

<a​ntilt:we2.ee> ... like malicious collective detection, in Gasper -- but thats too far away.

<s​pirobel:kernal.eu> dns checkpointing as a long term solution seems more centralizing than pos

I don't think anyone is proposing DNS checkpointing as a long term solution.

<s​pirobel:kernal.eu> there could be a benefit to have nodes with a bond that could be slashed beyond consensus

<s​pirobel:kernal.eu> we could discuss this outside of the pow-pos paradigm and think about it pragmatically

<s​pirobel:kernal.eu> brought this up earlier at agenda point 5: it could help increase the cost for malicious nodes spinning up tor hidden services

<s​pirobel:kernal.eu> blocking based on ips is a form of centralization as well

<s​pirobel:kernal.eu> anyway its 4am here i am running out of steam: wrote down a comment on this earlier: monero-project/meta #1256#issuecomment-3207233765

<a​ntilt:we2.ee> maybe we could have a work group instead a book ??

<s​pirobel:kernal.eu> i also like what jberman said about no fees + rewards. Its similar to what I said earlier that pow can be seen as pos with negative staking rewards if people are willing to defend the network by mining at a loss

<r​ucknium:monero.social> Feel free to discuss any idea now, including those not on the specified list.

<v​tnerd:monero.social> the few papers I looked at were junk, lots of half attempts to fix selfishin mining

<r​ucknium:monero.social> Thanks for wading through the junk. Can you share a few so we know to avoid them?

<s​pirobel:kernal.eu> flip flop: good idea, only question is how do we make sure it stays structured? can we agree on the core questions that should be answered?

<v​tnerd:monero.social> google ai recommended this: link.springer.com/article/10.1007/s10207-024-00857-5

<v​tnerd:monero.social> but I didnt like it. so much for ai

<v​tnerd:monero.social> I spent way too much time looking at it, their algorithm wasn’t quite clear imo which threw everything off

<a​ntilt:we2.ee> 1. DIff. BFT <> Pos 2. Design choices based on historical imlementations

<v​tnerd:monero.social> they also assumed that the selfishing miner would have an older timestamp which is rubbish because you would just set to the max allowed by protocol

<v​tnerd:monero.social> its possible that I missed something, but I wasn’t getting it. not sure if I can share it because its all begin paywall

<r​ucknium:monero.social> I skimmed the abstract on this one I think. I remember thinking that the tone was informal. Maybe that's an arrogant thought, but it stopped me from going further.

<v​tnerd:monero.social> *behind

<v​tnerd:monero.social> well their own algorithm has

<v​tnerd:monero.social> NumOfBrBlocks <- 0

<v​tnerd:monero.social> if (NumOfNrBlocks = 1) then

<s​pirobel:kernal.eu> Rucknium: more formal == better at hiding the skeletons in the closet 💀

<j​effro256:monero.social> This is especially true since we have a block difficulty calculation lag, so setting the timestamp ahead doesn't make our mining harder. If they set it too far in the future (>2 hours in Monero) then it will be rejected, but they can wait a certain amount of time depending on how far ahead they are of the honest chain

<v​enture:monero.social> "It’s very unfair for honest miners, and it’s a big problem that needs to be stopped." from the abstract... yeah quite informal to put it nicely 😅

<v​tnerd:monero.social> like what? I think they meant to say NumOfBrBlocks published at once or something but even with that assumption I dont think it worked

<v​tnerd:monero.social> sorry there was typo in that algorithm, they indeed set a value to 0 and then do an if on that value with stating what it really should be

<r​ucknium:monero.social> spirobel: I don't disagree with you on that. You need a closet detective for that.

<v​tnerd:monero.social> I wish I could copy+paste a portion from this pdf but I cant sorry (wont let me copy for whatever reason)

<v​tnerd:monero.social> anyway, hopefully I didn’t misread it and it was a good paper in the end. May go over it again since I paid for it and all. Never trust AI lol

<j​effro256:monero.social> Oops, sorry, falsely setting the timestamp in the future would make the mining *easier* with real-time targeting, but the point still stands: faking timestamps is still possible and doesn't hurt a selfish miner if done correctly.

<v​tnerd:monero.social> yes, an excerpt from the paper:

<v​tnerd:monero.social> "If miners broadcasted more than one block in the same time interval, one block should be selected as the valid block. Selfish miners keep their blocks secret for some period of time. Therefore, selfish miner’s block’s timestamp is old.”

<v​tnerd:monero.social> like what? how can you assume that? not all papers are the same

<r​ucknium:monero.social> We can end the meeting here. Feel free to continue discussing, as I know you will. Thanks everyone.

<s​pirobel:kernal.eu> thanks

<v​enture:monero.social> bye

<a​ntilt:we2.ee> bye

<s​gp_:monero.social> thank you

<s​pirobel:kernal.eu> vtnerd: i heard about this new ai project called aigarth that mines ai on cpus maybe it can solve that 😆

<s​pirobel:kernal.eu> the marketing material says something about growing the ai in a garden

<v​tnerd:monero.social> the other interesting thing about all of this is that not all tokens in the available supply were generated for ai computation - some were used to selfish mine xmr, etc.

<v​tnerd:monero.social> just interesting from an optics standpoint

<v​tnerd:monero.social> this is assuming the ai computation is genuine also

<s​pirobel:kernal.eu> as genuine as an ai garden could be

<s​pirobel:kernal.eu> if only jensen new. he could have invested in cpus instead of gpus

<s​pirobel:kernal.eu> if only jensen knew. he could have invested in cpus instead of gpus

<k​ayabanerve:matrix.org> Apologies for missing the MRL meeting. I've been working on migrating monero-serai to monero-oxide and upstreaming the FCMP++ libraries (which had included >13,000 lines forked from Serai's cryptography, but doesn't anymore).

<k​ayabanerve:matrix.org> Rucknium: Heard you're lukewarm as we haven't scratched the surface on proposals. My CCS would scratch the surface on a finality layer :p

<k​ayabanerve:matrix.org> (I understand and respect Rucknium's point)

<b​awdyanarchist:matrix.org> Not sure if it was mentioned, but here's the implementation of Eth Classic Modified Exponential Subjective Scoring (MESS). Basically depth penalty based on the time differential between the last common ancestor, and the new (reorg'd) head.

<b​awdyanarchist:matrix.org> ecips.ethereumclassic.org/ECIPs/ecip-1100