<g​ingeropolous:monero.social> with the most dense server available per xmrig benchmarks, 50 MH/s needs 12 racks full of 2U servers. 240 of them.

<g​ingeropolous:monero.social> where is this hashrate coming from and why wasn't it mining monero in the first place

<d​iw_tim:matrix.org> I heard an interesting theory suggesting that Qubic might be utilizing research compute resources from German universities, as their team consists of many German academics. However, I don't think it has a significant impact anyway. Their emissions reduction led to a decrease in participation from hashvault.pro at least, and they transitioned from consistently producing over 2 GH/s<clipped message>

<d​iw_tim:matrix.org> to around 1.2 GH/s.

<d​iw_tim:matrix.org> I heard an interesting theory suggesting that Qubic might be utilizing research compute resources from European universities, as their team consists of many European academics. However, I don't think it has a significant impact anyway. Their emissions reduction led to a decrease in participation from hashvault.pro at least, and they transitioned from consistently producing over 2 <clipped message>

<d​iw_tim:matrix.org> GH/s to around 1.2 GH/s.

<n​eromonero1024:monero.social> shai-deshe.gitbook.io/parallel-thou…f-of-work/the-qubic-minority-report

<n​eromonero1024:monero.social> according to this report, at best, pubic controlled 35% hash rate, not 51%

<d​iw_tim:matrix.org> Nothingburger...

<l​eonarth_:matrix.org> xmrstats.com -- the blocks look kinda hairy

<l​eonarth_:matrix.org> these 3 blocks were all mined by nanopool in succession, at least that's what pool monitoring websites say

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> 3482518

<l​eonarth_:matrix.org> 0.60307682

<l​eonarth_:matrix.org> ad33d3dffd10871956ff3c44190559a3e50d7b0fa4e592d12c864b46992d889e

<l​eonarth_:matrix.org> 3482519

<l​eonarth_:matrix.org> 0.60024536

<l​eonarth_:matrix.org> ed2c7d47169b9d0edb390a925adfd6c1257585e013b3c8616ee8f5e09cb75050

<l​eonarth_:matrix.org> 3482520

<l​eonarth_:matrix.org> 0.6019255

<l​eonarth_:matrix.org> 9460c80683ae0bd72c38d209449cc1a225009db8a86ec1eb6ba8843a5c190c2b

<t​orir:matrix.org> Pools can claim their own blocks, and usually publish that information via API. Naturally, they can lie. I saw on block on XMRStats that was claimed by both Nanopool and Qubic.

<l​eonarth_:matrix.org> isn't there a truthful way to identify who mines the blocks without relying on pool provided data?

<l​eonarth_:matrix.org> I thought the key for the coinbase would be the same, but it's not

<n​oname-user0:matrix.org> would there be any interest in forking Monero into a pos variant? or even running two chains? pow monero and pos monero?

<n​oname-user0:matrix.org> it seems there's some split in the community

<n​oname-user0:matrix.org> so im just curious if it makes sense to have two chains

<f​reddi99:matrix.org> how do you think there is a "split"? the money hungry "line go up" people are just way louder, not a split here

<k​ayabanerve:matrix.org> I wouldn't support a split noname:

<k​ayabanerve:matrix.org> If it happened, I wouldn't be surprised if it caused a fork to form. Monero Classic, MoneroV existed.

<k​ayabanerve:matrix.org> That doesn't change I'd only support fork there was rough consensus in support.

<k​ayabanerve:matrix.org> I'll also note the idea is much more amenable now than it was a year ago, and we'll see where it is in another year?

unless i am mistaken, is the TFL proposal the only one that seeks to ensure that honest miners/validators are always >51% (i.e., those validators on the finality layer). all other solutions seek to mitigate the impact of selfish/malevolent miners on the network, or deter bad actors from profiting from their actions. if a collision of bad actors don't care about cost/resources, we would still have a problem, no?

*collusion

"Protocol level changes are going to be lengthy - maybe several years away - and much of the community is going to push back on anything PoS-related, which may lead to a chain fork." monero-project/research-lab #140#issuecomment-3209327323 , it seems sech1 and fluffy have agreed to some 'ASAP' testing of the linked github

issue

" model a situation where an attacker has 30-40% of hashrate and just ignores detective blocks"

trying to gain a specific % of a public testnet could be problematic

It can be a private testnet with just 3 miners (attacker, honest miner, detective miner)

that sounds great - i guess nobody has asked to 'cap their hash/s at a specific value' or would that not be needed?

What's important for the test is relative hashrates of the miners

<a​sdfqwfe:matrix.org> I support it. Split the chain and let the Hodlrs/market decide which one they think is more valuable.

<a​sdfqwfe:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/xIZLiGAaRaptWBLhnzInZJaZ

