<s​yntheticbird:monero.social> it is

<s​yntheticbird:monero.social> \> haven't achieved 51%

<s​yntheticbird:monero.social> \> spread complete misinfo

<s​yntheticbird:monero.social> \> make people panic

<s​yntheticbird:monero.social> \> spread bots all over the community

<s​yntheticbird:monero.social> \> exchanges have blocked xmr over false informations

<s​yntheticbird:monero.social> the real impact of qubic is psychological

<v​enture:monero.social> i mean beyond being a marketing stunt.. that implies having another objective, like changing moneros protocol

<e​longated:matrix.org> We have mining botnets, not on social media though 😅

<u​ser2570:unredacted.org> Psyop or not, three letter agencies will happily use the strategy

<s​yntheticbird:monero.social> I think botnets are starting to show their limit unfortunately

<u​ser2570:unredacted.org> Psyop or not, three letter agencies will happily use the strategy if the mining rigs are ready

<b​oog900:monero.social> they do currently have 40% of the hashrate so I don't think we should just ignore that

<u​ser2570:unredacted.org> Does anybody else have a good understanding of blockDAG and can explain why exactly it's not more secure against reorgs?

<s​yntheticbird:monero.social> running moneroconsensus locally?

<s​yntheticbird:monero.social> oh nvm website works

<b​oog900:monero.social> miningpoolstats.stream/monero

<s​yntheticbird:monero.social> Qubic has been faking his API

if curious, they haven't done selfish mining nor attempted a reorg since last time

<s​yntheticbird:monero.social> this isn't reliable at all

<b​oog900:monero.social> have they, looked honest to me ngl

<s​yntheticbird:monero.social> yes they have, multiple time

we don't look at the api :)

<s​yntheticbird:monero.social> its all over r/monero

<s​yntheticbird:monero.social> only trust moneroconsensus.info

<b​oog900:monero.social> they turn their miners on and off so I don't think you can just count blocks

moneroconsensus.info gets the info from my code too! which gets it from pool api's ...

<o​frnxmr:monero.social> They once claimed like 14gh

<b​oog900:monero.social> ah I didn't see that 😆

<o​frnxmr:monero.social> So did supportxmr (multiple times)

<s​yntheticbird:monero.social> DataHoarder: really?

<o​frnxmr:monero.social> Again, zcash has a pool with 75%. The % means youre essentially at the mercy of the % holder, but doesnt mean instant destruction

<s​yntheticbird:monero.social> I thought it was using Ruck custom code

see footer, syntheticbird

<o​frnxmr:monero.social> Ruck is using datahoardera code, see footnote

their site is theirs fully

<s​yntheticbird:monero.social> mea culpa

I had just made that gathering tool long ago and added a few changes to have a bit more data and orphans

<s​yntheticbird:monero.social> well ig if i really wanted to be sure i should run the script with the new view key

their R backend (woah) does all the website, charting, querying monerod and building a proper meaning out of the data

<v​enture:monero.social> from 40 to >50% means they need +50% of their current hashrate, 20% net increase.

<v​enture:monero.social> I'm not sure how checkpointing, if that were implemented, doesn't prevent smaller re-orgs / squeezes all other miners out. I guess they could still squat all the blocks somehow even with max-reorg checkpoints

<s​yntheticbird:monero.social> DataHoarder: ack.

what I have seen so far that usually at least the hashrate numbers usually are pretty close recently, specially during marathons

<k​ayabanerve:matrix.org> user2570: Because it isn't magic, and if it follows PoW to decide the best chain, the best chain can be defined as a single blockchain with no relative blocks.

compared to what they pump out in their networks

<b​oog900:monero.social> the fact the have this much hashrate is shocking enough, yes they need more for 51%. with 51% they can just mine all blocks with a max reorg depth but they can't invalidate txs past a certain depth

<b​oog900:monero.social> with the eth proposal they wouldn't be able to get all blocks, only ones they mine first

<v​enture:monero.social> eth proposal doesn't involve staking / PoS?

<b​oog900:monero.social> it involves pushing all blocks to eth

<b​oog900:monero.social> and using the fist block on eth as the finalized block

<v​enture:monero.social> sounds good I guess

<b​oog900:monero.social> now you need to run an eth client to run a monero node tho

<r​avfx:xmr.mx> How much ram / storate that involve for full nodes?

<b​oog900:monero.social> full eth nodes, multiple terabytes

<v​enture:monero.social> at least rpc interface to eth and an eth wallet if you are mining?

<e​longated:matrix.org> For eth node ? PETA bytes for full node in a few years ?

<r​avfx:xmr.mx> Yeah, don't work for me.

<r​avfx:xmr.mx> I do have two wallet full node, but there not unlimited in storage.

<r​avfx:xmr.mx> One of them is free-ish, other one have a real cost I pay for myself

<b​oog900:monero.social> I don't want to be reliant on eth

<s​yntheticbird:monero.social> me neither

<o​frnxmr:xmr.mx> Yeah. Excuse my french, but fk that

<s​yntheticbird:monero.social> you should say "Au diable"

<o​frnxmr:xmr.mx> Id rather be reliant on fluffypony manually updating the dns record every 10 blocks

<r​avfx:xmr.mx> Au diable calis

<v​enture:monero.social> I'm not sure why this data availability on eth is needed.. can we not use tx_extra or something to store the latest eth block hash?

<b​oog900:monero.social> how would that prevent deep reorgs

<s​yntheticbird:monero.social> if only negative reorgs would be a thing

<s​yntheticbird:monero.social> past generated future blocks

<v​enture:monero.social> maybe I'm tired.. but lookup any competing block's stored eth block hash / block number, and go with the earliest?

<e​longated:matrix.org> I think there needs to be a new room called panic brainstorming

<s​yntheticbird:monero.social> best idea ever brought in this channel

<b​oog900:monero.social> I can mine all blocks and just reference eths genesis block?

<e​longated:matrix.org> And let’s leave researchers in this lounge

<v​enture:monero.social> confirmed :D I AM tired

<k​ayabanerve:matrix.org> boog900: It wouldn't be terabytes as we could prune them.

<b​oog900:monero.social> full eth node is what I thought was meant

<k​ayabanerve:matrix.org> But we wouldn't need a full Ethereum block.

<k​ayabanerve:matrix.org> *full Ethereum node

<b​arthman132:matrix.org> Qubic keeps flipping the on and off switch on their hashrate pool.

<o​frnxmr:xmr.mx> Thanks for the news

<o​frnxmr:xmr.mx> This is research lounge tho

<b​arthman132:matrix.org> Yes but it’s very relevant to what’s going on right now

<o​frnxmr:xmr.mx> its not

<o​frnxmr:xmr.mx> Did they flip on at 51% and start orphaning blocks?

<o​frnxmr:xmr.mx> We dont need a play-by-play for business-as-usual

<o​frnxmr:xmr.mx> Like my response, the play-by-play is just noise

<b​arthman132:matrix.org> No they keep flipping it on and off and the orphaned blocks are still very low

<o​frnxmr:xmr.mx> Ok, again, thanks for the news report. Will ping you next time i need an update. Feel free to lmk if its an emergency

<b​arthman132:matrix.org> Ok back to my hibernation

technically qbit wont attack us, they just want to prove we can be attack

id say because they are public and this is a malicious illegal things to do Lol ..

waiting for them to do direct malicious action is a loss of precious time against real attacker who wont announce themself..

gotta play one step ahead.. qbit isnt the nefarious attacker but someone bigger who gonna learn its possible

<b​arthman132:matrix.org> I think you’re right, if they really wanted to do like a double spend or something disastrous like that, they likely would have been able to pull it off already.

as weird it sound maybe we should get a peace treaty with qbit and just stop this drama nonsense somehow, we just need to fix the hole in our hull in the meantime

idk maybe they just need to heard 51% is possible with enought ressource

I dont think they gaining much money mining xmr at 230$ ..

<b​arthman132:matrix.org> What should we do?

think

I mean not you, but everyone, lol.

we got to debate a solution, either asic, hybrid, finality layer or something'

PoW concensus work very well, so well its about to be calculable where we gonna died because we couldnt secure the network enought to the demand

I think everyone can graps its a complicated time and require complicated fix

it was debated and talked about above ^

we should continues

people aren't active 24/7

thats fine.

great things take times

qbit isnt the direct threats here. and if we can help them win so we, win also some precious time to fix this

when I say help them win I mean just approve pow is not perfect and has flaw

<l​ordx3nu:matrix.org> I have so many logs to read through 😵‍💫

no concensus is perfect

or just ignore them anyway

gotta fix concensus 100%

Im a miner who has about 2x more ressource in my hardware than owning xmr .. trying hard is not enought

<b​arthman132:matrix.org> They stopped again something is definitely going on. This is like the 4th time they turned off and on in like 3 hours

that is just how they mine

they don't mine 24/7

they mine roughtly every hour, for 30 minutes

they usually are mining their own qubic stuff, then on "idle" period they mine monero

the special part has been marathons, which are listed in their own code

this is the relevant mining phase code github.com/qubic/core/blob/33dc1fae…3319f1978/src/qubic.cpp#L1909-L1989

these are the defined times they do marathons (24h mining) github.com/qubic/core/blob/main/src/public_settings.h#L105-L113

there is nothing weird going on, @barthman132:matrix.org

<b​arthman132:matrix.org> Oh ok

yeah thats just how their stupid shit work

Im not worried about qbit itself but what they showing publically that with enough ressource it easy to 51% attack, dont need milions if hardware is already available for AI ..

it feel like bitmain again but in another dimension threats

maybe make xmr pow only using rasperie pie Lol ..

or hybrid /finality.

<b​arthman132:matrix.org> I think a hybrid between a POS and a POW is a good idea. Because i believe you would need to attack both to achieve a 51% attack

if you guys are confident enought that FCMP will bring enough economic and side project to bring hashrate maybe concensus pow will be okey but its a real dillema

<b​arthman132:matrix.org> Lot of people are against it because they thing only about the negative/

think*

aka possible centralization of the node, which actually happen already on PoW using botnet..

we forked like 50 time since xmr exist I dont get how people are so against little change.

<b​arthman132:matrix.org> Yeah decentralization for pow right now is basically a sham in my opinion. You can basically buy out both POS and POW it’s just different methods of doing so

if you want to advocate hybrid it need a good talk on how it keep his decentralized advantage using PoW

basically we need to shuffle the xmr twitter or website and start doing some article toward community

(imo)

a community event talk ?

just brainstorming

<b​arthman132:matrix.org> How much do you think FCMP will help monero in terms of publicity?

<m​r_x_tcv:matrix.org> Kraken paused Monero deposits, claiming that a single pool has gained more than 50% of the network's total hashing power. Is Qubic's API lying about its hashpower? status.kraken.com/incidents/7ps8ws8hkym8

<b​arthman132:matrix.org> No not yet, but they’re getting pretty close

<k​ayabanerve:matrix.org> Kraken, IMO, is likely responding to the reporting by CoinTelegraph? earlier today (and similar) which wasn't substantiated.

the hashpower reported is roughly accurate

the percentage, is not

<k​ayabanerve:matrix.org> They note they detected, but I assume they noticed the risk of the event, not the event itself?

estimating that involves more than they do, and even if they used a rough estimate it's wildly off.

<k​ayabanerve:matrix.org> There has yet to be evidence of an actual 51%.

qubic mining monero also rises monero difficulty, so they lose the "50%" they had when they started

they can have vastly less and still achieve reorgs, of course

that's purely luck. an entity with consistently more than 50% would be able to, in the long term, continuously make their own secret chain longer

when they had less hashpower, they did 2-3 block chains as that happens regularly

they did not report blocks they lost (they got outmined, orphaned). this data has been gathered for future reference, btw

<3​21bob321:monero.social> riat.at/reaction-coindesk-research-…ged-51-attack-on-monero-pow-network

