<b​arthman132:matrix.org> Do you think CFB hoped for a better than a little over 20% pump?

probably because thats the level it was at before they started their xmr crusade

it dumped like 18% a day or 2 after they started

when they were getting ddos'd or whatever

<b​arthman132:matrix.org> True he probably isn’t pleased that qubic only went up around 10% this month.

<a​gencyfed:matrix.org> yo whats up guys

Qubic growth is just from the news. When I was in the discord everything else was pretty much ignored like their "decentralized AI"

"Qubic did seem to have around 20% of the Monero hashrate for a while and they may have sold some coins for USD, to rent hashrate to temporally push the hashrate up to over 30%. Qubic has significantly less than 51% of the hashrate, but perhaps it has just above the 33% theoretical threshold, where selfish mining is profitable" -- BitMEX

<b​asses:matrix.org> Decred created this: dcrdata.decred.org/attack-cost This shows how costly a serious attack is. Considering that Monero is much more expensive than Decred, this attack would be almost economic suicide for the attacker. This is just counting the code, as we still have the Monero community on our side against a potential attacker.

<b​asses:matrix.org> forwarded from Monero main room.

<g​onbatfire:monero.social> Decred has a PoS component, that's what's increasing it's attack cost, it's not lower than Monero

<g​onbatfire:monero.social> Monero security budget is simple to calculate: Emission * Price

<c​ountbleck:matrix.org> aw man, I accidentally got into monero-project/meta #1250

<c​ountbleck:matrix.org> I didn't realize the meeting wasn't over 😭

<g​iorgiameloni:matrix.org> Let's share some leaks on Cubic shall we

<s​ervers.guru:matrix.servers.guru> Did qubit stopped the attack? Everything back to normal?

<b​arthman132:matrix.org> Everything is a bit quiet

i think the monero marketing team should create a new imaginary adversary, that we can defeat in the pursuit of publicity

<b​arthman132:matrix.org> Do you think it’s possible that he isn’t even interested in a real 51% attack and that once the momentum stops with qubic he will just rug pull it.

<t​esttank:matrix.org> Their next “marathon” is planned for tomorrow

<b​arthman132:matrix.org> At what time?

<s​ervers.guru:matrix.servers.guru> Roh. Fucking losers. I thought they were done after their blogpost.

<t​esttank:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/tMuGKLXSEXgYrygcoaumfinw

<b​arthman132:matrix.org> I think Saturday is their real shot to actually achieve it. If they fail on Saturday then I’m pretty confident we should be able to hold out until Wednesday

<t​esttank:matrix.org> I plan to spend a few moneros to rent some haspower during those timeframes

<b​arthman132:matrix.org> Sounds like a plan! I have a few thousand dollars of bitcoin I could reluctantly burn to slow them down if we’re getting desperate.

<t​esttank:matrix.org> In that case you can watch xenumonero video on how to rent rigs! youtu.be/IAHVpV1LG18?si=yJ7g6zwptR_Kcqh2

<t​esttank:matrix.org> In that case you can watch this video on how to rent rigs! youtu.be/IAHVpV1LG18?si=yJ7g6zwptR_Kcqh2

<b​arthman132:matrix.org> It’s nice they’re giving us a breather on Wednesday. We just need the community to calm down and refocus

<b​arthman132:matrix.org> Alright I think I found a good rental rig for 300 dollars a day for 5mhz a second

<b​arthman132:matrix.org> I’ll do it when they do one of their little marathons. Qubic is basically idle right now

> If they fail on Saturday then I’m pretty confident we should be able to hold out until Wednesday

^ that's a good one

<b​arthman132:matrix.org> The halving will slow them down and I’m hoping that would be enough to not threaten monero for a while.

<1​7lifers:matrix.org> yes

<1​7lifers:matrix.org> quickly

<1​7lifers:matrix.org> someone go buy up all their hashrate

<1​7lifers:matrix.org> go to war

<3​21bob321:monero.social> Loose the battle, win the war

<1​7lifers:matrix.org> loose? i'd rather have tight

