<c​ountbleck:matrix.org> Does "aggregation interval" mean "the number of hours used to determine each datapoint"?

<c​ountbleck:matrix.org> If so, why does the 24 hour setting have only three datapoints?

<r​ucknium:monero.social> CountBleck: Yes

<c​ountbleck:matrix.org> I see the 6 hour one starts at August 8 but not the 24 hour one

<c​ountbleck:matrix.org> I would expect graphs with higher aggregation intervals to display a wider range of time, to maintain a similar number of data points

<r​ucknium:monero.social> The data starts August 8 at 12:00 UTC because that's when data with the most number of mining pools started to be collected, thanks to updates by DataHoarder: git.gammaspectra.live/WeebDataHoarder/monero-blocks

<c​ountbleck:matrix.org> because right now the 24 hour one looks pretty flat

<c​ountbleck:matrix.org> ah, understood

<r​ucknium:monero.social> Thanks for the feedback. I will clarify in the `<Placeholder text>`

<g​onbatfire:monero.social> [@elongated:matrix.org](https://matrix.to/#/@elongated:matrix.org) I'm talking about poisoned outputs... Thought I was in the right room... youtu.be/iABIcsDJKyM?si=HitNoNYrn2JRD6V1

<g​onbatfire:monero.social> Well it's on me for not using the correct term I guess, anyways has anyone done that? No tradeogre wallets have moved but we don't know about XMR ones

<g​onbatfire:monero.social> [@elongated:matrix.org](https://matrix.to/#/@elongated:matrix.org) I'm talking about poisoned outputs... youtu.be/iABIcsDJKyM?si=HitNoNYrn2JRD6V1

<e​longated:matrix.org> And TO guys don’t know about it ? A few hops and it’s not traceable

<g​onbatfire:monero.social> Yep but just knowing that they did 1 hop after being offline is enough

<g​onbatfire:monero.social> If they move any of the funds it pretty much confirms an exit scam

<e​longated:matrix.org> You don’t know if they moved it or it’s a decoy

<g​onbatfire:monero.social> Using the method I linked you can guess with a high probability

<e​longated:matrix.org> Go watch it again

<f​r33_yourself:monero.social> I've been trying to think through some of the downsides associated with moving to Proof of Work plus Proof of Stake consensus. I saw kayab mention that if 34% of validator stake goes offline or doesn't come to consensus to finalize blocks, then it is effectively similar to a denial of service attack on the network. No transactions get through with finality, so it is similar to an <clipped

<f​r33_yourself:monero.social> empty block attack. If PoW + PoS gets implemented what measures could be put in place to reduce the likelihood of a bad actor or motivated attacker from getting 34% of the stake early on right when this change is deployed? Seems like if a motivated attacker wanted to, they would just need to be one of the first to stake a lot of Monero to validate. Maybe slashing would get around <clipped

<f​r33_yourself:monero.social> this? I'm not very familiar with how Proof of Stake works, so I'm just thinking through the weak points with that possible idea.

<f​r33_yourself:monero.social> I know ofrnxm mentioned that his proposal would be that only coinbase (freshly mined) monero could be staked. That would require a motivated attacker to first mine a bunch of Monero, then stake it, so I guess that would be one barrier of entry. Whereas without that barrier they could just buy a bunch of Monero and submit themselves and their Monero as a large portion of initial st<clipped

<f​r33_yourself:monero.social> ake to validate transactions.

<f​r33_yourself:monero.social> Mentally I'm trying to grasp in as clear and simple terms as possible what are the largest risks associated with shifting to PoW + PoS, as well as what the clear benefits are. It appears that two main benefits would be greater protection against deep reorgs and hence double-spends. But perhaps a finality layer by itself wouldn't protect against empty blocks being proposed by PoW m<clipped

<f​r33_yourself:monero.social> iners. It also appears that moving to a PoW + PoS system with a finality layer would enable to the removal of the 10-block lock. Just curious if people who better understand the proposals, and Proof of Stake, could clearly explain some of the risks and benefits? I'm not entirely sure what to make of it yet.

<e​longated:matrix.org> What about triple pow ? Randomx/mergeminewith-ltc/sha3

<e​longated:matrix.org> 40:30:30

<b​asses:matrix.org> openssh.com/pq.html

<b​asses:matrix.org> OpenSSH Post-Quantum Cryptography

<b​asses:matrix.org> >More recently, in OpenSSH 9.9, we have added a second post-quantum key agreement mlkem768x25519-sha256 and it was made the default scheme in OpenSSH 10.0.

<b​asses:matrix.org> >all the post-quantum algorithms implemented by OpenSSH are "hybrids" that combine a post-quantum algorithm with a classical algorithm. For example mlkem768x25519-sha256 combines ML-KEM, a post-quantum key agreement scheme, with ECDH/x25519, a classical key agreement algorithm that was formerly OpenSSH's preferred default. This ensures that the combined, hybrid algorithm is no wor<clipped message>

<b​asses:matrix.org> se than the previous best classical algorithm, even if the post-quantum algorithm turns out to be completely broken by future cryptanalysis.

<b​asses:matrix.org> most important point

<r​ucknium:monero.social> Here's the Qubic full restore key for that view key earlier: xcancel.com/c___f___b/status/1954837460686414187

<r​ucknium:monero.social> `hold threaten vector point lawsuit vein nestle much scrub bowling smash pizza howls strained afoot vary elapse nimbly trying sugar bubble jazz sailor soggy afoot`

<r​ucknium:monero.social> The wallet's been swept of all coins, of course.

<r​ucknium:monero.social> To the "Blocks mined by mining pools" tab of moneroconsensus.info , I added text about what a malicious party can do with majority hashpower share.

<r​ucknium:monero.social> Tell me if you disagree with anything I say there.

<m​onerobull:matrix.org> are we super unlucky right now?

<m​onerobull:matrix.org> seems like it

<m​onerobull:matrix.org> imagine not having zeroconf and waiting 15 minutes on a block twice in a row

<m​onerobull:matrix.org> uhm

<m​onerobull:matrix.org> was that the biggest reorg ever just now

<l​ordx3nu:matrix.org> Looks like 4?

3

<m​onerobull:matrix.org> we had 3 before

<m​onerobull:matrix.org> makes sense that they can do 3 with 30% of hash

<l​ordx3nu:matrix.org> Oh yeah 3

<m​onerobull:matrix.org> ok so no smoking gun

<m​onerobull:matrix.org> Ruck, your site is very cool

17:09:44 <m-relay> <m​onerobull:matrix.org> are we super unlucky right now?

unlucky + lucky

<r​ucknium:monero.social> See my "Table: Duration of meta attack to achieve attack success probability of 50 percent" monero-project/research-lab #102#issuecomment-2402750881

<r​ucknium:monero.social> If they have 30% of hashpower and they are continuously trying to re-org 3 blocks, we would expected that it takes 45 minutes of pursing that strategy to achieve a 3-block re-org with 50% probability.

<p​reland:monero.social> Of the last 21 orphans, they have won 20 of them.

<r​ucknium:monero.social> They don't broadcast chains that they lose.

It looks like they are not mining empty blocks now?

<b​oog900:monero.social> xcancel.com/c___f___b/status/1954926476958028186

<b​oog900:monero.social> that includes fails that don't seem to be on moneroconsensus.info ?

<b​oog900:monero.social> self hosting ig

<r​ucknium:monero.social> Interesting. Yes, possibly self-hosting it on a node that gets their failed attacking chains. I licensed it AGPL, by the way.

<r​ucknium:monero.social> In the repo I haven't included instructions of how to add the `monero-blocks` info, but it should be obvious enough.

<r​ucknium:monero.social> I would encourage people to self-host because moneroconsensus.info could start refusing connections or becoming very slow if a lot of users connect simultaneously.

<r​ucknium:monero.social> I will write some more deployment instructions soon.

<s​gp_:monero.social> I want to share my thoughts here before posting on the github issue, but I think tevador's proposal 98 to bolster p2pool will primarily harm small miners more than it will harm pools. That's potentially fine depending on the tradeoffs considered, but I figured this would be useful to write up for discussion: gist.github.com/SamsungGalaxyPlayer/892472b28fa2ed92db47f51678637f87

<r​ucknium:monero.social> I zoomed in on the image: the top block says `Pool: QUBIC` 👀

<b​oog900:monero.social> hmm good spot

<b​oog900:monero.social> wonder why the others are not flagged as qubic

<s​gp_:monero.social> the person could have edited the html

<b​oog900:monero.social> you would think they would do at least the other 3 in the main chain tho lol

<b​oog900:monero.social> half arsed the marketing material

<r​ucknium:monero.social> If they are secret chains, their infrastructure might not communicate fully.

<r​ucknium:monero.social> It's a PNG file, not HTML. If you self-host you could easily edit the CSV file that the Shiny app pulls data from, of course.

<j​effro256:monero.social> Hi tevador, it's good to see you're back

Hi

<k​ayabanerve:matrix.org> tevador: did you consider every RandomX hash sampling RingCT outs, and their SHA hash being the hash used for pow?

<k​ayabanerve:matrix.org> (Instead of cache building off blockchain data once every 64 blocks)

<k​ayabanerve:matrix.org> (So IO scales with hash power)

<k​ayabanerve:matrix.org> Also, of course, great to see you again :)

The current proposal minimizes changes in RandomX and mining software. It basically boils down to replacing calls to randomx_init_cache by a daemon RPC call. Doing online disk IO would be much trickier.

<e​longated:matrix.org> x.com/c___f___b/status/1954823638022037733 which monero team is working with cubic ?

<k​ayabanerve:matrix.org> Fair re: minimizing changes.

<k​ayabanerve:matrix.org> elongated: Probably none? They've made a lot of definitive posts with authority they (or even no one) has.

<k​ayabanerve:matrix.org> Unless they're arguing they themselves are now 'Monero team'?

<s​yntheticbird:monero.social> can official twitter account please say "no we aren't"

<g​ingeropolous:monero.social> i wish merge mining with tar woulda worked out better

<g​ingeropolous:monero.social> tari

<g​ingeropolous:monero.social> someones just gotta launch a monero merge mined NGU crypto. use the standard scamcoin playbook for it - pay to get into exchanges, market makers, marketers, influencers, etc etc

<g​ingeropolous:monero.social> or use the same resources to buy up the books on exchanges.

<g​ingeropolous:monero.social> in essence i feel this is an economics problem.

<g​ingeropolous:monero.social> I wonder if doubling the blocktime to 4 minutes would do anything useful

<g​ingeropolous:monero.social> i mean, its like, 51% attacks are inevitable in a permissionless PoW network, so how can you make them more tolerable and survivable.

<g​ingeropolous:monero.social> staking finality != permissionless, afaiui .

<a​tomfried:matrix.org> Well there is dark.fi ... Maybe not the NGU scamcoin you are hoping for but maybe it works out better than tari

when Is darkfi launching? :)