<3​21bob321:monero.social> Pwnd

they were very lucky with the specific long reorg they had, as, monero pools got very unlucky, not producing blocks for 20-30 minutes, and they also got very lucky, producing quite a short peak of blocks

quite some blocks in a short time, at peak*

<m-relay> <b​arthman132:matrix.org> How much do you think FCMP will help monero in terms of publicity? ----- I cant know the future, and I think none cant... we might need a certain way to know we it would only happen with enforcing a new concensus imo

market reaction is definitively out of our reach, while we can expect positive, to how much, and how substainable it would be ? Too many question to base the security of monero on the unknown

While it would be the best thing to happen its also seem, realitically, the worst also

fcmp could help publically, but strong enforcement on kicking out botnet and making sure real dedicated people expend on monero is somewhat assured... it would need another plan with fcmp basically

<b​arthman132:matrix.org> What can we do in terms of making it easier to buy monero? I think a big problem is that even if a average person wants monero, they simply don’t know how or the process is simply too complicated.

<b​arthman132:matrix.org> Monero being delisted by a lot of exchanges has hurt its growth in the long run unfortunately

we can both agree its an extremely complicated question

def PoS system of staking does give some mechanical incentive to hold monero and prompt up PoW part but the intrequasy of the concensus is out of my reach

we need multiple brain on this

main concern I read on different forum and disc is about centralization when it come to finality layer/hybrid, maybe start addressing a formal answer could help driving the discution toward a fix

<b​arthman132:matrix.org> I think that too. We need to have some incentive to actually hold your monero. Sure centralization is a problem, but we have in reality been dealing with centralization hashrate problems for years with the current pow. I believe supportxmr had 40 to close to 50% of the hashrate for a while before qubic

<o​frnxmr:xmr.mx> Or they are activating their NGU soft fork

<o​frnxmr:xmr.mx> No deposits = no dumping. But you can buy with withdraw 🥹

<o​frnxmr:xmr.mx> Research

<b​arthman132:matrix.org> This is why I think we should maybe address the situation from a core standpoint as many people do have many different opinion that doesnt necessarely reflect the reality of the long term problem we suffer

Yes centralization from pool and botnet standpoint may be as bad as PoS but what if someone come with factual argument that not only finality/hybrid fix this problem but ensure security,preservation and soverignty

stays*

<o​frnxmr:xmr.mx> There are numerous proposals on the table

arent those proposal still on research standpoint only ?

Ive saw the rick ones

(not saying its bad, havent seen the other one)

<o​frnxmr:xmr.mx> not necessarily. We might hage already started coding on them, but design choices and drawbacks need sorting out

definitively

<o​frnxmr:xmr.mx> Like dns checkpoints - we can enable these by default (already a feature, but disabled), and have them automatically updated to reject deep reorgs / to checkpoint the old chain

<o​frnxmr:xmr.mx> Thats a near instant bandaid that takes maybe 30mins to implement

again I dont think qbit is a direct threats as they are just trying to make themself public known using us, lets just assume they win. We need to concentrate on the solution

<o​frnxmr:xmr.mx> Instant meaning, its not a new feature, just a new release with 1 or 2 lines of code changed, and a bash script

<o​frnxmr:xmr.mx> But this isnt "good" long term (its centralized), its an emergency measure

realistically, how long it might take to code a Hybrid/finality layer ?

<o​frnxmr:xmr.mx> Probably at least 6 months?

ahh, its not even the question tho, people cant focus on a single question I feel

<o​frnxmr:xmr.mx> Hybrid i assume much less

6 month seem good enough

but if people dont want to heard shit..

how this thing work, how preserve monero privacy

on their side, PoW is only possible

<o​frnxmr:xmr.mx> if were adding pos, i still only like my proof of pow 🤷‍♂️, but i'm not smart enough to understand why others dont

Im a big miner... I wont advocate for only pow, but At the end, im here for privacy

<o​frnxmr:xmr.mx> My proof of pow would essentially only allow pos for miners..

its just a vehicule for privacy, i cant change vehicule

I can*

<o​frnxmr:xmr.mx> as a miner, what do you think about hybrid pos where you can only stake coinbases

another reasoning I hear.. hybrid is more point of failure..

(while negationing the strenghtening of security)

wdym only coinbase?

staking only on coinbase ?

<o​frnxmr:xmr.mx> Only your block rewards can be staked, is that i mean

hm

so only your gain from staking OR mining can be staked

?

<o​frnxmr:xmr.mx> Cant stake coins after you transact with them. This would exclude exchanges, whales, dnm, government etc from being able to stake

its.. interesting

but also, hurt the mechanical incentive toward economic

<o​frnxmr:xmr.mx> You can only initially stake your POW mines coins. Then once staked, you can earn extra on them. But the only way to become a staker, is to mine

problem is most of monero distribution is already done

imo

doing this is hurting the benefice of using pow

<o​frnxmr:xmr.mx> thats fine. If the coins have been spent, then the new stake is distributed "fairly"

its a great ideas for a starting coin tho

<o​frnxmr:xmr.mx> for a starting coin, i think a bad idea

maybe something like a timelimit, or mixing it with PoW ?

like you got to have hashrate

its really tweaking

hybrid is a no brainer

we really just have to decide what the best way to do it

<o​frnxmr:xmr.mx> late adopters wont be able to get any meaningful stake, because early block rewards were so large. So it would only work with a flat emission (like tail emission)

<o​frnxmr:xmr.mx> My last message is: if starting from genesis

<b​arthman132:matrix.org> Would there be a minimum amount of stake like ethereum?

from this question, why does ETH has choose 32 eth minimum to stake

could answer alot

(idk the answer)

they already put alot of ressource studying those question

ressources and time, we may not have.

if im a dummies dumb dumber and idk shit (which is probibalistically the right answer) Id say 1xmr 1 vote so as the minimum staking requirement

(while very importantly requiring the hold the pow faction which im somewhat in, 1 cpu 1 vote ) but the synergy might drive the both up

<b​arthman132:matrix.org> Makes sense we should keep the staking requirements low, because if we don’t. only like the top 5% of miners would be able to even own any stake.

indeed, keeping requirement as plausibly lower as possible

<b​arthman132:matrix.org> How can we make mining more profitable? Because if we’re going in that direction where you can only stake with mining profits. Then we still run in the problem where only whales are realistically able to mine monero in any sort of profitability.

isnt already the case with pow ?

<a​sdfqwfe:matrix.org> Doesn't this hurt fungibility? How do you distinguished between stakeable and non-stakeable XMR?

botnet malware are extremely powerfull now, it cost them nothing/.

<a​sdfqwfe:matrix.org> Also, doesn't it kinda miss the point that nation state attackers are going to have more mining equipment than you, and thus more stakeable XMR?

having both option wouldnt make it 2x more secure if not more ?

its another step ahead for someone with big ressource to wage war against us

<b​arthman132:matrix.org> I get that, but if we’re going to a hybrid system and don’t change the financial incentives to mine monero. Then the only people able to own stake are whales who just run with botnets

right, but with fcmp and with different L2s project and experimentation, wouldnt it be too crazy to think incentive is multiplated ?

sorry I think it doesnt even anwser directly your question, but certainly more opportunity small people are attract to

I state before that market expectation is our of our reach.

is out*

maybe just gonna go yolo and embrace the market Lol ..

<b​arthman132:matrix.org> True fcmp will definitely help us, but it’s not if it will help us, but how much will it help monero price in general. Monero has released updates like dandelion in 2020 and many other changes over the years. But still the price of monero has stayed around 100 to 300 dollars for like 8 years now.

dandelion havent attract more developper

fallowing sol/eth gain, its mostly from side project

if we need average market gain to preserve and secure xmr long run we need to attract more developper who will build either core or side project

Im not a phd and Im not sure to fully understand FCMP, but how can it help us bring new technology and experiment on the market

(through dev and community)

I hear about grease, which is actually awsome in the way it bring talk, but we need like 10 of those project

I believe fcmp can be a catalyst just like ringCT was in 2016, but as market has expended we need some better structure to power the change, like maybe a marketing fundation

sorry to speak so much, I hope we can find a solution for the greatest privacy project out there to survivre and also, thrive

<b​arthman132:matrix.org> I did think monero was doing well in terms of growth from 2024 to early 2025. I think we just have to find a way to make it easier to buy monero and just add new features like FCMP.

I think that too, we still doing well, the problem is not well enought for an 3-4-5ghs attacker , how can it become a problem ? Maybe its not at the end and FCMP will close economic gap we need to secure the network

not well enought security*

but we could secure that question while also releasing/working/expecting fcmp gains

through hybrid or smth

vitalik did explain his reasoning switching to pos from a distributive and security standpoint, some argument does make sense

<b​arthman132:matrix.org> I think at this point a hybrid system between pos and pow is the way forward. Sure there will be people against it, but at this point it’s a necessary change.

completely agree, and qbit make a point where AI hardware keep growing, and be accessible to a future attacker.

fcmp only would just postpone the problem I think

which people will came later ans say why we dont have fix this inherently risk

I dont think preservation of xmr should be base on future xmr market gain but should be hard coded

<b​arthman132:matrix.org> I think only able to stake mined profits is a good middle ground in terms of dealing with the problem of centralization. The hybrid system would also make us far less of a target, because they have to have 51% on both the POS and the POW to basically take over the network.

def incentivized dedication toward securing xmr blockchain, but security will growth much slower than a normal pow staking I guess

making a opportunity windows for an attacker in the early stage

<b​arthman132:matrix.org> Sure even if the pow is a little stronger than POS. It still makes it harder for a bad actor to take over the network than the current system.

true.. as no consensus is perfect anyways

as it come faster

give less time for an attacker to organize ressource

<g​ingeropolous:monero.social> so does a determined PoS attacker just stake a bunch, get kicked off, stake a bunch, get kicked off... repeat until something?

<g​ingeropolous:monero.social> oh lulz. so, general buy in proof of stake is probably being kicked around.. but monero is hard to buy.

<b​arthman132:matrix.org> The system we’re talking about is a system where you can only stake mined profits. The pos acts like a second layer of defense, so an attacker would need both 51% of pos and pow to successfully pull off the attack. This makes it far harder to take over and will discourage many attackers from even trying to attack the network in the first place. Deterrence is a big deal in terms <clipped mess

<b​arthman132:matrix.org> of if it’s even worth it to attack monero in the first place.

im donating to any ccs targeting those questions, even though im a hardcore miner.. what point to mine if , reward arent good enought AND network is still at risk ? Been +20 month reinvesting in hardware but it seem wastefull over time while people just asking me to add more hashrate wtf ? I have hard time understanding people of my own church

<g​ingeropolous:monero.social> i don't think there's enough people mining

<g​ingeropolous:monero.social> call me captain obvious

Lol it feel those people just waiting to call a rebounce to say see price up, now profitable, no ?well yes for me but what for europeans with 30 cent khw ? whats with american with 20 cent or whatever... we can hardly compete the electric price worldwide

security of monero should really be from buthan, canada and russian mainly ?

weirdly decentralized if you ask to me ..

or maybe make pow stupidly easy for shitty hardware like rasppery pie and block cpu Lol! No AI will ever use rasp

anyway, staking just seem natural thing to do after 12 year of distribution

<g​ingeropolous:monero.social> well then what about their inability to get coinbase txs to stake?if they can't mine, they won't be able to participate in the coinbase stake thing

alot of question ill ask you guys to keep talking working in 7 hours gn chad

<n​eromonero1024:monero.social> for the PoS layer, it makes sense

<a​lexanarcho:matrix.org> is there a way to check the current hashrate when running the miner with monerod as a systemd service?

<n​eromonero1024:monero.social> you'd have to use configure something like this: github.com/SChernykh/p2pool/blob/master/docs/SYSTEMD.MD

