<f​ullninja:matrix.org> Proposing an idea to solve qubic saga and make p2pool more rbust for long term

<f​ullninja:matrix.org> Creating an option on p2pool to donate a chosen % of the mining rewards to use it as an extra mining reward on p2pool.

<f​ullninja:matrix.org> Assuming there's enough miners who care more about decentralization then short term profit (enough to create bigger subsidies then qubic) then we can end this saga, and make p2pool stronger for long term.

<f​ullninja:matrix.org> .

<k​ayabanerve:matrix.org> That isn't a solution, albeit it's a feature request for sech1.

<f​ullninja:matrix.org> Why isn't it a solution?

<k​ayabanerve:matrix.org> Because it's a potential improvement based on voluntary subsidiaries to combat other pools from offering subsidies, not a fundamental solution.

^ as I see it within p2pool workings someone's share could "opt" to some degree into being provided to current PPLNS range

that way it can get seen in the regular scan for earnings/transaction building for rewards

so it's not giving anything more like they "donate" their share weight to others

would require p2pool changes ofc

the alternative is, you can get current miner addresses on p2pool, and, just mine on p2pool yourself on those addresses

that works today, and xvb already does that

<f​ullninja:matrix.org> if there will be enough subsidies from donated mining rewards we can make future attacks harder. Not a fundamental solution but a good temporarily solution that can also be used in future events ("good" miners will increase the % of donated reward every time a centralized pool gets too big)

<k​ayabanerve:matrix.org> DataHoarder: you can just only submit a fraction of the shares you actually mine.

that too

you can do it today, as described ^

<a​ntilt:we2.ee> @fullninja:matrix.orgif you are positive that the attacker mines empty blocks only, choosing a higher fee tier will do no harm other than reducing your privacy a little.

they mine all

sometimes they mine empty

it was mentioned here, as they disconnect from network to do selfish they run out of mempool and high blocks in their attempts end up empty

You can get a list of p2pool wallet addresses, and either send XMR to them directly, if you wish so, or mine to their wallets

<a​ntilt:we2.ee> ... then feed your LLM to brag about it :)

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

<k​ayabanerve:matrix.org> FYI, I am considering drafting a CCS on a finality layer and would have to prioritize:

<k​ayabanerve:matrix.org> A) The design and documentation

<k​ayabanerve:matrix.org> B) A proof of concept finality binary, which if necessary, could be immediately deployed using Ethereum as the finality layer

<k​ayabanerve:matrix.org> C) The implementation of my nominated consensus algorithm, which is the part that'll likely take the longest to competently do

<k​ayabanerve:matrix.org> I'm sure this'll be discussed during the meeting (one of the bullets is my meta-issue), but I wanted to raise this question *a bit* beforehand to give people some time to think/get any basics out of the way. I'm sure I'll restate all relevant parts during the meeting to ensure everyone is up to speed though.

<k​ayabanerve:matrix.org> At first glance, C seems like a horrible option. The reason it's present as an option is because if Monero ever deployed a BFT finality layer, the consensus algorithm used is largely independent from how it's glued into Monero (which is what A is). They're two parallel tracks BUT most of the time on auditing, performance, p2p networking, would be spent on the consensus algorithm (<clipped message

<k​ayabanerve:matrix.org> hence why it arguably should be done first).

<k​ayabanerve:matrix.org> But all of this would be to begin development on a potential future choice, and we'll have the best education and discussions with option A.

<f​iatmoneysucks:matrix.org> Unfortunately, I won't be present, but I wish everyone who will participate a good meeting.

<a​tomfried:matrix.org> Regarding the BFT layer, i think the main concern is how to choose the validators. I guess thats part if A)?

<a​tomfried:matrix.org> *of

<k​ayabanerve:matrix.org> Technically, any method of 'stake' would work in a decentralized fashion, yet the proposals have been blocks mined or XMR. The former doesn't work _well_. It either has too long a window, and requires anyone who mines a block also runs a node for a year, or too short a window, and doesn't protect against 51% attacks which can be sustained for a few weeks.

<k​ayabanerve:matrix.org> Or they've been unquantifiable concepts like a node's reputation, or centralized such as 'the Monero team'.

<k​ayabanerve:matrix.org> *I'm not asking for feedback on a CCS which doesn't exist. I'm trying to take a temperature check to decide if I should submit a CCS and if so, how.

<k​ayabanerve:matrix.org> Sorry if this is too vague at this time

<k​ayabanerve:matrix.org> Though that'd be its own form of feedback 🤔

<a​tomfried:matrix.org> What is the Main reason of the proposed bft algorithm?

<a​tomfried:matrix.org> I guess it should be quantum safe and asynchronous?

<a​tomfried:matrix.org> Couldnt narwhale also fit this?

<d​ufebo98:monero.social> Can some of ETH‘s Casper FFG be introduced

<k​ayabanerve:matrix.org> Tusk isn't PQ. Ethereum's consensus isn't formally proven (though some derivatives are).

<k​ayabanerve:matrix.org> (Tusk assumes a random coin, and practically, random coins are done via BLS. While there are PQ random coins, to integrate them into Tusk successfully would be its own commentary).

<k​ayabanerve:matrix.org> I believe there's enough unknowns and discussions that if I was to make a CCS, it'd be best to be *my* presentation and analysis of options as leading to *a potential scheme* that everyone could discuss and contribute to before taking further actions.

<a​tomfried:matrix.org> I am just a bit scared of the cubic communication complexity

<1​7lifers:matrix.org> cubic communication complecity, also known as C3

<1​7lifers:matrix.org> cubic communication complexity, also known as C3

<k​ayabanerve:matrix.org> Practically ideally, we'd have quadratic.

<k​ayabanerve:matrix.org> (Avalanche claims constant, but with many issues elsewhere. Algorand published an interesting paper on asynchronous consensus with sub-quadratic complexity though...)

<r​ucknium:monero.social> kayabanerve: Can I stop you there and wait until the meeting, which starts in 20 minutes? It can get messy when discussion before the meeting bleeds into the meeting. You can continue in #monero-research-lounge:monero.social . And I have a proposal.

<r​ucknium:monero.social> This may be an unusual meeting. On the agenda is PoW mining pool centralization: monero-project/meta #1254

<r​ucknium:monero.social> This topic is fundamental to the Monero project. I will request more structure than usual for that agenda item.

<r​ucknium:monero.social> The purpose of the discussion at _this_ meeting is not to decide any changes to Monero's consensus protocol and blockchain security model, but to start to plot out an Research & Development plan toward addressing weaknesses, both theoretical and empirical.

<r​ucknium:monero.social> I propose that the structure of the discussion on the mining centralization agenda item be:

<r​ucknium:monero.social> 1) I anticipate that there may be more readers and writers than at a usual MRL meeting. Therefore, start by stating your relationship to the Monero project and areas of knowledge/expertise (if any). "Ordinary user" is a fine response. Participation by new participants is fine and encouraged.

<r​ucknium:monero.social> 2) State what you consider to be the major problem(s) with Monero's consensus protocol and blockchain security model, if you think there are any problems. This includes problems that have actually occurred and theoretical problems that are possible but have not yet occurred. Do not respond to each other at this point in time.

<r​ucknium:monero.social> 3) State what you consider to be Monero's ideological and ethical principles, especially as they are relevant to potential solutions to mining pool centralization. Feel free to rank the importance of these principles. Again, don't respond to each other at this point in time.

<r​ucknium:monero.social> 4) General open-ended discussion on potential solutions to the mining pool centralization problem.

<r​ucknium:monero.social> (Don't post these now. Wait until the mining centralization agenda item comes up.)

<r​ucknium:monero.social> If anyone has suggestions for this structure, please suggest them.

<k​ayabanerve:matrix.org> Of course Rucknium:

<a​rticmine:monero.social> I would suggest that we separate the discussion between:

<a​rticmine:monero.social> 1) Improvements and fixes to the existing POW., both at consensus and node relay

<a​rticmine:monero.social> 2) The introduction of non POW consensus mechanisms such as but not limited to

<a​rticmine:monero.social> Trusted Execution Environments

<a​rticmine:monero.social> Proof of Stake Hybrid solutions

<a​rticmine:monero.social> Other non POW consensus solutions

<a​rticmine:monero.social> 2) Is way more controversial than 1)

<a​rticmine:monero.social> So we should start with 1)

<r​ucknium:monero.social> ArticMine: That sounds great to me. Can I insert your two bullet points into my #4 above?

<a​rticmine:monero.social> Of course

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

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

<a​rticmine:monero.social> Hi

<b​oog900:monero.social> hi

Hello

<c​haser:monero.social> hello

<s​pirobel:kernal.eu> hi

<s​gp_:monero.social> Hello

<v​tnerd:monero.social> Hi

<h​bs:matrix.org> Hi

<s​packle:monero.social> hello

<k​ayabanerve:matrix.org> 👋

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

<r​ucknium:monero.social> me: Improvements to moneroconsensus.info , which monitors orphaned blocks and mining pool centralization. Writing up simulation results for questions on review of PR #9939 "p2p: Improved peer selection with /24 subnet deduplication to disadvantage 'spy nodes'" monero-project/monero #9939 (Will post an hour or two after the meeting).

hello

<a​fungible:matrix.org> Greetings. Looking forward to the meeting discussion.

<a​rticmine:monero.social> Me working on the fee calculations.

<a​rticmine:monero.social> The results are posted after the size estimates

<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> seraphis-migration/monero #44

<a​rticmine:monero.social> I posted the link s to the fee results here

<o​frnxmr:monero.social> bug hunting & testing some fcmp stuff

<a​rticmine:monero.social> The enforcement of the requirement that all transactions are economical to mine regardless of size is the basis for the calculations

<a​rticmine:monero.social> We have to take into account the quadratic nature of the penalty

<o​frnxmr:monero.social> my kiss take on fcmp fees/scaling: for fcmp fees i think we should do.. same 300kb standard median. larger txs mean fees will bump up to "normal" tier more often. Unimportant fee = 0.00002xmr per (input+output), other tiers same multipliers as current

<a​rticmine:monero.social> This more than compensates for the verification time costs

<o​frnxmr:monero.social> The verification is linear per input afaict

<a​rticmine:monero.social> Keeping the median unchanged failed in 2017

Long-time XMR user here. By XMR user, I mean I actually use it as a currency. I also mine. I have also attended Monerotopia. I typically take a hands-off approach, but in this instance, I'd be remiss not to speak up for other silent XMR users and encourage cypherpunk and decentralized values. It's easier to keep liberty we have, than to regain it once it's lost. I look forward to hearing

everyone out. That is all.

<s​yntheticbird:monero.social> wrong chat

<s​yntheticbird:monero.social> => #monero

<c​haser:monero.social> maybe wrong agenda item

<r​ucknium:monero.social> This would be the right chat if it were during the mining centralization item, which comes later

<s​yntheticbird:monero.social> mea culpa all rights to the moderator, Rucknium our supreme leader

sorry. Please continue

<o​frnxmr:monero.social> wdym?

<o​frnxmr:monero.social> In 2017, didnt tx sizes decrease? I dont recall the history of the median changes

<r​ucknium:monero.social> This? getmonero.org/2017/12/11/A-note-on-fees.html

<a​rticmine:monero.social> The transactions were to big to scale so were stuck. A second hard fork was needed to fix the issue

<o​frnxmr:monero.social> I'm running fcmp right now with 8mb blocks (15mb at peak)

<a​rticmine:monero.social> Basically if one increases the tx size by a factor of 3 then the base has to increase by a factor of 3. Fees then stay the same

<r​ucknium:monero.social> Was it that a large tx could not fit in a block when the block size median had not been raised yet?

<a​rticmine:monero.social> The fees get very high

<a​rticmine:monero.social> This is good to know

<a​rticmine:monero.social> It means that the proposal increase in the base median makes sense

<a​rticmine:monero.social> Take a look at the 128 input TXs to see what I meam

<a​rticmine:monero.social> The key ratio is tx weight/ long term median

<r​ucknium:monero.social> I will keep the meeting moving...

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

<r​ucknium:monero.social> AFAIK, ofrnxmr has been trying to trigger bugs on his private testnet.

<r​ucknium:monero.social> So that an alpha stressnet can begin.