<s​yntheticbird:monero.social> never

<s​yntheticbird:monero.social> i mean, when middle east become stable

<s​yntheticbird:monero.social> which means never

<s​yntheticbird:monero.social> i swear this is relevant to darkfi

<f​iatmoneysucks:matrix.org> Why Monero don't use a selfz

<s​yntheticbird:monero.social> a selfz?

<f​iatmoneysucks:matrix.org> Why Monero don't have a self-hosted repo in Gitea or GitLab with a .onion link? Github sucks*

<f​iatmoneysucks:matrix.org> My wifi sucks too :3

<f​iatmoneysucks:matrix.org> theverge.com/news/757461/microsoft-…-resignation-coreai-team-transition

<s​yntheticbird:monero.social> I should really get librejo.monerodevs.org up and running gosh

<s​yntheticbird:monero.social> postgresql was the biggest mistake of humankind

<j​effro256:monero.social> Yeah IDK what's wrong with it at the moment, but it's throwing a bunch of 500 internal server errors

<s​yntheticbird:monero.social> postgresql is corrupted

<s​yntheticbird:monero.social> and i haven't find the time to investigate

<s​yntheticbird:monero.social> one thing im sure is that once its restored im gonna migrate to sqlite

<3​21bob321:monero.social> Better then mariadb