<n​eromonero1024:monero.social> it's a guide on p2pool but it also works with `monerod`... the output will be shown in the log file

<n​eromonero1024:monero.social> for simplicity, however, I later switched to using `tmux` instead

Reading all the heated discussions it bothers me this situation can easily end in btc/bch/bsv style of forks down the road because the proposed solutions carry large enough risks and require years of research and testing and sound controversial to many (PoS, using external networks for finality). This situation can also end in nothing which arguably is worse than doing something.

So why not go with the hybrid solution of mining RandomX+Sha256 for now, split at some ratio favoring RandomX, like 75%/25%. It would be a sensible compromise to satisfy majority. There are good arguments for and against ASICs. Admittedly this will be a bandaid solution until a better one is researched but it's less controversial than most others.

It's the evil (or not so evil?) we know from before, and it'll be strictly controled with only 25% hashing power. I understand it may be a question of pride for RandomX developers but man must accept reality and adapt.

The risk of fork wars is real. The risk of loss of confidence in Monero if status quo is preserved is real too. The attack vectors of multi-pow, are they really bigger than those of the other solutions?

Thank you for your attention :)

<n​eromonero1024:monero.social> quoting Luke (kayabaNerve), multi PoW is worse than single PoW because somehow, it allows easier 51% attack vector

<n​eromonero1024:monero.social> if a fork war breaks out, so be it... may the best chain win

<n​eromonero1024:monero.social> personally, I'm confident that we can find a reasonable solution

<b​arthman132:matrix.org> How does it allow a easier attack? You need to have both the pow and the pos to do a 51% attack. If you only have 51% of one, sure it would cause some disruption, but it’s not disastrous or anything close to that.

<n​eromonero1024:monero.social> this is why I was quoting Luke... I don't know the details in-depth myself

<b​arthman132:matrix.org> It doesn’t really make any sense at least in my opinion. But what do I know

<o​frnxmr:xmr.mx> "if they cant mine".. then they need to secure another chain

<o​frnxmr:xmr.mx> Monero is secured by pow

<b​arthman132:matrix.org> Is it really though? Because if you need to have both the pow and the pos it just makes it so the attacker has to pour in more resources for a successful attack. Gain vs cost is a big deal in terms of if a network is chosen to be attacked by someone.

<o​frnxmr:xmr.mx> Not dumping your pow earning _is_ a cost

<b​arthman132:matrix.org> I mean I pretty much treat the POs in the hybrid system as a last line of defense. Because sure if an attacker gets a hold of the pow it would be bad, but at least with the addition of the POs it won’t just be a disaster where a attacker could just double spend immediately after getting the 51% in the POW making monero lose most of its value.

<u​ndergroundhuman:matrix.org> The Case Against ASIC Resistance (2018)

<u​ndergroundhuman:matrix.org> griffinknight.com/p/the-case-against-asic-resistance

<b​arthman132:matrix.org> This is how I vision a hybrid system would work. I think this would greatly help incentivize people to mine in my idiot mind. imgflip.com/i/a395pp

<b​arthman132:matrix.org> Thoughts?

<e​longated:matrix.org> Nothing vicious about it, just helps miners and network.

<b​arthman132:matrix.org> It creates a positive feedback loop rewarding people actually mining and keeps them invested to mine more

<e​longated:matrix.org> So what’s vicious ? It’s their perogative, what they want to with their xmr

<e​longated:matrix.org> So what’s vicious ? It’s their prerogative, what they want to with their xmr

<b​arthman132:matrix.org> Nothing about is vicious and in my opinion it’s objectively better than the current system.

<e​longated:matrix.org> Okay, you labelled it as vicious which is a negative term

<b​arthman132:matrix.org> Oh I did? Then that’s a error then sorry about that

<b​arthman132:matrix.org> Any other thoughts?

<e​longated:matrix.org> No, I am for hybrid solution; details on % can be worked out

<b​arthman132:matrix.org> Yeah I just want to hear arguments for and against the idea is all

<e​longated:matrix.org> There is no argument, except mindset of pos being piece of shit ; except in this case it’s not

<e​longated:matrix.org> Maybe we can term it as proof of coin 🤣 and stop using word pos

<s​ellmoneronow:synod.im> +1 to boog9000 proposal of using Ethereum as the finality layer.

nice name

<s​ellmoneronow:synod.im> nioc = coin nice name

I think you got boog's idea mixed up with someone else's thought

<s​ellmoneronow:synod.im> I'm pretty sure boog9000 proposed using Ethereum as a finality layer.

<s​ellmoneronow:synod.im> Why reinvent the wheel with our own? We can rely on Ethereum and switch to our own finality layer if needed, after enough research is done.

<s​ellmoneronow:synod.im> Pruned ETH nodes can be used to prevent absurd storage requirements.

<r​ottenwheel:unredacted.org> can someone set the channel to voiced nicknames only?

<r​ottenwheel:unredacted.org> ah, that's right, all the obvious ofrn alts are on matrix.

<r​ottenwheel:unredacted.org> hey sellmoneronow, make me a sandwich!

there's IRC as well which would need changing

<s​ellmoneronow:synod.im> Rottenwheel, this is the lounge where free conversation is permitted (loosely moderated)

<s​ellmoneronow:synod.im> No one cares what you have to say anyway. Stick to X with your dumb takes.

<r​ottenwheel:unredacted.org> DataHoarder not very good at catching sarcasm or snark, are we?

in these times? no

<r​ottenwheel:unredacted.org> [@sellmoneronow:synod.im](https://matrix.to/#/@sellmoneronow:synod.im) a mirror may help your evident lack of self awareness, cunt.

<s​ellmoneronow:synod.im> Monero is moving to PoS whether you like it or not. Now sell your $2 worth of Monero and move on.

<r​ottenwheel:unredacted.org> ignored.

<s​ellmoneronow:synod.im> Next time don't falsely accuse long time members like ofrnxmr without proof.

Issue #136 has gone off the rails it seems.

<b​arthman132:matrix.org> What do you think of my idea of pos.

<b​arthman132:matrix.org> m-relay

classic alt not understanding a bridge is not the user

<b​arthman132:matrix.org> Ok what’s your idea?

<r​ottenwheel:unredacted.org> DataHoarder would be much easier to declutter the channel from this void of nobodys being loudmouths by just enforcing voiced nicknames only, but I don't think matrix has anything like that.

<s​ellmoneronow:synod.im> t​evador Why did you not implement #96 back in 2022?

<s​ellmoneronow:synod.im> Everyone forgot about MineXMR and now we pay the price.

<s​ellmoneronow:synod.im> By 'you,' I refer to the entire Monero community, and it is not entirely your fault.

<s​ellmoneronow:synod.im> t​evador Why did you not implement #98 back in 2022?

<r​ucknium:monero.social> tevador: I didn't try to follow comments on that issue because I expected it to go off the rails. I have some repo powers on `monero-research`. Want me to do anything?

<b​oog900:monero.social> It was kayaba's, I don't even support the idea :)

<s​ellmoneronow:synod.im> Sorry I was mistaken. What do you support?

<b​oog900:monero.social> Trusted nodes

<e​longated:matrix.org> Hybrid model

<s​ellmoneronow:synod.im> Hybrid model is using a finality layer.

