<l​owdegree:matrix.org> I am 314stache_nathy from Reddit, I have deleted my account in Reddit and Matrix (an foid

<l​owdegree:matrix.org> I am 314stache_nathy from Reddit, I have deleted my account in Reddit and Matrix.

<l​owdegree:matrix.org> I deleted from Reddit to Use more decentralized platforms (and my old account here haved problems).

<l​owdegree:matrix.org> Nice meet you again guys :)

<k​ayabanerve:matrix.org> vtnerd: It's up to us, but for a finality layer:

<k​ayabanerve:matrix.org> - We can having staking outputs be transparent

<k​ayabanerve:matrix.org> - We can have staking outputs be private

<k​ayabanerve:matrix.org> If private, we need to eventually decrypt the _sum_ of stake. This isn't an issue. What's notable is decryption of not just the sum, but every individual staking output, would be possible by:

<k​ayabanerve:matrix.org> - A malicious 67%

<k​ayabanerve:matrix.org> - A quantum computer

<k​ayabanerve:matrix.org> We can avoid this by adding one more layer to the system.

<k​ayabanerve:matrix.org> - The user creates a timelocked output to stake

<k​ayabanerve:matrix.org> - The user creates a stake transaction which:

<k​ayabanerve:matrix.org> 1) Proves the existence of a staking output

<k​ayabanerve:matrix.org> 2) Proves it encrypts the correct amount

<k​ayabanerve:matrix.org> Ugh, my formatting just got butchered.

<k​ayabanerve:matrix.org> If we are unlinkable to the outputs, slashing becomes more difficult. It's possible?

<r​ucknium:monero.social> kayabanerve: Did you check the recent work in PoPETs about private Monero reserve proofs? Maybe something could be useful in there.