<r​ucknium:monero.social> Will the alpha stressnet fork from the public testnet, like the last stressnet, or start from genesis?

<r​ucknium:monero.social> I think for the "public stressnet", fork from testnet would be good because performance issues could develop when the blockchain already has some GB in it.

<r​ucknium:monero.social> jberman and jeffro256 aren't here right now to give an idea of how they view the exact launch process. But ofrnxmr could take the lead maybe. That would take some labor off their shoulders.

<j​effro256:monero.social> Oops sorry, thanks for the ping

<a​rticmine:monero.social> This also impacted the fee discussion

<j​effro256:monero.social> I haven't looked at Artic's recent comments on the tx weight GH issue, but I'm going to do that today.

<j​effro256:monero.social> Rn I'm reviewing and testing the 128-in FCMP++ PR, seems good so far. The contest code is more or less ready to go for usage in the stressnet. I think that we could start planning the date for the stressnet now, but I might hold off until j-berman is here

<o​frnxmr:monero.social> "Will the alpha stressnet fork from the public testnet, like the last stressnet, or start from genesis?" << mine starts from genesis, _but_ the fees are different pre-tail emission

<a​rticmine:monero.social> There was a major spike in fees in 2017 with the introduction of ring ct

<a​rticmine:monero.social> Tx size ~13500 bytes for 2 in 2 out

<r​ucknium:monero.social> Ok. The stressnet launch planning discussion can occur outside of the meeting time, especially so jberman can give input.

<o​frnxmr:monero.social> Jeffro, i'm also running the 128in pr. I think this shoukd definitely be included in stressnet

<j​effro256:monero.social> Forking from an existing network would yield more accurate DB migration times, more accurate FCMP tree handling times, etc. However, it might be an overhead that outweights its benefits

<v​enture:monero.social> sorry, to chime in.. but it burns to ask.. was it not decided to restrict 8-in, 8-out (fan-in/fan-out) for FCMP? why these 128-in fee calcs? please ignore if it's out of place

<j​effro256:monero.social> Rucknium: at what chain size would it not be worth it in your opinion to use an existing network ?

<o​frnxmr:monero.social> I'm going to get my blocks up to ~20+mb and then share my binaries so rucknium and others can try it out

<o​frnxmr:monero.social> Jeffro, testnet is only abt 7gb iirc. My db is around 1gb currently

<o​frnxmr:monero.social> (But those 7gb take like 12hrs to sync.. )

<j​effro256:monero.social> What seems to be a rough agreement right now is to allow >8-in/8-out txs at the consensus level, but require PoW to *relay* larger txs in the mempool

<r​ucknium:monero.social> jeffro256: I don't know. I like forking from testnet since as ofrnxmr said, the fees and scaling, etc. And it was not difficult to do it last stressnet (but the code has changed a lot with FCMP, of course).

<j​effro256:monero.social> Probably b/c there are hardly any peers

<o​frnxmr:monero.social> no, due to checkpoints

<o​frnxmr:monero.social> Lack-of*

<j​effro256:monero.social> Or lack thereof?

<r​ucknium:monero.social> Didn't new testnet checkpoints get added?

<o​frnxmr:monero.social> Not to the monero-project. We only added them to the stressnet

<j​effro256:monero.social> Okay let's do that

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

<j​effro256:monero.social> That's interesting, I wouldn't have thought that it would take that long to verify 7GB worth of tx proofs, but I haven't ever actually profiled it

<r​ucknium:monero.social> jeffro256: had a question about simplification of the code in github.com/monero-project/monero/pull/9939 to have the "already-connected" subnet qualification to be made at the `/24` subnet level instead of the current `16` level. According to my simulations, it makes very little difference given the current network structure, assuming the spy nodes found by boog900

<j​effro256:monero.social> (for testnet w/o checkpoints at least)

<b​oog900:monero.social> its all the PoW hashes too

<r​ucknium:monero.social> When honest nodes have the default 12 outbound connections, setting the "already-connected" subnet qualification to the `/16` subnet level gets you an average of 1.048 connections to the spy nodes. When it is `/24`, the average is 1.064. A very small increase.

<r​ucknium:monero.social> I will post teh write-up and code on the PR

TIA

<r​ucknium:monero.social> Like I said before the meeting, I want some structure in the next agenda item on mining pool centralization.

<r​ucknium:monero.social> The purpose of the discussion at _this_ meeting is not to decide any changes to Monero's consensus protocol and blockchain security model, but to start to plot out a Research & Development plan toward addressing weaknesses, both theoretical and empirical.

<j​effro256:monero.social> But there is also geographical distribution concerns also, not related to spy nodes. How does going from /16 to /24 affect that? A less diverse set of already-connected peers might slow down tx&block propagation for those farthest away from the "center" of the node graph

<r​ucknium:monero.social> jeffro256: I can look into that. I have the actual IP addresses of a network scan, so I can translate that into geography

<r​ucknium:monero.social> Thanks

<r​ucknium:monero.social> For the next agenda item:

<r​ucknium:monero.social> 1) I anticipate that there may be more readers and writers than at a usual MRL meeting. Therefore, start by stating your relationship to the Monero project and areas of knowledge/expertise (if any). "Ordinary user" is a fine response. Participation by new participants is fine and encouraged.

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

<r​ucknium:monero.social> 2) State what you consider to be the major problem(s) with Monero's consensus protocol and blockchain security model, if you think there are any problems. This includes problems that have actually occurred and theoretical problems that are possible but have not yet occurred. Do not respond to each other at this point in time.

<r​ucknium:monero.social> 3) State what you consider to be Monero's ideological and ethical principles, especially as they are relevant to potential solutions to mining pool centralization. Feel free to rank the importance of these principles. Again, don't respond to each other at this point in time.

<r​ucknium:monero.social> 4) General open-ended discussion on potential solutions to the mining pool centralization problem. The discussion will proceed:

<r​ucknium:monero.social> 1) Improvements and fixes to the existing POW., both at consensus and node relay

<r​ucknium:monero.social> 2) The introduction of non POW consensus mechanisms such as but not limited to A) Trusted Execution Environments, B) Proof of Stake Hybrid solutions, C) Other non POW consensus solutions

<r​ucknium:monero.social> Agenda item:

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

<a​ntilt:we2.ee> could we agree on @jeffro256:monero.social proposed changes now ?

<r​ucknium:monero.social> The context of this is Qubic's selfish mining strategy where they have perfromed a few blockchain re-organizations recently. One was 7 blocks deep.

<k​ayabanerve:matrix.org> FCMP++ R&D

<k​ayabanerve:matrix.org> Serai Developer

<k​ayabanerve:matrix.org> PoW vulnerability to coordinated actors at scale risking double spends and censorship.

<k​ayabanerve:matrix.org> Decentralization and privacy.

<a​rticmine:monero.social> I have been involved with the Monero project since 2014 and with POW mining since 2011 Have worked on Monero scaling and have been on the core team since 2016

<r​ucknium:monero.social> 1) Me: I have been providing research analysis for Monero's privacy and security for about four years. I am an empirical microeconomist. My areas of knowledge are statistics, economics, and game theory. I have chaired the weekly MRL meetings for a while.

<c​haser:monero.social> 1] Monero Research Lab regular and researcher of blockchain technologies in general.

1) Monero dev since 2017. Chair of the weekly Monero Tech Meetings. Frequent poster in the Monero subreddit.

<o​frnxmr:monero.social> 1. ofrnxmr. Monero abuser

<o​frnxmr:monero.social> 2. ability to invalidate txs w/ a deep enough reorg, and no "rules" or protections against it. Exampke: we have a 10 block lock, but there is no enforcement that 10 blocks are actually final

<o​frnxmr:monero.social> 3. payments. reliable and immutable.

<c​haser:monero.social> 2] I see two factors regarding Monero's current consensus that create a problem: 1) the mining algorithm is geared toward general-purpose hardware which is easy to access/rent, 2) the reward issuance in dollar terms is currently low both relative to other cryptos and the global availability of general-purpose hardware. these make attacks in the Nakamoto consensus (e.g. selfish min<clipped message>

<c​haser:monero.social> ing, or a 51% attack,) more feasible than desired.

<a​rticmine:monero.social> I see the Qubic situation as an attack on Monero's decentralization. There is also a lot of history since the principals in Qubic were also related to Bytecoin, an over 83% pre mine from which Monero was forked in 2014

<a​rticmine:monero.social> There is a lot of history and bad blood here

<r​ucknium:monero.social> 2) Problems: Low security budget at the current real purchasing power of 1 XMR. Behavior of individual miners to concentrate in a few pools (unclear why this occurs). Using a "flow" to protect a "stock", i.e. only a flow of PoW rewards protects the stock of the value that users keep in the XMR in their possession.

<a​ntilt:we2.ee> 1] scientist: physical modeling with recursive filter networks

is there a reasonably good writeup of the reorgs and, in particular, the contents of the reorgs and transaction equivalency (or lack thereof)?

<s​gp_:monero.social> Longtime user

<s​gp_:monero.social> I wish to keep the majority of Monero's PoW advantages and ethos, while strategically mitigating some of the most significant downsides of pure nakamoto consensus. Notably, these are decentralization, accessibility, censorship resistance, and fair issuance.

<s​gp_:monero.social> I do not believe PoW "tweaks" will address the most significant issues of nakamoto consensus in Monero. I believe that a TFL approach is most likely to yield the best tradeoffs.

2) The main problem I see is that Monero is too small, simply put.

<a​rticmine:monero.social> 3 The above says it very well

I have been asked to pass this message from discord: "I think I speak for a lot of people here saying the issue of mining pool centralization is quite concerning & requires immediate attention since a successful attack on the network would result in the loss of trust in the ecosystem and once lost, it'll be nearly impossible to get back. At the

time of writing, a 6-7 block reorg was demonstrated to have happened in the past few days thanks to rucknium's amazing tools & work with the help of other devs. A solution to this problem is needed yesterday & frankly monero should've addressed this issue a long time ago considering the historical progress in this field of research."

<j​ohn_r365:monero.social> sgp_: TFL = Trailing Finality Layer?

<r​ucknium:monero.social> kanzure: The tx contents of the re-orged blocks did not change. You can check this with `print_pool_stats` in your `monerod` console. No double spend txs attempted.

thank you rucknium. that is interesting.

<r​ucknium:monero.social> 3) Principles: Privacy, decentralization, accessibility, fungibility.

<v​enture:monero.social> ordinary user, somewhat technical background and somewhat studied monero technicals. also, sporadic donor

<v​enture:monero.social> 2.

<v​enture:monero.social> - double-spend attacks if >51% is reached, less likely since there the attacker would be known to be affiliated with the majority block producer. would presumably give way to legal recourse since this would be plain theft

<v​enture:monero.social> - censorhip, restricting txs somehow. this is also the reason why i think that any finality might come short of mitigation since nothing can be finalized what wasn't accepted by a centralized PoW provider

<c​haser:monero.social> 3] principles:

<c​haser:monero.social> * privacy. a solution shouldn't leave users, and ideally miners/validators too, any worse off than the current level.

<c​haser:monero.social> * censorship-resistance. same as previous point.

<c​haser:monero.social> * decentralization.

<c​haser:monero.social> * resilience. if a solution works, it should work in highly adversarial settings too.

<c​haser:monero.social> * avoiding high complexity.

<c​haser:monero.social> * integrity of monetary policy. leave it intact, or at least never increase the overall issuance rate of XMR.

<c​haser:monero.social> * asset integrity. the consensus protocol shouldn't issue a secondary asset.

<c​haser:monero.social> * open-mindedness. judge solutions based on how they work and what they achieve, not where they come from or what narratives are attached to it.

<s​gp_:monero.social> yes, FTL = trailing finality layer

<s​gp_:monero.social> yes, TFL = trailing finality layer

<s​yntheticbird:monero.social> Faster than light?

<a​ntilt:we2.ee> 2] I pointed out that CPU hashrate may be rented 4 month ago and suggested a 2nd BFT layer based on Eigentrust - now called "finality layer"

<o​frnxmr:monero.social> When i said "payments, reliable and immutable", it should go without saying: confidential, accessible, and decentralized

<s​pirobel:kernal.eu> what is the benefit of a finality layer compared to proof stake?

3) Monero should stay "trustless" and "permissionless". Otherwise forget all the fuss and use credit cards and paypal.