<r​ottenwheel:unredacted.org> [@kayabanerve:matrix.org](https://matrix.to/#/@kayabanerve:matrix.org) FYI. forum.monero.space/t/about-kayabanerve-finality-layer/2101

<e​longated:matrix.org> Yes in monero and not on eth chain

<s​ellmoneronow:synod.im> Why not ETH?

<e​longated:matrix.org> Depending on 3rd party chain doesn’t work in long run

<b​arthman132:matrix.org> What about a hybrid system like decred, which you can mine and just stake the coins just by owning them?

<s​ellmoneronow:synod.im> We only need to soft-fork and can do it quickly. Using a finality layer on Monero will take years, probably as long as FCMP++.

rucknium: not sure what can be done, perhaps each proposed solution in the table should get its own discussion? The #136 would become reserved for proposals to be added to the table.

agree on last part

<s​ellmoneronow:synod.im> I agree. We can rely on a third party until the finality layer on Monero is finalized.

solution should be compared

finality layer seem to open up door to be a vassal of eth to speed up thing which im not fan

<e​longated:matrix.org> It doesn’t have to take years, it can be completed after fcmp and development can be done in parallel if we find competent devs for it

<e​longated:matrix.org> Fcmp++ is already on Dev testnet

(im not against it in any mean otherwise)

<r​ucknium:monero.social> tevador: I will propose that in #MRL

<s​ellmoneronow:synod.im> Luke said it will take at least 2 years.

<s​ellmoneronow:synod.im> There is also considerable debate surrounding this issue, with members I respect such as ArticMine expressing opposition to PoS, while boog9000 supports trusted nodes and tevador proposes his own solution. Luke advocates for the finality layer. I'm unsure how we will reach a resolution.

<e​longated:matrix.org> Everything will be discussed and debated and will reach a resolution

<s​ellmoneronow:synod.im> FCMP++ was supported by everyone in the community so even with the best conditions it took years.

<s​ellmoneronow:synod.im> I hope so.

<e​longated:matrix.org> Fcmp++ needed is entirely new, pos is already on other chains we just need to adopt it as per our needs

<e​longated:matrix.org> Fcmp++ is entirely new, pos is already on other chains we just need to adopt it as per our needs

<s​ellmoneronow:synod.im> True I didn't consider that.

<s​ellmoneronow:synod.im> ofrnxmr what idea do you like?

<s​ellmoneronow:synod.im> I need to hear as many opinions as I can.

<e​longated:matrix.org> He is ok with pos but wants only coinbase outputs to be staked, which can be problematic imho if attacker keeps mining lot of coins

<o​frnxmr:xmr.mx> immediately? Enable dns checkpoints by default, have core update the dns checkpoints anytime a deep reorg is detected

FWIW I had PoW/PoS hybrid impl in Townforge which you can start from. I don't stake the currency directly so all the privacy preserving stuff will have to be added but I've got all the difficulty stuff taken care of for example. In return, please send patches if you find bugs :P

<b​arthman132:matrix.org> What about a hybrid system like decred?

<o​frnxmr:xmr.mx> Short term? Trusted nodes for rolling 10 block checkpoint preventing >10 block reorg, and allowing dns fo be opt-in again

<s​ellmoneronow:synod.im> What is the difference between dns checkpoints and trusted nodes?

<e​longated:matrix.org> Would be great if you can work on getting it implemented on xmr 😅 we miss you..😢

<o​frnxmr:xmr.mx> dns is centralized to one entity

<s​ellmoneronow:synod.im> So Cake Wallet could become a checkpoint and how would DNS prevent a 51% attack?

<o​frnxmr:xmr.mx> No, core would run the checkpoints

<e​longated:matrix.org> Where did cake wallet come into the picture ? Checkpoints avoid deep reorgs

<s​ellmoneronow:synod.im> Someone has to run the checkpoints

<a​rticmine:monero.social> No. The proposed finality layer gives POS authority over POW

<o​frnxmr:xmr.mx> Neither prevents a true 51% attack where all future blocks can be reorged out 1 by 1

Well, maybe I can help if this is the chosen solution.

<s​ellmoneronow:synod.im> I honestly don't see any issue with PoS having authority over PoW because technically PoS would be staked XMR (higher economic value) compared to mining hashes.

<e​longated:matrix.org> With hybrid they need to 51% on both pow and pos

it sound stronger

<o​frnxmr:xmr.mx> Yeah, elon, for "either" i meant 1. Dns and 2. trusted nodes on rolling 10 block checkpoint

Oh fuck, giving cake wallet a say o what the good chain is ? wtf ?

<s​ellmoneronow:synod.im> Unless I'm being naive about PoS.

<o​frnxmr:xmr.mx> moneromooo, that wasnt proposed

<o​frnxmr:xmr.mx> Thats just a misunderstanding by ..

OK. Jut saw that in drive by. Phew.

<s​ellmoneronow:synod.im> Even if core runs the checkpoints how is that any different? This situation reminds me of Zcash's trusted setup

<e​longated:matrix.org> Temporary patch

<o​frnxmr:xmr.mx> Core running checkpoints is a temporary measure to prevent reversal of finalized/unlocked coins

<s​ellmoneronow:synod.im> Hm okay that does sound better compared to messing with the fees

<o​frnxmr:xmr.mx> Can be enabled nearly immediately, since its already implemented

<a​rticmine:monero.social> POS can be attacked with a 19th century version of fractional reserve banking.

which is still stronger than all the AI hardware laying around ready to damage us

Gonna be "fun" having core in shits to have at lesat one awake online 24/7.

<s​ellmoneronow:synod.im> So can PoW? Banks can use their money to rent out hashes or buy rigs.

<o​frnxmr:xmr.mx> Proof of pow > proof of debt

<b​arthman132:matrix.org> That basically goes for both pow and pos

<o​frnxmr:xmr.mx> Moneromooo, cant we use a script with --reorg-notify to update checkpoints?

a​rticmine: how ? AIUI, pos would rely on "physical" coins, not on what a bank claims you are entitled to.

<s​ellmoneronow:synod.im> ArticMine let's say we ignore PoS for a moment. What is the alternative?

<o​frnxmr:xmr.mx> Proof of pow

<a​rticmine:monero.social> 19th century insolvent fractional reserve banks could also start gold mining

<s​ellmoneronow:synod.im> I don't like ASIC PoW.

<o​frnxmr:xmr.mx> Yeah, asics are a non-starter for me

You could, but it might get the wrong chain. I've not followed how this qubic thing works so maybe it'd be enough.

<e​longated:matrix.org> Nothing much, than hoping some entity saves us for 51% attack using hash power

<s​ellmoneronow:synod.im> Monero was built on the premise of RandomX

<s​ellmoneronow:synod.im> This is ridiculous.

<e​longated:matrix.org> Randomx came later on

what

randomX just came later in the game

answer to bitmain

<b​arthman132:matrix.org> Randomx literally came out in 2018

<s​ellmoneronow:synod.im> Oh I didn't know that

<b​arthman132:matrix.org> Yeah you could have mined monero with asics in the past

for a year or so some asic miner did made bank

<o​frnxmr:xmr.mx> Could have, but only bitmain did

<s​ellmoneronow:synod.im> And what happened?

<e​longated:matrix.org> Only bitmain did that afaik

<o​frnxmr:xmr.mx> bitmain mined with secret asics @ 90% of the network hash -> randomx to get rid of them

<s​ellmoneronow:synod.im> So they maintained a monopoly over ASICs

<b​arthman132:matrix.org> Yes but isn’t Bitmain very popular anyway?

<e​longated:matrix.org> Never sold it to public

<a​rticmine:monero.social> There was collaboration rather than a civil war

<s​ellmoneronow:synod.im> Bitmain basically owns most of the Bitcoin pools nowadays

asic could only be a solution if a core plan is made with manufacturer but it seem stretch compare to PoS alternative like hybrid

<s​ellmoneronow:synod.im> They agreed not to 51% attack for emissions?

<e​longated:matrix.org> Discussions and panics are not civil war, bitmain didn’t collaborate

<o​frnxmr:xmr.mx> No, they wanted $ so they never admit to doing anythinf

well there it is, if manufacturer couldnt collaborate and help creating a fair environement then its a no no

<a​rticmine:monero.social> Bitmain for 90% of the hashrate yet Monero won in the end

<s​ellmoneronow:synod.im> Sounds worse than the Qubic situation

<o​frnxmr:xmr.mx> asics were _secret_

<e​longated:matrix.org> Bitmain just was left with with asics, monero moved to randomx and here we are

<o​frnxmr:xmr.mx> Yeah. Qubic is on a media blitz. bitmain was silent

Kaspa did seem to has some control over manufacturer it seems tho

key word is *some*

initial release happen to has multiple manufacturer release at same time with low to high cost machine so everyone had a 'fair share'

<b​arthman132:matrix.org> If we’re going to have a hybrid system. Would anyone be allowed to stake or just a miner? Because if it’s only going to be miners then how can we tell if the coins came from a miner in the first place?

<o​frnxmr:xmr.mx> Anyway, while i dont like pos, i can get down with popow

<a​rticmine:monero.social> POS is simply far too divisive to even come close to getting the community consensus needed to address the Qubic threat

<o​frnxmr:xmr.mx> for me: miner only

<s​ellmoneronow:synod.im> One of the proposals is that anyone can stake

<e​longated:matrix.org> Hopefully anyone can stake, pos with just mined outputs won’t be effective

I agree on the fact that community is extremely divised on the proof of stake factor..

sadly

<e​longated:matrix.org> Change is disruptive

part of this could be people arent educated enought

<o​frnxmr:xmr.mx> If were doing "anyone can stake" we might as well get rid of pow

<b​arthman132:matrix.org> Yes but how would we be able to tell anyways? Monero is anonymous, so how can we tell if a coin came from a miner or not?

<o​frnxmr:xmr.mx> Coinbase outputs are different

isnt what colored coin was ?

<s​ellmoneronow:synod.im> what can we do then? ASICs might not be the solution given their history of centralization from Bitmain. Doing nothing is not wise either, and I find it difficult to comprehend ofrnxmr's Proof of PoW idea

to be fair part of that is some entity are extremely heavy on PoW despite not being good enough to secure us lol

open discution may open up doors

<b​arthman132:matrix.org> Oh ok thanks, if we can tell then I would like a hybrid that only miners can access, because it would incentivize mining monero and make it more profitable

AMA threads

<a​rticmine:monero.social> When your house is on fire, you don't commission a book on the technical specifications of a very controversial type of fire fighting apparatus

Well, Lol. True.

<s​ellmoneronow:synod.im> Do you think tevador's proposal can work?

PoW extremism will be fast on the trigger to call core hijack if its push too much on them

<s​ellmoneronow:synod.im> Basically heavily incentivizing miners to use p2pool

gotta please the faction I guess

<s​ellmoneronow:synod.im> By making it difficult for pools to distribute cache due to bandwidth requirements so this makes miners host their own node making it easy to mine on p2pool

<a​rticmine:monero.social> I think trevadors's proposal is part of the solution and should be implemented

<b​arthman132:matrix.org> Could we just settle the problem with a vote?

<s​ellmoneronow:synod.im> Monero DAO

<b​arthman132:matrix.org> Could we just settle the problem with a vote? <<>> sure but you and I don't get a vote because we are clueless

<a​rticmine:monero.social> We can learn from Monero's current success with privacy

<o​frnxmr:xmr.mx> Proof of pow does this

<o​frnxmr:xmr.mx> 98 kills gupax, doesnt it

<b​arthman132:matrix.org> Same I’m dumb so I probably shouldn’t vote, but the debate needs to be settled one way or the other

<s​ellmoneronow:synod.im> How?

<a​rticmine:monero.social> I also believe block signing can be part of solution

<e​longated:matrix.org> How to avoid cpu farms/datacenters renting ? If we want to stick to just pow

<o​frnxmr:xmr.mx> by allowing p2pool users to earn rewards for staking

<s​ellmoneronow:synod.im> Is that similar to wownero?

<a​rticmine:monero.social> This is not the essence of the Qubic threat

FWIW, before any vote, if there's going to be one, there should be a proposal by proposal gathering of pros and cons. With people being vocal about their choices, this should go fast :) We'd need someone to maintain the table though (/me hides).

<o​frnxmr:xmr.mx> No. Wow is similar to block signing

<s​ellmoneronow:synod.im> block signing to promote solo mining

<a​rticmine:monero.social> What we have is a highly centralized merge mining

<e​longated:matrix.org> That is next threat level

<b​arthman132:matrix.org> Well how would we set up the vote in the first place?

<a​rticmine:monero.social> Block signing to force the decentralization of existing pool

<s​ellmoneronow:synod.im> Wait so we can stake XMR on p2pool?

<a​rticmine:monero.social> Including Qubic

<s​ellmoneronow:synod.im> Using your proof of PoW idea

<a​rticmine:monero.social> Forgot about POS. Too controversial and far too long to implement

<s​ellmoneronow:synod.im> Won't this need several hardforks?

<e​longated:matrix.org> Forgot or forget ? Yes, can take time to implement

<b​arthman132:matrix.org> I mean supportxmr had around 40 to 50% of the hashrate for years before qubic. It’s not like just because qubic will be gone we won’t have centralization problems without qubic.

<a​rticmine:monero.social> Just 1 HF Trevadors's proposal and block signing

<e​longated:matrix.org> Link to this block signing proposal ?

<s​ellmoneronow:synod.im> supportxmr is not publicly announcing that they will orphan blocks and double spend on the newtork

<s​ellmoneronow:synod.im> supportxmr is not publicly announcing that they will orphan blocks and double spend on the network

<a​rticmine:monero.social> The key to block signing is to decentralize the pools not trying to kill them

<s​ellmoneronow:synod.im> Qubic is a hostile threat

<a​rticmine:monero.social> Qubic can be turned around

<b​arthman132:matrix.org> If a were a malicious actor most of the time they won’t broadcast their intentions. The fact is qubic is doing this for marketing in my opinion.

<e​longated:matrix.org> Any pool can turn around and become threat

<a​rticmine:monero.social> POUW can merge mine with Monero if Monero uses block signing

<s​ellmoneronow:synod.im> CfB said that they will host a vote to decide whether or not to continue orphaning blocks. It depends on what the holders want, not what we say.

<e​longated:matrix.org> Cumfrombehind words are garbage it’s not even a decentralised coin

<a​rticmine:monero.social> A pool is not a threat if they do not have control. over the blocks

<a​rticmine:monero.social> This is the point of block signing

<a​rticmine:monero.social> So it is compatible with Qubic

<e​longated:matrix.org> Link to block signing proposal ?

<s​ellmoneronow:synod.im> Is there any proposal we can read on block signing?

<a​rticmine:monero.social> I am working on putting one together

<e​longated:matrix.org> Looking forward to it 👍

<s​ellmoneronow:synod.im> +1

<a​rticmine:monero.social> ... and I am not planning on writing a book fist

<a​rticmine:monero.social> First

<s​ellmoneronow:synod.im> No 500 XMR CCS for your proposal?

<b​arthman132:matrix.org> I like a hybrid system, because I think we should encourage mining as much as possible

<a​rticmine:monero.social> No CCS at all

<b​arthman132:matrix.org> How a hybrid system should work

<b​arthman132:matrix.org> 1: a miner mines monero

<b​arthman132:matrix.org> 2: a miner earns profit from monero

<b​arthman132:matrix.org> 3: a miner stakes his profits if he chooses to.

<b​arthman132:matrix.org> 4: the miner(staker) is rewarded for their contribution to the network

<s​pirobel:kernal.eu> I came up with a new consensus but I am not sure yet how to name it. Its different from proof of work and proof of stake. We could call it proof of General but it sounds retarded. maybe you guys have better ideas for names. The description is here: serai-dex/serai #333#issuecomment-3193653479 it is really about proving the absence of denial of service.

I think the response to qubic reaching 51% and implementing their "proposal" should be to issue emergency DNS checkpoints to orphan their chain until they start mining with everyone else.

<b​arthman132:matrix.org> Based

<o​frnxmr:xmr.mx> Anyone AGAINST setting `enforce dns checkpoints` to enabled by default in the next release?

<b​arthman132:matrix.org> If they’re against it they’re wrong

<s​ellmoneronow:synod.im> Who exactly will be running the dns checkpoints?

<o​frnxmr:xmr.mx> kool. will see if we can get pr up today. 0.18.4.2 is around the corner btw

<s​ellmoneronow:synod.im> I don't know who "core" is

<o​frnxmr:xmr.mx> Core

<s​pirobel:kernal.eu> tevador: can you read this please serai-dex/serai #333#issuecomment-3193653479 would greatly appreciate your feedback

<s​ellmoneronow:synod.im> luigi, binaryfate, etc.?

<o​frnxmr:xmr.mx> ideally a script that sets it automatically when there is a --reorg-notify on a deep reorg

<s​ellmoneronow:synod.im> Mb I thought core meant Bitcoin core 🤦‍♂️

<r​ucknium:monero.social> Probably most nodes do not have `enforce-dns-checkpointing` set, so what do you do about that? docs.getmonero.org/interacting/monerod-reference/#server

<o​frnxmr:xmr.mx> Ruck ^

<b​arthman132:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/yFZfzCuIYSfeSZNSQLQUjCXe

I waited with .2 exactly for this reason

<o​frnxmr:xmr.mx> Selsta's 5 steps ahead of us

<t​esttank:matrix.org> What a fuck?

<b​arthman132:matrix.org> Ok the dropped back down to oblivion, but how did that even happen?

<o​frnxmr:xmr.mx> @bart "113.22 GH" from fastpool. Its likely bug with their api

<b​arthman132:matrix.org> Still funny though

<r​ucknium:monero.social> What do you do about most nodes, which have not set the `--enforce-dns-checkpointing` flag? This suggestion is basically a soft fork and would require coordination with node operators that a soft fork requires.

<r​ucknium:monero.social> I'm not against it, but how will you solve that issue?

Should check it still works, it's never been used :P

<r​ucknium:monero.social> Most reachable nodes _do_ have `--enable-dns-blocklist` set. That's just to block "bad" nodes from connecting to your node.

<r​ucknium:monero.social> That ^ claim is supported by the data I collect for moneronet.info

<o​frnxmr:xmr.mx> Ruck, the idea is to enable it by default in the coming release

<r​ucknium:monero.social> If Qubic fails to achieve 51% for selfish mining or ceases its attack after anti-Qubic DNS checkpoint record start to be update, then even the nodes that have not set `--enforce-dns-checkpointing` would return to the checkpointed chain.

<r​ucknium:monero.social> A lot of people don't update

<r​ucknium:monero.social> to the most recent release

<o​frnxmr:xmr.mx> Mining pools would

15:07:42 <m-relay> <o​frnxmr:xmr.mx> Anyone AGAINST setting `enforce dns checkpoints` to enabled by default in the next release?

I'm for it, it's what exists already and it can be made opt-out still.

<r​ucknium:monero.social> You would want mining pools, exchanges, and major merchants to update.

<o​frnxmr:xmr.mx> And exchanges should also update

<o​frnxmr:xmr.mx> Btcpayserver would update if it wasnt broken :P

or, mining pools exchanges and merchants can just add that flag

instead of updating

it already exists

<r​ucknium:monero.social> If exchanges update, Qubic won't be able to sell its XMR on its attacking chain.

DataHoarder: it has never been used so unclear if it works

<r​ucknium:monero.social> I mean, its mining rewards on the attacking chain would be worthless.

so we have to be really careful to know the consequences of this but so far it appears the most realistic solution that can be implemented in a reasonable amount of time

<b​arthman132:matrix.org> Meh I’m sure the community will understand

misread, it was added after the tree hash consensus split

so it wasn't used then

<r​ucknium:monero.social> Would this be set to orphan all of Qubic's blocks or just their attacking alt chains?

<u​ntraceable:monero.social> Has anyone thought of making a statement and putting it up on the getmonero site regarding the qubic situation? A lot of false information being reported by crypto news sites at the moment.

attack only? otherwise we won't know if a block in mined by qubic

<o​frnxmr:xmr.mx> yes, and i think a post-mortem is better than helping them with their PR @untraceable. Also, we cant make foot-in-mouth statements that "dont age well"

there are ways to know, but it makes no sense to do on non-attacks

<r​ucknium:monero.social> What if they do get 51% of hashpower and orphan all other blocks?

<s​ellmoneronow:synod.im> Are you donttracemebruh

checkpoints would need to get put every so often on the tip of the decided "canonical" chain

<r​ucknium:monero.social> Set DNS checkpoints to follow a specific orphan?

if they want, they would then start orphaning again from that tip

not earlier, rinse and repeat

This gives core the ability to stop monero though. While I agree this is a lesser evil, it's not great.

<b​arthman132:matrix.org> It’s for the greater good

yeah, that comes with a big warning for MoneroPulse docs.getmonero.org/infrastructure/m…pulse/#moneropulse-as-attack-vector

if people have to update in order to get the "benefit" of this default, I wonder how much of a fraction of these people would also add --enforce-dns-checkpoints.

Maybe I'm assuming people wold read the release message...

--enforce-dns-checkpoints already exists, but it's opt-in

<r​ucknium:monero.social> The mentality of a lot of solutions is "prevent double-spend attack". The manifest adversary says that they won't do that. Plus, it's risky for them to do that because it is fraud and exchanges can punish them for that by de-listing, even in the absence of any government action. They have said they want to centralize all rewards to themselves. They have also actually mined empty b<clipped mess

<r​ucknium:monero.social> locks and suggested that they may choose to censor transactions. DNS checkpointing, without aggressive orphaning of Qubic's own blocks, do not prevent centralization of all rewards to themselves nor mining empty blocks.

the release would make it opt-out

Yes. I know I bitch enough about Firefox for making shit shit opt-out so you get screwed at least once.

<r​ucknium:monero.social> Collecting all rewards damages honest miners. Mining empty blocks damages users and merchants.

A medium term thing might be to allow more than one source of DNS checkpoints, and "vote" on them. Same as the other DNS stuff, though they'd be controlled by different volunteer parties like seed nodes are.

there are multiple DNS sources for moneropulse

and all have to agree

Before everyone goes overboard, has someone assessed the actual damage done by CFB and his goon army ?

<o​frnxmr:xmr.mx> moneromooo, i believe that is the "rolling checkpoint" proposal w/ trusted nodes cc boog900

4x

AFAIK this does not apply to the DNS checkpoints, and if it does, all the domains are one single owner.

From my pov all he achieved was to delay transactions a bit and some legitimate miners occasionally lost a few % of mining rewards.

ah, they are, indeed

Oh OK.

<o​frnxmr:xmr.mx> You would be able to specify trusted nodes, or use some defaults

expanding moneropulse list would be a starter docs.getmonero.org/infrastructure/m…ero-pulse/#moneropulse-is-dns-based

if not making it opt out at least be able to specify alternate sources

<r​ucknium:monero.social> tokr: Qubic is at about 45% of hashpower. The hashpower of supportxmr fell a lot a couple of days ago. Probably some miners turned off their rigs because the purchasing power of the block reward has reduced.

DNSSEC will still break in many dns resolvers, though...

(or get entirely stripped)

<r​ucknium:monero.social> So, Qubic has done limited disruption, but they could cause major disruption in the near future.

<s​pirobel:kernal.eu> yes. there is no immediate danger. people need to relax. The default failure case of the Byzantine Generals Problem is not theft. It is denial of service. the problem is with pow the cost for performing denial of service is not that high and it can be repeated in perpetuity (as the cpus dont disappear). if they double spend and continue to do so we can always roll back the network<clipped message>

<s​pirobel:kernal.eu> to a state before the double spend. so they cant steal. We just have to wait until we can transact again. Which will be after we made their cpus worthless by charging a cost to denial of service in xmr. I made a comment on this here: serai-dex/serai #333#issuecomment-3193653479

<b​arthman132:matrix.org> I mean they did cause 8% orphan blocks a couple days ago

<s​pirobel:kernal.eu> so what. they cant double spend.

if the checkpointing is what the short term bandaid ends up, I think a clearer list of when they'd be used would be necessary

so it's clear what users are activating via that, and when it will be done

current MoneroPulse description has that it'd be used in consensus chain splits, not orphan chains like current ones

<r​ucknium:monero.social> They could cause transactions deeper than 10 confirmations to become invalid, which would not directly benefit themselves, but would have a similar effect as a double spend against the merchants that were to be the recipients of those txs.

<o​frnxmr:xmr.mx> not just merchants, but anybody receiving a tx

<s​ellmoneronow:synod.im> Can someone post the PR link

So the conlusion is no damage beyond a bit of vandalism sofar ?

<s​ellmoneronow:synod.im> Or is that not ready?

<o​frnxmr:xmr.mx> There isnt a PR for dns checkpoint default being changed yet

<o​frnxmr:xmr.mx> Tokr, correct

<o​frnxmr:xmr.mx> Also, non-qubic miners lost $

<s​pirobel:kernal.eu> and into the future. they cant double spend as it would be illegal and we can just revert to before the double spend happened.

<s​pirobel:kernal.eu> read this though.

<s​pirobel:kernal.eu> anyways i am out

<s​pirobel:kernal.eu> cya

<r​ucknium:monero.social> Reverting a double spend isn't advisable.

<l​ordx3nu:matrix.org> I'd imagine they don't want to reorg too much because they are making profit from mining xmr

effectively the checkpoints being used for orphan chains would be peer review of incoming blocks :) > <DataHoarder> we should do peer review of every block coming in :)