<a​sdfqwfe:matrix.org> The only reason the government hasn't crushed us because we're too small for them to care about.

<g​ingeropolous:monero.social> if a collusion of bad actors don't care about cost/resources, it doesn't matter if its PoS or PoW if they can overtake the "good" %.

<a​ntilt:we2.ee> Right, let's see happens to Ethereum PoS next year.

<a​ntilt:we2.ee> *what happens

<g​ingeropolous:monero.social> why, is something happening with ethereum?

<n​eromonero1024:monero.social> IMO, the government has not good enough incentive to attack eth

<n​eromonero1024:monero.social> 1. it's a transparent blockchain... they can just do statistics/tracking

<n​eromonero1024:monero.social> 2. they use Tether as a proxy to exercise additional soft currency power... taking down eth isn't congruent with that

<a​ntilt:we2.ee> @gingeropolous:monero.social oh yes. Huge capital inflows. You bet, this is about control. First its paper (etfs) but eventually SOME actors will turn these claims into power. Already validators are OFAC compliant to /some/ degree.

<a​ntilt:we2.ee> @neromonero1024:monero.social ETH will be permissioned by the US gvmt -- IMHO

<n​eromonero1024:monero.social> oh yeah, government can also just co-opt eth validators... no need to violently crush it

<n​eromonero1024:monero.social> basically, eth is a great asset for the government

<n​eromonero1024:monero.social> are most validators US-based?

<a​ntilt:we2.ee> 88% US + vassals

<n​eromonero1024:monero.social> HOLY shit