<r​ucknium:monero.social> That stated, Qubic can make it appear that a double-spend against a victim occurred, by double-spending to itself. Then, a "double spend" tx would appear in the nodes, but there would be no actual victim, just propaganda value.

<a​ntilt:we2.ee> both are variants of BFT, one not based on wealth

<r​ucknium:monero.social> Has everyone who wanted to speak on the first three bullet points spoken?

<a​rticmine:monero.social> On principals:

<a​rticmine:monero.social> We need to stay away from TEEs The Intel ME is an example of a TEE that even the NSA in the US found obnoxious

<a​rticmine:monero.social> We also need t stay away from hybrid POS systems

<s​pirobel:kernal.eu> which one is not based on wealth? its not like cpus and electricity are free

<s​pirobel:kernal.eu> arcticmine: yes.

<r​ucknium:monero.social> Now we will get into General open-ended discussion on potential solutions to the mining pool centralization problem. First: Improvements and fixes to the existing POW., both at consensus and node relay.

<r​ucknium:monero.social> (Note: discussion of non-PoW solutions will follow after this first point discussion.)

<a​rticmine:monero.social> I would suggest instead that we focus on hardening our existing POW both at the consensus and node really levels

<s​pirobel:kernal.eu> what is the security budget currently and how much would the attack cost increase by this measure ?

<c​ountbleck:matrix.org> Is this where tevador's bandwidth-based idea comes in?

<r​ucknium:monero.social> There was a paper published recently in a top economics journal. It was circulated as a draft for a few years: Budish, E. (2025). "Trust at Scale: The Economic Limits of Cryptocurrencies and Blockchains", The Quarterly Journal of Economics, 140(1), 1–62. moneroresearch.info/101

<m​rmatrixer:matrix.org> Where can I watch the meeting?

<r​ucknium:monero.social> Part of the abstract:

<r​ucknium:monero.social> > This article shows that Nakamoto’s novel form of trust, while undeniably ingenious, is deeply economically limited. The core argument is three equations. A zero-profit condition on the quantity of honest blockchain “trust support” (work, stake, etc.) and an incentive-compatibility condition on the system’s security against majority attack (the Achilles heel of all forms <clipped message

<r​ucknium:monero.social> of permissionless consensus) together imply an equilibrium constraint, which says that the “flow” cost of blockchain trust has to be large at all times relative to the benefits of attacking the system. This is extremely expensive relative to traditional forms of trust and scales linearly with the value of attack. In scenarios that represent Nakamoto trust becoming a more signi<clipped message

<r​ucknium:monero.social> ficant part of the global financial system, the cost of trust would exceed global GDP. Nakamoto trust would become more attractive if an attacker lost the stock value of their capital in addition to paying the flow cost of attack, but this requires either collapse of the system (hardly reassuring) or external support from rule of law.

<a​rticmine:monero.social> I like both trevador's idea and Sech1's with 1%

<j​effro256:monero.social> 1. Full-time developer paid thru Monero CCS since 2023. User since late 2017. Formal education in computer science and distributed systems, and working knowledge of elliptic-curve-based cryptography.

<j​effro256:monero.social> 2. One issue that I believe to have been a large one for some time is the lacking present security budget due to a front-heavy monetary emission policy. Unfortunately, this is hard to change after the fact. This *can* be helped by furthering adoption and raising XMR price to make financial attacks against PoW harder / riskier.

<j​effro256:monero.social> 3. Principles: privacy, fungability, decentralization, permissionless, ease-of-use, honoring past social contracts, salability over time&space, battle-hardening, research-focus

<a​rticmine:monero.social> Both can be implt

<a​rticmine:monero.social> Implemented

<r​ucknium:monero.social> CountBleck: Yes, it could. That's monero-project/research-lab #98

<a​ntilt:we2.ee> I want to point out that BFT may be tied to a resource we control... and thats the community (trust) itself.

<r​ucknium:monero.social> Keith Meister: You're watching it right now. It's all text-based.

do the monero developers consider monero PoW hard-fork to be substantially different from (say for example) successfully deploying a bitcoin PoW hard-fork? do the present conditions exceed anyone's notions for requiring a PoW hard-fork? just curious.

<s​gp_:monero.social> Personally, I don't think that any clear issues arose from RandomX. RandomX worked exactly as intended. Nakamoto consensus worked exactly as intended. An adversary selfishly mined blocks and lost more money than they made, though this doesn't factor in free PR value

<s​gp_:monero.social> Certain tweaks could be made to make pool mining less competitive, which could help reduce the advantage of mining pools and could help with decentralization. The tevador proposal, while interesting, may _increase_ centralization by turning away small miners (it raises their costs to require a node in some circumstances). In any case, I don't see these as addressing the "core" pro<clipped message>

<s​gp_:monero.social> blem, even if certain tweaks are considered appropriate and selected. Another proposal needs to be considered in conjunction, imho

<k​ayabanerve:matrix.org> Sorry to jump in, but this is very wrong.

<k​ayabanerve:matrix.org> But yes, we should focus on PoW immediately per Rucknium's chairing

<k​ayabanerve:matrix.org> I like tevador's proposal but am concerned about the risk a higher percentage of honest miners disappear than malicious miners, while in such a delicate state.

<k​ayabanerve:matrix.org> tevador did respond to this concern though.

<a​rticmine:monero.social> As for the security budget a lot of the issue with Qubic is shifting of miners to their centralized pool

<a​rticmine:monero.social> We also have to be careful here that we do not create a cure that is far worse than the desise

<r​ucknium:monero.social> sgp_: I agree that it honest mining pools could become less concentrated, e.g. no honest mining pools above 5% total hashpower, the Qubic attack could still happen. Reducing honest mining pool centralization is good, but much more would be needed.

+1

<k​ayabanerve:matrix.org> That isn't to say I drop my concern, just to say tevador has their own opinion.

<o​frnxmr:monero.social> I dont think they _shifted_ miners, but attracted (or rented) dormant hashrate

<k​ayabanerve:matrix.org> rbrunner: can you clarify which message you're supporting, please?

ArticMine's

Cure versus desease

<s​gp_:monero.social> There are many bad options indeed :)

<o​frnxmr:monero.social> +1 on avoiding cures that are worse than the cancer

We have it in our hands to destroy Monero all on our own :)

<k​ayabanerve:matrix.org> Thank you

<s​pirobel:kernal.eu> how much in dollar terms cost is it currently to perform a 51% attack on monero? I have read people say its 75 million or just a few hundred k

<k​ayabanerve:matrix.org> I'm not entirely convinced tevador's proposal is guaranteed to be better than worse re: the current malicious pool, but I support it generally.

<r​ucknium:monero.social> kayabanerve: I would ask Matrix-side commentators to do the same by prefixing their response comments with the username of the user they are responding to. This helps keep IRC-side logs, which are used for the GitHub issue, understandable.

<a​rticmine:monero.social> They have my being that successful on raw sustainable hash power. What Qubic is being very successful is in creating a social engineering attack.

<a​rticmine:monero.social> When I see radical proposals that go against the basic principles of Monero, I see their success

<k​ayabanerve:matrix.org> $1 because by adding $1 in outside incentives, you'll pay the highest reward for hash power, and a hyper-efficient capitalist market will have all hash power go to you /s

<a​rticmine:monero.social> This discussion is my evidence

<s​pirobel:kernal.eu> we dont even have a clear number, right? is there a ball park figure ?

<r​ucknium:monero.social> spirobel: About 432 XMR is emitted to miners every day. That is called the "security budget".

<s​pirobel:kernal.eu> thats not much to secure billions of dollar in market cap

spirobel: They currently seem to pay with their own coin, emissioned weekly out of thin air, for free

<r​ucknium:monero.social> Here are some tables endor00 produced a while ago: "51% attacks and mining incentives" gist.github.com/endorxmr/a13dce62ae1ba4676a1ed0311d96bf07

<j​effro256:monero.social> Which works as long as the AI-hype-ponzi machine keeps pouring in money to Qubic's coin

Exactly. That can take a while :)

<o​frnxmr:monero.social> [@articmine:monero.social](https://matrix.to/#/@articmine:monero.social) the best proposal ive heard, was sent to me in dm (and sent to pool operators). For pools to collude with one another to perform a real 51% attack with the goal of censoring qubic's blocks. i had to go to bed after reading that

<c​haser:monero.social> spirobel: it's a function of the inflation rate, a very delicate balance that all assets need to keep, not just Monero.

<a​ntilt:we2.ee> 100.000$ / month for 1GH

<s​gp_:monero.social> ofrnxmr: that only works so long as they have a minority hashpower, even if everyone else agreed to do that. If they got the majority for a sustainer period, then that wouldn't work. And we're back to square 1

<s​pirobel:kernal.eu> lets say you are a whale right now, if you wanted to contribute to the security of the network you would have to sell part of your xmr to mine at a loss. so there is a negative feedback loop here. PoW just adds sell pressure and no security

Pool centralization has been an issue long time before qubic. Miners don't care. Even 0% fee is not enough to make miners move to p2pool. That's why #98 was proposed.

<o​frnxmr:monero.social> Spg, i forgot the /s. It was actually proposed, but asking to be 51%d is.. against monero core values

<a​rticmine:monero.social> Which would stop them dead in their tracks right now

<c​haser:monero.social> jeffro256: right, they're currently probably sustainable because they're dumping their coin on retail investors who buy into the hype.

<s​gp_:monero.social> let's all centralize around one big pool but it's actually trustworthy and only denies blocks by bad people /s, ofc

<a​rticmine:monero.social> They are not close to 51% on a sustainable basis

<o​frnxmr:monero.social> "we hate big pools. also: hey pools, can you combine and 51% attack the network?"

<s​gp_:monero.social> I personally think that on the PoW tweak front, tevador's proposal is the most realistic, by far. That's where discussion should focus around in the future

<a​rticmine:monero.social> One can even use node relay e orphan malicious blocks

<a​rticmine:monero.social> To

<o​frnxmr:monero.social> sgq, I think node relay stuff is my preferred direction

Realistic short-term mitigations are: 1) Renting hashrate to help the network. 2) Temporarily raising tx fees (as a relay rule).

<a​ntilt:we2.ee> are there any ideas on how to fade in #98 slowely ??

<j​effro256:monero.social> That's assuming we can differentiate Qubic blocks from non-Qubic blocks, which would probably rely on nodes connecting into Qubic mining pools

<m​rmatrixer:matrix.org> Where can I watch the meeting?

<o​frnxmr:monero.social> youre in the meeting now, keith

<1​7lifers:matrix.org> here. scroll up.

<1​7lifers:matrix.org> i got some fresh popcorn ready to last the whole meeting

<m​rmatrixer:matrix.org> Which users are the devs?

<a​rticmine:monero.social> No checking how the block structure compares to an honest block structure.