<r​ucknium:monero.social> kayabanerve: Any recommended introductory texts on blockchain finality layers?

<u​nt0ld:matrix.org> I'm a noob to PoS type of stuff. My impression of them is how validators have to be these datacenter grade super duper reliable servers with impeccable uptime or they get slashed. This goes against what I consider to be one of the main pillars of Monero: A computer savvy person should be able to run every aspect of Monero from home. This means not being penalized for downtime. Is <clipped message>

<u​nt0ld:matrix.org> it possible for the finality layer to provide that?

<k​ayabanerve:matrix.org> Rucknium: No, sorry.

<k​ayabanerve:matrix.org> unt0ld: With an asynchronous BFT algorithm, worse hardware would just mean slower consensus, not any penalties.

<k​ill-switch:matrix.org> Most of the work I've seen published on why PoS doesn't meet the constitutional requirements of a consensus algorithm (it's not a consensus algorithm) comes for the largest PoW project, Bitcoin. example: 21ideas.org/en/proof-of-stake-is-a-scam

<k​ill-switch:matrix.org> Most of the work I've seen published on why PoS doesn't meet the constitutional requirements of a consensus algorithm (it's not a consensus algorithm) comes from the largest PoW project, Bitcoin. example: 21ideas.org/en/proof-of-stake-is-a-scam

<k​ayabanerve:matrix.org> (the entire point of asynchronous consensus is progress despite the lack of a synchronized clock, where slow hardware would potentially be a violation of a synchronous clock)

<u​nt0ld:matrix.org> so okay. let's say i have some monero. first of all will there be a minimum stake amount? then let's say i'm already hosting a node and mining. can i also stake and host a validator, all locally at home? i will not get penalized if a sharknado happens and electricity or internet cuts out for a few hours or even days?

<k​ayabanerve:matrix.org> I'm sure we could technically layer in a penalty, especially if it's leader-based? But that'd be a design decision to discuss adding, not a fundamental property.

<u​nt0ld:matrix.org> becuase if validators have to be hosted in giga uptime servers, that kinda brings us back to specific hardware -> ban/confiscation problem

<k​ayabanerve:matrix.org> Probably. Probably. Maybe. We don't have a proposal in front of us to actually discuss. It's why I'm proposing drafting a comprehensive document (myself, with CCS funding). I'd advocate yes, yes, no

<k​ill-switch:matrix.org> It would be helpful to, for any given CCS proposal, to design the logical attack(s) in parallel to demonstrate where they fail, what sort of modified pseudo-consensus is achieved, and if and how it dilutes the distributed consensus problem that is solved by PoW

<k​ayabanerve:matrix.org> The CCS would be to design a proposal.

<k​ayabanerve:matrix.org> (documenting design questions, options, and making a recommendation)

sound like something I would donate to

thanks for the upcoming work and initiative

<g​onbat.zano:zano.org> spirobel @spirobel:kernal.eu: Are you satisfied with ETH's PoS implementation?

<g​onbat.zano:zano.org> I think that stuff like the 32ETH minimum and users needing to build perfect server infra to avoid slashing introduces awful centralization

<g​onbat.zano:zano.org> So even though I believe pure PoS is the best at increasing attack cost, these tradeoffs are not worth it and I prefer hybrid for now

<g​onbat.zano:zano.org> Hybrid implementations can avoid slashing or staking minimums

<s​pirobel:kernal.eu> gonbatfire: @gonbat.zano the main problem with eth is not how they do PoS its their consensus is not state of the art and their shipping of new features to production is too slow. I share the viewpoints expressed by Max Resnick

<s​pirobel:kernal.eu> there was this long interview with him that got a lot of attention when he "defected" to solana youtube.com/watch?v=R3gBiU-A1ic

<g​onbat.zano:zano.org> Are there any pure PoS implementations that solve long range attacks without slashing?

<g​onbat.zano:zano.org> If there are, sure, but I'm not aware of one yet, except what Zano is researching but that's very far from now

<g​onbat.zano:zano.org> And ofc, these implementations also need to work privately, not a small task

<c​haser:monero.social> Cardano's "Ouroboros" PoS algorithms don't have slashing and they claim they can remain secure within certain reasonable bounds. my problem was that the papers are incredibly dense, and I felt seen when I asked Emin Gun Sirer (arguably a notable researcher in the field, having invented the Avalanche algo) what he thinks about Oruroboros, and he told me "Prof Kiayias is a respectab<clipped messag

<c​haser:monero.social> le academic, but I don't understand the papers either"

<g​onbat.zano:zano.org> Oh yes, Ouroboros, that's what Zano is researching, as we believe in can be implemented in Cryptonote and even improve privacy, I have no clue how that works either

<g​onbat.zano:zano.org> Strictly talking about security budget, Ouroboros like consensus would be awesome for Monero, but ofc it would be the hardest one to convince the community

<g​onbat.zano:zano.org> hybrid is waaay easier to "swallow"

<t​orir:matrix.org> arxiv.org/abs/2405.09173v2 is an interested paper. From the abstract:

<t​orir:matrix.org> > In the synchronous and dynamically available setting, with an adversary that controls at least one-half of the overall resources, no protocol can be EAAC. [expensive to attack in the absence of collapse]

<t​orir:matrix.org> I think the ultimate requirement is to make it impossible for an attacker to control a large percentage of some resource, regardless of whether that is hashrate, stake, or something else.

<t​orir:matrix.org> I'm curious about the viability of a hybrid PoW/Proof of Space model, personally, but in practice I don't think Proof of Space is easy to mine since you need to dedicate a multiterabyte hard drive for mining.

<s​yntheticbird:monero.social> multiterabyte hard drives are much cheaper to buy than EPYC cpus while being significantly more expensive to rent

<s​yntheticbird:monero.social> 16TB+ for around 400€, last gen EPYC is 2k+

<t​orir:matrix.org> General consensus seems to be that people don't like proof of stake because it favors the already wealthy. I think we should consider other scarce resources besides staked Monero and Proof of Work to secure the network.

<s​pirobel:kernal.eu> what if there was no inflation?

<s​pirobel:kernal.eu> what would be a better scarce resource than xmr without inflation?

<e​longated:matrix.org> There is no chance no inflation will be agreed upon, you can let it go.

<s​pirobel:kernal.eu> why? i thought we are into crypto because we dont like inflation

I think you're saying no inflation from pos blocks only, right ? Pow blocks are left as is ?

<e​longated:matrix.org> Tail emission is to secure the chain

<e​longated:matrix.org> He is asking for only pos with no inflation

<t​orir:matrix.org> If only PoW is used for the current emission rate and PoS has no reward, it still doesn't stop a wealthy entity from simply buying stake to attack the network. (Yes, in theory by attacking the network, even if the stake is not slashed, the price drop will punish the attacker, but that risk doesn't matter to a government)

Ah. So yes, no chance :D

<s​pirobel:kernal.eu> elongated: tail emission is only necessary because miners have to give money to their local power plant and amd for the cpus

<b​oog900:monero.social> xcancel.com/c___f___b/status/1955718215146914137#m

<b​oog900:monero.social> just trust us guys

<e​longated:matrix.org> I am certain that majority are against going only pos.

<t​orir:matrix.org> I personally think if there aren't enough miners to keep the network secure, that increasing tail emission to increase the security budget of the network is a good idea. However... the emission rate is an agreed-upon thing from the start of Monero and changing the parameters of the currency this far into it is a big no-no.

<s​pirobel:kernal.eu> so why not just use zano then ? ( I dont own any zano and I dont think hybrid solutions are a good idea)

<e​longated:matrix.org> Zano is a premied shitcoin, best not to look up to them

<e​longated:matrix.org> Zano is a premined shitcoin, best not to look up to them

<s​pirobel:kernal.eu> a wealthy entity can rent cpus for a few hundred k a month. much more dangerous than having to spend hundreds of millions worth of xmr to attack proof of stake. pos is orders of magnitude more effective and you can get rid of inflation

<e​ndor00:matrix.org> That whole idea of "this is how it was done from the start, we're not changing that" is the reason why btc is the mess that it is, from a technical standpoint

<e​longated:matrix.org> If btc changes it, it goes to zero

<e​longated:matrix.org> Same for xmr

<e​longated:matrix.org> You can’t change rules of game just like that

<s​pirobel:kernal.eu> eth is a counterpoint though

<n​oname-user0:matrix.org> no, a lot of coins have made the change

<e​ndor00:matrix.org> Not only is that false, but it btc *doesn't* change then it *will* go to zero in 20-30 years because mining will become unsustainable

<e​longated:matrix.org> Xmr is tiny compared to eth, even eth faced backlash when it went pos

<s​pirobel:kernal.eu> but the backslash was overcome.

<s​pirobel:kernal.eu> and they didnt do any of this half half hybrid thing

<e​longated:matrix.org> How many other coins did such a change and survived?

<s​pirobel:kernal.eu> we should think about this from the end: what is the end state of private p2p cash and do what ever it takes to get there

<w​eaverethan:matrix.org> if monero goes POS i'm out. that's proof of shitcoin

<n​oname-user0:matrix.org> in a hybrid pow pos consensus, you can just look at the pos blocks as a decentralized network checkpoint

<g​onbat.zano:zano.org> Same with hybrid?

<e​ndor00:matrix.org> The idea of adjusting Monero's emission rate has been brought up before (by myself included). The problem is that the emission rate is only half of the equation of the mining incentive, and the coin price is the other half. It's hard (maybe even impossible?) to predict how the market would react to such a change, and thus you could end up hurting the overall incentive

<s​pirobel:kernal.eu> how many miners do you run?

<v​enture:monero.social> btc supply *will change it in the next couple year. They will freeze / retire pubkey-only outputs, like satoshis to mitigate against quantum.

<w​eaverethan:matrix.org> they could be acceptable

<n​oname-user0:matrix.org> for those who are saying that pos = shitcoin... they need to grow up

<v​enture:monero.social> btc supply \*will change it in the next couple of years. They will freeze / retire pubkey-only outputs, like satoshis to mitigate against quantum.

<v​enture:monero.social> btc supply \*will change in the next couple of years. They will freeze / retire pubkey-only outputs, like satoshis to mitigate against quantum.

<s​pirobel:kernal.eu> we make a law: everyone who says pow only has to spend 10k a month on hashrate

<w​eaverethan:matrix.org> 3

<t​orir:matrix.org> I have no special loyalty to Monero. I will leave for a better privacy coin. Every privacy coin makes tradeoffs, Monero isn't perfect, but it is currently the best one.

<t​orir:matrix.org> If Monero moves to a hybrid PoW/PoS model I will probably continue using it, personally.

<e​ndor00:matrix.org> PoS means that the only way to become part of the system is for someone else to sell you some of their money - i.e. some of their power. This goes against their own incentive. Therefore, those who have money have the power, and they will stay in power unless they decide to sell it all away

<n​oname-user0:matrix.org> oh wait... this is interesting. we can implement a pos finality layer with no rewards but it doesnt construct blocks, instead it provides checkpoints which are already built into monero so ppl just need to --enforce-dns-checkpoints on their nodes to accept the changes

<n​oname-user0:matrix.org> means not even a soft fork really

<e​ndor00:matrix.org> Better law: anyone who proposes a different mining/staking system has to actually understand the technical implications of both the current and the proposed system

<s​pirobel:kernal.eu> now people have to sell their xmr or buy less to buy cpus and eletricity.

<n​oname-user0:matrix.org> and ifffff its going well, we can consider pos rewards based on the same consensus latee

<s​pirobel:kernal.eu> you could sell your miners and buy more xmr

<s​pirobel:kernal.eu> and there would be no inflation

<t​orir:matrix.org> venture: There was a paper posted around here showing that many of those old outputs could still be spent safely post-quantum. It would require consensus changes for Bitcoin.

<v​enture:monero.social> hm, if you get it, I would be curious to read about that. Not sure how that would work right now

<g​onbat.zano:zano.org> Monero needs to increase it's security budget by at least 10x, or it will continue to be in reach of even small states

<g​onbat.zano:zano.org> Doing nothing / minor changes to current PoW just won't cut it

<s​pirobel:kernal.eu> there has to be a change sooner or later. pow is just nostalgia

<g​onbat.zano:zano.org> 100k / month to attack the network really is nothing, I've saying this since 2023

<s​pirobel:kernal.eu> subsidy for power companies + amd

<e​ndor00:matrix.org> Go ahead and pump up that coin price! I'll be waiting to fire up my miners ;)

<e​ndor00:matrix.org> Counterpoint: anything other than pow os just hype

<g​onbat.zano:zano.org> The idea has always been for price to pump before govs wake up, worked out for BTC, I think it's naive for newer coins

<e​ndor00:matrix.org> *is

<w​eaverethan:matrix.org> pow/pos hybrid then hmmm

<t​orir:matrix.org> Found it. "Post-Quantum Readiness in EdDSA Chains" eprint.iacr.org/2025/1368.pdf

<t​orir:matrix.org> Before anyone asks, no that will not work for Monero. That was already asked here.

<f​iatmoneysucks:matrix.org> Monero isn't perfect; improvements need to be made, and some of them require help from other cryptocurrencies like Zano. Perhaps we could bring in a Decred developer who helped create Decred's hybrid PoW+PoS system. All help is welcome. Monero even has a better PoS opportunity, as there aren't any large companies holding XMR (e.g., large CEXs).

<v​enture:monero.social> Thanks!

<g​onbat.zano:zano.org> Yes! There's plenty of valuable research done by "less pure" projects, crypto as a whole has advanced tremendously just thanks to ETH

<t​orir:matrix.org> Seems I may have mis-skimmed the paper, it might not actually apply to Bitcoin after all.... um, do your own research!

<t​orir:matrix.org> It might apply in cases where the private key was derived using certain derivation schemes, which may or may not be the case for many Bitcoin addresses.

<v​enture:monero.social> yeah it does seem some sort of migration / interaction is needed.

increasing fees disincentivizes p2pool, especially smaller miners, because it increases the cost of consolidating the many outputs you get

people always say that p2pool has no fees but you incur a cost using the many small outputs

there's a task opened for optimizing consolidations of miner outputs

also for preventing these being used in normal transaction decoys

wonderful \o/

I think you mentioned this b4 :)