<s​yntheticbird:monero.social> I think the only software I ever used that used mariadb was metasploit

<s​yntheticbird:monero.social> and everything make sense

<f​iatmoneysucks:matrix.org> I had no idea librejo existed, it's a really important tool, thank you.

<f​iatmoneysucks:matrix.org> By the way, the other day I was asked about the progress of the new official Monero website (getmonero.org).

<f​iatmoneysucks:matrix.org> I even tagged you there.

<f​iatmoneysucks:matrix.org> reddit.com/r/Monero/comments/1mk9kg…ny_update_on_the_new_monero_website

<f​iatmoneysucks:matrix.org> I had no idea librejo existed, it's a really important tool, thank you.

<f​iatmoneysucks:matrix.org> By the way, the other day I see a post was asked about the progress of the new official Monero website (getmonero.org).

<f​iatmoneysucks:matrix.org> I even tagged you there.

<f​iatmoneysucks:matrix.org> reddit.com/r/Monero/comments/1mk9kg…ny_update_on_the_new_monero_website

<c​ountbleck:matrix.org> If you need help with the rewrite, then I might be up for it

<s​yntheticbird:monero.social> You are the fourth then

<s​yntheticbird:monero.social> progress have stalled because designer got extremely busy

<c​ountbleck:matrix.org> the fourth person to offer?