<o​frnxmr:monero.social> also cc [@kayabanerve:matrix.org](https://matrix.to/#/@kayabanerve:matrix.org) what about an orphaned blocks difficulty addition, or uncle blocks etc

<s​gp_:monero.social> I suppose I'm also for higher tx fees. But it's not a complete solution

<s​pirobel:kernal.eu> pow is nostalgia. why not rip off the band aid? if just 10% of xmr holders stake we have a security budget in the hundreds of millions much more than 432 xmr

<o​frnxmr:monero.social> So the diff isnt based on "5gh" when there is really 7gh mining

<j​effro256:monero.social> I thought Qubic patched that recently

<a​rticmine:monero.social> If the difference is big enough block or delay

<s​gp_:monero.social> articmine wouldn't that just cause split consensus?

<k​ayabanerve:matrix.org> I'm not immediately sure if allowing referencing orphaned uncles to increase the network's difficulty would be good or not. I'd guess not, because whoever includes the orphans would face the wrath.

<o​frnxmr:monero.social> wouldnt everyone include the orphans?

<a​rticmine:monero.social> If Qubic is forced to mine honest block the harm in the attack is diminished

<r​ucknium:monero.social> IMHO, raising tx fees as a relay rule won't work for two reasons: 1) You would still not have enough fee, as a percentage of block reward. 2) It is easy to get around nodes that update to new node relay rules, so txs would still get to miners. This happened with nonzero lock time.

<b​oog900:monero.social> what would including orphans even fix here?

<k​ayabanerve:matrix.org> Agreed but there's no good way to require a block is honest.

<o​frnxmr:monero.social> The diff is artificially low. This would create an acxurate difficulty

<c​haser:monero.social> you could allocate a minor part of the issuance to reward orphan inclusion.

<o​frnxmr:monero.social> Chaser, thats how uncle blocks work, no?

<b​oog900:monero.social> but that would just slow blocks down rather than stop a selfish mining attack

<k​ayabanerve:matrix.org> *agreed a miner forced to mine honest blocks diminishes the attack.

<a​rticmine:monero.social> Yes, but nothing forces nods to relay dishonest blocks

<k​ayabanerve:matrix.org> I mean, it's bad for the network.

<k​ayabanerve:matrix.org> Selfish mining is based on withholding a longer chain so adversaries are mining on old data.

<b​oog900:monero.social> qubic created a lot of orphans during their attack that they didn't broadcast you would be rewarding them

<c​haser:monero.social> ofrnxmr: I believe so, yes

<k​ayabanerve:matrix.org> Taking longer to switch to the best chain is on purposely keeping yourself on an old chain.

<r​ucknium:monero.social> kevinnegy.github.io/Selfish%20Mining%20Re-Examined.pdf

<r​ucknium:monero.social> > ETH, on the other hand, shows that a new selfish miner with any hash rate and any γ value can at least break-even. This finding is entirely due to the uncle block reward system that exists in ETH, which is described in more detail in Appendix A.

<k​ayabanerve:matrix.org> If honest miners are *randomly* behind the actual longest chain, they can immediately close the gap by switching and have the best odds of the actual next block.

<r​ucknium:monero.social> According to my interpretation, giving uncle rewards can promote selfish mining, at least below the usual 33% hahspower threahold ^

<s​pirobel:kernal.eu> benefit of PoS is faster finality, higher TPS, no inflation. whales are naturally incentivized to protect network security by staking. tx fees will be enough to compensate stakers.

<s​gp_:monero.social> spirobel: I believe that discussion is tabled for later

<a​rticmine:monero.social> ETH has serious orphan blocks issues due to relativistic (physics) effects

<c​haser:monero.social> Rucknium: interesting, thank you for noticing that

<j​effro256:monero.social> Allowing uncle blocks also removes the current implicit penalty for slow block propagation, which can de-stabilize the network

<a​rticmine:monero.social> It takes a finite amount of time for light to travel over fibre optic cable

<v​enture:monero.social> if orphaning blocks skews the hashrate down, and given the general attack vector of having too few miners... how about rewarding net hashrate / difficulty increase? Incorporating that in a sort of dynamic block reward tied to a set difficulty over time?

<v​enture:monero.social> Currently, it has a negative feedback loop, every new miner diminishes the returns of existing ones

<s​yntheticbird:monero.social> in practice the hashrate goes up when the price goes up

<s​yntheticbird:monero.social> it has been observed forever

<b​oog900:monero.social> you would be changing the emission then presumably

<s​pirobel:kernal.eu> flip flop: if we assume 100 k for 1 month of 1GH it means the only reason this attack is not performed its because its hard to acquire that much cpus without kyc

<s​yntheticbird:monero.social> I honestly wouldn't see anyone wishing to avoid kyc attack monero. On the other end I easily see people wanting to attack monero to not having to worry about kyc.

Lol. We do know who attacks us right now, no?

<o​frnxmr:monero.social> Rbrunner, we dont know who he works with/for

<s​pirobel:kernal.eu> sgp_: the question is really related. 98 is just more band aid if at all

<a​ntilt:we2.ee> right

<s​pirobel:kernal.eu> we cant even measure the impact properly

<k​ayabanerve:matrix.org> spirobel: which is why it's being discussed _next_.

<a​rticmine:monero.social> A 51% attack against Monero could be considered a criminal act in many jurisdictions so avoiding KYC would make sens

<s​gp_:monero.social> spirobel: I agree with the practical challenge of renting hashrate. A thief swapping xmr to btc or whatever is incentivized to rent hashrate if they can to double spend. That's certainly an important scenario that Monero's consensus needs to be prepared for

<k​ayabanerve:matrix.org> Oh, sorry if I replied regarding the wrong thing spirobel

<s​gp_:monero.social> rentable hashrate is one of the most significant disadvantages of a cpu friendly algo

<v​enture:monero.social> ArticMine: not quite, only the double-spend is criminal. not having more than 51%.

<v​enture:monero.social> So yes, since qubic is public, double-spend is unlikely. Censorship/kyc attack after having achieved 51 more so IMHO.

<s​gp_:monero.social> asic friendly hashrates are more centralized around manufacturing, but it's harder to "driveby" doublespend

<r​ucknium:monero.social> sgp_: Weakness and a strength. Network recovery after an attack is easier with CPU-mineable since no one could have bought up all the CPUs.

<a​rticmine:monero.social> Attack against a computer network are criminal. There is no exception for privacy preserving decentralized networks

<v​enture:monero.social> which renders even a finalizing layer mute, when you can't get your tx in the PoW block provider's block in the first place.

<a​ntilt:we2.ee> the sad answer is that high decentralization... has not been demonstrated in practice. In practice, we trust.

<r​ucknium:monero.social> And even a strength for defenders to rent their own defense hashpower if there is advance notice, as in this Qubic case.

<s​yntheticbird:monero.social> I wouldn't count on geopolitical superpower to apply their law to such an extent

<s​gp_:monero.social> rucknium yeah I'm not pro asic, but the cpu friendly algo has the downside of these social, ponzi-driven social attacks being easier to rally up

<a​rticmine:monero.social> They may not have a choice

<s​gp_:monero.social> "there are pros and cons" ha

ArticMine Apologies for intervening but in most jurisdictions wouldn't an entity need to press charges for this to be an effective deterrent ? As long as i am aware there is no Monero Foundation legal entity at this moment to be able to do that... That's an assumption you can of course defend your point just bringing something up. :)

<a​rticmine:monero.social> There is also the risk of decentralized litigation

<r​ucknium:monero.social> Anyone familiar with a review research article on hardening PoW blockchain consensus?

Anyway, I think tevador idea proposed in "98" would take months of finalizing and hardforking into service. That may well be too late for our *immediate* "Qubic problem"

<a​rticmine:monero.social> Anyone hurt by the attack could press charges

<s​gp_:monero.social> new included mining pool service: lawyers for civil litigation

<s​pirobel:kernal.eu> ArticMine: if its down to this and we are ready to admit it: why do we need to buy cpus to secure the network and gift money to utility companies? we could reduce inflation to zero and tell bitcoiners: there will only ever be 18 million monero. And cost of attack would be orders of magnitude higher than it is now

<a​rticmine:monero.social> It is one of many possible options

<v​enture:monero.social> 51% attacks are not criminal. taking over an org / hostile take-overs happen even in stock markets. but I'm not an expert

<r​ucknium:monero.social> IMHO, probably the best short-term defense is people adding more hashpower, from their own machines or renting hashpower, during the Qubic hashpower spikes.

with that in mind miners could theoretically press charges for yesterday's attack for making them miss profits from the orphaned blocks i am unsure how realistic that would be

<s​pirobel:kernal.eu> its the only option that is sensible. I saw someone mention he is willing to sell xmr to rent hashrate to secure the network. so currently we have negative inflation proof of stake. people love monero so much they are willing to pay to secure it.

<s​yntheticbird:monero.social> Let's not be naive here, both US and Europe jurisdictions would be delighted to hear XMR plunged to death. That is without considering lobbyist and corruption. There is no chance that civils will achieve a case against Qubic. On the other end, it just take one grant from an ally/strategic country to Qubic to transform the case into a geopolitical mess that will slow/stuck things e<clipped me

<s​yntheticbird:monero.social> ven further. Qubic have the high grounds here

<a​rticmine:monero.social> I remember when an individual said that Bitcoin was not money in 2011. The SEC fitted the individual for an orange jumpsuit.

<r​ucknium:monero.social> I will do a broad literature search on articles about hardening PoW blockchain consensus without altering its fundamentals. Any other specific actions to take on PoW-based research?

<b​oog900:monero.social> how would you prove your didn't just disconnect from the network and happen to reconnect once they overtook the mainchain?

Don't forget that courts, litigations etc. usually drags on freaking years. People, that's not useful.

<b​oog900:monero.social> the miner disconnect from the network^

<r​ucknium:monero.social> In the next 5 minutes I will move us to discussing non-PoW options, unless there are really new things brought up about PoW.

<v​enture:monero.social> the shoe is always on the other foot with these guys. it's a commodity here, but money there *sigh

<b​oog900:monero.social> on Monero this would be enough to invalidate pretty much all txs if they reorged more than 10 blocks

<s​pirobel:kernal.eu> rucknium: proof of work is nostalgia.

<b​oog900:monero.social> would checkpoints fall under PoW?

<o​frnxmr:monero.social> Hyc's rolling hash of hashes

<s​pirobel:kernal.eu> also: pos would help with the eclipse / sybill attack of nodes

<s​yntheticbird:monero.social> spirobel can you wait on the rucknium to bring the next point

<j​effro256:monero.social> We could still use checkpoints with PoS. Is that what you are asking?

<s​yntheticbird:monero.social> spirobel can you wait on rucknium to bring the next point

<r​ucknium:monero.social> boog900: IMHO, checkpoints with current PoW fits in this section. Could fit in the next section, too.

<b​oog900:monero.social> I wouldn't be for a distributed version like that, but not allowing reorgs beyond 10 blocks is something I have been liking the thought of more and more

<s​gp_:monero.social> checkpoints most closely fall under PoS/TFL, unless you are implying daily/hourly monerod software releases :p

<o​frnxmr:monero.social> Sgp, we have dns checkpointing, so it doesnt require releases.

<b​oog900:monero.social> no rolling checkpoints I think it what bitcoin cash calls just not allowing reorgs beyond 10 blocks

<b​oog900:monero.social> beyond X blocks^

<s​gp_:monero.social> boog900: that leads to split consensus with nodes though. What chain does a newly syncing node follow? The highest hashrate one, or a different one with less work that other nodes claim they saw first?

<o​frnxmr:monero.social> i dont buy the bootstrapping is as a blocker

<b​oog900:monero.social> it would be the highest hashrate with the hope an attacker can't keep up forever

<b​oog900:monero.social> they would have a period where they can get new nodes but the real chain should overtake them eventually

<r​ucknium:monero.social> Arguably, BCH has an bigger sword of Damocles hanging over its head than Monero does, with its SHA256 hashing. And BTC people wanting to kill it since 2017.

<o​frnxmr:monero.social> The chain which the majority of your peers are on

<s​gp_:monero.social> so during the attack we have two networks

If BCH does that, I guess they came up with a solution for these bootstrapping problems?

<b​oog900:monero.social> sadly

<b​oog900:monero.social> better than a big reorg IMO

<o​frnxmr:monero.social> We already have 2 networks during attack

<r​ucknium:monero.social> BSV (Bitcoin Satoshi's Vision) had an attacker that mined empty blocks for a awhile IIRC. A rolling checkpoint wouldn't fix that.

<s​gp_:monero.social> currently nodes have clear instructions about which chain to prefer. With the same info, nodes will agree on which is the single "correct" one

<o​frnxmr:monero.social> your node can currently get thrown onto a bad chain during bootstrap

<s​gp_:monero.social> this would have two nodes running the same code, depending on their view of the network, disagree

<s​yntheticbird:monero.social> thats wht highest hashrate make more sense

<s​yntheticbird:monero.social> imo

<o​frnxmr:monero.social> Has happened to me a few times, wjen malicious nodes decided to share a bad chain ~ block 1.5million

<b​oog900:monero.social> only new nodes would be affected

<r​ucknium:monero.social> Let's go to the next sub-item:

<r​ucknium:monero.social> 2) The introduction of non POW consensus mechanisms such as but not limited to A) Trusted Execution Environments, B) Proof of Stake Hybrid solutions, C) Other non POW consensus solutions

<k​ayabanerve:matrix.org> Rucknium: Actually, it could have helped.

<s​gp_:monero.social> while the attack is ongoing, the network is stalled and there are 2 networks

<b​oog900:monero.social> hopefully new nodes would not have the same economic impact as reorging old nodes

