<a​ndrewjackson:matrix.org> using gupaxx with local node, I just need to work out how to "point", I'm not to good on that, I will work it out later, shouldn't be to hard, I will set up another old laptop with a full node and an open port, it's closed at the moment I'm using Mulllvad

<e​ddie:oblak.be> this section in your config.json for xmrrig should look something like this

<e​ddie:oblak.be> ```

<e​ddie:oblak.be> "pools": [

<e​ddie:oblak.be> {

<e​ddie:oblak.be> "algo": "rx/0",

<e​ddie:oblak.be> "coin": "Monero",

<e​ddie:oblak.be> "url": "192.168.1.4:3333",

<e​ddie:oblak.be> ```

<e​ddie:oblak.be> when p2pool node is configured something like

<e​ddie:oblak.be> ```

<e​ddie:oblak.be> p2pool --stratum 192.168.1.4:3333 ...

<e​ddie:oblak.be> if p2pool and monerod run on the same host it could be smth like

<e​ddie:oblak.be> ```

<e​ddie:oblak.be> p2pool --stratum 192.168.1.4:3333 --host 127.0.0.1 --zmq-port 18038 --rpc-port 18081 ...

<e​ddie:oblak.be> ```

<e​ddie:oblak.be> also depending on your monerod config

<e​ddie:oblak.be> if p2pool and monerod run on the same host it could be smth like

<e​ddie:oblak.be> ```

<e​ddie:oblak.be> p2pool --stratum 192.168.1.4:3333 --host 127.0.0.1 --zmq-port 18083 --rpc-port 18081 ...