<s​yntheticbird:monero.social> but there should be room for a meeting

<s​yntheticbird:monero.social> to offer their help for the rewrite yeah

<c​ountbleck:matrix.org> I *might* get busy too (I'm a high schooler and college app season is approaching)

<c​ountbleck:matrix.org> but I *might* be able to offer some help

<s​yntheticbird:monero.social> everyone is dw

<c​ountbleck:matrix.org> I just joined matrix.to/#/#monero-site:monero.social; is that the right place for me to lurk?

<f​iatmoneysucks:matrix.org> reddit.com/r/Monero/comments/1mnjmp…_exchanges_are_following_traditions

<f​iatmoneysucks:matrix.org> Well, CEXs don't have much influence on Monero, and that also means that they won't have much influence if Monero has a hybrid PoW+PoS system.

<f​iatmoneysucks:matrix.org> Honestly, so far Monero seems to be the only cryptocurrency that would have a fair PoS system, because there are no big companies with a large centralized Monero stock, I think Qubic is being great to see where Monero can improve, sometimes something bad comes to make things better.

<b​oog900:monero.social> Did we just have a 7 block reorg?

<b​oog900:monero.social> moneroconsensus.info just loaded and yes we did

<l​ordx3nu:matrix.org> Impressive

<b​oog900:monero.social> yeah I think that is a new record

<o​frnxmr:monero.social> I had a tx with like 3 confs lol. Seems to have returned to my wallet

<m​onero.arbo:matrix.org> goddamn

<c​ountbleck:matrix.org> Dayum

<o​frnxmr:monero.social> Lets see if i can respend

<o​frnxmr:monero.social> i wonder if its back in my txpook. I didnt make note of the txid

<b​oog900:monero.social> ofrnxmr: I think they are doing what you said and disconnecting their node, the last 4 blocks had no txs which makes me think they emptied their pool with the first 4

<b​oog900:monero.social> anyone running a public node and has logs of an IP connecting right before sending you 8 blocks that caused a reorg?

<o​frnxmr:monero.social> Im runnin on level 0 :/

<o​frnxmr:monero.social> I'll switch to lvl 1

I see 6 blocks with no txs 88-93

<c​ountbleck:matrix.org> explorer.jetskipool.ai/xmr-tracker is looking a bit interesting

<o​frnxmr:monero.social> I got a lot of

<o​frnxmr:monero.social> ```

<o​frnxmr:monero.social> 2025-08-11 22:52:42.977 E Transaction spends at least one output which is too young

<o​frnxmr:monero.social> ```

<o​frnxmr:monero.social> Right before the reorg

<b​oog900:monero.social> ruidx I only counted the blocks that caused the reorg, but yes

<o​frnxmr:monero.social> Hold on, looks like back to back reorgs

<o​frnxmr:monero.social> Nvm, same reorg (alt blocks -> spends too young spam -> reorg)

<b​oog900:monero.social> yeah this probably happens because your node pops blocks off the top of the chain to do the reorg so new txs will look like they are spending outputs that are less than 10 blocks old

<o​frnxmr:monero.social> Breh, my logs look like shit

<o​frnxmr:monero.social> Reorgs every 10 mins all day

<p​reland:monero.social> Nakamura was a fucking genius

<o​frnxmr:xmr.mx> My tx reappeared in my wallet, and has 1 confirmation now

<o​frnxmr:xmr.mx> Another reorg

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

<m​onerobull:matrix.org> we got some eyes on gupax

<p​reland:monero.social> It’s in 9 days actually

<o​frnxmr:xmr.mx> is this where centralized pools start peering to each other?

<p​reland:monero.social> August 20th 1200 UT

<m​onero.arbo:matrix.org> is part of the strategy with the empty (or under-filled) blocks that they propagate faster and so have a higehr chance of becoming canonical compared to full blocks?

<p​reland:monero.social> Tbh yeah, this is the part of the story where they decide to 51% the network in order to keep Qubic out

<o​frnxmr:xmr.mx> This is what i meant about increasing fees doesnt help, if all of blocks on the left get reorgd out

<p​reland:monero.social> Yeah

<b​oog900:monero.social> it was they don't do that anymore tho

<m​onero.arbo:matrix.org> some are still empty and others are only like 40 kB even when the mempool is full

<p​reland:monero.social> And yeah that’s the idea; looking at that deep reorg I wonder if they manually “cut off” transactions at the end

<b​oog900:monero.social> Lyza ^

<p​reland:monero.social> Tbh I think they were hoping for a 10 block reorg.

<o​frnxmr:xmr.mx> I dont. I think they got 7 and broadcast it before they lost it

<m​onero.arbo:matrix.org> probably wouldn't even use a full node jsut to generate empty block templates but yeah still

<o​frnxmr:xmr.mx> I think theyll get their 10 though

<p​reland:monero.social> Hoping; once they saw the rest of the chain catching up they gave up and just accepted the easy 4.2 XMR

<o​frnxmr:xmr.mx> Ofrn wishes his node would reject empty blocks if local txpool doesnt agree that the blocks being emoty

<o​frnxmr:xmr.mx> Another reorg

<o​frnxmr:xmr.mx> Theyre not getting 10 straiggt, but now are about to do 801-810 in pieces

<o​frnxmr:xmr.mx> Theyre at 801-801 now

<o​frnxmr:xmr.mx> 801-808

<o​frnxmr:xmr.mx> I guessed yesterday that they have over 50% hashrate and are likely hiding some on centralized pools.

<m​onero.arbo:matrix.org> I was wondering about empty (or under-filled) blocks getting a relay rule to delay broadcast but thinking it through, it would just make it harder for other miners to build on those blocks

<o​frnxmr:xmr.mx> My idea would be to delay building on them and accept a "better" block as the canonical one ESPECIALLT if the better block was received first

<o​frnxmr:xmr.mx> if i wait for you to submit your good block, then i can win with a late subsission of half-assed work, just based on quantity of garbage that i submit, that seems a bit flawed to me

<o​frnxmr:xmr.mx> the point of the blockchain and if miners isnt just to build blocks and take emission, its to mine transactions

<m​onero.arbo:matrix.org> so the rule would be something like, in the event of a chain split, weigh number of transactions (or fullness of blocks) as well as total PoW?

<m​onero.arbo:matrix.org> I was thinking of something like a PoW penalty for underfilled blocks, but the mempool is ephemeral and non-canonical so nodes that aren't online when the chain split happens won't have that info when syncing

<o​frnxmr:xmr.mx> Txpool 1mb due to reorgs

<o​frnxmr:xmr.mx> Rule would be: if i have a block that has 300tx in it, and some dumbass sends me an empty block to reorg the one im building on, reject the empty chain

<p​reland:monero.social> A semi-joking, semi-serious proposition: what if we only allowed mining from the major pools *temporarily, until August 22nd or a few days after*.

<o​frnxmr:xmr.mx> haha

<p​reland:monero.social> Wait for their halving to screw over their plans, keep them from earning *anything* in the meantime, and then see where things are at

<p​reland:monero.social> Downside is, well, I don’t think I need to explain it lol

<o​frnxmr:xmr.mx> honestly the easiest solution rn would be "my txpool has 1mb of txs in it. Reject blocks that dont mine blocks that match the scaling, aka 290kb or less atm"

<b​oog900:monero.social> I think this site tells you when they are mining an alt chain: explorer.jetskipool.ai/xmr-tracker

<b​oog900:monero.social> there was no block 1 min ago ...

<p​reland:monero.social> I didn’t think about that….yeah that’s exactly what that means

<m​onero.arbo:matrix.org> how does a node just coming online know which chain is canonical?

<p​reland:monero.social> And now that you mention it, I remember being confused about a week ago because they seemed to be claiming to have mined a block mined by support….maybe they’ve been messing with selfish mining for longer than they’ve let on

<o​frnxmr:xmr.mx> The one that isnt empty :D lol

<m​onerobull:matrix.org> this fucker removed the retweet and posetd my image with his own text

<m​onerobull:matrix.org> this fucker removed the retweet and posted my image with his own text

<o​frnxmr:xmr.mx> 40sec now

<3​21bob321:monero.social> Rdo

<p​reland:monero.social> Ffs this is finals week for me too

<b​oog900:monero.social> has our miners just given up or something?

<b​oog900:monero.social> finally

<o​frnxmr:monero.social> Im mining, but i'll probably get reorged if i find a block. Rip

<b​oog900:monero.social> I would end it all if I solo mined a block and it got reorged

<m​onerobull:matrix.org> 10 offers on miningrigrentals just got taken :P

<m​onerobull:matrix.org> >Showing records 1-25 of 155 not including 177 rented

<b​oog900:monero.social> do we think their current hidden chain is less than or longer than 7 🤔

<b​oog900:monero.social> they had quite some time to build it up

<p​reland:monero.social> Tbh I’m partially scared *for* Qubic

<p​reland:monero.social> All of the node ips are completely public, and each one (in theory) should be the location of a 10k$+ server….

<o​frnxmr:monero.social> Now heres the f'd up part.

<o​frnxmr:monero.social> If they can keep their chain ahead, they dont _have_ to keep reorging every 2-8 blocks. They can go ahead and reorg 100+n blocks

<b​oog900:monero.social> anything over 10 will be pretty bad as thats when txs start getting invalidated

<m​onerobull:matrix.org> do we need PoS for 1/10 blocks

<o​frnxmr:monero.social> i think the "whAt AboUt BooTstrappInG" is a non-argument

<j​ack_ma_blabla:matrix.org> why are allowing reorgs this deep ? a 10 block reorg can make many txs invalid

<o​frnxmr:monero.social> I'll take centralized bootstrapping (seed nodes, dns checkpoints etc) to limit reorgs to under 10 nlocks

<o​frnxmr:monero.social> The arguement i keep hearing is that offline or new nodes dont know which chain to sync to

<o​frnxmr:monero.social> And, to me, thats not an argument

<m​onerobull:matrix.org> if they reorg now thats going to be 10

<o​frnxmr:monero.social> We have seed nodes, checkpoints etc

<o​frnxmr:monero.social> Its already there, i think

<j​ack_ma_blabla:matrix.org> good that monero team is working with them 🤣

<r​ucknium:monero.social> I have about 130 connections to my server now, probably most of them to moneroconsensus.info

<p​reland:monero.social> Must be an attack, there’s definitely nothing of interest going on to warrant that /j

<o​frnxmr:monero.social> they dis 798-801, then 801-803, then 893-808

<m​onerobull:matrix.org> the jetski tracker says block 1 min ago

<j​ack_ma_blabla:matrix.org> find belarusian ips and forward them to kremlin

<o​frnxmr:monero.social> Sorry

<o​frnxmr:monero.social> 801-805, then 806-808

<b​oog900:monero.social> they are still mining on a secrete chain ...

<b​oog900:monero.social> explorer.jetskipool.ai/xmr-tracker

<m​onerobull:matrix.org> brace for impact

<o​frnxmr:monero.social> Boog, you think they have >50%? (i do)

<o​frnxmr:monero.social> Now, is this datacenter, state sponsored, randomx break, or cfb doing magic tricks

<b​oog900:monero.social> their own tooling says they don't

<j​ack_ma_blabla:matrix.org> possible, we dont have enough miners due to NGD

<m​onero.arbo:matrix.org> miningpool stats reports 4 GH from known pools, they self report as having 2.5 GH

<m​onero.arbo:matrix.org> do you think they're lying, or do you think some pool is redirecting to them or something? where's the rest of it

<o​frnxmr:monero.social> they could be lying. How are they gettinf longer chain so reliably, with the same hr as the past week (30%)

<o​frnxmr:monero.social> Ah, i think they are moning on centralized pools (fake reporting), then stealing the blocks they find

<p​reland:monero.social> If I’m being completely honest: it’s because botnets eroded mining profitability *so much* that it kicked out most honest miners

<o​frnxmr:monero.social> So centralized pools are reporting their hashrate as a part of their total, but not getting any blocks from the qubic workers

<o​frnxmr:monero.social> Nonsense

<m​onerobull:matrix.org> ha

<m​onerobull:matrix.org> they just caved

<o​frnxmr:monero.social> Price woukdnt stay at "300$" if it costs much less to mine

<m​onerobull:matrix.org> no 10 block reorg just yet

<r​ucknium:monero.social> AFAIK, stealing blocks from centralized pools isn't possible.

<o​frnxmr:monero.social> Watch it be 20 blocks

<m​onero.arbo:matrix.org> okay so hear me out. Let's say pool A mines a block, block starts to propagate. Meanwhile, pool B is still mining on the OLD chain, unaware of pool A's block

<m​onero.arbo:matrix.org> it's only for a few seconds, but between this and other tricks I'm not clever enough to think of, having mining centralized plus using empty / smaller blocks etc might be enough to get more blocks than their hash power would suggest

<b​oog900:monero.social> how much would this much hashrate cost to rent?

<b​oog900:monero.social> and is it even possible to rent this much

<m​onero.arbo:matrix.org> plus every orphaned block is wasted effort, and our pools were getting orphaned a lot

<j​ack_ma_blabla:matrix.org> try buying actual hardware and then mine & calculate your roi

<m​onerobull:matrix.org> miningrigrentals.com/rigs/randomx/btc

<b​oog900:monero.social> damn they probably just lost quite a few blocks

they just orphaned a block with 2 blocks

<o​frnxmr:monero.social> Not that im aware

<m​onero.arbo:matrix.org> how would you steal a block from a mining pool? it has their address in the coinbase

<b​oog900:monero.social> they are selfish mining which probably makes the global hashrate seem lower than it is

<b​oog900:monero.social> they will use this to claim a 51%

<o​frnxmr:monero.social> You send useless hashes to the pool, and then you mine a block, you dont send it

<m​onerobull:matrix.org> Rucknium: thanks for the incredible tool that lets us view this attack live

<o​frnxmr:monero.social> Useless = hashes with lower difficulty than the block target