<e​longated:matrix.org> Why should nodes accept consecutive empty blocks, if their mempool is not empty ?

<o​frnxmr:monero.social> A) nah b) i only like proof of pow c) no comment

<k​ayabanerve:matrix.org> If a finality layer is sufficiently quick to achieve finality, even if a malicious miner tries to reorg out honest blocks, they may already be finalized.

<b​oog900:monero.social> stalled? we would have 1 correct and 1 that is ahead for as long as they want to keep the wasted mining

<k​ayabanerve:matrix.org> They just have to be the first broadcast block for the finality layer to observe, if it's sufficiently responsive.

I and the miners I work with only like PoW. Absent PoW, we move to other cryptocurrencies. Simple as.

<s​gp_:monero.social> I consider TFL a more robust mechanism than "don't reorganize past 10 blocks"

<s​yntheticbird:monero.social> elongated i had the exact same thought but this is hard to get right as depending on the node local scope

<b​oog900:monero.social> a lot more complicated though

<j​effro256:monero.social> Tbf, this is already technically true for 1-block-deep reorgs. If there's two chains with the same exact height, b/c of the difficulty calculation lag, a node will choose whichever one it saw first, then switch to the chain which has the next block built on top of it, so on and so forth.

<o​frnxmr:monero.social> also: theres no reason why qubic _has_ to share empty blocks. They can effectively stuff the blocks to the brim and make for an arguable worse attack

<r​ucknium:monero.social> What is a Trailing Finality Layer?

<j​effro256:monero.social> i.e. there's no "tie-breaker" rule

<r​ucknium:monero.social> Or link me something that you think explains it well.

<s​gp_:monero.social> the complication is worth it imo to avoid potentially prolonged split consensus

<e​longated:matrix.org> Let’s say a node accepts 2 empty blocks, if miner is not clearing mempool (even half of it) the miner is malicious?

<k​ayabanerve:matrix.org> With an asynchronous consensus algorithm, like the one I posited, we'd achieve consensus however frequently the environment allows (limited by processing speed, bandwidth, and latency). Because we wouldn't have a hard requirement on any performance, anyone could run a validator over any network (such as Tor).

<s​gp_:monero.social> I'm less concerned about a 1-block reorg since those essentially need to happen in honest scenarios as well

<o​frnxmr:monero.social> Attacker just switches to mining full blocks of their own txs

<k​ayabanerve:matrix.org> We can use an asynchronous consensus algorithm to finalize existing Monero blocks (PoW). This would prevent them from being reorganized off of.

<c​haser:monero.social> Rucknium: electriccoin.co/blog/the-trailing-f…ng-stone-to-proof-of-stake-in-zcash

<k​ayabanerve:matrix.org> This would ideally prevent selfish mining and ensure X% of hash rate actually earns an average of X% of blocks, if sufficiently responsive.

<k​ayabanerve:matrix.org> More definitely, it stops deep re-orgs.

<s​pirobel:kernal.eu> what is the security benefit of the finality layer over PoS?

<k​ayabanerve:matrix.org> It also lets us replace the 10-block lock with a finality-block lock. Outputs can be spent once the block creating them is finalized. This would, ideally, reduce the 10-block lock to just a few seconds (so effectively non-existent).

<a​rticmine:monero.social> How is this finality layer secured?

<k​ayabanerve:matrix.org> We would need to decide validators, which we'd presumably do via PoS.

<e​longated:matrix.org> Pos ?

<c​haser:monero.social> I believe a stake-based finality layer as an overlay to the current Nakamoto consensus is the best option, and viable without compromising on any of Monero's principles. I'm categorically against any solutions involving trusted execution environments (Intel SGX, etc.) because of their nature of being trusted, potentially backdoored from day 0, and frequent in-the-wild exploits.

<a​rticmine:monero.social> So we are back t POS?

<k​ayabanerve:matrix.org> PoS is just proof of stake and can mean many things. Zano's PoS allows someone who stakes to produce a block. Here, PoS entitles one to participate in a live network to finalize blocks.

<a​rticmine:monero.social> For security

<b​oog900:monero.social> would they be rewarded for staking?

<s​pirobel:kernal.eu> kayabanerve: why not just switch to PoS ?

<s​gp_:monero.social> using PoS for the finality layer instead of entirely helps maintain more of Monero's PoW values. It's not perfect all around, but it _may_ be the best bang for our buck all around

kayabanerve, that recent paper that you linked to, is it really so attractive as title and abstract seem to suggest? Is that a substantial improvement of "state of the art"? eprint.iacr.org/2024/677

<s​gp_:monero.social> fwiw, I am quite worried of a large service (e.g. exchange) effectively halting the finalizations (and in effect, the network). I think that's a real risk that needs to be carefully considered in the TFL design

<s​pirobel:kernal.eu> sgp_: in other words: there is no scientifically sound reason, just nostalgia for PoW

<s​gp_:monero.social> arguably, "fair distribution of new coins" is a reason

<k​ayabanerve:matrix.org> The TEE solution I proposed has been withdrawn and I maintain is fundamentally misunderstood by anyone still yelling against it because TEEs are insecure.

<c​haser:monero.social> spirobel: Nakamoto proof of work is fundamentally more sound, lower complexity and ensures wider participation in block validation over longer spans of time. it's a good ground to build on IMHO.

<r​ucknium:monero.social> At the end of the meeting, I want to list specific actions that specific people will take to advance this issue. Keep that in mind.

<o​frnxmr:monero.social> Spriobel wants to eliminate the emission as well

<a​rticmine:monero.social> POS has a fundamental flaw that cannot be solved. What the network cannot determine is whether the person putting up the stake is actually long Monero in this case.

<a​rticmine:monero.social> Sure the stalker has put up XMR. But. What prevents the stalker from borrowing XMR and then selling it creating a larger short position in XMR than the stake.

<a​rticmine:monero.social> Then the stalker has an incentive to create havoc on the network in order to devalue his debt

<e​longated:matrix.org> Pow+pos is more sensible

<k​ayabanerve:matrix.org> But regardless, we can move on.

<k​ayabanerve:matrix.org> boog900: I'd propose 20-50% of the emissions.

<e​longated:matrix.org> They will need large number of pos nodes to do that ?

<k​ayabanerve:matrix.org> spirobel: PoW as a first pass has some arguments, as it arguably means we have a VDF in our consensus protocol _and_ it reduces the amount of options voted on.

<k​ayabanerve:matrix.org> monero-project/research-lab #135#issuecomment-3169589987

<k​ayabanerve:matrix.org> rbrunner: That paper was notable for not using PKC. By simplifying out PKC, there schemes resolves as PQ.

<k​ayabanerve:matrix.org> Overall, it's quite notable for being direct and clean though.

<k​ayabanerve:matrix.org> It is still of cubic communication complexity in one area though, which we'd accept or we could discuss improving with non-PQ cryptography if too slow to evaluate.

<o​frnxmr:monero.social> Articmine, thats why i only like the idea of staking coinbases

<k​ayabanerve:matrix.org> Sorry, my messages have failed to send for the last minute.

<a​rticmine:monero.social> Fractional reserve banking is the death of PaoS

<o​frnxmr:monero.social> "proof of pow"

<s​pirobel:kernal.eu> we established before in this chat that 1gh is 100k per month and the only reason keeping people from performing this attack is that it is illegal and this amount of hashrate is hard to acquire without kyc

<s​gp_:monero.social> articmine does that not _also_ impact PoW? Go short XMR, rent hashrate, 51%....

<k​ayabanerve:matrix.org> The biggest risk of the finality layer is a malicious set of validators can halt the network, and try to double spend at that moment they finalize two different blocks, yep.

<a​rticmine:monero.social> Staking coinbase does not prevent going short

<b​oog900:monero.social> I still like the no reorgs past 10 blocks :)

<b​oog900:monero.social> No need to decrease emission for miners

<b​oog900:monero.social> No need to worry about exchanges

<k​ayabanerve:matrix.org> boog900: as a blind rule?

<c​haser:monero.social> boog900: there's no need for that if you make block-winning miners the validators, and *require* them to participate in the finalization process for N blocks afterwards to claim their PoW reward.

<e​longated:matrix.org> What if attacker does 51% starting with that hf ? Only they get coinbase and control pos

<b​oog900:monero.social> yes

<a​rticmine:monero.social> We know that CEXs have gone short Monero. POS is a way to bail them out

<s​pirobel:kernal.eu> ArticMine: same goes for CPU hashing power. the difference is that we have to waste money in the current case. lets say you are a whale right now, if you wanted to contribute to the security of the network you would have to sell part of your xmr to mine at a loss. so we currently have negative inflation PoS and call it proof of work.

<k​ayabanerve:matrix.org> I'm against staking 'blocks mined' or their coinbases.

<b​oog900:monero.social> now someone with 51% just needs enough blocks

The fundamental issue of PoS are long range attacks (you can buy lots of empty wallets and roll back the chain from the time they had enough funds to stake). Ethereum solves this by "asking a friend which chain is the real one".

<k​ayabanerve:matrix.org> I'm against an arbitrary re-org depth.

<a​rticmine:monero.social> Not so simple. The Canadian winter is coming

<k​ayabanerve:matrix.org> tevador: You'd need the stakes of the ancient _validator set_, not just ancient wallets, assuming the first validator set is trusted.

<a​rticmine:monero.social> Then there is excess solar

<k​ayabanerve:matrix.org> That's one of the pleasant things about keeping PoW around: it serves a VDF to some degree. If you're initially syncing and see two different chains, they should have vastly different amounts of work.

<k​ayabanerve:matrix.org> *first validator set is checkpointed

<r​ucknium:monero.social> What is VDF?

<b​oog900:monero.social> its not ideal but none of this is and its simple

<a​ntilt:we2.ee> sorry I can't see how this train of thought is any different from a regular "short"

Checkpoint = "asking a friend" solution.

<a​rticmine:monero.social> I still see no answer to fundamental POS security

<c​haser:monero.social> kayabanerve: for that they would get slashed, no?

<k​ayabanerve:matrix.org> Verifiable Delay Function Rucknium, sorry.

<c​haser:monero.social> boog900: indeed, it can't protect against 51% attacks.

<j​effro256:monero.social> Yeah this would seem to just further entrench mining pools, especially if they started just creating coinbase outputs out to a single self-owned address, and then splitting from there

<a​ntilt:we2.ee> thats why going hybrid is needed

<k​ayabanerve:matrix.org> chaser @chaser:monero.social: If the active validator set (as needed to double spend) yes.

<o​frnxmr:monero.social> mining pools have to issue payouts. Cant mine "used" coins

<o​frnxmr:monero.social> Cant stake*

<a​rticmine:monero.social> That is the bear attack on POS. The short is incentivized to cause harm to the network to profit

<r​ucknium:monero.social> flip flop: You need to give the username of who you are replying to, especially when the user is on the IRC side.

<r​ucknium:monero.social> IRC side can't see which message is being replied to on the Matrix side.

<a​rticmine:monero.social> From the short

<s​gp_:monero.social> I personally think the idea of keeping PoW "in charge" at the front, while backstopping it with PoS, is a reasonable sell

<b​oog900:monero.social> hybrid doesn't fix that

<s​yntheticbird:monero.social> The finality layer really looks good. Is there no way to limit the damage of a malicious staker over time ?

<k​ayabanerve:matrix.org> Qubit could've shorted Monero before attacking it with PoW though?

<s​gp_:monero.social> slashing

<g​ingeropolous:monero.social> the hybrid just feels like we're adding a new door to exploit

<s​gp_:monero.social> yay design decision we need to solve

<k​ayabanerve:matrix.org> boog900: PoW + FL can potentially enable trade-offs regarding long range attacks and historical validator sets.

<s​pirobel:kernal.eu> ArticMine: you always end up with proof of stake no matter what. with proof of work you just need to jump through additional hoops that are unnecessary. from a pragmatic perspective the cost of attack would be an order of magnitude higher if monero was proof of stake. no way you can hedge this with shorts on kyc exchanges

<k​ayabanerve:matrix.org> We're replacing the PoW 51% attack risk with the issues of PoS.

<k​ayabanerve:matrix.org> (if we add a FL)

<a​rticmine:monero.social> Adding layers and complexity does not hide the fundamental flaw in POS

<c​haser:monero.social> kayabanerve: I'd be interested to hear your reasons