<o​frnxmr:xmr.mx> The lower the xmr price, the easier it is to "own" the network (and 100% of block rewards)

they also promised rewards from monero, so their PR machine also needs its price to not be that low

<o​frnxmr:xmr.mx> if they got 30% of blocks at $300, thats not as good as 100% of blocks at $150

They'd probably just pay out of pocket regardless

<r​ucknium:monero.social> It shouldn't be too hard to test enforcing dns checkpointing on testnet, right?

<o​frnxmr:xmr.mx> I think so. It has testnet checkpoints

<o​frnxmr:xmr.mx> Or should

$ dig -t txt testpoints.moneropulse.net +dnssec

is currently empty

but it has the record

so that would work

<o​frnxmr:xmr.mx> So: 1. Create checkpoint 2. attempt to Reorg testnet below the checkpoint

Sure, legit miners lose to orphans. But they would still lose some to Q even if Q where mining legitemately.

<r​ucknium:monero.social> I will spin up a few more reachable testnet nodes, to prepare for a test.

they would. but the checkpoints would act as a line of defense/bandaid against deep reorgs they might attempty forcefully

<s​ellmoneronow:synod.im> No stop coping Mr. Solana (Ethereum is better). Qubic voters already confirmed they want to orphan blocks:

<s​ellmoneronow:synod.im> proposals.qubic.org/?status=active_proposals

if they mine as normal, although not great, it's effectively hashpower they have

<s​ellmoneronow:synod.im> github.com/qubic/proposal/blob/4c12…gic-qubic-monero-quorum-decision.md

<s​ellmoneronow:synod.im> Do you (the Computors) want to start orphaning Monero blocks of other Monero miners when the Qubic contribution to Monero network exceeds 51% of the total hashrate?

they have voted, yes. but can they do it as lucky as last time?

<s​ellmoneronow:synod.im> If they get 51% they can orphan every block

<s​ellmoneronow:synod.im> No luck needed

<b​arthman132:matrix.org> Maybe let’s just them orphan blocks and see what happens

<b​arthman132:matrix.org> /s

<s​pirobel:kernal.eu> i dont give a shit about either solana or monero. they both have inflation which I am against. If qubic wants to commit a crime its their decision. Just proves that pow is done for. The last comment I made on this topic is in this github issue. serai-dex/serai #333#issuecomment-3193653479 I am only interested to talk to people that interact with that comment.

<s​pirobel:kernal.eu> * ethereum