<k​ayabanerve:matrix.org> Validators, to vote, would have to say 'I own some output for X' (again, not linked to the output under FCMP++ methodology except via a key image'. We could assign dedicated key images for staking, allow slashing staking key images, and then as we prove the key image wasn't prior used, we would prove the staking key image wasn't slashed?

<k​ayabanerve:matrix.org> But requiring publishing the staking key image would be linkable from on-chain outputs to validators. We'd have to handle the 'staking key image' inside the FCMP and not actually publish the 'staking key image'. Probably a _sparse_ merkle tree?

<k​ayabanerve:matrix.org> TL;DR We can get effectively full unlinkability from staking to actual Monero outputs _and_ maintain slashing with more and more technical designs. All descend from the FCMP methodology, and all would be feasible, but would require:

<k​ayabanerve:matrix.org> - An extra TX type to add a forward-secret degree of separation between the output and the stake declaration

<k​ayabanerve:matrix.org> - A non-trivially slower FCMP (4x?)

<r​ucknium:monero.social> moneroresearch.info/266 Thakore, V., & Vijayakumaran, S. (2025). MProve-Nova: A Privacy-Preserving Proof of Reserves Protocol for Monero, Proceedings on Privacy Enhancing Technologies, 2025(2), 582–606.

<f​lyingfish0:matrix.org> Is it technically possible to know ( as a miner software) if i'm taking part to an attack from my pool on the network ? and if so adding an option on the mining software to switch to another pool if such attack is detected. This prevents those who invest in monero from hurting the trust in the token

<k​ayabanerve:matrix.org> (This is in response to a tweet from vtnerd, which I responded there and here as well as I'd prefer to discuss it here)

<k​ayabanerve:matrix.org> Rucknium: I'd have to look for the exact techniques but possibly :)

<r​ucknium:monero.social> Pedro Da Fonseca: This is a good question to bring to the #monero room. The short answer is use p2pool.

<r​ucknium:monero.social> Thakore & Vijayakumaran (2025), linked above, have their own technique and the literature review could be helpful. It applies to RingCT outputs now AFAIK.

<k​ayabanerve:matrix.org> I've outlined a few chapters of my proposed book to discuss ways the L1 can declare staking outputs, and the tradeoffs it causes :)

<f​lyingfish0:matrix.org> Ok but It could also be a defense mecanism, if the most part use this option, even if they're on qubic for profitability each time they try to become a bad actor they're fucked and can't know in advance by how much

<f​lyingfish0:matrix.org> Only works if they use the mining software from monero when linked to qubic don't know if it's the case

<s​pirobel:kernal.eu> this has privacy implications though. Assuming the stake is a large percentage of the monero supply, knowing the amount staked (and how it changes) helps with correlating large amounts of capital that move in and out of monero.

<k​ayabanerve:matrix.org> I was responding specifically to being able to link it to outputs.

<k​ayabanerve:matrix.org> If you see a notable amount of Monero leave the staking pool, and a similar notable amount hit your exchange, then obvious guesses are obvious.

<s​pirobel:kernal.eu> if you consider the extreme case where almost all of the monero is staked, then it is easy to correlate when somebody swaps in and then out again. For large movements of capital this still applies even at realistic percentages of total market cap staked. thought you agreed to this here serai-dex/serai #333#issuecomment-3191481625 but just realized when rer<clipped message>

<s​pirobel:kernal.eu> eading that you only agreed to low amount of stake per validator. I would argue even low amount of stake for the total network is desirable. Would you agree?

<k​ayabanerve:matrix.org> Sorry, I did misunderstand you there. I called for an accessible stake for decentralization.

<k​ayabanerve:matrix.org> Considering the amount of stake is only publicly revealed as a weekly difference, I'm unsure how impactful that is for small entries/exits into the staking pool.

<k​ayabanerve:matrix.org> By assigning everyone one stake, and having someone who stakes five times still appear as five distinct validators, it also wouldn't be feasible to determine if one large amount of stake dropped off or a lot of small entries.

<k​ayabanerve:matrix.org> I'll agree there's theoretical concerns regarding the privacy pool

<s​pirobel:kernal.eu> I don't think those are theoretical. One of the main benefits of Monero over something like tornado cash is that you can go in with size.

<k​ayabanerve:matrix.org> Monero users don't have to stake if they don't want exposure to these considerations.

<h​bs:matrix.org> I once understood that what was being considered was to only stake coinbase outputs, is that no longer the case? Because in the case of coinbase outputs there is direct linkability with the mining address in the case of p2pool. And in order to maximize the number of coinbase outputs one detains, the use of p2pool imposes itself, right?

<s​yntheticbird:monero.social> This was ofrnxmr idea

<s​yntheticbird:monero.social> and it isn't considered at the moment because of mining window and hashrate need to stake enough coinbase

<s​yntheticbird:monero.social> so it will either take 2 weeks for big pools, or 2 years for other

<s​yntheticbird:monero.social> at least that's what i remember

<h​bs:matrix.org> Thanks for the precision, that's too bad it's not seriously considered, this would retain the ethos of Monero way more than if a staker can simply buy its stake :-(

<a​rticmine:monero.social> An issue here is false accusations by blockchain surveillance companies that, while mathematically unsound, could still be accepted by a court of law especially at first instance.

<a​rticmine:monero.social> Blockchain surveillance is based upon the sale of guesses to governments and law enforcement.

<a​rticmine:monero.social> It is for front deterministic

<a​rticmine:monero.social> From

<s​yntheticbird:monero.social> The fact that judges understand nothing to cryptography or mathematics yet have to decide on the life of someone else over it. Explaining them why they are false sounds like insolence doubled by an impression of arguing semantics to them. No shit they prefer to rely le and blockchain surveillance claims. It's always about assurance, not doing the right thing

<a​rticmine:monero.social> The issue is that the Court can accept an argument that can be mathematically valid for a certain case and extrapolate it to situations where there is little or no mathematical validity.

<a​rticmine:monero.social> This is what happened in the case in US Federal Court that I was presented at last year. I am not saying that this will be upheld by the higher courts, but even if it is overturned on appeal a lot harm can be done to an innocent person.

<a​rticmine:monero.social> If blockchain surveillance can work for large amounts, then innocent people with small amounts can and will be falsely accused.

<a​rticmine:monero.social> I was working for the defense in the case.

<s​pirobel:kernal.eu> 1. this affects non staked users as well. 2. it is not only about evidence considered in court. Even heuristics that help narrow a case are to be avoided. Amount staked + changes in amount staked are a piece of information that narrows the possibilities when trying to correlate amounts flowing in and out of Monero. 3. The burden of proof is on the proposal for a high percentage of<clipped message>

<s​pirobel:kernal.eu> total MC staked. Solana halted and had to be restarted by a bunch of people in a discord channel. Ethereum halted as well. Even over 60% in the case of sol and around 30% in the case of eth was not enough to prevent a shutdown. A higher percentage staked does not seem to correlate with higher security in terms of liveness. serai-dex/serai #333#issuecommen<clipped message>

<s​pirobel:kernal.eu> t-3194677441 pointed out in this comment how we can compare PoW PoS and hybrid PoW-PoS solutions. If someone has a better idea how to reason about the relative security please go ahead.

<s​pirobel:kernal.eu> hbs: staking from coinbases would also introduce needless fungibility issues. It creates a situation similar to ordinals. Where some fresh coinbase outputs are worth more than other outputs. Because you can stake from them. It just makes the system harder to reason about for no benefit.

<s​yntheticbird:monero.social> tbf, whatever the crypto, coinbase outputs has always and will always be worth more than non coinbase outputs. At the condition that the seller can prove it is indeed coinbase.

<s​yntheticbird:monero.social> this includes monero as well

<s​yntheticbird:monero.social> tho for monero the difference in value is way less than transparent chains

<k​ayabanerve:matrix.org> hbs: It is an option but isn't my preferred option as control of hash power immediately leads to a takeover of the PoS layer. Even now, it'd cede the system to our largest pool.

<k​ayabanerve:matrix.org> spirobel: Ethereum didn't halt since moving to PoS. They once had finally stall for some hours, but the chain itself continued. We could have similar behavior with Monero, falling back to the current PoW.

<n​oname-user0:matrix.org> I don't think we would actually meet the minimum threshold of pos stake to get it started for monero

<n​oname-user0:matrix.org> this is a risk no one is talking about

<k​ayabanerve:matrix.org> It would be trivial to only have the system start after X stakes have been created, at some minimum, which we could even have decay over time.

<n​oname-user0:matrix.org> the eth pos transition took a good long time to do to endure staking was ready. also they had a lot of centralized nodes and treasury coins to jump start it

<n​oname-user0:matrix.org> that's not so safe is it? having like only 10% of the network stake

<k​ayabanerve:matrix.org> I mean, practically, if we're 'over-subscribed' (more stakes than targeted validators), we would want to raise the stake requirement, in a manner akin to how we adjust blocks' difficulties

<n​oname-user0:matrix.org> i guess the downside to a few stalkers would be imbalanced reward distribution IF we give some stake rewards

<k​ayabanerve:matrix.org> Having a notational 500m USD of a no-premine, tail-emission coin staking??

<k​ayabanerve:matrix.org> That'd be 'not so safe'?

<n​oname-user0:matrix.org> if only a couple nodes stake... think kraken and kucoin

<n​oname-user0:matrix.org> then yes?

<h​bs:matrix.org> But could a combo of coinbase value + number of coinbase outputs be beneficial to p2pool as it would produce more outputs when mining on p2pool?

<k​ayabanerve:matrix.org> Then it could simply be sybil'd.

<s​pirobel:kernal.eu> just read the post mortem of the incident. the tldr is that they just got lucky. It is an over complicated system that is hard to reason about. It is also besides the point. The burden of proof is on higher stake to show it actually helps with liveness. Even in this case they would have ended up with the 25 minute "time out" if the stake was lower.

<k​ayabanerve:matrix.org> Higher stake means the same percent, but a higher amount, must go offline for finality to stall

<k​ayabanerve:matrix.org> Here's offchain labs's post-mortem: medium.com/offchainlabs/post-mortem…et-finality-05-11-2023-95e271dfd8b2

<k​ayabanerve:matrix.org> They primarily blame a implementation vulnerable to effective DoSs and highlight how the network automatically recovered.

<s​pirobel:kernal.eu> yes this is the one I read. if there was more stake on the wrong implementation the mess would have been worse. So higher stake does not help

<h​bs:matrix.org> The finality layer or p2pool?

<o​frnxmr:monero.social> Its not a coinbase once it's transferred, so its not possible to value it differently. Its only worth anything to the producer

some people buy minted coins higher

so yeah, one step higher value (or with known path)

I know that they do that for btc but is it a thing for Monero?

I know some people that prefer the p2pool outputs compared to pools ones when mining, as it's provable from coinbase, which fits well on their tax records (instead of explaining who transferred it to them)

haven't heard of buying them

<s​pirobel:kernal.eu> read up on long range attacks. old miners can sell their private keys and cash out. It just effectively creates a new asset class from miner private keys.

<h​bs:matrix.org> who would buy private keys and retain the outputs? That is utter risky as you cannot have any guarantee the seller didn't keep a copy of the key!

<s​pirobel:kernal.eu> yes its a total mess. it makes the security of the system harder to reason about but you have to consider it

<a​rticmine:monero.social> Criminals, that have off chain methods of enforcement.

<h​bs:matrix.org> You mean methods like physical threat?

<a​rticmine:monero.social> I mean as an example how organized has operated for centuries

<a​rticmine:monero.social> Organized crimes

<h​bs:matrix.org> But back on the topic of using coinbase outputs for staking, besides the selling of private keys, what would the attack scenarios be? Because pools do not hold the majority of their mined coins, so they would not have a lot of coinbase outputs to dedicate to staking.

If an argument is "PoS using any output means one can buy a stake, which is bad", then one has to consider "Pools have all their coinbases, they just buy coins to pay their miners" too. The cost to both is about the same.

<s​yntheticbird:monero.social> You missed the point

<a​rticmine:monero.social> How about pools transferring ownership off chain becoming nominee holders of the keys?

<a​rticmine:monero.social> The pools have just borrowed the outputs

pools transfer IOU's

<a​rticmine:monero.social> To attack POS it is cheaper to borrow rather than buy

<h​bs:matrix.org> How do they finance buying those coins?

<a​ntilt:we2.ee> borrow + withdraw! good luck.

<a​rticmine:monero.social> No need to buy.

<a​ntilt:we2.ee> can't stake paper

<o​frnxmr:monero.social> Who in their right mind would "loan" their private keys, when they can stake them theirself

<a​rticmine:monero.social> Who holds the key and who holds the paper?

15:13:39 <m-relay> <o​frnxmr:monero.social> Who in their right mind would "loan" their private keys, when they can stake them theirself

they pay you more. same as current problem

some people only care about $/h not the underlying

<o​frnxmr:monero.social> Why woukd qubic need to pay more, if they already own the private keys

at some point they could pay enough for anyone to stop caring

<o​frnxmr:monero.social> Any mining pool already owns the privkeys

<h​bs:matrix.org> But if they stake they can't pay their participating miners

<a​ntilt:we2.ee> to reduce large holders influence in PoS, i propose quadratic voting (or other expo)

but a new malicious entity can offer up $ for all the coinbases

and rent them high up enough

<o​frnxmr:monero.social> The arg oresented is that theyd hodl the coinbases and then buy xmr (using a loan?)

not pools, not qubic, say, someone wants to implement a new attack

<h​bs:matrix.org> But by staking they risk being slashed, especially if their initial intent is to hijack the finality layer

<o​frnxmr:monero.social> i dont like finality layer. To me, it sounds like "pow is just for show now. 5gh or 50gh, finality layer is new captain"

<a​rticmine:monero.social> Qubic's attack is agnostic to POS vs POW. Qubic actually targets the pools

<h​bs:matrix.org> So that makes those coinbase outputs a bad collateral

<h​bs:matrix.org> it works because the coinbase outputs have no specific value and can be sold

<h​bs:matrix.org> Unless the two are tightly related, which the reliance on coinbase outputs instills

<a​ntilt:we2.ee> but not agnostic to slashing....

<a​rticmine:monero.social> This has been my point . It is a path to full POS

<h​bs:matrix.org> which a lot reject

<o​frnxmr:monero.social> Thats why u need to take babysteps to hijack the consensus

<s​yntheticbird:monero.social> I really get the TFL improvement. Instead of letting chaos ensue by malicious actors, let's add this so that malicious actors can just halt the network and give us the time to repair the damage. But honestly at this point just bring in the TEE

<a​rticmine:monero.social> Define TEE

<s​yntheticbird:monero.social> trusted execution environment

<h​bs:matrix.org> Not fan of the TEE party

<s​yntheticbird:monero.social> me neither

<a​rticmine:monero.social> TEE are just a form of DRM

<a​rticmine:monero.social> The Intel ME is a TEE

<s​yntheticbird:monero.social> what I mean, is TFL has an improvement but will require human manual and centralized intervention to repair the mess. probably with an hard fork. From a mediation pov, the tee solution is a way more streamlined approach. But again, i'm satisfied by it

<s​yntheticbird:monero.social> yes ArticMine, i too despise TEE, they are insecure and/or backdoored

<s​yntheticbird:monero.social> IM NOT SATISFIED BY IT

<s​yntheticbird:monero.social> NOT

most TEE deployed so far have been broken, exploited, dumped, side channel attacked. that's a reason you don't get 4K blurays on PCs anymore without specific weird old cpus, but those got blacklisted

<a​ntilt:we2.ee> The "correlation penalty" (eth2book.info/latest/part2/incentives/slashing) detects malicious colaborators... and the penalties hurt.

<a​rticmine:monero.social> The sheer complexity makes a strong case for proof of work

<a​ntilt:we2.ee> well, then TF. /s

<k​ayabanerve:matrix.org> Only somewhat? It was suggested as initially caused by multiple operators independently failing. Also, just because higher stake wouldn't have helped in this case (only better distribution), doesn't mean it wouldn't help in others spirobel:

<k​ayabanerve:matrix.org> hbs: A miner can on-purposely create many outputs to game their stake.

<h​bs:matrix.org> That's why I was thinking about a combo of value + number of outputs, not just the number of outputs.

<k​ayabanerve:matrix.org> Yes but that can still be gamed by on purposely maximizing the output count

<h​bs:matrix.org> Would probably need a custom formula to limit harm

<k​ayabanerve:matrix.org> I'd propose a scalar on the amount of outputs to weight them accordingly to risk

<k​ayabanerve:matrix.org> I'd suggest a weight variable from 0 to 0

<k​ayabanerve:matrix.org> :p

<k​ayabanerve:matrix.org> Pure quantity alone is fundamentally at the miner's selection and cannot be trusted

<s​gp_:monero.social> Could miners not include in blocks they mine transactions with huge fees to increase the value of their coinbase outputs

that'd need to be excluded, more tricky fun

<s​pirobel:kernal.eu> kayabanerve: the argument for higher stake needs to be better. it needs to be clear in which circumstance higher stake actually helps.

<s​pirobel:kernal.eu> currently we are in a clapping to scare the elephants away type of situation.

Good thinking. Also means when youpublish the block, miners now have an incentive to mine with that tx on the prev block to "steal" it :D

<k​ayabanerve:matrix.org> This effectively reverts to blocks mined then DataHoarder?

blocks mined, but only coinbase, which then gets fun when multiple outputs exist

(p2pool)