<j​effro256:monero.social> Yeah I guess it depends on how long you can delay payouts / what % fee you take

<s​pirobel:kernal.eu> buying cpus or asics + wasting money on electricity is a form of stake

<b​oog900:monero.social> kayabanerve: why no fixed max reorg depth?

<k​ayabanerve:matrix.org> Isn't the existence of shorts fundamentally an incentive to on purposely damage something?

<s​yntheticbird:monero.social> spirobel if you really feel like you need to shill pure PoS, try make that feeling go away.

Fixed reorg depth leads to permanent chain splits.

<s​yntheticbird:monero.social> you're unhelpful at spamming Articmine your point over and over

<c​haser:monero.social> jeffro256: what do you mean by "splitting from there?"

<s​gp_:monero.social> tevador: agree

<g​ingeropolous:monero.social> stake is permanent. if qubic had acquired enuf to perform a 51% on PoS.... then what?

<k​ayabanerve:matrix.org> chaser @chaser:monero.social: Either the window is short, and a 51% attack enables compromising the PoS layer too, or the window is long, and miners have to stick around for a year.

<r​ucknium:monero.social> spirobel: IMHO, your zero-inflation proposal for PoS collides with the collective action problem, at least for small stakers: If my validation is a drop in the bucket, why bother? It's more costly to me to validate than the small benefit I am getting to secure the chain. Or public goods problem, whatever term you prefer.

<s​pirobel:kernal.eu> ArticMine: pow is an added layer of complexity to proof of stake. it just means you need to buy cpus and send a check to your utility company to proof your stake in the network

<k​ayabanerve:matrix.org> boog900: Assumes a synchronous network and enables getting nodes stuck on alt-chains when syncing.

<a​rticmine:monero.social> A failing exchange could easily do this . MtGox staking Bitct?

<g​onbat.zano:zano.org> Respondind to ArticMine: To borrow such a large amount of the supply of a multi billion dollar coin you will still need more resources in the form of collateral than what it costs to rent CPUs

<g​onbat.zano:zano.org> Both PoW and PoS fall to actors with unlimited resources, it just takes way more with PoS

<a​rticmine:monero.social> Bitcoin

<k​ayabanerve:matrix.org> gingeropolous: Social slash.

<s​pirobel:kernal.eu> same problem currently with pow rucknium. pow is just a different colored version of proof of stake with added inefficiency and hoops

<j​effro256:monero.social> chaser: a mining pool normally pays out directly in the coinbase tx b/c of lower bytesize, but if we were to switch to only being able to stake coinbase outputs, a pool could pay out to itself, stake that output, and then when done, pay out in a regular tx

<g​ingeropolous:monero.social> pls explain to me like ive never really dug into PoS fixits

<k​ayabanerve:matrix.org> If the PoS layer fails, the Monero community deploys a hard fork to choose a chain and invalidate the malicious stake.

<g​ingeropolous:monero.social> jesus monkeybut

<b​oog900:monero.social> same with reorg?

<o​frnxmr:monero.social> I said somewhere else "pow pools may run "staking pools" where they stake your coins and pay extra if you dont withdraw them", but thats, imo, better (and less static) than exchanges running staking pools with people's "long term savings"

<b​oog900:monero.social> max reorg depth^

<a​rticmine:monero.social> Any dishonest CEX can borrow XMR at no cost

<k​ayabanerve:matrix.org> PoS halts on such a catastrophe. PoW will re-org. A re-org depth limit won't re-org but also won't halt at all.

<o​frnxmr:monero.social> Mining pool dont usually pay out in the coinbase, only p2pool does that

<k​ayabanerve:matrix.org> Unless you say any 10-block alt chain causes a halt. Then I can go halt every node right now. Give me a week.

Btw, have we considered renting some hashrate tomorrow? When qubic comes back to try again. Not sure if that's an ethical use of the general fund.

<o​frnxmr:monero.social> Artic, like tradeogre staking zano deposits

<c​haser:monero.social> kayabanerve: a finality layer can't stop a 51% attack anyway, so... regarding window length, I'm sure we can come up with a reasonable middle-ground between 10 blocks and 1 year.

<g​onbat.zano:zano.org> To artictime: If a CEX adquires 51% of XMR supply, they have vastly exceeded the budget needed to attack using PoW

<k​ayabanerve:matrix.org> ... a finality layer explicitly stops a 51% attack?

<g​ingeropolous:monero.social> 51% of what is currently staking

<k​ayabanerve:matrix.org> (as in, deep re-orgs)

<b​oog900:monero.social> the chance of a non malicious 10 block reorg is incredibly small

<o​frnxmr:monero.social> No, they dont jeed a budget to have 51% of the _staked_ xmr

<o​frnxmr:monero.social> They just need deposits

<k​ayabanerve:matrix.org> There are too many ongoing conversations for me to properly participate in.

boog900 you can't limit the reorg depth, otherwise an attacker can cause a permanent chain split.

<o​frnxmr:monero.social> @gonabat

<b​oog900:monero.social> best you can do is selfish mine 9 blocks send them out and hope to split the network on the next block

<s​pirobel:kernal.eu> rucknium you can look in the other channels people are willing to rent aws servers to protect monero with rented hashrate. there is so much belief and power in this community that people are going out of their way to incur costs to protect the network. it is a pos system where you lose money if you stake and people still do it

<g​ingeropolous:monero.social> yeah, what is the current topic of discussion?

<k​ayabanerve:matrix.org> chaser @chaser:monero.social: A finality layer stops deep re-orgs for as long as it stands.

<k​ayabanerve:matrix.org> gingeropolous: You're right a PoS finality layer could be captured. We'd generally assume that won't happen, as we assumed it for PoW, but now are revisiting.

<k​ayabanerve:matrix.org> boog900: You can't halt on a 10-block re-org though. You have to halt on any 10-block alt chain existing because you don't know which side you're on (the malicious one or the honest one).

<r​ucknium:monero.social> **Topic is: The introduction of non POW consensus mechanisms such as but not limited to A) Trusted Execution Environments, B) Proof of Stake Hybrid solutions, C) Other non POW consensus solutions **

<k​ayabanerve:matrix.org> boog900: You're assuming a synchronous network.

<b​oog900:monero.social> I wasn't calling for a halt fwiw

<s​pirobel:kernal.eu> another benefit of having validators with stake is that we can use this to prevent ecllipse attacks of nodes

<k​ayabanerve:matrix.org> But that was my original point. A finality layer failure causes a halt. A PoW failure doesn't.

<s​yntheticbird:monero.social> Other non POW consensus solutions? What if the finality layer was based on Proof of Space \/s

<o​frnxmr:monero.social> @tevador it will he hard to rent hashrate using xmr during a 51%. We have some btc though?

<r​ucknium:monero.social> ofrnxmr: I was looking at that BTC, too :D. miningrigrentals takes BTC.

<g​onbat.zano:zano.org> To ofrnxmr: What's harder/more expensive? An exchange custoding 51% of staked XMR or an entity adquiring 51% of pow. I think that's the key.

<g​onbat.zano:zano.org> I'm inclined to believe the prior is less likely

<k​ayabanerve:matrix.org> I believe I would like to draft a CCS to write a book going over the design questions for a finality layer, potential options, and my recommendations. I believe this presentation will be informative and while it won't answer if we should have a finality layer, may clarify what one is and the trade offs present.

<g​onbat.zano:zano.org> Especially if staking promotes self custody, can be done

<o​frnxmr:monero.social> @gonbat the latter. The former costs nothing

<k​ayabanerve:matrix.org> Would people here be receptive to such a CCS to create such documentation and provide a recommendation for IF we were to adopt a finality layer?

<g​ingeropolous:monero.social> was there any merit in what i posted on the github thing

<g​ingeropolous:monero.social> i dunno if that qualified as non-PoW, or if i should wait for a PoW based thing

<k​ayabanerve:matrix.org> This is my attempt to establish a proper conversation topic on the overwhelming flood of messages regarding the concept of a finality layer.

<s​yntheticbird:monero.social> jokes on you I can't read

<o​frnxmr:monero.social> I'd +1 the research

<k​ayabanerve:matrix.org> gingeropolous: Can you clarify?

It would cost around 0.04 BTC for 100 MH/s for 24 hours. Part of the cost would be recouped with mined XMR.

<g​ingeropolous:monero.social> the idea was that mining a block gives you a "credit" to add a block to the chain in the future, in some rolling window.

kayabanerve: Currently looks to me as the least unreasonable proposal on the table, so to say. I think it should get elaborated.

<k​ayabanerve:matrix.org> > chaser @chaser:monero.social: Either the window is short, and a 51% attack enables compromising the PoS layer too, or the window is long, and miners have to stick around for a year.

<g​ingeropolous:monero.social> basically, creating some kind of "past work means you do good work".

<k​ayabanerve:matrix.org> was my comment here on that idea, which I even mentioned in my GH issues when first posted.

<a​rticmine:monero.social> I believe we would need to address the underlying security of the proposed POS firts

<k​ayabanerve:matrix.org> ArticMine: If you believe PoS never has anything at stake (but PoW does), I'm unsure how you want us to address that other than by agreeing with you.

<o​frnxmr:monero.social> @gonbat kucoin and kraken probably hold more xmr in reserves than any other entity. Kucoin has (likelt falsly) claimed to have 9million xmr. This costs them negative amounts, as they are paid when a user uses their service. They pay nothing. Example: tradeogre was / is staking zano. They dont pay _anything_ for this stake

<k​ayabanerve:matrix.org> ... or by renaming PoS to Proof of Coin so it's not about if anything is at stake, but just about a decentralized way to select people to issue finality.

<a​rticmine:monero.social> Focusing on the top layer does not address the base POS layer issues

<s​pirobel:kernal.eu> @gonbat.zano: ArticMine ofrnxmr CEX only have paper monero those are excluded from staking. serious note: it makes no sense for an exchange to do a 51% attack and there is no CEX that holds that much XMR. so they would have to buy it

<c​haser:monero.social> I will support such a CCS, both in spirit and with my donation

<s​gp_:monero.social> the threshold is lower than 51% afaik

<s​gp_:monero.social> for pos

<k​ayabanerve:matrix.org> 34% is the academic bound for consensus in any asynchronous network.

<s​gp_:monero.social> I think it's conceivable that an exchange could have 34% of staked coins

<k​ayabanerve:matrix.org> In an asynchronous network, Monero only requires one malicious node by the way.

<g​onbat.zano:zano.org> To ofrnxmr: if it's confirmed that over 51% of XMR Is custodied then I'd stay away from PoS

<g​onbat.zano:zano.org> however if that's not yet the case, PoS can be used to incentivize self custody, by disallowing delegations

<s​pirobel:kernal.eu> sgp_: true. still the practical cost of attack is orders of magnitude higher than a 51% attack against a pow network

<k​ayabanerve:matrix.org> I'll reiterate the potential to social slash.

<s​gp_:monero.social> Access to capital isn't precisely the same as cost

<k​ayabanerve:matrix.org> The community can always issue a HF invalidating all staked coins if the shakers misbehave, even if they do so in a way so catastrophic, it halts the current chain.

<g​ingeropolous:monero.social> so social slash just means that a bunch of people decide that the bad actors blocks shouldn't be included

<g​ingeropolous:monero.social> so we could just get all the existing pools to make an agreement to mine on each others blocks and we'd have a similar thing

<k​ayabanerve:matrix.org> No. If the finality layer is co-opted, we can issue a hard fork resetting it, burning all staked coins.