gingeropolous: yeah, reading more on (monero-project/research-lab #136), it seems the proposal does not include any sort of reputation element. i thought it was mentioned somewhere before, but obviously was not.

<n​eromonero1024:monero.social> in the issue, some comments were asking about a reputation system... maybe that's where you heard about it

<d​iw_tim:matrix.org> Nothing wrong with this...

which proposal midipoet ?

any of them?

<d​iw_tim:matrix.org> Is SChernykh sech1?

<j​effro256:monero.social> Yes

qubic has started selfish mining from the pools, they are delaying blocks

<l​ordx3nu:matrix.org> OK let me know if it is concerning enough that I should buy hash rate

they say to have prevented the PR posted x.com/c___f___b/status/1958545729837785580

#140

<l​ordx3nu:matrix.org> Looks like they are just trolling

<k​ayabanerve:matrix.org> flip flop @antilt:we2.ee: Can you clarify "+ vassals"?

<r​avfx:xmr.mx> US vassals usually mean Nato countries

<r​avfx:xmr.mx> And any other that rely on US for there currencies or defense

<k​ayabanerve:matrix.org> Yes, which is why I was asking to beak down the distribution further lol

did anyone implement the selfish mining #140?

<v​enture:monero.social> check out #141

<v​enture:monero.social> My shadow ban on GH got finally lifted. Honestly, I'm curious to know why this idea is stupid and can't work 😅

long orphan chain incoming from their pool data

no idea what they did but #140 is still doable? they changed nothing on stratum

<l​ordx3nu:matrix.org> I have 115 mh going, purchased an hour ago

+6 blocks ahead with shared root at 3482833

3482832*

<o​frnxmr:xmr.mx> 6 blocks ahead is cray

<o​frnxmr:xmr.mx> How much luck or hashrate do you need to pull that off

ahead, but root is longer

they have 40

<k​ayabanerve:matrix.org> 86% if actually every two minutes given honest hash power

so it's 8 blocks

they were lucky, monero unlucky

<k​ayabanerve:matrix.org> That assumes they aren't just misrepresenting their tail though

they published

<k​ayabanerve:matrix.org> *that 80+% number is if they mine that many per honest block and is meaningless, sorry

7 blocks orphaned

<l​ordx3nu:matrix.org> 😅

<v​enture:monero.social> selfish mine (with >2 block re-orgs) works by having a portion of honest miners mine on the wrong branch. they partition the honest miners and skew the hashrate distribution to their favor.

<k​ayabanerve:matrix.org> There was a question asked. I misinterpreted the parameters asked. I answered per what I misinterpreted.

<k​ayabanerve:matrix.org> I never thought Qubic had such a large percent nor meant to suggest that. I was commenting on how outlandish it'd be.

<v​enture:monero.social> I know. sorry! I was wanted to emphasize that they don't rely on luck alone anymore (past the ramp-up phase).

<v​enture:monero.social> But I guess everyone knows that

<v​enture:monero.social> even in the ramp-up phase, it's bound to happen within say 720 blocks that you find couple of blocks in a row given a certain threshold share. no luck involved

<l​ordx3nu:matrix.org> looks like they are attempting another big reorg

they are still on tip here

<r​avfx:xmr.mx> Does "renting" do something if it's done "after" Pubic ramp up?

<r​avfx:xmr.mx> I ask because it look like most of the rigs on mining rentals seam to be mining anyway, rented or not.

<r​avfx:xmr.mx> Renting before they start would allow us to prevent them to rent the rig at best price, but it have to be done before.

<o​frnxmr:xmr.mx> Assuming rigs are mining xmr: renting them only functions as a way to lighten your pockets

<o​frnxmr:xmr.mx> If they are mining qubic: you temporarily pull hash away from qubic, while funding qubicminers

<o​frnxmr:xmr.mx> If they are idle: these should be ok to rent

<r​avfx:xmr.mx> You can see the history of the rigs you rented, all of them I got from them, where mining before even during unrented period

<r​avfx:xmr.mx> There is no way to know the history of a specific offer before you rent it, I think

<j​ack_ma_blabla:matrix.org> miningrigrentals.com/rigs/306700/?currency=BTC < Rental history

<r​avfx:xmr.mx> oh yeah, there is

<r​avfx:xmr.mx> So yeah, they mine when not rented.

<r​avfx:xmr.mx> It's why I stopped renting actually

<j​ack_ma_blabla:matrix.org> Who is going to keep idle machines ?

<r​avfx:xmr.mx> if it's work to let renters use it, it's worth to mine with it too

<r​avfx:xmr.mx> worth**

<r​avfx:xmr.mx> renting them is just to make your rigs more profiteable

<r​avfx:xmr.mx> (you always get less than you pay in rental fee)

<b​arthman132:matrix.org> Even with qubic halving it seems like it did fuck all and now we have to hope for Qubic price to just collapse or something. It just goes to show you that expecting people to mine monero for no reason other than they like the project is a terrible idea. Qubic miners make double than what a monero miner makes. Expecting people not to work in their self interest is a dumb idea and i<clipped mess

<b​arthman132:matrix.org> s not realistic whatsoever.

<s​yntheticbird:monero.social> 🦜

<o​frnxmr:xmr.mx> That mfker is not real

<s​yntheticbird:monero.social> the animal or the idiot in the chat?

<o​frnxmr:xmr.mx> The meme video

<s​yntheticbird:monero.social> i'm sorry for my terrible lack of culture

<o​frnxmr:xmr.mx> youtube.com/watch?v=rKkzRvJqF9o << `synthetic` bird (emoji)

<s​yntheticbird:monero.social> lmao

<o​frnxmr:xmr.mx> btw, that was super research releated.

<b​arthman132:matrix.org> You guys are laughing now, but in the next 5 years where a serious threat comes along. We’re completely screwed. You think Qubic is a major player? Please they’re a small fish in a big pond and I wonder if they only did an attack as a marketing stunt to be honest. Monero just isn’t going to survive in the next 5 to 10 years in the pace we’re going now.

<o​frnxmr:xmr.mx> There are "supposedly" some that are idle

<o​frnxmr:xmr.mx> Those are the only ones i'd rent

<o​frnxmr:xmr.mx> Otherwise you take a gamble between a) funding qubic miners while reducing qubic hashtate (giving them more fuel for next marathon) or b) having negative net gain, since youre just (potentially) moving hashrate from one pool to another, 0 effect on network hash, and negative effect on your pockets

<o​frnxmr:xmr.mx> Also you see the rental rates go frok 0.53ltc per mh to 0.9

how do we know that q halving occured?

<s​yntheticbird:monero.social> I'm really wondering if pushing for the development of miningrental as a temporary mitigation to qubic which is also very probably using miningrental not a form a perverse incentive

there's another reorg incoming if they don't lose this one, they seem ahead +3

<b​arthman132:matrix.org> I can’t get into moneroconcensus.info

<o​frnxmr:xmr.mx> vips only

I'm in

syntheticbird stop thinking , give money to miningrentals

<o​frnxmr:xmr.mx> Qubic is probable leasing their rigs on MRR

<s​yntheticbird:monero.social> plowsof 5/5

<b​arthman132:matrix.org> Oh ok how many blocks have they orphaned?

they are waiting at 35

or unlucky

so if monero finds one now, they'd probably push?

<b​arthman132:matrix.org> 35? Jesus it’s been pretty bad

block number ending in 35

<b​arthman132:matrix.org> Oh ok

we are at 33

<b​arthman132:matrix.org> What’s the percentage of blocks orphaned?

the site works, go there (if you type it properly, bookmark it)

<b​arthman132:matrix.org> It still just says the server is down

<b​arthman132:matrix.org> At for me

<b​arthman132:matrix.org> At least for me

36 as well

Double edged sword that is getting sharper. If the rig rental is not idle, where is it mining? Solo? Or a pool? If pool then you just stole hashes from their comoetition? Ofrnxmr when will people start realising