<l​ordx3nu:matrix.org> I have a hunch that sellmoneronow might be trying to spread fud

<s​pirobel:kernal.eu> sorry

<s​pirobel:kernal.eu> i dont give a shit about either solana or ethereum. they both have inflation which I am against. If qubic wants to commit a crime its their decision. Just proves that pow is done for. The last comment I made on this topic is in this github issue. serai-dex/serai #333#issuecomment-3193653479 I am only interested to talk to people that interact with that comment.

<s​ellmoneronow:synod.im> xenu the midwit stop talking and go back on 4chan

<s​ellmoneronow:synod.im> I'll read your proposal

<s​pirobel:kernal.eu> great thanks

<s​ellmoneronow:synod.im> Does it have anything to do with PoS? ArticMine convinced me against PoS

<s​ellmoneronow:synod.im> Before I deep dive into it

<s​pirobel:kernal.eu> honestly I dont feel scared about monero. it is amazing to see how passionate people are

<s​pirobel:kernal.eu> monero has the strongest community in all of crypto

<s​pirobel:kernal.eu> I addressed his arguments yesterday. What I commented on today is different from both pow and pos

<s​ellmoneronow:synod.im> Hm so you're essentially suggesting to use Alpenglow instead of HoneyBadgerBFT for the finality layer?

<s​pirobel:kernal.eu> no

<s​pirobel:kernal.eu> go to the last comment

<s​pirobel:kernal.eu> i see both pos and pow in a different light now

<s​pirobel:kernal.eu> we are only defending against denial of service

<s​pirobel:kernal.eu> sorry for people in irc here is the copypasta The reason you disagree is because in the case of Serai the validators are both counterparties and nodes in the network. You have to split the consensus into two parts: 1. execution of transactions and verification that no double spend happened. 2. the performance of the counterparty role that settles transactions on other networks.

<s​pirobel:kernal.eu> During the first part of the consensus, the fault we need to defend against is denial of service. The default failure case of the Byzantine Generals Problem is not theft. It is denial of service.

<s​pirobel:kernal.eu> Quote from the Byzantine Generals paper: "With unforgeable written messages, the problem is solvable for any number of

<s​pirobel:kernal.eu> generals and possible traitors."

<s​pirobel:kernal.eu> lamport.azurewebsites.net/pubs/byz.pdf

<s​pirobel:kernal.eu> We state that a participant in the first part of the consensus has to put up a Generals Bond of 1 Serai (in the case of Monero 1 XMR). If this participant to the network decides to double spend, every counterparty to the network, from the street vendor to the billion dollar exchange will observe it.

<s​pirobel:kernal.eu> As a result, the network halts as the consensus can't move to the second phase where people act as counter parties to the network.

<s​pirobel:kernal.eu> The network is restarted after the Generals Bond of the perpetrator is wiped out.

<s​pirobel:kernal.eu> Why did nobody discover this earlier? People have a hard time separating themselves from being a counterparty to the network while participating in the maintenance of its safety. But now that these two roles are separated we can clearly see that we are only defending against liveness failures not theft.

<s​pirobel:kernal.eu> It is fair to find a new name for this. Note the use of the term Generals Bond as opposed to stake.

<s​ellmoneronow:synod.im> Replying to this: serai-dex/serai #333#issuecomment-3193653479

<s​ellmoneronow:synod.im> What about Sybil attacks?

<s​ellmoneronow:synod.im> Is this not vulnerable to Sybil...

<r​ucknium:monero.social> The suggested p2pool setup instructions suggest to set `--disable-dns-checkpoints` 😅 github.com/SChernykh/p2pool?tab=readme-ov-file#gnulinux

<r​ucknium:monero.social> I suppose it doesn't matter much because all that changes from the default is that the `monerod` log doesn't give a warning if you are on a chain that the DNS checkpoints don't agree with.

yeah, feedback on that

make the dns query non-blocking

that was blocking blocks every couple of minutes and delaying broadcast of them or receiving new blocks

that equals delay, and for a pool, that means they are mining on the wrong template and wasting mining

sech1 can probably bring up any other points around that recommendation