<o​frnxmr:monero.social> [@gonbatfire:monero.social](https://matrix.to/#/@gonbatfire:monero.social) : its not 51% of xmr, but 51% of the staked xmr. Kucoins 9-10million is clearly fake.

<g​ingeropolous:monero.social> hmmm... the we

<g​ingeropolous:monero.social> WE

<s​pirobel:kernal.eu> thats why its good that monero is anti custody. it will be much secure than other coins that are held in large percentages by exchanges (that still are unlikely to commit extremely self damaging crimes all at the same time )

<k​ayabanerve:matrix.org> We, the Monero community.

<g​onbat.zano:zano.org> To ofrnxmr: then that would be a matter of getting everyone to stake, much easier/meaningful than getting everyone to mine

<g​ingeropolous:monero.social> sounds permissioned and centralized to me, but that could be just me

<s​yntheticbird:monero.social> Brother luigi decide when to release

<s​yntheticbird:monero.social> I think this is already centralized enough

<s​gp_:monero.social> there's also a _risk_ that networks like Serai/Thorchain/whatever get strong acceptance _and_ are programmed to stake

<o​frnxmr:monero.social> And open for coopting / infilatration at the community level( see bitcoin)

<g​ingeropolous:monero.social> codes not the network bro

<k​ayabanerve:matrix.org> It's about as permissioned as us deciding to do a HF banning Qubic from mining (if we could) and then getting the community to download and run the new release.

<g​onbat.zano:zano.org> I wouldn't like that

<k​ayabanerve:matrix.org> I'm noting a social slash would be the same complexity and process.

<g​ingeropolous:monero.social> permanent solutions to temporary problems. Look, if the chain was unusable and everything was falling apart then sure, maybe.

<o​frnxmr:monero.social> qubic, and anyone, should be allowed to mine. But the network should protect against "breaking" itself, whether intentionally or unintentionally.

<g​ingeropolous:monero.social> we got a 6 block re-org

<a​rticmine:monero.social> Yes specifically banning Qubic is the same. Who is proposing this

<a​rticmine:monero.social> I cannot support this finality layer

<b​oog900:monero.social> 7* :)

<s​yntheticbird:monero.social> stonks

<v​enture:monero.social> an immediate band-aid for deep-reorgs would be raising the cost to mine a block, ie. lower the block frequency?

<g​onbat.zano:zano.org> To gingeropolous: Qubic can go away tomorrow, there's still the long time issue of only needing 100k to attack for a month, security budget needs to raise, and price alone won't cut it

<b​oog900:monero.social> that would make it easier to remove more PoW?

<c​haser:monero.social> kayabanerveI in a trailing finality layer as you propose it, what would happen if a malicious pool attempts a reorg that's deeper than the trailing span?

<k​ayabanerve:matrix.org> It wouldn't be acknowledged. Nodes would always follow a blockchain descending from the last finalization.

<o​frnxmr:monero.social> this would make it more difficult to reorg, no? - changing to 4 minute blocktimes causing a dbling of the difficulty. (Also increases size of p2pool payouts, and blocks(?))

<g​ingeropolous:monero.social> aight, lemme try and summarize my idea again. There's a rolling window. When you mine a block, a new protocol decreases the friction for you to add a block in the future. The more friction you have (by being a new miner) means that nodes question whether to add your 7 blocks to the chain tip. The less friction you have, means that your future block will be added to chain tip without question

<g​ingeropolous:monero.social> obvi difficult to implement during an attack.

<k​ayabanerve:matrix.org> That would seem to encourage centralizing to just a few pools, if not one or two?

<c​haser:monero.social> kayabanerve: in that case, how would a node syncing from genesis decide between two conflicting chains?

<s​yntheticbird:monero.social> so you would add mining state into blocks?

<b​oog900:monero.social> I would have assumed reorging 2 blocks at half the difficulty would've been harder than 1, but I could be wrong

<g​ingeropolous:monero.social> no, normal miners could still have decreased friction.

<k​ayabanerve:matrix.org> chaser @chaser:monero.social: There should never be two distinct finalized chains.

<s​gp_:monero.social> gingeropolous: does this not encourage consolidation around a single pool? I don't follow

<k​ayabanerve:matrix.org> That's either a catastrophic error, or we could adopt a synchronous tiebreaker based on most work exclusively for initial block downloading.

<s​pirobel:kernal.eu> i support the finality layer idea, also because staked validators can help with the eclipse / spam attack on nodes.

<g​ingeropolous:monero.social> So your a solo miner. You mine a block. You have high friction because you don't mine blocks that often. Your block makes it to another node. They have to choose whether to add your block. Your single block has high friction, but its a single block.

<j​effro256:monero.social> venture: no. If we increase the block time, the *amount of time* that a reorg spans is the same, just a fewer number of blocks. It has no effect on security or really UX, except now that the block time is higher. It may result in a lower block propogation time to block time ratio, which increases stability, but that really isn't a huge issue in the context of this discussion

<g​ingeropolous:monero.social> Now say you are an attacker. You mine 6 blocks. You have high friction because you don't mine that often. This 6 block thing comes to a node. The node goes "hey, you have high friction. I don't think I should add these blocks"

<v​enture:monero.social> boog900: current successful re-orgs with less than 51% happen only by luck over time, Ruckniums meta attack. that would be mitigated somewhat if the difficulty for a block was doubled (ie, 4-min blocks)

<o​frnxmr:monero.social> @ginger, isnt this backwards? Amd is pro-pool, anti solominer?

Have we thought about working on making propagation faster for all blocks

<g​ingeropolous:monero.social> if the attacker only sent 1 block, then yeah, the node may consider adding it

<s​gp_:monero.social> 1 year block times here we go /s

<j​effro256:monero.social> gingeropolous: this is more or less uncle blocks, yeah?

<k​ayabanerve:matrix.org> This seems to optimize mining around low friction nodes which will be frequent miners, AKA large pools, and would simultaneously eliminate p2pool which can't identify itself as a pool in its current form.

<k​ayabanerve:matrix.org> (or at least, never let it get to a lower friction state)

<a​rticmine:monero.social> Are there any other non POW proposals under consideration?

<g​ingeropolous:monero.social> it depends on how large the window is

<g​ingeropolous:monero.social> and the main thing is to prevent selfish mining

has anyone looked into Stellar's Proof of Agreement?

<b​oog900:monero.social> I would have thought more blocks lowers the part luck plays

<g​ingeropolous:monero.social> there's no reason a 6 block re-org from the same miner should come to a node and the node go "yup this is obviously better than what i have"

I think the main way we can prevent selfish mining is taking a page from Bitcoin book from 2015 with what they did with FIBRE

<g​ingeropolous:monero.social> and selfish mining is the mechanism of double spend 51% attacks blah blah

<a​ntilt:we2.ee> yes

<k​ayabanerve:matrix.org> Non-BFT PoS and using Ethereum for finality would be the other non-PoW non-FL discussions.

<k​ayabanerve:matrix.org> (Or using BTC)

<v​enture:monero.social> boog900: seemingly, but re-orgs "roll-back" in time, and the odds of finding a block is higher with more frequent blocks.

<s​yntheticbird:monero.social> I'll also redrop the Proof of Space which is way harder to rent

<b​oog900:monero.social> I would not want to depend on another network

I don't think we should depend on other chains

<g​ingeropolous:monero.social> i mean i'd prefer merge mining with BTC over anything else. Easy enough to fork away from if BTC gets compromized

<s​gp_:monero.social> I know kayaba rescinded TEE due to it not helping with the 51% PoW attack, but TEE is one option to keep in mind due to it potentially being useful at mitigating individual tx censorship. I only mention this for completeness, I'm not actually _for_ TEE at this stage

<k​ayabanerve:matrix.org> SyntheticBird: PoS is still _a_ PoW.

<a​ntilt:we2.ee> tell me more...

<o​frnxmr:monero.social> "if btc gets compromised" welcome to 2017?

<s​yntheticbird:monero.social> A lot of problems seems easy to eliminate through forking unsurprisingly

<g​ingeropolous:monero.social> well i'll run my idea through my simulator and see how solo miners do

<b​oog900:monero.social> but the odds of finding more blocks with the same PoW as one big one with luck would be smaller

<k​ayabanerve:matrix.org> I rescinded it because it doesn't really help with anything sgp_:

P2Pool are already able to take one block into a single network packet and sends it to many peers at once, with packet sizes less than 1 KiB. but this is just in the p2pool software, is there anyway this can be implement for all nodes so that non-p2pool pools get the same ability

<s​yntheticbird:monero.social> very true, the second point stand tho. cpu is easier to rent than storage

Bitcoin was compromised by Blockstream a while ago

<s​yntheticbird:monero.social> I'm not shilling it btw, just notating it here

<k​ayabanerve:matrix.org> It fails during a 51% attack and doesn't solve anything not already 'solved' when there isn't a 51% attack.

<a​rticmine:monero.social> The Intel ME is a TEE. A rather controversial one

<s​pirobel:kernal.eu> sgp_: i 100% agree with ArticMine when it comes to TEE. tee is just horrific and we should not entertain this

<k​ayabanerve:matrix.org> > The TEE solution I proposed has been withdrawn and I maintain is fundamentally misunderstood by anyone still yelling against it because TEEs are insecure.

<k​ayabanerve:matrix.org> It's fun how I said this almost an hour ago.

lol

<s​yntheticbird:monero.social> I was gonna quote it

<o​frnxmr:monero.social> hey. I'm not pretending to understand it

<s​gp_:monero.social> I brought it back, I thought it could still help with anti censorship. I'll sync on this later and we can drop further discussion here

<r​ucknium:monero.social> I aim to not break any meeting length records again, so I would like to have the "main part" of the discussion end in 15 minutes. Of course, discussion can continue in this room and #monero-research-lounge:monero.social . At the end, I want specific people to commit to specific steps to advance this R&D agenda.

<k​ayabanerve:matrix.org> The only actionable item here that I see is one of two:

<k​ayabanerve:matrix.org> - Attempt rough consensus on a fee policy

<k​ayabanerve:matrix.org> - Attempt rough consensus on if my CCS would be received or immediately declined as work on a path we haven't agreed to take, even though my CCS would be to write how that path would look

<a​ntilt:we2.ee> can you point me to a description?

<k​ayabanerve:matrix.org> I don't believe we'll agree to any hard forks today, and I'm unsure there's any other relay rules we can discuss today.

<s​yntheticbird:monero.social> I'm personally interested into having your CCS completed before discussing it

<s​gp_:monero.social> (or if anyone else wants to help with TFL research)

Pumping up the fee can help with miner profitability, does anyone know the average amt a block receives in fees?

<k​ayabanerve:matrix.org> I would like to not spend a few hours drafting a CCS to explore, explain, and recommend a FL unless that would potentially be accepted depending on if the proposal itself is fair.

<k​ayabanerve:matrix.org> (I don't charge millions of dollars)

<a​rticmine:monero.social> How about the proposals from trevador and Sech1 that have effectively been sidelined?

<k​ayabanerve:matrix.org> flip flop @antilt:we2.ee: The first would be as in Zano, the second would be exactly what it says.

<s​yntheticbird:monero.social> can someone link sech1 proposal?

<k​ayabanerve:matrix.org> Those require hard forks. I don't believe we'll agree on a hard fork today.

<s​yntheticbird:monero.social> im all for tevador one but as rbrunner said it will take time to implement

<k​ayabanerve:matrix.org> SyntheticBird: Miners sign their blocks and get a minimum percent of the reward.

<r​ucknium:monero.social> I personally don't support a fee change in the short term because it does not help with the short-term problem. In the medium or long term, fee policy changes could be a good idea, especially if it were linked to PoW difficulty as an oracle for the purchasing power of 1 XMR.

Is that to prevent the hidden mining tactic pubic tried doing?

<s​pirobel:kernal.eu> I think we should have another one that rips the band aid off completely. no inflation PoS

<o​frnxmr:monero.social> - 10 block reorg limit. Doesnt require hf, can be opt-in.

<o​frnxmr:monero.social> - sanity check on block contents. Not accepting lower quality blocks that arrive later than higher quality ones

<o​frnxmr:monero.social> - potential block frequency change

<k​ayabanerve:matrix.org> Also, no one has to listen to me as I try to co-opt Rucknium's position of chair. I'm only trying to steer to what could happen today because:

<k​ayabanerve:matrix.org> 1) I explicitly have self-interest

<k​ayabanerve:matrix.org> 2) I figure we'll continue discussions this next week and only need the meeting for summaries, reasonable clarification (< 2 hours of it), and rough consensus

<s​gp_:monero.social> I'm sorry but an opt-in 10 block reog limit is literally you opting in to run on a different network than everyone else if anything goes wrong

<k​ayabanerve:matrix.org> Soiled: No, it's to reduce pool mining.

Gotcha

<k​ayabanerve:matrix.org> ofrnxmr: The first assumes a synchronous network. The second keeps miners on worse block chains when being attacked.

<o​frnxmr:monero.social> Blame bch. Theirs is entirely modifiable with a runtime flag 😅