it's two different tasks in github

<o​frnxmr:xmr.mx> Datahoarder, mrl 108 and 109 are basically dead

sad to hear :( maybe can be revisited if there's any changes to be done in monero itself that requires an upgrade

<o​frnxmr:xmr.mx> One of them was pretty much finished but closed in favor of fcmp

<o​frnxmr:xmr.mx> And the proposed fcmp fees (cc articmine) are going to make large input txs much more expensive

<o​frnxmr:xmr.mx> Im not smart enough to understand why 128in txs need to pay more than 8in. 128in is smaller in size per-input than an in, and linear for verification. So, 8in is the worse tx type imo

<o​frnxmr:xmr.mx> It takes less time to produce 8in, uses more space, and same verification. So 16x 8in txs (128 inputs total) uses much more space, and takes same amount of time to verify, compared to a 128in tx

well, that's going to be subpar for all the mining outputs, given that the push is for mining onto p2pool or solo

<o​frnxmr:xmr.mx> Anyway. Im trying to get my blocks up to 20+mb (fcmp) and, its much easier to do with 1in txs

<o​frnxmr:xmr.mx> (since those are the largest per-input)

<o​frnxmr:xmr.mx> 128input are more economical. If, example, it cost 0.00002xmr per input, then a 128in tx would cost more per byte than an 1in

<o​frnxmr:xmr.mx> If you charged per-byte, then 128in cosrs _less_ per input. I think we should bill txs as "per-input" if we want to charge more for 128in w/o unfairly discriminating against them

<t​esttank:matrix.org> A day, but the point still stands

<e​longated:matrix.org> Are we even allowing 128in ? Didn’t they say max 8in/out

hasn't been decided yet

there have been optimizations and soon we will get better numbers from testnet

<e​longated:matrix.org> Okay, someone in MRL did say that today too

<t​orir:matrix.org> Max 8in has definitely been suggested and considered, but from the tone of recent meetings 128in is still on the table. No one has made a final decision either way.

<e​longated:matrix.org> What is the tx size for 128in/8out ?

<o​frnxmr:xmr.mx> ~115kb iirc

<o​frnxmr:xmr.mx> Let me see if i can find one

<o​frnxmr:xmr.mx> Ive decided. 8 is ux destroying :D

<o​frnxmr:xmr.mx> Stressnet will have to use 128in, else tou end up with crippled wallets

<o​frnxmr:xmr.mx> The pr is open and my testnet is using it. It uses powers of 2 for tx inouts (2/4/8/16/32/64/128). I havent had any issues with it. Using the 8-max, often was unable to send txs. Like "i have 0.25xmr inputs and need to send 3xmr" rip

<o​frnxmr:xmr.mx> With 128in, its np. I cant say i understand why 8 was even considered. Verification isnt much slower than ringct afaict.

<o​frnxmr:xmr.mx> I verify abt 300kb/second on ringct, and abour 250kb/sec with fcmp

<e​longated:matrix.org> Probably bcoz bulk of txs don’t use it, but we shouldn’t limit it bcoz exchanges will need higher in

<t​orir:matrix.org> 8in is supposed to also have privacy benefits by not allowing a small number of transactions with a huge number of inputs to stand out.

<t​orir:matrix.org> In practice, it seems to me that consolidating transactions when your wallet gets hundreds and hundreds is very challenging to do with 8in.

<e​longated:matrix.org> This, imagine being a vendor accepting 0.1xmr and need to pay 100xmr to someone 😅

<e​longated:matrix.org> Would be fun to sync on mobile wallets

<b​arthman132:matrix.org> Should we move to POS at this point?

<o​frnxmr:xmr.mx> sending 30xmr with 0.25xmr inputs needs 128

<o​frnxmr:xmr.mx> Even something like ccs. Imagine having to do payouts if the donations are small smallish :/

<t​orir:matrix.org> ofrnxmr: You can do it with 8in by consolidating all of your inputs in multiple transactions. If you had 128 inputs, you would spend 8 inputs to 1 output 15 times each in its own transaction. Then wait for the 10 block lock, and consolidate your 15 inputs into two outputs with two more transactions. After another 10 block wait, you could finally make your final payment.

<o​frnxmr:xmr.mx> yeah, lol, no

<t​orir:matrix.org> Yes, 128in is very helpful indeed to avoid that whole process.

<o​frnxmr:xmr.mx> I have script sending txs and was a PITA to even try to automate the wallet maintenance

<o​frnxmr:xmr.mx> Outputs below N sixe -> sweep them to myself -> send 85 txs -> no

<o​frnxmr:xmr.mx> Wait 10 blocks and adjust the size and do it again. Rip. Such a waste of chain space

<t​orir:matrix.org> I can't imagine every wallet developer being forced to develop the UX for users sweeping transactions that way, especially with that 10 block lock getting in the way.

<o​frnxmr:xmr.mx> 128inputs uses less space on chain than all of this maintenanxe too

<o​frnxmr:xmr.mx> Much less, espefially if i have to do multiple rounds

<m​onero.arbo:matrix.org> 8 inputs is totally unworkable

<o​frnxmr:xmr.mx> Problem i see now, is that fees are proposed to discriminate against large input txs

<o​frnxmr:xmr.mx> like, 50x or 200x fees ...

<m​onero.arbo:matrix.org> I mean if I'm reading the chart right, 128 inputs takes over 3 seconds to verify. that is also unworkable

<o​frnxmr:xmr.mx> it takes same amount if time for 16*8in

<m​onero.arbo:matrix.org> even 2 in, 2 out being 54 ms limits the entire chain to, what, 20 tps at best? and that's on a damn ryzen 7950

<o​frnxmr:xmr.mx> Which, if it saves me 200x fees, i'll be forced to spam the chain with _larger_ txs