so if made opt-out (or tbh regardless, if it's intended to be used by pools) that should get a fix

<s​pirobel:kernal.eu> it does not matter. the honest generals can always find each other and propose a chain where all the double spenders are slashed and even the ones proposing wrong chains as part of this procedure are slashed.

<s​pirobel:kernal.eu> pow and pos both solve this problem accidentally. (albeit in a very convoluted and inefficient way)

<s​pirobel:kernal.eu> that is a result of mixing the roles of counterparty to the network with participating in the network as a node

seems they started delaying block broadcasts

in the past attempts they delayed one minute

Does anyone monitor their mining jobs ?

<l​ordx3nu:matrix.org> So they are trying for reorgs?

<s​ellmoneronow:synod.im> Anything on moneroconsensus?

<s​ellmoneronow:synod.im> I don't see reorg attempts

<b​arthman132:matrix.org> Only 1 block has been orphaned in the last 24 hours

they have very low hashrate according to their rates

<b​arthman132:matrix.org> Last time I checked they had 1.7gh a second, so pretty low for their usual rate

<s​ellmoneronow:synod.im> It's extremely volatile, although the most I've seen them with is about 48% of total hash rate.

<b​arthman132:matrix.org> Yes their hashrate is all over the place, so it’s difficult to pin down

<l​ordx3nu:matrix.org> Probably ddos

<b​arthman132:matrix.org> Maybe they have lied about being ddosed before though

<s​ellmoneronow:synod.im> The source for ddosing is a random message on Telegram that CfB posted

<s​ellmoneronow:synod.im> Why not show the actual logs?

<b​arthman132:matrix.org> Because he’s lying duh

their nodes have been hit at times hard, from our observations

<b​asses:matrix.org> people still caring about cfb guy

specially at the start of the previous marathon

<b​arthman132:matrix.org> Well if that’s the case I don’t really care about their nodes, they can burn in a fire all I care

<s​ellmoneronow:synod.im> Head of the snake

<m​onerobull:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/oqQmqwdMVxdNzdVhBbhPkNNb

<m​onerobull:matrix.org> whats this

<b​arthman132:matrix.org> Are going to do the dns checkpoints?

<b​arthman132:matrix.org> Are we going to do the dns checkpoints?

<b​asses:matrix.org> well people are already fighting back this clown

<s​ellmoneronow:synod.im> Rucknium is testing right now

they changed how they report the line, monerobull

according to discord

it's based on miningpoolstats now

<m​onerobull:matrix.org> so they are trying to turn this into a "legit" pool all of a sudden?

<b​arthman132:matrix.org> Nah we shouldn’t believe anything they say

<m​onerobull:matrix.org> of course not

<b​arthman132:matrix.org> Their promises to play “nice” are worthless

<b​arthman132:matrix.org> How long does the dns checkpoints need to be tested?

<o​frnxmr:xmr.mx> first need to sync up a testnet

<o​frnxmr:xmr.mx> Then update the dns checkpoints

<o​frnxmr:xmr.mx> Then attack it

<b​arthman132:matrix.org> Yes, but is there a rough estimate?

<o​frnxmr:xmr.mx> the test, once started, should take less than an hour

<b​arthman132:matrix.org> That’s good news

<s​ellmoneronow:synod.im> Is there any way to formally prove dns checkpoints without relying on short term integration tests...

<o​frnxmr:xmr.mx> has to be coordinted with dns operator

<o​frnxmr:xmr.mx> Yes, using testnet

<r​ucknium:monero.social> `--prune-blockchain --sync-pruned-blocks` should sync a testnet node faster, right?

rucknium: no, it only reduced bandwidth

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

oh wait, without fast sync checkpoints i'm not sure if it works at all

on testnet

<o​frnxmr:xmr.mx> i though only if there are other pruned nodes, which i doubt there are

so maybe no benefit at all

<o​frnxmr:xmr.mx> Oh yeah. Selsta is righr

<o​frnxmr:xmr.mx> No checkpoints = sync-pruned has no effecr

<u​ser2570:unredacted.org> Can someone please quickly explain this dns checkpoints solution?

<r​ucknium:monero.social> I am syncing four new testnet nodes with `--testnet --enforce-dns-checkpointing --keep-alt-blocks`

<u​ser2570:unredacted.org> Can someone please quickly explain this dns checkpoints solution?

<u​ser2570:unredacted.org> Or give a link..

<o​frnxmr:xmr.mx> Fastest would be to download someone elses testnet @plowsof ipload to send.vis.ee plz lmao

<r​ucknium:monero.social> I guess I could turn off `--enforce-dns-checkpointing` on one or two of them to see what happens when it's off.

<o​frnxmr:xmr.mx> Nvm. Send.vis ia max 2.5gb. Ginger, do you have a testnet that you can share the db?

<r​ucknium:monero.social> I guess I can run `xmrconsensus` on the testnet nodes, too, to get a visual.

I'll not make a monero-pools for testnet :)

<r​ucknium:monero.social> Lol I know. I will code in a bypass for that. Should have a bypass for mainnet anyway.

<r​ucknium:monero.social> According to testnet.xmrchain.net , testnet network hashrate is 500H/s. Should not be difficult to re-org at all.

<g​ingeropolous:monero.social> you gotta ping my full name for me to get notigfications

<g​ingeropolous:monero.social> but yeah theres a DB on the xmrchain box

<g​ingeropolous:monero.social> Rucknium: , do you want it on the MRC? i can try and dload the file from xmrchaon

<r​ucknium:monero.social> Let me see what we've already got on MRC.

<g​ingeropolous:monero.social> yeah the box that had the testnet running on MRC got repurposed

<r​ucknium:monero.social> I see the stagenet blockchain in a few places, but no testnet blockchain yet.

<g​ingeropolous:monero.social> ok, the xmrchain testnet data.mdb is download to /scratch/fresh_testnetdb_20250816 . I dunno if data.mdb files are cross compatible these days... i always forget

<g​ingeropolous:monero.social> downloadING

<g​ingeropolous:monero.social> on zenith

<g​ingeropolous:monero.social> 5 mins left

<r​ucknium:monero.social> Great. I think once it downloads I can push it out to my syncing nodes.

<r​ucknium:monero.social> Thanks!

Summary of the proposed mitigation: If qubic gets to 51% and starts orphaning all other blocks (it's their plan), we tell major pools and exchanges to enable dns checkpoints and start checkpointing the honest chain until qubic stops mining their useless fork. The honest chain should eventually overtake it, after which checkpoints won't be needed anymore.

their last block they mined was delayed about one minute

That will be too late. It's not like they're readong this chat (or however you'd tell them) 24/7 ready to restart with the flag on.

And the flag presumably needs to stay on until something changes which is not "they stop trying", given they can change their mind at any moment.

So if we decide to use this flag, we have to use it early for it to worka s intended.

That flag would probably need to stay on until some permanent solution is implemented.

In the meantime, telling people to consider bumping confirmations would be a good idea too.

We can enable DNS checkpoints by default with a point release.

<k​ayabanerve:matrix.org> Why is everyone so eager to enable by default a centralized mechanism to decide the best chain??

repost of what I typed before, but > if the checkpointing is what the short term bandaid ends up, I think a clearer list of when they'd be used would be necessary > current MoneroPulse description has that it'd be used in consensus chain splits, not orphan chains like current ones

100% blocks mined by one malicious pool is not centralized?

<o​frnxmr:xmr.mx> also, anchoring to insert_chain_here is nasty

Realistically, it's the only mitigation that can be rolled out in days.

It's possible that merely publicly announcing our strategy could be enough to discourage them from attempting this.

<r​ucknium:monero.social> IMHO, securing the chain's censorship resistance through decentralized mining has temporarily failed (not for lack of trying).

<d​iego:cypherstack.com> yawn. Another day in Lounge. Let's gooooo!

<o​frnxmr:xmr.mx> @tevador, yeah, cuz theyd lose a good amount of money unless they honest mine

<b​arthman132:matrix.org> What’s the plan currently?

<r​ucknium:monero.social> gingeropolous: Uploaded `data.mdb` works. Thanks!

<o​frnxmr:xmr.mx> How can i get a copy :P

<o​frnxmr:xmr.mx> Synced faster than cuprated 💪💪

<d​iego:cypherstack.com> Switch to PoD. Proof of Diego.

<o​frnxmr:xmr.mx> Bart ^

<m​onero.arbo:matrix.org> we could roll out the randomx update and whatever else to force upgrading, maybe soon after the point release

<o​frnxmr:xmr.mx> Thats a hard fork

<o​frnxmr:xmr.mx> Also, he cant see that you replied to him

Preparing a hard fork would take months.

<m​onero.arbo:matrix.org> no kidding

<m​onero.arbo:matrix.org> and yeah okay so "soon" is relative

<o​frnxmr:xmr.mx> Randomx haed fork right now would lost hashrate from botnets but not qubic

<o​frnxmr:xmr.mx> qubic auto-updates their malware. Botnets don't

The original plan was to do a PoW change with the FCMP upgrade.

<b​arthman132:matrix.org> What are the POW changes?

<m​onero.arbo:matrix.org> all I'm saying is if we wanted to make sure people were using the version with dns checkpointing as default, we do have stuff in the wings that's been waiting

<e​longated:matrix.org> Potentially bricks x5

It's incomplete: tevador/RandomX #274

<m​onero.arbo:matrix.org> my bad I thought it's been ready for some reason

I got bogged down in some C++ hell.

<b​arthman132:matrix.org> Sounds like good stuff

<d​uggavo:matrix.org> C++ developers: #define while if

I blame templates.

<b​oog900:monero.social> have you heard of our lord and saviour: 🦀

<k​ayabanerve:matrix.org> I'd agree with it, if a pool takes over, if DNS checkpoints were only C blocks deep _and_ nodes kept a history of checkpoints as to detect if it's being ping-ponged across distinct chains tevador

<k​ayabanerve:matrix.org> But I'd also claim it proves a mandate for a decentralized finality layer

<o​frnxmr:xmr.mx> Its just an emergency response, not a long term solution

The monero journal: peer reviewing incoming blocks :)

<o​frnxmr:xmr.mx> I dont think using dns checkpoints proves anything aside from "we were unprepared"

it's a bandaid that exists in code, with a different purpose, but that can be raised ahead of time for people who want to either opt in or opt out of it again

<b​arthman132:matrix.org> It’s the best we can hope for I guess

<b​oog900:monero.social> I don't really like the idea of relying on a single entity & DNS

<g​ingeropolous:monero.social> then mine more!

it's not pretty but nothing else is a realistic countermeasure

at least i haven't seen another proposal that can be implemented in a short time frame

<b​oog900:monero.social> multiple entities over monero's p2p network, could be done pretty fast

Oh yes, sybil better than core.

If you write something better, it can be swapped in when ready.

<b​oog900:monero.social> If your sybiled you aren't getting the good blocks at all

<b​oog900:monero.social> By multiple entities I mean you have a built in list of pubkeys of approved nodes/people and you would forward their messages over the network

<b​oog900:monero.social> Not just listening yo any node

Ah, when you say p2p it's just using p2p comms, but not really p2p then ? Fair enough.

<g​ingeropolous:monero.social> re: short time frames, i see: 1. DNS 2. raise tx fees 3. decrease blocktimes., though the latter one i feel needs a bit more math and stuff thrown at it. I mean, the assumption is their main attack is going to be to selfish mine longer chains to cause massive re-orgs, right?

I don't think it'd be faster than to allow more domain soures sing the existing system though.

sources using*

<g​ingeropolous:monero.social> well nvm last one is a hardfork, i guess thats not short time frame really

<b​oog900:monero.social> Not faster but better IMO

they have orphaned two blocks

their selfish mining is active

<v​enture:monero.social> stupid question... but what's the rational to this rolling 720 block difficulty target? and not, like similar to stratum auto-diff, on the last 3?

<k​iltsonfire:matrix.org> Monero: add 1 Hz “workshares” to harden liveness & selfish-mining resistance

<k​iltsonfire:matrix.org> TL;DR

<k​iltsonfire:matrix.org> Think of PoW as an information sampling process. Right now we get ~1 sample every 120 s (one block).

<k​iltsonfire:matrix.org> Add a tiny, header-only workshare object that miners emit at ~1 per second network-wide.

<k​iltsonfire:matrix.org> Let each block claim recent shares and make chain selection use block weight = 120 + number of claimed shares (simple mode).

<k​iltsonfire:matrix.org> Result: ~120× more independent samples per 2 minutes ⇒ way tighter consensus, much harder to stall or game with <51% hashpower.

<a​ntilt:we2.ee> @kiltsonfire:matrix.org do not flood && read the backlog before posting. Thx!

<g​ingeropolous:monero.social> yah, please use pastebins for things of that size

Qubic has stopped sending mining tasks

they are stuck at block 3479274 from what I can see from pools

wasting mining

<o​frnxmr:xmr.mx> Spammed in dev too

<l​ordx3nu:matrix.org> Datahoarder: their hashrate is showing 0 now

they are having fun issues

I see their pools stuck with the same old job

seems they started again just now, but they are highly unstable

<l​ordx3nu:matrix.org> Yeah it looks like they are back up 👀

they are no longer selfish mining as of the last couple of blocks they found, there is no delay

<r​ucknium:monero.social> testnet moneroconsensus: testnetnode1.moneroconsensus.info

Too much chatter here to read and understand everything, but I honestly think the best path forward in the short and medium term is to compose a finality layer/checkpoint on one of the new US regulated stablecoin L1s. Stripe's, or Circle's or Coinbase's (if that is possible given their design). I imagine it is possible.

If everyone thinks that's bonkers, than a checkpoint/finality on some other chain is the immediate mitigation for whatever is happening currently. We can then have 6-12 months to think again.

If a random coin like Qubic can cause this much drama, then it's obviously a serious vulnerability enough to mitigate action being taken as soon as is feasibly possible.

<h​bs:matrix.org> Wouldn't that mean abandoning the decentralization and censorship resistance of Monero?

But we aren't decentralised or censorship resistant now, given we can be 51% attacked. That's an actual existential crisis

If we use a checkpoint, we can force nodes to follow an "honest" chain, and rely on the security guarantees of some other chain

<h​bs:matrix.org> Using an OFAC compliant blockchain would mean we risk the finality layer to be censored

They can't sensor a commitment.

<h​bs:matrix.org> They can decide to not mine tx from specific EOAs

As they won't be able to forward project the commitment/hash we put on their chain

I guess they could "censor" our commitment, but if anything that would be a greater ideological win

<h​bs:matrix.org> But would stop the blockchain

HBS: what do you mean EOA? (excuse my ignorance)

<h​bs:matrix.org> Addresses

<h​bs:matrix.org> EOA=Externally Owned Address

They'd have to pan all potential addresses that "might" commit

It would be absolutely bonkers

Plus, what are they banning for?

<h​bs:matrix.org> That's unfortunately something we should consider

<h​bs:matrix.org> Don't need to have a reason, OFAC just needs to add addresses to their lists

<h​bs:matrix.org> And all validators would consciously exclude them

As I see it, it's obvious stablecoins are becoming the defacto "future" of cryptocurrency. If we can leverage their security guarantees for our benefit, that's a huge win

hbs: fair enough, but I don't think it's feasible for OFAC to ban all potential addresses that attempt to write data to the stablecoins.

<h​bs:matrix.org> Ethereum is still more decentralized than those new chains. With encrypted mempools then we can consider using it.

<h​bs:matrix.org> They would just need to follow the Monero validators' addresses which would probably be easy to find

Yeah, I guess you could engineer the commitment in one of those ZK rollups

(not being technical enough to actually understand whether that is possible)

- but assuming it is

<h​bs:matrix.org> Finality is probably way longer if using rollups, would need to check hard finality of various chains

<o​frnxmr:xmr.mx> Bruh

I just think we need to be realistic about what Monero's long term goal is. I am not sure if "digital private cash for humanity" is feasible. Certainly not feasible given the current state of play. So then we, as a community, have to decide what the actual ideological goal is now.

<o​frnxmr:xmr.mx> I think you need to go away

<o​frnxmr:xmr.mx> Lmao

<o​frnxmr:xmr.mx> The mfka said to use a ua regulated stablecoin lmao

My own personal opinion is that Monero is a technology of protest, against the status quo, whatever that is.

<r​ottenwheel:unredacted.org> eh?

<r​ottenwheel:unredacted.org> Monero isn't digital private cash for humanity because...

<r​ottenwheel:unredacted.org> you'll have to elaborate on that a bit more.

at the moment, the status quo IS the US regulated stablecoins. They are out existential threat (especially when it comes to privacy/surveillance). If you can protest, by leveraging their affordances against them, you'll create a far greater movement

<r​ottenwheel:unredacted.org> 🤔

rottenwheel: Qubic, whatever the fuck that is, has created an existential threat against Monero.

Qubic literally has a website that's looks like it's pulled from an AI website generator

<r​ottenwheel:unredacted.org> and that's... worrisome? 🤔

<r​ottenwheel:unredacted.org> the attacker is running an AI-created website!

That network (Qubic) has brought "the private digital cash for humanity" almost to our knees.

<o​frnxmr:xmr.mx> midipoet smells like a pig

<r​ottenwheel:unredacted.org> ehhhhh... hard disagree there. 😂

Literally, all it took was some tokeneconomics, and some good marketing on twitter, to dent the whole reputation of the Monero project

<r​ottenwheel:unredacted.org> it reorganized few blocks, created a fuzz and everyone looked into it. not even a 51% attack or double spend. 😂

<r​ottenwheel:unredacted.org> can't imagine qtip reading you say that he almost brought us to our knees out of a few block reorgs...

Ok, then let's just sit back and do nothing?

<h​bs:matrix.org> Its greatest achievement would be to get the Monero community to vet changes which would go against our ethos, and reading multiple matrix rooms lately it seems this is exactly what is unfolding

<r​ottenwheel:unredacted.org> dent the whole "reputation of the monero project".

Obviously not a threat

<r​ottenwheel:unredacted.org> repu... what? 😂😂😂

<o​frnxmr:xmr.mx> no, lets switch to usdc

<r​ottenwheel:unredacted.org> this guy thinks monero has reputation. 🤣

Ok. You guys continue on. All is good in Monero land. Nothing to worry about here

<r​ottenwheel:unredacted.org> monero reputation: GF wallet theft, bytecoin past, prominent coin used in botnet farms and dnm...

<r​ottenwheel:unredacted.org> reputation... give me a break with this guy...

<h​bs:matrix.org> The Qubic situation is clearly a wake up call, but reactive changes are probably not what we should fall for

rottenwheel: none of those threats threaten the ability for Monero to function properly as "digital private cash for humanity".

<r​ottenwheel:unredacted.org> 😴

<r​ottenwheel:unredacted.org> you must be fun at parties.

<o​frnxmr:xmr.mx> I wouldnt even say qubic is a wake up call. Its more like getting dicks drawn on your face for falling askeep

<r​ottenwheel:unredacted.org> squeeze in dad jokes and I'd pee my pants having a conversation with you. lovely!

<o​frnxmr:xmr.mx> Aka it was to be expected

I see the conversation has turned to what ye know best

<r​ottenwheel:unredacted.org> lol

Dicks and pee

<r​ottenwheel:unredacted.org> because there's never a point with you.

Well done guys and girls

<o​frnxmr:xmr.mx> better than fed speak

Outstanding

<r​ottenwheel:unredacted.org> maybe when you learn how to interpret words, it'll change.

<r​ottenwheel:unredacted.org> until then, I'll just keep trolling you.

<r​ottenwheel:unredacted.org> see? the point was that the reputation of monero is as tainted as it gets and instead of you reading that, you claim I was going for threats to it being digital private cash.

<r​ottenwheel:unredacted.org> but what do I do arguing with someone who truthfully believes the so called status quo is a US regulated stablecoin?

<r​ottenwheel:unredacted.org> the 🧠 is there to be used, not as decoration...

If the security of the chain is questioned, Monero isn't anything to anyone. It's just another shit coin.

If you don't believe that, fine. That's your choice

<r​ottenwheel:unredacted.org> cool beans.

<r​ottenwheel:unredacted.org> ok, cool.

None of the aspects you mentioned regarding the reputation of Monero impact the security of the chain. Literally, none of them.

<r​ottenwheel:unredacted.org> Alexa, what does the word reputation have to do with security? 🤔

<r​ottenwheel:unredacted.org> A: None. Midi is just slow...

Yes. Security guarantees have absolutely no impact on reputation of a project.

You are 100% correct rotten. What we do without you

<r​ottenwheel:unredacted.org> ...which... is... what... I'm... saying?

<r​ottenwheel:unredacted.org> 🤣

<r​ottenwheel:unredacted.org> but qtip has brought monero to its knees!

<r​ottenwheel:unredacted.org> USDC and USDt the standard!

<c​haser:monero.social> sorry if it's already been asked. the blocks mined chart on moneroconsensus.info shows a surge in unknown blocks, especially on August 15, 00:00--12:00 (6-hour aggregation). concurrently, miningpoolstats.stream/monero was showing a surge in blocks from "qubic.org" and "xmr-stats.qubic.org".

<c​haser:monero.social> does anyone know how MiningPoolStats identified those blocks and how reliable that is?

<r​ucknium:monero.social> chaser: AFAIK, Qubic re-opened its mining pool API.

23:16:09 <m-relay> <c​haser:monero.social> does anyone know how MiningPoolStats identified those blocks and how reliable that is?

they opened the api

press the link

add /stats

they also have another endpoint, afaik

ah, their reporting is broken now, for found blocks at least

<c​haser:monero.social> thanks Rucknium, nioc, DataHoarder! DataHoarder, can your monero-blocks tool use that API to assign past blocks to Qubic? the blocks mined chart on Monero Consensus gives the impression that Qubic hit ~45% in some of those intervals, while it's probably much less, because there are other unknown sources.

they don't show past blocks.

we have better ways to show that. specially, they publish past view keys, so you can find out exactly which outputs they mined

for current tracking, they have noticeable patterns on chain

they have had a few long chained blocks of good luck, where rest of monero found nothing

but it's normal

<b​arthman132:matrix.org> Monero up 20 dollars today

<c​haser:monero.social> barthman132: -> #monero-markets:monero.social

<b​arthman132:matrix.org> That’s a good thing

<c​haser:monero.social> barthman132: I don't care, take non-research discussion elsewhere.

<b​arthman132:matrix.org> Ok fine im just trying to look for good news is all

the good news is no big reorgs today, they didn't have that much hashrate when doing selfish + no luck

it was hard to monitor pools as they kept going down all the time or being unstable

<c​haser:monero.social> DataHoarder: I see. was MiningPoolStats using those patterns to infer the source? or is it like they were plugged into Qubic's API at the time the block was mined, so they got the data?

<b​arthman132:matrix.org> Yea I think they were around 33% when they tried to self mine and try to orphan blocks.

no. they were plugged in when they got the data

<l​ordx3nu:matrix.org> They have another 12 hours planned. But yeah, so far nothing really happened.

<b​arthman132:matrix.org> Are they done with their marathon today?

no

it's 24h long, 12 to 12 UTC

it's written in their code

also > "[10:27 PM]Come-from-Beyond: Moving to another coin will take months of development, we are mining Monero during this"

<o​frnxmr:xmr.mx> They can move to wownero_ why they lyinf

private key stuff?

<o​frnxmr:xmr.mx> hmm, true

hoping they move away soon after saying they won just to do something is nonsense, instead of working with what we have short and long term

<o​frnxmr:xmr.mx> hear me out..

🙉

<o​frnxmr:xmr.mx> When there is a selfish mining attack, it _requires_ longest chain, and _ignores_ first seen

<o​frnxmr:xmr.mx> Why are we accepting blocks that arent seen for 10mins?

nodes could have been attacked and not received blocks, and fed a mined chain

so they suddenly find a new peer, so they sync from that one ...

<o​frnxmr:xmr.mx> There is a suggestion on monero issues (i'll link it in a sec) about requring timestamps to roughly match locally at time of arrival. My idea is similar, but is essentially, if your tip is block 101a @ 12:00, if you dont have any notice of 101b by 12:01, you dont accept it. withheld blocks would have to be released within 1 minute of your first seen block to be considered as an al<clipped message>

<o​frnxmr:xmr.mx> t. If 101b is broadcast at 12:01, and 102b becomes the longest chain at 12:03, you would start working on 102b and still be reorgable if 102a arrives before 12:04 with 103a arriving before 12:05

<o​frnxmr:xmr.mx> Essentially, longest chain is locked in after 1/2 block time. It shouldnt 1min for a block to cross the network, and defintely shouldnt be receiving 7 blocks 14 mins late

<o​frnxmr:xmr.mx> If soneone is mining while partitioned, than their blocks should be worthless, as the longest chain was decided before they thought about handing in their project late

local clock can be off by hours, if not days

we do that on p2pool, 30 minutes max offset

there were a lot of crazy computers out there

1h offsets are not unusual

<o​frnxmr:xmr.mx> my idea isnt about 12:00 as a timestamp on blocks, but about offset from received time

what about eclipse attacks?

one node gets eclipsed, feed a chain. say two blocks of matching difficulty. then it uneclipses, sees a chain of length 3, but it's too late

the rest of the network is at that

how does this peer know the rest of nodes are not attackers feeding an orphaning chain to them?

<o​frnxmr:xmr.mx> did you know monero price went up $20 today? (jkjk lol)

as for distributing checkpoints, have we though about dumping these on append-only certificate logs?

<o​frnxmr:xmr.mx> I havent thought that far. Came to my mind while at the store

not as unique, but as an autonomous addition to moneropulse

these can be queried and followed by other parties, and multiple can be setup and are redundant

<o​frnxmr:xmr.mx> i want to know hyc's thoughts on it, since i stole the idea from him and i believe ooo123

<o​frnxmr:xmr.mx> The idea of p2p shared hash of hashed ala checkpoints

heh. DHT!

<r​ucknium:monero.social> All are up: testnetnode1.moneroconsensus.info testnetnode2.moneroconsensus.info testnetnode3.moneroconsensus.info testnetnode4.moneroconsensus.info

<o​frnxmr:monero.social> i wish i could ve the one to try the selfish attack, but my testnet will take too long to sync

<r​ucknium:monero.social> Note that `testnetnode3` has one extra orphan that the other nodes don't. My local attacking chain failed, but it persists in the node that tried it.

<r​ucknium:monero.social> All of the node have `--enforce-dns-checkpointing` set. Probably we would want half of them to go without it so we could see what happens when nodes don't have it set.

<o​frnxmr:xmr.mx> I wonder what the procedure is like to set checkpoints. If it can be automated with a script

it's dns records, some of these could run their own servers that automatically have the newest data

don't need to resolve anything except TXT records, after all, and be signed properly

are we going to reinforce PoW before considering more deep consensus change ?

maybe a big reorg coming

hmm

thanks

they are a few heights ahead on the pools

reorg of 9

<r​ucknium:monero.social> 7 again?

when 3479412 was found they pushed 3479405 to 3479413

<b​oog900:monero.social> they still have more?

if any they are mining on what's considered public tip now

<b​oog900:monero.social> ok

Rucknium i know you are not a fan of machine learning but this touches on the pros/cons of some preciously suggested selfish mining defences arxiv.org/pdf/2307.00529

<r​ucknium:monero.social> plowsof: Thanks. Seems interesting, but complicated.

they even mention the word hybrid

<l​eonarth_:matrix.org> Rucknium: on your consensus tool, why are they showing as unknown - they're not hiding anymore

<l​eonarth_:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/TEJsWBZogVKdpWiOObCdaJSB

<l​eonarth_:matrix.org> is this a 7 reorg or larger? how do you calculate, based on the blocks pushed on the right side I suppose

that tool does not pool from their stats

they don't put historical data out in a queryable way

was that a 7 block or 8 block reorg

<r​ucknium:monero.social> 7 blocks. Didn't even have to use my toes to count that one. It will be a "bad thing" if we have to start using toes.

<l​eonarth_:matrix.org> lol

<l​eonarth_:matrix.org> DataHoarder: you rewrote randomx in go: git.gammaspectra.live/P2Pool/go-randomx

I did

with JIT

it's based on previous work but they abandoned it and called it impossible

<l​eonarth_:matrix.org> impossible what, to run randomx in go?

see post they had

they used bigfloat for randomx

not native float64, as golang did not expose rounding mode

you can do it via soft float64 (I also implemented that) or via locking the thread and setting rounding mode via asm

see the support matrix to see what is done on each case

<l​eonarth_:matrix.org> what were you trying to accomplish, a p2pool implementation in Go?

in most cases in interpreter mode you only need that specific case

? I have one

it's what runs observer

<l​eonarth_:matrix.org> you have a whole p2pool that we can compile in Go and use?

also used to find bugs across to c-p2pool, we recently had quite a list of issues found by my implementation on p2pool as well, and back

yes

it has a more fun api, also it has a stratum that can specify any address (that p2pool supports) and it'll generate for that

it's not heavily tested

#p2pool-log exists on matrix (see the observer links) if you want to chat more about p2pool and that

<l​eonarth_:matrix.org> fantastic

<l​eonarth_:matrix.org> what are you gonna do next, rewrite monerod in Go :D

01:51:37 <DataHoarder> it's not heavily tested < the stratum part. the rest is

don't entice me, heh. I already implemened half the signature systems to check transactions and decoys for observer

<l​eonarth_:matrix.org> any advantages over the C++ impl of p2pool?

it can be used as a library partially or fully, to interact with all the p2pool and half the monero world

<l​eonarth_:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/lbQgGwaVpWpxTaTUdITpylzw

<l​eonarth_:matrix.org> so many outside deps, isn't it a hassle to manage so many repos

dual implementation tests for consensus bugs or bad specification, as well

they are my repos

<l​eonarth_:matrix.org> could have put everything in go-p2pool/pkg/...

imported so they are not outside

each one is a fork

some specific ones like monero rpc are inside

example git.gammaspectra.live/P2Pool/go-json

I can still rebase that on the source original on github with my changes

I also stripped these external packages of silly dependencies

<l​eonarth_:matrix.org> lukechampine.com/uint128 -- so bad Go still didn't add native int128, there's a big issue open where they keep saying to just use big.Int

<l​eonarth_:matrix.org> lukechampine.com/uint128 -- so bad Go still didn't add native int128, there's a big issue open where they keep saying to just use big.Int pkg, which sucks

I think if you want to comment on this code, #p2pool-log or #p2pool-observer

it's lounge but let's not pollute as much, the interesting parts for everyone were said, now the conversation is only interesting for both of us :)

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> √ user src/go-p2pool > ./go-p2pool

<l​eonarth_:matrix.org> 2025-08-16 23:58:09.314 [P2Pool] INFO Consensus Software GoObserver v4.5 (devel) (go1.24.5)

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> works nice!

<l​eonarth_:matrix.org> will try to replace my current p2pool with this one, just curios

and you are using go-randomx! btw, we also support the RandomX one.

if you want to depend on it, use the normal RandomX / C RandomX. I think instructions are in README