it was pushed

<b​arthman132:matrix.org> Damn they got almost 5% of the blocks orphaned.

<b​arthman132:matrix.org> Only 1 monero pool(outside of qubic) has 1ghs or more of hashrate

<o​range_horizon:matrix.org> So I worked out that my idea here fails with what I would call hidden hash rate: Basically an attacker maintains a relatively low hash rate identity, and then at the point of attack rents more hash power and proposes blocks under the low hash rate identity. This could eventually be detected by the network, but as long as an identity can propose even one block that it didn't fairly<clipped m

<o​range_horizon:matrix.org> mine, the whole thing collapses to sybil.

<c​haser:monero.social> D​ataHoarder: is the reason that monero-blocks doesn't assign blocks to Qubic that their API is closed, or that their reputation is beyond damaged and they can't be trusted to not claim unknown blocks that aren't theirs?

<o​range_horizon:matrix.org> There is at least one possible solution: For the network to reward the ability to submit a block based on accumulated hash rate under a given identity: Under my proposed idea hash power is being tracked per miner key. so once a miner accumulates enough hashes, it is allowed to submit a block to the chain.

<o​range_horizon:matrix.org> multiple miners would submit blocks as they achieve the required accumulated hashes to avoid a stall if the correct miner is offline, and the nodes choose the block from the miner with the most work accumulated.

<o​range_horizon:matrix.org> maybe this allows for reorgs still though, by accumulating hashes on a large number of identities and the submitting blocks all at once. unless that can be solved somehow.

chaser: there is no block id mapping

so no, can't really assign well. they also change their patterns

<c​haser:monero.social> does that mean pools can report fake blocks to monero-blocks like they can report fake hash rate to e.g. MiningPoolStats?

<l​eonarth_:matrix.org> this might sound stupid, though imagine if we require miners to sign the block they submit with their private key and must put the public key to verify the signature in the memo

<l​eonarth_:matrix.org> nodes validate the signature using the privkey in the memo

<l​eonarth_:matrix.org> and only the miner receives the reward, this would make pools useless

yes, that's just a project to gather data. confirmation must be done via other means or general pattern finding (some pools have a per-instance random number on extra data in tx, which stays until pool reboots)

leonarth, that is what wow does, but with the key for that tx (so only that output can be spent)

<o​range_horizon:matrix.org> This was discussed on the github repo: monero-project/research-lab #136 If you do a word search for 'sign' it'll pretty much allow you to read through the thread.

<o​range_horizon:matrix.org> related, I'm not sure that breaking up pools necessarily stops an attack. cannot an attacker just utilise some other command and control structure to co-ordinate many individual miners?

<l​eonarth_:matrix.org> basically allowing solo mining only

<l​eonarth_:matrix.org> can still run multiple miners w/ multiple wallets

<l​eonarth_:matrix.org> though you need to have a wallet alongside every miner

<o​range_horizon:matrix.org> This was discussed on the github repo: monero-project/research-lab #136 If you do a word search for 'sign' it'll pretty much allow you to read through the thread.

<o​range_horizon:matrix.org> related, I'm not sure that breaking up pools necessarily stops an attack. cannot an attacker just utilise some other command and control structure to co-ordinate many individual miners?

<o​range_horizon:matrix.org> My intuition is that the only way to prevent attacks, is they need to be made extremely expensive.

<l​eonarth_:matrix.org> this will also break all the botnets, as miners are running on in those once hacked network, although access might have been lost

<l​eonarth_:matrix.org> also putting the wallet alongside the miner on not-your-own-servers exposes you to funds seizure once the admin finds your miner

<l​eonarth_:matrix.org> orange_horizon: how can you coordinate a large botnet which is basically what qubic is, when all the miners must have a wallet and sign transactions and the reward only goes to that individual miner participating in the network

<l​eonarth_:matrix.org> s/transactions/blocks

<o​range_horizon:matrix.org> If I remember correctly, encumbered keys was one of the ways to avoid having to share the spend key with miners but still having them mine for the pools wallet, but in the case of qubic these are willing participants running closed source code and not necessarily requiring the reward. what matters to the attack narrative is simply that they control the blocks on the chain. any act<clipped m

<o​range_horizon:matrix.org> or that doesn't need the reward could simply allow the rewards to fall to the miner whilst controlling what is in the blocks can't they?

<l​eonarth_:matrix.org> the whole idea of their scheme is that they're mining monero, get the reward, sell the reward, burn qubic tokens, reducing supply so that miners earning qubic would see its value go up - therefore becoming more profitable than mining monero directly

<l​eonarth_:matrix.org> if every miner in their botnet is receiving the reward individually on their wallet, then the burn incentive is gone