<e​ddie:oblak.be> ```

<e​ddie:oblak.be> also depending on your monerod config

<a​ndrewjackson:matrix.org> OK thanks, i will have go at it later, will keep the hash going until Pubic calms down 😅

<a​ndrewjackson:matrix.org> Bitcoin is getting dumped due to the continuing attack on Monero 😂

<r​avfx:xmr.mx> All youtubers are high on BTC pump so it have to dump, the question is how much

<r​avfx:xmr.mx> (they in fact try to shill it so people fill them)

<r​avfx:xmr.mx> as always lol

<h​ardenedsteel:monero.social> allegedly because of Gate exchange didn't increase the confirmations limit

<g​ogo2464:matrix.org> what is better between retoswap and 67w4f46nfrfigohl4ypgpo7cjnftl57rorha3zmn4xkll5jvmi6mi4qd.onion please?

<h​ardenedsteel:monero.social> monerica isn't exchange

Revuo Monero Issue 246: August 17 - 26, 2025. revuo-xmr.com/weekly/issue-246

<e​ddie:oblak.be> qubic is now mining less than 50/100 blocks, it's still finding a lot of blocks .. I discovered sporestack yesterday (spore64i5sofqlfz5gq2ju4msgzojjwifls7rok2cti624zyq3fcelad.onion) and used it to rent some dedi to at leats add a few KH's to the network.

<e​ddie:oblak.be> Which made me wonder, how can MRR be so "cheap" for megahash size of mining rigs in comparison to renting a normal dedicated server

<e​longated:matrix.org> 🤖

<a​lexandre:uii.pt> Perhaps it's cheating? Not sure how those rentals work, do you just put your address? Or does it give access to run xmrig as you please?

<e​ddie:oblak.be> It doesn't give access to the machines

<e​ddie:oblak.be> So it could be cheating , not sure

<a​lexandre:uii.pt> Hmm, in which case, unless you run it for longer and do statistics you can just be "unlucky"

<l​ightobserver:monero.social> Does anyone know if there are wallets that are supporting LWS ? I know mymonero and edge, but I was hoping for some others (and I don’t use them)

<e​longated:matrix.org> Cake or monerujo should add lws support

<e​longated:matrix.org> Diego Salazar: maybe stack can do it?

MRR gives a score indicating roughly how accurate the stated HR is which is based on feedback, now they just need to add a score on how accurate that feedback is

as to MRR being cheaper than dedicated servers, they just need to make more money renting their rigs than mining with them

<s​hortwavesurfer2009:monero.social> I'm not sure of any others, but the Monero.com wallet, while doesn't have LWS, does support background synchronization, which keeps you pretty close to up to date with the blockchain.

<s​hortwavesurfer2009:monero.social> So while it's not a light wallet, you also don't end up opening it and needing to synchronize 15,000 blocks.

<l​ightobserver:monero.social> It would be awesome if they add LWS through onion with username and password. I would love to donate if that is the case.

<l​ightobserver:monero.social> I know, it ok. But sometime annoying bc so slow. Do you know that the dedicated monero node has inbuild LWS service. Pretty handy

<e​longated:matrix.org> How easy is it to install lws on windows or macOS ?

<l​uks0011:matrix.org> hi guys, need to swap >500k usdt for xmr, need help where to do it? any particular dex or swap that wont lock funds/

<m​onerobull:matrix.org> dmed you

<m​onerobull:matrix.org> in the future there will be serai, right now there is retoswap.com but the liquidity is not there yet

<s​hortwavesurfer2009:monero.social> The adversary managed to get 32% of the last 1,000 Monero blocks.

<s​hortwavesurfer2009:monero.social> So while they still don't have 51%, they are still able to cause problems in very short bursts.

<t​allhatdoug:matrix.org> howdy

<s​yntheticbird:monero.social> yo happy to see you here

<t​allhatdoug:matrix.org> I heard this is where the cool kids are

<e​ddie:oblak.be> And it's just annoying overall

<e​ddie:oblak.be> Although I see a lot of people joining in with all what they have to add extra hashpower here and there, which is heartwarming, it seems that the community isn't able to mobilize truly big numbers of hashpower to put qubic in its place.

<e​ddie:oblak.be> I am not blaming anyone, I am as guilty of it as the next man 😅

<e​ddie:oblak.be> Then again it's hard to measure how much hashpower was added in defense of the network

15:09:15 <m-relay> <s​hortwavesurfer2009:monero.social> So while they still don't have 51%, they are still able to cause problems in very short bursts.

they do have the ability to get over 51%, but haven't done so

they have done it over bursts they can sustain

but they only bring these up to make long reorgs

<d​iego:cypherstack.com> ;)

<e​ddie:oblak.be> It seems last 6 months overall hashrate increased a little over 1GH/s

<s​yntheticbird:monero.social> hashrate was at its peak when monero increased in price

<s​yntheticbird:monero.social> it remember seeing almost 6GH/s when xmr was at almost 320€

yes

when xmr price up

hashrate up

<e​ddie:oblak.be> Yeah peak seems to have been around may

<s​yntheticbird:monero.social> qubic started the attack when monero fell in price

<e​ddie:oblak.be> last 3 motnhs relatively flat

<a​lexandre:uii.pt> hmm, why did it fall then? if not due to the attack

some attacker sold tons of XMR iirc

scammer i think

<t​allhatdoug:matrix.org> if you wanna support monero from qubic & show some love... just mine at my pool: tallhatdoug.com, that'd be awesome

<t​allhatdoug:matrix.org> p2pool's another solid way to support Monero!

<e​ddie:oblak.be> yeah it was that story about the scammer dude in UK that tried to launder 300 million BTC through xmr

why does kuno need a X contact

"oh if you don't put in your twitter, then it won't be verified right away blah blah blah"

<e​ddie:oblak.be> Pretty frontend, good job

i don't get why kuno needs a twitter contact if you want it to be more "convenient"

<a​lexandre:uii.pt> from what i understood, a pool has no benefit when compared to p2pool, if so, why doesn't everyone just jump to p2pool?

<e​ddie:oblak.be> a centralized pool has a much simpler setup

<a​lexandre:uii.pt> but for the miner it's the same, no?

<e​ddie:oblak.be> is't just running xmrig binary , and that's it

you have to host p2pool somewhere

<e​ddie:oblak.be> no, if you do p2pool you need to figure out p2pool :p

<e​ddie:oblak.be> it's not that hard, but it's something extra

i don't host it on the same machine as xmrig, because of RAM requirements

<a​lexandre:uii.pt> you can use someone else node, tho it's not ideal

<e​ddie:oblak.be> also some mining pools offer more algo's and other nonsense :p

using some other monero node with p2pool is like

<e​ddie:oblak.be> some have modified xmrig binaries for alledgedly better returns

better than a centralized pool

eddie: give source code >:(

<e​ddie:oblak.be> als, with tari pools do merge mining for you so you don't have to bother with that too

<a​lexandre:uii.pt> could p2pool be attacked with a "51% attack"? (and thus indirectly attacking monero)

p2pool can do merge mining

<a​lexandre:uii.pt> or in the unlikely scenario of having 100% of blocks by p2pool it would be fine?

<s​hortwavesurfer2009:monero.social> To the best of my understanding, even if P2 pool had 100% of blocks, it would be fine.

<s​hortwavesurfer2009:monero.social> If true, that would actually be a very good thing, because then there would be no way anybody could 51% attack the network.

<e​ddie:oblak.be> what is actually the api miningpoolstats queries to get pool data?

<t​allhatdoug:matrix.org> yes

the API that asks the pool for its hashrate

that can be easily faked

<e​ddie:oblak.be> can you give an example?

<a​lexandre:uii.pt> i was just wondering if p2pool could be attacked and thus monero could be attacked, imagine someone manages to control majority of p2pool hashrate, wouldn't that mean they can "fabricate" blocks?

<s​hortwavesurfer2009:monero.social> Hmmmmm. I am not sure

<t​allhatdoug:matrix.org> dude, let me break it down for ya. if some big time miner was trying to pull a fast one, they'd have to command 51%+ of the overall hash rate first. but even then, their power wouldn't grow by joining p2pool since everyone's still mining to their own node or remote node. this means that p2pool can only maintain the existing distribution of hashrate, not add to centralization. if s<clipped message>

<t​allhatdoug:matrix.org> omeone controls majority of p2pool's hashrate, they can still attack the 51% network. ideally p2pool has tens of thousands of independent miners

<j​ivan:pal.email> If anyone could amass that much power and pull a fast one, it'd be Doug Dimmadome, owner of the Dimmsdale Dimmadome.

<t​allhatdoug:matrix.org> yessir!

<a​lexandre:uii.pt> so cubic is basically taking the fact that people are mining there already and adding more of their own power.

<a​lexandre:uii.pt> by themselves they couldn't reach any meaninful hasharete

<s​hortwavesurfer2009:monero.social> Exactly. They reward miners who switch to them with their shitcoin. If they had to actually get all the hashrate themselves to attack the network straight out, they would not be able to.

<t​allhatdoug:matrix.org> I ain't no expert, but I'm gonna trust datahoarder & sech1 to lay it all out in their upcoming blog post. they're the ones who know the ins and outs of qubic mining

<s​hortwavesurfer2009:monero.social> I am very much looking forward to that.

What do the Monero developers have to say about the 9 block reorgs?

<t​allhatdoug:matrix.org> never a dull moment with monero

<s​hortwavesurfer2009:monero.social> Aint that the truth

<t​allhatdoug:matrix.org> Evolver -> it's pretty unsettling... with Qubic being able to perform 10+ block reorgs (they chose to limit it at 9 blocks) and orphaning 7.64% of the last 720 blocks. developers are rushing to apply a bandaid fix with DNS checkpoints, so let's hope they get it sorted soon

<s​hortwavesurfer2009:monero.social> I think they will. Even with all this mess going on, it still serves its purpose as a digital currency.

<s​hortwavesurfer2009:monero.social> If you order something physical, you're going to get a lot of confirmations before the thing is ever shipped out anyway.

<s​hortwavesurfer2009:monero.social> All this crap mainly hurts latency-sensitive applications, such as exchanges and maybe the gift card providers, although even they could just up their confirmations.

tallhatdoug: Please do share & link more about this DNS checkpoint fix.

hortwavesurfer2009: You can't order shit from it if it's price crashes.

*short

*its

<t​allhatdoug:matrix.org> I believe it impacted exchanges such as Gate, where just 10 confirmations were required

<e​ddie:oblak.be> I was able to get servers with a little delay yesterday during them having 60/100 blocks

<s​hortwavesurfer2009:monero.social> DNS Checkpointing has been in the code at least since I started using it in 2022.

<s​hortwavesurfer2009:monero.social> However, it wasn't tested to defeat normal reorganization attempts like this. It was tested to fix one time consensus issues if there was a problem.

<s​hortwavesurfer2009:monero.social> docs.getmonero.org/infrastructure/monero-pulse

tallhatdoug: Will the fix release get posted here: getmonero.org/blog

<s​hortwavesurfer2009:monero.social> DNS checkpoints are an opt-in feature currently.

<o​frnxmr:xmr.mx> It wasnt tested at all* LOL

<o​frnxmr:xmr.mx> hahahaha

sorry, but how will DNS checkpoints help the network here? And is there a link explaining it?

<t​allhatdoug:matrix.org> E​volver -> yes. as shortwavesurfer2009 said, DNS checkpoints have been an optional feature in Monero nodes already implemented, but with this bandaid update they will become opt out. developers are currently doing tests for the change in the #monero-research-lab:monero.social

<s​hortwavesurfer2009:monero.social> docs.getmonero.org/infrastructure/monero-pulse

<t​allhatdoug:matrix.org> sorry #monero-research-lounge:monero.social not lab

<t​allhatdoug:matrix.org> ☝️

<s​hortwavesurfer2009:monero.social> The problem, and the reason that it was opt-out before, is because by doing so, it is centralizing to whoever controls the Monero pulse infrastructure, which is the core development team. If you trust them, that's great. If you don't trust them, then that's not great. And that's why it was an opt-in feature only.

<o​frnxmr:xmr.mx> The DNS checkpoints act as a low effort trailing finality layer

<s​hortwavesurfer2009:monero.social> Look at Bitcoin core versus Bitcoin knots. Bitcoin knots no longer trusts the core development team.

<o​frnxmr:xmr.mx> they were opt-in* before, because they are untested and cause more harm than good in current form

<s​hortwavesurfer2009:monero.social> Good to know. So now they are doing more rigorous tests on the damn thing.

I am assuming the devs will make it an opt-out feature.

<s​hortwavesurfer2009:monero.social> Yeah, there's a command you can issue when starting your node called disable DNS checkpoints

<s​hortwavesurfer2009:monero.social> By default, currently to my understanding it warns the user if something is detected incorrectly, but doesn't do anything except warn the user. You can set in FORCE DNS Checkpointing, and that will force you to use what they think is the proper chain, or you can disable DNS Checkpointing entirely.

<s​hortwavesurfer2009:monero.social> Enforce*

ofrnxmr: By how many blocks might it trail? And what's keeping the devs' blocks from not moving forward on a bad chain?

<o​frnxmr:xmr.mx> 2-3

<o​frnxmr:xmr.mx> the main thing is to disallow >10 block reorgs

hooray!

:D

Will it be up to the individual node operators for now whether they want to activate this change?

what is stopping the registrar's from modifying the checkpoint though

does monero's DNS checkpoint domain have DNSSEC?

i hope the node won't be querying over unencrypted DNS

yes, all do DNSSEC

and multiple domains all have to agree

this system already existed

the work now is to test it with shorter cadence for having rolling checkpoint

what is stopping ISPs from blackholing any responses to a DNS request containing moneropulse

if this is using unencrypted DNS

I guess which DNS server is used would individually be up to the node...

if this is using unencrypted DNS, the choice of server would not matter at all

ISPs could blackhole any requests containing moneropulse on any UDP packets on port 53

Maybe forcing DNS over HTTPS using a custom resolver could be better?

If not now, then next time.

Still also using DNSSEC, of course.

Cindy: the DNS is using the system dns

if system or your local router is using DoH, that will be used

i see

Ten years ago, DoH wasn't invented or popular

the critical users here are, exchanges, and monero pools and anyone who mines

this will work well with anonymized DNSCrypt

as long as the critical consensus or monetary entities follow the right chain, that will work well

Cindy: nothing is being changed besides using the already existing method

you can take a look at it or enable it today

--enforce-dns-checkpoints

further changes on it or long term plans that change how monero works would come later on. this is a bandaid measure that can work semi-quick with minor changes

yeah i know

which is good

What's keeping the Pulse nodes from moving forward with a bad chain...

the checkpoints are chosen by the core dev team

it's listed in the monero pulse page what could happen, Evolver

if you are curious about how monero itself makes DNS requests or checkpoints work, see github.com/monero-project/monero/blob/master/src/common/dns_utils.cpp and github.com/monero-project/monero/bl…ter/src/checkpoints/checkpoints.cpp respectively

these also include the "release" checkpoints

how does the core dev team determine what is the good fork

they place the checkpoints regularly, say, tip -2 blocks

that means no fork can be longer than the uncheckpointed area

these are done before reorgs happen

making long 10+ reorgs unattainable

if they happen, nodes enforcing checkpoints will refuse these and over time build on what was selected

17:36:43 <Cindy> how does the core dev team determine what is the good fork

this is currently being tested as well across the dev/lab channels

what cadence/delay works best

if you are curious you can sync up to testnet and see the reorgs they are doing

so they're simulating qubic?

they are simulating altchains testnetnode4.moneroconsensus.info

not explicitly qubic

they are testing longer, and shorter reorgs

and see how different nodes pick them with and without checkpoints enabled

Is there any risk of Pulse retracting its choice of what's selected, switching to a new incompatible selection?

different node testnetnode3.moneroconsensus.info

i see

that's a pretty long reorg chain

Evolver: all people would have to agree on doing that, as listed on docs.getmonero.org/infrastructure/m…pulse/#moneropulse-as-attack-vector

yeah, they are testing more cases than usual, Cindy

there's a side track of expanding that page to include this new usecase, expanding the list of checkpoint endpoints to have more people involved, etc.

right now they are focusing on it being technically feasible and stable

i can't host a monero node, i only have HDDs!!

let's hope that a onion monero node that has DNS checkpointing exists

DataHoarder: but if adding too many people, how will they develop their own consensus? And can the DNS response return a list of checkpoints that don't have internal consensus, so what happens then?

only checkpoints that agree are used

well, that's the trick isn't it? I'm not who decides to add more or less, but it has been considered and tabled for future(?) discussion in the rooms

I am retelling what I remember from the MRL discussions these past few weeks, which have logs as well available :)

!tip Cindy an SSD and moar ram

I noticed at moneroconsensus.info in its 6h chart that it had gone to 55% for Unknown pool.

DataHoarder: any expected timeline for this change? a week?

I guess you won't know. Sorry.

they are still actively testing on testnet, possibly to shorten release timeline for this

worse would be rushing then asking for users to enable something that doesn't work well or actively harms monero more than helps, so yeah. better be sure

nioc: :o

thx <3

best thing about IRC is that you can have a custom CTCP that sends your monero address

tbh, running Monero on an HDD is perfectly fine. just have a lot, a lot of ram!

then it will all get cached :)

imagine IRC aliases in monero wallet lol

type someone's nick in monero, and it'll connect to libera and send them a CTCP request

DataHoarder: well, it was making my system super slow

it's more like a joke, basically your RAM would just be the "SSD"

ahhhh

so you're saying, making a ramdisk on the extra ram :P

then it would be like qubic's crappy node program

Binaries for v0.18.4.2 are now available at getmonero.org

ty bF

<j​effro256:monero.social> Yes, thank you binaryFate

are subaddesses safe?

like, are they not gonna be linked somehow to the main address?

<j​effro256:monero.social> For more exposure, I'm re-posting in this room. This is why you should download v0.18.4.2: monero-project/monero #10059

of course i've heard of the janus attack

<j​effro256:monero.social> @Cindy_: without an active Janus attack, there isn't a way for people to link subaddresses together or main addresses to subaddresses unless they have a quantum computer that works to break Ed25519's discrete log problem

<j​effro256:monero.social> So currently known passive attacks for linking Monero addresess with current technology: none

also arch linux still has 0.18.4.0

and their issues say "severity: low"

i should bug them to update quickly with this issue :P

<j​effro256:monero.social> That would be great

bumped to 8.4.2 and i've never seen this one before. Sync data returned a new top block candidate: 3486453 -> 3404857 [Your node is 81596 blocks (3.7 months) ahead]

v0.18.4.2*

baz: i saw this before, but it happens rarely

if this prints more frequently now it might be a bug or a side effect of one of the changes we had

i'll watch out for it, i'm doing another update now and i'll see if it shows the same

<r​avfx:xmr.mx> I installed the update yesterday when I made the Alpine package, I did not get that issue