BCH good

<b​oog900:monero.social> and not is opting to run on a chain which could have a load of txs removed by an attacker?

<k​ayabanerve:matrix.org> Instead of miners immediately jumping to a longer chain to best purpose their work, they'd continue on a worst chain by choice 🤮

<o​frnxmr:monero.social> We literally have cjeckpoints rhat do this already

<o​frnxmr:monero.social> Dns checkpoints can force those who opt-in onto a core-decided chain

<k​ayabanerve:matrix.org> It makes selfish mining easier as now, even when you do finally publish, you don't have competition.

<b​oog900:monero.social> yeah if someone reorgs beyond checkpoints we would have multiple chains right now

<o​frnxmr:monero.social> Peopke running 18.3.4 can reorg deeper rhan 18.4.1

<k​ayabanerve:matrix.org> We can move to a single checkpoint of the last PoW-only block if we adopt a finality layer /s

<b​oog900:monero.social> We can add rules that prioritizes chains that were published for longer

<k​ayabanerve:matrix.org> ... that literally just wastes honest hash power

<s​gp_:monero.social> option Z: monero devs run the finality layer exclusively with frequent DNS checkpoints #centralization

<b​oog900:monero.social> a 9 block alt chain should not be mined on if a 9th block comes from the previous main chain

<k​ayabanerve:matrix.org> It has honest hash power waste time on a worse chain, before they actually mine a candidate chain

<o​frnxmr:monero.social> - sanity check on block contents. Not accepting lower quality blocks that arrive later than higher quality ones

<o​frnxmr:monero.social> Boog, thats similar to this

<k​ayabanerve:matrix.org> For chains of equal work, I believe nodes already prefer the first seen? No?

<g​ingeropolous:monero.social> i mean, thats why the DNS checkpoint system was created, for defense etc, afaik

<o​frnxmr:monero.social> Sgp: isnt that why the dns-checkpoints flag was created

<j​effro256:monero.social> kayabanerve: Yes

<b​oog900:monero.social> split network > 1000 block reorg

<k​ayabanerve:matrix.org> So your proposal boog900 would only help for chains of more work and less time seen vs less work and more time seen, which is why it wastes honest hash

<o​frnxmr:monero.social> First seen, but they will reorg to longest chain, even ia longest is selfish

<b​oog900:monero.social> temp split network*

<a​rticmine:monero.social> Are there any more items on the agenda?

<k​ayabanerve:matrix.org> It also allows taking advantage of network conditions to make a second-seen chain less preferred, even if first broadcast

<b​oog900:monero.social> possibility of*

<r​ucknium:monero.social> There are no more items on the agenda

<k​ayabanerve:matrix.org> ArticMine: My attempts for rough consensus on two items I thought we may be able to, and more running in circles.

Has anyone considered faster block propagation

<k​ayabanerve:matrix.org> Or none per the official agenda :p

<s​yntheticbird:monero.social> Sir it's been 7 months, can i sleep now?

<b​oog900:monero.social> this was part of the 10 block max reorg FWIW

<b​oog900:monero.social> it would only be for blocks close to the boundary

<b​oog900:monero.social> to try mitigate the risks of a chain split

<k​ayabanerve:matrix.org> That assumes a synchronous network :///

<b​oog900:monero.social> a small price to pay

<k​ayabanerve:matrix.org> Considering synchronous networks don't exist IRL?

<k​ayabanerve:matrix.org> They're solely ideal models of computers?

<k​ayabanerve:matrix.org> I disagree.

<k​ayabanerve:matrix.org> We should move to a solution which works in asynchronicity.

<b​oog900:monero.social> as long as their is not someone constantly wasting an immense amount of hashes keeping the bad chain it'll resolve it self eventually

<b​oog900:monero.social> if not a simple update to the built in checkpoints will kill it

<k​ayabanerve:matrix.org> The fact sticky chains wastes any hash power of honest miners presumably decreases honest miner profitability.

<b​oog900:monero.social> we have never had a 8 to 9 block reorg so it would be very small

<k​ayabanerve:matrix.org> And re: a max re-org depth, no, the difficulty on the alt will trend to 0 and be infinitely cheap to keep alive indefinitely.

<k​ayabanerve:matrix.org> Not really when an adversary is already so large and doing all of these attacks?

<b​oog900:monero.social> it would have less PoW eventually?

<k​ayabanerve:matrix.org> It'd tip in their favor further.

<k​ayabanerve:matrix.org> But with a max re-org depth, they won't re-org back to the chain with the most work boog900:

<j​effro256:monero.social> boog900: Guaranteed network splits at 10 blocks would certainly increase the incentive for an attacker to go for a 10-block reorg

<k​ayabanerve:matrix.org> I will no longer be present here in the remnants of the meeting but solely popping in occasionally. Bye y'all.

<a​rticmine:monero.social> I just don't see these highly controversial solutions where there is clearly little consensus as an option.

<a​rticmine:monero.social> 1) TEEs . Thankfully this has been withdrawn

<a​rticmine:monero.social> 2) 2 POS hybrid solutions.

<a​rticmine:monero.social> The harm in my view is that the above are distracting the community from even considering way less disruptive proposals, that are way less controversial.

<s​yntheticbird:monero.social> good night

<s​yntheticbird:monero.social> ArticMine, this is the non-PoW section

<s​yntheticbird:monero.social> we are deemed to discuss controversial changes

<n​oname-user0:matrix.org> hybrid solutions are more forward looking imho

<r​ucknium:monero.social> I don't see a lot of support for immediate relay-rule fee changes. kayabanerve has a proposal on the table for him to draft a CCS on Trailing Finality Layer research (the proposal would be subject to all the normal discussion and vetting as any other CCS, if proposed). What does everyone think of the proposal to write a CCS proposal?

<b​oog900:monero.social> true, but you would need to publish at the exact right time and also have those blocks ready and mined

<o​frnxmr:monero.social> +1 of research proposal. I dont see any problem with looking into it

<b​oog900:monero.social> also this is why I mentioned prioritizing the chain that got reorged?

<b​oog900:monero.social> maybe if you got reorged at 9 blocks the limit is dropped?

<h​ardenedsteel:monero.social> are there estimation of the hashrate of the attack?

<h​ardenedsteel:monero.social> we can roughly calculate how much hashrate coming by observing staled (orphaned) blocks

<h​ardenedsteel:monero.social> static.learnmeabitcoin.com/technica…hain/51-attack/equation-success.png

<a​rticmine:monero.social> Good day

<s​pirobel:kernal.eu> ArticMine: the pow game has been plaid out. its either asics, gpus or cpus. I personally think the endgame for private digital cash is zero inflation pos with 1-10 second finality. (default path sub 2 second finality)

<g​onbat.zano:zano.org> ArticMine: how much do you think Monero security budget needs to increase? 2x, 10x?

<g​onbat.zano:zano.org> The latter only happens with drastic approaches

<b​oog900:monero.social> for the reorged chain only*

<r​ucknium:monero.social> I will search the research literature for ways to harden PoW consensus. I will also try to get a basic understanding of Trailing Finality Layer and the research on Proof-of-Stake failure modes. I haven't looked into PoS much because PoW-only was taken for granted.

<s​gp_:monero.social> I think Zcash's resources are a good starting point for TFL research

<j​effro256:monero.social> I'm heading out. Good meeting, y'all, thanks to everybody who participated.

<a​ntilt:we2.ee> electriccoin.co/blog/the-trailing-f…ng-stone-to-proof-of-stake-in-zcash

<c​haser:monero.social> Rucknium: Kayaba said they'll write the proposal only if there's a good chance of it being accepted so it's not in vain. can anyone here give such a guarantee? I personally see the mentioned exploratory work as useful and support the effort.

One Weird Trick to Stop Selfish Miners > eprint.iacr.org/2014/007.pdf

<r​ucknium:monero.social> We can end the meeting here. Thanks everyone.

<s​yntheticbird:monero.social> Thanks

<s​gp_:monero.social> Thank you Rucknium for breaking this up and focusing the discussion!

<k​ayabanerve:matrix.org> I more meant if MRL is cool with it chaser @chaser:monero.social:

Have a good one yall

<v​enture:monero.social> Thanks, good night.

<r​ucknium:monero.social> Feel free to continue discussing here or in #monero-research-lounge:monero.social

<k​ayabanerve:matrix.org> Because Monero Community will want MRL to sign off

<k​ayabanerve:matrix.org> So I wanted to ask if MRL may even sign off, and not ouright refuse it because we aren't currently working on a FL, and it sounds like yes

<s​pirobel:kernal.eu> Rucknium: also look into how much the security budget and cost of attack is in PoW vs PoS that would be helpful in having an informed discussion and if a hybrid would ever make sense from an economic point of view

<c​haser:monero.social> kayabanerve: got it. several people said yes here, none against

<s​gp_:monero.social> Shower thought on the 10 block lock (I haven't thought it through that thoroughly): it might incentivize pools to only publish their combined blocks in 10-block batches (?)

<s​gp_:monero.social> *10 block reorg limit

<n​oname-user0:matrix.org> it's optional to follow it. it's more of a suggestion. and if you dont agree to --enforce-dns-checkpointing then you will naturally still follow the normal longest chain rules afaik. so this would cause some serious network splits unless the enforce flag was default.

<r​ucknium:monero.social> HardenedSteel: I tried using the method of Ozisik, Bissias, & Levine (2017) "Estimation of Miner Hash Rates and Consensus on Blockchains" arxiv.org/abs/1707.00082

<r​ucknium:monero.social> but I don't get the iterative algorithm to converge. I will try again sometime.

<s​pirobel:kernal.eu> kayabanerve: i dont think a hybrid pow pos system makes sense, but I still support your proposal because it moves the discussion forward.

<h​ardenedsteel:monero.social> can you look up on that: learnmeabitcoin.com/technical/blockchain/51-attack

<h​ardenedsteel:monero.social> matrix.monero.social/_matrix/media/…ero.social/hZYSyVFKoYEDsvMZfzAASiqM

<r​ucknium:monero.social> spirobel: Ok. That is a lot to do in a week (with everything else), but I can get to it eventually.

<h​ardenedsteel:monero.social> there's also ruby code calculate

<h​ardenedsteel:monero.social> given time span, the attacker roughly has ~20% hashrate

<s​pirobel:kernal.eu> its the first question you have to ask rucknium. because if the conclusion is that pow is vastly less secure more expensive than pos: why bother with pow and hybrid systems?

<r​ucknium:monero.social> I think the case has already been made that with side-payments, cost to attack PoS can be the cost of paying an interest rate.

<r​ucknium:monero.social> But I will have to look into the research!

<s​pirobel:kernal.eu> the state of the art on consensus systems currently is between alpenglow and Mysticeti

<s​pirobel:kernal.eu> everything else is a sideshow of obscure low market cap stuff or highly theoretical

<r​ucknium:monero.social> HardenedSteel: Thanks. I just skimmed it. I think mine is better :D monero-project/research-lab #102#issuecomment-2402750881

<r​ucknium:monero.social> I think they are using the original Satoshi formula, which had a small error.

<m​rmatrixer:matrix.org> What users are the official devs?

<h​ardenedsteel:monero.social> > Here's the equation from the Bitcoin Whitepaper (Section 11):

<g​onbat.zano:zano.org> Current Pure PoS impmementation like ETH have very centralized ways to avoid long range attacks, it's why Zano sticks to hybrid even though we believe PoS is superior

<s​pirobel:kernal.eu> the issue with zano is that its a very small community so its centralized in any case.

<g​onbat.zano:zano.org> let's move to lounge

<s​pirobel:kernal.eu> the game is between ETH, solana and (in theory) sui

<s​pirobel:kernal.eu> ok

<f​reeman:cypherstack.com> Hi all! I've been OOTL recently, but does anyone have an analysis estimating the Qubic control percentage, based on probability of replacing the top X blocks? I would be very interested in comparing anyone's analysis, thanks

<h​ardenedsteel:monero.social> read a bit little above

<h​ardenedsteel:monero.social> read little bit above

<f​reeman:cypherstack.com> I should have been more thorough 😅 thanks a ton, I look forward to reading these

<h​ardenedsteel:monero.social> judging from the table and moneroconsensus.info

<h​ardenedsteel:monero.social> around ~23%