<l​eonarth_:matrix.org> why, I love the fact that it's all pure Go

I have been tracking an issue on mine on specific cpus missing some AVX2 extensions

or run it in purego mode

otherwise it does JIT compilation!

-tags purego

<l​eonarth_:matrix.org> Dero tried to run a privacy evm chain in pure Go

guess who didn't accomplish it, dero people

they are the ones that did the groundwork for the go one

rewrote quite much of it, but at least kept their program generators

<l​eonarth_:matrix.org> you know the events that led them to abandon the project?

<l​eonarth_:matrix.org> CFROUND instruction, chip manufacturer (Intel, AMD, ARM, etc.) can alter or remove their implementation, resulting in unexpected behavior that could lead to forcing invalid proofs on the chain

<l​eonarth_:matrix.org> they noted this randomx security issue while making the Go implementation, though does the C++ impl have the same flaw?

<o​frnxmr:monero.social> Bro just keeps ignoring datahoarder

<o​frnxmr:monero.social> go to [#p2pool-log:matrix.org](https://matrix.to/#/%23p2pool-log:matrix.org)

do move to #p2pool-log the observer channel for more, as said

<o​frnxmr:monero.social> I think i linked wrong room

or if it's about randomx design #monero-pow as I have less say for that

oh yeah that is the wrong room

see git.gammaspectra.live/P2Pool/observ…r#maintainer-run-observer-instances

there you have irc or matrix links

<l​eonarth_:matrix.org> moved

<o​frnxmr:xmr.mx> [#p2pool-log:monero.social](https://matrix.to/#/%23p2pool-log:monero.social)

<l​eonarth_:matrix.org> yup, was in wrong room

<l​eonarth_:matrix.org> thanks ofrn

<b​arthman132:matrix.org> Kraken has suspended monero deposits. Do you think that could have prevented many people just selling off their monero?

<o​frnxmr:xmr.mx> [@barthman132:matrix.org](https://matrix.to/#/@barthman132:matrix.org) I don't care, take non-research discussion elsewhere.

<o​frnxmr:xmr.mx> [@barthman132:matrix.org](https://matrix.to/#/@barthman132:matrix.org) -> [#monero-markets:monero.social](https://matrix.to/#/%23monero-markets:monero.social)

<b​arthman132:matrix.org> Thanks

they are no longer selfish mining according to the delay I see from pools to monerod

<d​anielgreg:matrix.org> tbh pos doesn't make sense. bitcoin mining is also not really profitable. asic miner, space and electricity -> roi is like 2 years and that's assuming the price of BTC doesn't go below like 60k and asic don't break and they break.

<d​anielgreg:matrix.org> the price of monero will rise because the coin is superior. more miners notice, randomx is our strength. we need more hashrate and hs is constantly increasing ever since randomx. thats good.

<d​anielgreg:matrix.org> monero roi is also tad different. everyone has motherboard with cpu. asics become useless eventually. i have 15 year old hw that still runs and works fine.

<b​arthman132:matrix.org> Well a lot of people mine bitcoin in the expectation that its value will go up, so even if they don’t immediately make a profit, they’re expecting to make one. A hybrid system would make sense, because I think it would not only incentivize miners. It would also give a incentive for miners to actually hold their monero

<o​ne-horse-wagon:monero.social> Would it hurt the blockchain in any way if P2Pool became 81% of the total hash? I say 81% because IMO, no other pool should be larger than 19%. 81% would prevent selfish mining if that level was maintained. I want to push the idea on reddit of more miners coming on board and others switching over to P2Pool.io.

<o​frnxmr:xmr.mx> a centralized pool can use p2pool

<o​frnxmr:xmr.mx> Simply requiring "p2pool" doesnt prevent selfish mining

<o​frnxmr:xmr.mx> P2pool is just a pool where each p2pool talks to one another and shares the reward. You can run p2pool on your own (without unselfish peers)

<g​ingeropolous:monero.social> my wacky idea might prevent selfish mining

<o​ne-horse-wagon:monero.social> What is your wacky idea?

<g​ingeropolous:monero.social> github.com/Gingeropolous/friction/blob/main/friction_longer.md . Careful, dunno if the cryptography makes sense. i wrote something in words that make sense to me, and a bot filled in the gaps

<g​ingeropolous:monero.social> that coupled with 98 might do something

<a​lexanarcho:matrix.org> technically, the heaviest chain is valid, not the longest, right?

cum difficulty indeed

<o​ne-horse-wagon:monero.social> How long would a newcomer have to mine before he established a reputation as a trusted miner? Your idea does have a lot of merit.

<o​frnxmr:xmr.mx> So.. force pool mining? lol

<o​frnxmr:xmr.mx> Cant say i like the idea of assigning reputation to miners

<o​frnxmr:xmr.mx> Essentially means the largest miners reorgs always win(?) And smaller fish get screwed

<3​21bob321:monero.social> Social credit score mining

<j​effro256:monero.social> gingeropolous: with all due respect , please don't flesh out your ideas with a chatbot and post it in a human chatroom. It just generates a lot of noise and isnt respectful of readers' time. I'd much rather have the bats bones of thought concisely laid out in a short gist. At the moment, in my opinion, chat bots can be decent at summarization (compression), but are pretty terrible<clipped mes

<j​effro256:monero.social> at expounding on details (decompressing)

<j​effro256:monero.social> *bare bones

<a​ntilt:we2.ee> Did you notice that LLMs allways try to sell you an idea? They fail to consider even the most trivial counter argument:

<a​ntilt:we2.ee> A reputation system can only be implemented month or even yrs BEFORE an attack -- otherwise attackers build up their rep as fast as the legitimate "old" chain.

<j​ack_ma_blabla:matrix.org> 8 block reorg!

<a​ntilt:we2.ee> I see trust scores as part of a solution, but only if we have a fresh start. Ban spy nodes, and chill selfish miners out.

<l​eonarth_:matrix.org> ~5XMR lost by honest pools in this re-org

<e​longated:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/aiwCNQkDTjATdaOneMSxNZBa

^ These links probably don't work on IRC. Gives me "Not found".

<j​fuffjcjkdrngisozkfng:matrix.org> That’s crazy

<e​longated:matrix.org> moneroconsensus.info < height 3479613

<n​oname-user0:matrix.org> no one really lost anything... their mining was real and if they didnt do it selfishly, they would have secured more tx fees along with these blocks. (probabilistically)

<n​oname-user0:matrix.org> it's not like fees were distributed and unlocked yet. that would be a much different story

<n​oname-user0:matrix.org> it's the same as mining an orphan block

<o​frnxmr:xmr.mx> Tevador, the link is to a screenshot of moneroconsensus.info

<b​asses:matrix.org> ibb.co/B26xjgJh here is the pic sent

<b​asses:matrix.org> matrix image links have been broken for IRC for a while

It seems that qubic's blocks rarely have more than a handful of transactions. They are either disconnected from the network most of the time or they use some nonstandard block template building method.

They run a modified monerod and who knows how clumsy they were while doing it

<e​longated:matrix.org> They only want to mine for block rewards and don’t care about transactions or the network.

For example qubic's block 3479622 contains only high-fee transactions, at least 16x the minimum.

<g​ingeropolous:monero.social> yeah im thinking long term fixes, not just to counter whats happening right now.

<g​ingeropolous:monero.social> so the gist is the longer you have mined, the more weight your blocks have during a fork choice. but sure i'll drop it because it doesn't address the attack we have now

<e​longated:matrix.org> Cubic is mining they have weight

i doubt they'll sustain it over a year. or 2. etc. long rolling windows.

Even though qubic is annoying, I think CfB is only trying to prove his point with no malicious intent. Imagine how much worse it would be if there was someone with destructive goals. That's the real future threat. There is no scarcity of CPUs and they can easily be acquired by a dedicated attacker.

<s​yntheticbird:monero.social> oh look a bot

cuprated no longer compiles on freebsd by the way which may be a low priority for now, just saying

"no malicious intent" github.com/qubic/proposal/blob/main…gic-qubic-monero-quorum-decision.md

We have different definitions of "malicious"

What would you call the attacker with a much bigger budget who doesn't announce plans in advance? You can call qubic malicious too, fine with me, all i am saying is it could be worse.

<j​ack_ma_blabla:matrix.org> Relying solely on POW will be a mistake in the long run. Given the current scale of XMR mining, it's easy to acquire the necessary computing resources with a decent budget.

<a​sdfqwfe:matrix.org> They have no illicit intent. But it is malicious.

<b​asses:matrix.org> how it is "no illicit intent" mr Monero_PoS_Fan

<b​asses:matrix.org> everyone replying to the link posted by tevador didn't even read it. Brain programmed by CFB

<b​asses:matrix.org> how about CFB donates all the $ he made from this "experiment" to Monero general fund?

<a​sdfqwfe:matrix.org> It's illegal to double spend. It's not illegal to DDOS (as far as I'm aware).

<a​sdfqwfe:matrix.org> They don't want to double spend.

<o​frnxmr:xmr.mx> We should anchor monero to a compliant / regulated stablecoin

<o​frnxmr:xmr.mx> A US* compliant one

<e​longated:matrix.org> I want a kremlin compliant

<r​afaelkinder:matrix.org> Hey question, actually two:

<r​afaelkinder:matrix.org> Wownero claims to be solo mining only. First, how is this done technically? Second, would it take to make this not horrible for monero?

<r​afaelkinder:matrix.org> Hey question, actually two:
Wownero claims to be solo mining only. First, how is this done technically? Second, what would it take to make this not horrible for monero?

they force miners to sign the solution with their key as part of the pow process

there's workarounds if pools really wanted to exist

<r​afaelkinder:matrix.org> Do you think it could be done?

<b​asses:matrix.org> xcancel.com/zooko/status/1955679269792927795#m lol

<b​asses:matrix.org> sometimes I doubt how smart zcash people are

<s​yntheticbird:monero.social> \> Someone: "Should I avoid this tomato? It says it's been over 2 days now..."

<s​yntheticbird:monero.social> \> zooko: "Maybe, but be sure that tomato is still red and looks like a fruit. Also the tomato is aligned with consumer standards"

<b​asses:matrix.org> he's AI

<s​pirobel:kernal.eu> zcash is secured by proof of zookos groceries

<b​asses:matrix.org> lets backdoor our chain to allow LE catch "bad guys"

<b​asses:matrix.org> avg zooko take

I believe this is the quote you are referencing.. " And by the way, I think we can successfully make Zcash too traceable for criminals like WannaCry, but still completely private & fungible."

*zooko quote

<b​awdyanarchist:matrix.org> When is the next MRL meeting? Is there a posted schedule?

every Wed

time?

1700 UTC

<a​rticmine:monero.social> I have read the Qubic proposal. I am far from convinced that this is licit.

<a​ntilt:we2.ee> Wed - we'll prob decide on checkpoints

<a​rticmine:monero.social> findlaw.com/criminal/criminal-charg…s/hacking-laws-and-punishments.html

<a​rticmine:monero.social> Any computer used in the Monero Network is a protected computer under US legislation

<a​rticmine:monero.social> The Qubic developers may be on the verge of serious felonies here. This is a legal question and I am not a lawyer

<a​rticmine:monero.social>

<a​rticmine:monero.social> My suggestion to the Qubic developers is get legal advice.

<b​asses:matrix.org> is Monero project a registered legal entity in U.S?

<a​rticmine:monero.social> That is not the point

<b​asses:matrix.org> I mean it could be illegal for people that is living in U.S regardless

<b​asses:matrix.org> contributing to Qubic attack

<a​rticmine:monero.social> The US is just one example

<b​awdyanarchist:matrix.org> In that case I'll do my best to submit two alternatives that much lower risks, with less impact to consensus, that at least mitigate most of the risk we're currently facing. That is either:

<b​awdyanarchist:matrix.org> A) Time adjusted blockweights, or

<b​awdyanarchist:matrix.org> B) Depth Penalty

<b​awdyanarchist:matrix.org> Both cases allow for nodes to self heal in the case of partitioning attacks, while significantly increasing the hashrate an attack needs to perform a 10-block reorg

<a​rticmine:monero.social> Monero is a worldwide decentralized network. The potential for decentralized litigation against and adversary is huge

<a​rticmine:monero.social> Basically any member of the Monero community who feels injured could sue or report to the authorities in any jurisdiction worldwide.

<b​awdyanarchist:matrix.org> Checkpointing comes with real risks of network fractures. It's a matter of either having 50% HP, or a large minority and getting lucky eventually. You can then snipe at the Nth block, and hope to split half the network behind the checkpoint. After which, only manual/social intervention fixes it.

<a​ntilt:we2.ee> thats just to buy time in the face of a Q* pump

<b​awdyanarchist:matrix.org> I can understand that. Still, it's a hard fork consensus change, and it might do more harm than good

<b​awdyanarchist:matrix.org> Imagine if instead of, say a 10 block reorg, we had a network split because Qubic sniped at the checkpoint (if it's 10 blocks). A reorg isnt great, but a network fracture is worse.

If there is only one source of checkpoints, I fail to see how that could fracture the network.

<b​awdyanarchist:matrix.org> I suppose if it's an entity we trust, then sure. I'd be way more comfortable with a *temporary* DNS checkpoint that simply adheres to a social layer we trust, as an immediate mitigation. But a simple rolling checkpoint I would be pretty worried about

<a​ntilt:we2.ee> its actually already there: --enforce-dns-checkpointing

You are probably referring to a max reorg depth limit, which could cause network split and I wouldn't recommend that solution.

<b​awdyanarchist:matrix.org> Interesting. Okay. Yeah I suppose that's a big benefit.

<r​ucknium:monero.social> With docs and everything :) docs.getmonero.org/infrastructure/monero-pulse

<r​ucknium:monero.social> Does someone want to set in motion a plan to test DNS checkpoints on testnet? I'm not the best programmer, so I probably shouldn't take the lead. I have some visualization infrastructure set up though: testnetnode1.moneroconsensus.info testnetnode2.moneroconsensus.info testnetnode3.moneroconsensus.info testnetnode4.moneroconsensus.info

<r​ucknium:monero.social> I suppose one could fork the `monerod` repo and just put in different DNS domains for testnet, so core would not have to be involved in the test at all.

<r​ucknium:monero.social> Then, write a script to update DNS records on the fly. And try re-org attacks.

<b​awdyanarchist:matrix.org> As long as it's temporary, that does seem like a solid immediate mitigation

Honestly, Depth Penalty sounds like a good solution, just because of the double take.

<s​yntheticbird:monero.social> agree with moneromooo

<a​ntilt:we2.ee> @rucknium:monero.sociali'd like to have a little time with the regulars, before all the new ppls jump in...

<o​frnxmr:xmr.mx> antilt, what?

<a​sdfqwfe:matrix.org> What laws do they break? Should we sue them?

It looks like they will be moving to attack dogecoin instead. xcancel.com/IMOLFG/status/1957125126756983132

<s​yntheticbird:monero.social> I see no explicit statement that they will stop mining monero

> "[10:27 PM]Come-from-Beyond: Moving to another coin will take months of development, we are mining Monero during this"

tevador: that was reiterated over a couple of channels, as well. this was sent just before last marathon they had

<l​ordx3nu:matrix.org> i created a "monero defense fund" for tomorrow's qubic marathon a few hours ago. I have 1.85 XMR in donations after a few hours 😀.

<l​ordx3nu:matrix.org> xcancel.com/xenumonero/status/1957090056331497679

view key?

<l​ordx3nu:matrix.org> e6c7d6dbd9ef0ab5acb21274aa9886940c3f2ba96bb834c7fef2c68d3013a203

<v​tnerd:monero.social> Rucknium: you need test boxes, code changes, and DNS wizardry?

<v​tnerd:monero.social> Any idea on a good DNS host. I currently use easydns but getting access to their API may take a few days for approval

<r​ucknium:monero.social> I think I have nearly enough test boxes (4 reachable nodes on separate IP addresses). Maybe a few people can join the test on their own machines. I think you would want to have two different domains on two different DNS services to see what happens when DNS record updating isn't completely synchronous.

<v​tnerd:monero.social> Yikes. These checkpoints will prevent a legit network split to heal correctly too. Although given what has happened, people will assume such an event was 51% case

<v​tnerd:monero.social> *in the caae of a major network split

<o​frnxmr:xmr.mx> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) can you share the db somehow?

What is the format of the TXT record for the DNS checkpoint?

<a​rticmine:monero.social> restislaw.com/liability-51-attacks-cfaa

<p​-q:matrix.org> Can‘t find the link but the statement was like this: the switch to ASIC takes about 4-6 month preparation while this time they still mining XMR

<l​eonarth_:matrix.org> they moved to doge

OK, found it. The format is height:hash.

<s​yntheticbird:monero.social> Leonardo: they claim to be willing to move to doge

<s​yntheticbird:monero.social> not the same

<e​longated:matrix.org> Where are they going to find that many asic miners, it’s just fake.

See the xcancel.com link I posted above.

<l​eonarth_:matrix.org> they use consensus and the community voted, so that's how it's gonna be

<s​yntheticbird:monero.social> someone ban this bot

<l​eonarth_:matrix.org> if Q breaks community consensus then they don't have a community

<l​eonarth_:matrix.org> lol, ok :)

why do they need a community wen they have a i

<l​eonarth_:matrix.org> true, aigarth should decide

wait, they are going to do AI with asics next?

<l​eonarth_:matrix.org> whatever they're doing idgaf

<t​esttank:matrix.org> I don’t think the Monero community should start being reliant on the judicial system 🤣

rucknium: I set a testnet checkpoint on checkpoints.xmrdb.com, height 2813706.

It seems that testnet checkpoints cannot be enabled anyways without changing the code. github.com/monero-project/monero/bl…onote_core/cryptonote_core.cpp#L267

And DNS checkpoints are loaded 1x per hour if enabled.

<s​pirobel:kernal.eu> technically we are not. we just have to outbid qubit in terms of CPUs to restart the network in case they decide to commit a crime. added another comment to this thread that breaks it down a bit serai-dex/serai #333#issuecomment-3194677441

<o​frnxmr:xmr.mx> Can someone share the data.mdb for testnet?

<m​onero.arbo:matrix.org> The doge security budget is 3.3 million per day lol

<m​onero.arbo:matrix.org> plus LTC, more like 3.7 mil

<e​longated:matrix.org> Xmr is 1/30th , but can’t compare them as those are asic and we are 🤖

<o​frnxmr:xmr.mx> doge + ltc is also a little bit higher combined market cap

<e​longated:matrix.org> 1cpu 1vote ftw 🙌

<e​longated:matrix.org> Little ? 😅

<m​onero.arbo:matrix.org> about 8x higher, so still a bit mismatched

<m​onero.arbo:matrix.org> XMR would need to be over $8000 to have the same security budget as LTC+Doge

<m​onero.arbo:matrix.org> which would be enough to make it a top 5 crypto again, almsot as big as XRP

<l​eonarth_:matrix.org> in the Block header, who fills in the timestamp of when the block was created, the miner that submits it or the validator that receives it?

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

<e​longated:matrix.org> Imagine the number of CPU’s needed

<l​eonarth_:matrix.org> therefore the miner can lie about the block creation time?

<o​frnxmr:xmr.mx> 6

<o​frnxmr:xmr.mx> Yes

<m​onero.arbo:matrix.org> there's some restrictions I believe, not sure exactly what, but they can't stamp it compeltely arbitrarily

<o​frnxmr:xmr.mx> It has to be within a few hrs iirc

<l​eonarth_:matrix.org> Lyza: then what if we change that, and have the validator input the timestamp of when the block was received and peers must agree on the time value, would that be feasible?

<e​longated:matrix.org> We can reach that price point someday if we go hybrid (not ofrnxmr model)

<m​onero.arbo:matrix.org> but yes I've seen some research about manipulating timestamps to try to manipulate difficulty, don't know too much about it

<s​pirobel:kernal.eu> its a problem that can be solved with money though. if qubit gains 51% and decides to halt the network, monero whales just have to get together and buy 13 million worth of CPUs (if they dont want to write of their monero value to 0 ) probably they can sue cfb afterwards to pay for the expense

<m​onero.arbo:matrix.org> Idk, rn the timestamp is verified by being part of the block (i.e. hashed for PoW

<s​pirobel:kernal.eu> its a problem that can be solved with money though. if qubit gains 51% and decides to halt the network, monero whales just have to get together and buy 13 million worth of CPUs (if they dont want to write off their monero value to 0 ) probably they can sue cfb afterwards to pay for the expense

<o​frnxmr:xmr.mx> Imo pow is pointless with finality layer or truly hybrid pos. The pos becomes the god

<l​eonarth_:matrix.org> what I'm trying to get at, if the Validators can ensure the timestamp of the block upon receiving it, we won't have block reorgs

<o​frnxmr:xmr.mx> damn are we in _research_ lounge or #monero?

<l​eonarth_:matrix.org> as only the blocks received and validated with the lowest timestamp would be added to the chain

<s​yntheticbird:monero.social> #monero-lounge 2.0. Brought to you by CfB

<m​onero.arbo:matrix.org> so everyone would lie to try to make their block the lowest acceptable number

<e​longated:matrix.org> POS can’t mine blocks, pow does the work keeps those botnets happy ; go full pos and get second recession like when asic was kicked

<s​pirobel:kernal.eu> #monero cigar lounge

<o​frnxmr:xmr.mx> pos decides What pow chain is real. So 5gh or 50gh, its up to the validators

<l​eonarth_:matrix.org> the miners send a block, the validators verify the proof and timestamp it using consensus

<l​eonarth_:matrix.org> does it make any sense?

<e​longated:matrix.org> Hybrid

<v​tnerd:monero.social> I still don't know how doge is a thing, but I know nothing about markets and finance

<l​eonarth_:matrix.org> when someone selfish mines and sends 3 blocks at a later time with higher block height, the timestamps would be validated with a later time except the last block which wasn't known to the network yet, therefore their submission is invalidated

<s​pirobel:kernal.eu> I become more and more convinced that both hybrid and PoS is a bad idea but monero whales should buy a bunch of CPUs and a nuclear power plant.

<v​tnerd:monero.social> I never thought these hybrid solutions would work out

<v​tnerd:monero.social> It's almost too confusing to reason about. Maybe just need to read up more

<e​longated:matrix.org> And how is it different from asic miners ? Gov capturing those farms ?

<s​yntheticbird:monero.social> sorry guys can you stop making sense. literally two days ago it was chaos and now there is consensus that the well thought decision of like 10 years ago still make sense today

<s​yntheticbird:monero.social> shocking i know

<e​longated:matrix.org> Thank you 🙏🏻 I will rest in peace

<s​pirobel:kernal.eu> we can defend it with mines and drones

<s​pirobel:kernal.eu> we should add a robot factory

<e​longated:matrix.org> Overclocked

<s​pirobel:kernal.eu> to produce the drones.

<s​pirobel:kernal.eu> it is proof of drones

<s​pirobel:kernal.eu> vs the government

<e​longated:matrix.org> Article might like it if it’s legal

<e​longated:matrix.org> Really? Didn’t we want to use law

<s​pirobel:kernal.eu> who ever controls the factory that makes more drones says what is legal

<e​longated:matrix.org> Time to self delete

<s​yntheticbird:monero.social> Did i just assisted to a suicide?

<s​yntheticbird:monero.social> rip elongated idr-2025

<l​eonarth_:matrix.org> #define BLOCK_FUTURE_TIME_LIMIT 7200 -- 2 hours in the future

<l​eonarth_:matrix.org> why do we need such long time buffer for block submission?

<n​oname-user0:matrix.org> 1000% this. im very much against this change.

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

<o​frnxmr:xmr.mx> Damn, noname has me responding to 5hr old msgs

<a​rticmine:monero.social> Which explains why Qubic is having so much trouble with their attack on Monero

<o​frnxmr:xmr.mx> Honestly, true

<o​frnxmr:xmr.mx> If we were a lesser chain, things may have spiraled out of control already

<v​tnerd:monero.social> Rucknium: added same value to checkpoints.vtnerd.com they are different servers

<v​tnerd:monero.social> Same value as tevador

<n​oname-user0:matrix.org> we should not ignore the possibility of a longer term reconfiguration of moneros consensus algorithm to prevent these types of attacks in the future.

<o​frnxmr:xmr.mx> Need to update the locations in the codebase and rebuild

<n​oname-user0:matrix.org> but short term the community and the coin network has done well

<o​frnxmr:xmr.mx> If i had a copy of the db, i could do the attack right now 🥲. Anybody have the data.mdb for testnet that they can upload? Plz n thx

<n​oname-user0:matrix.org> for nodes that dont make this change they might fork off so in a sense it is a hard fork but not in the traditional definition.

<o​frnxmr:xmr.mx> its not a hard fork, thats a chain split

<n​oname-user0:matrix.org> well you are inadvertently changing the consensus rule

<n​oname-user0:matrix.org> and mandating it rather than making it optional

<n​oname-user0:matrix.org> i should say explicitly changing the consensus rule from longest chain to must follow dns pulse checkpoint

<n​oname-user0:matrix.org> so that is a hard fork

<o​frnxmr:xmr.mx> And no, they would end up back on the healthy chain

<o​frnxmr:xmr.mx> Unless qubic has 51%, then the honest chain will become the longer one

<o​frnxmr:xmr.mx> So their nodes that reorg onto qubic, will end up being reorged back onto normal chain, and qubics blocks will be perm orphaned

<n​oname-user0:matrix.org> umm isnt that the whole point of what this is supposed to mitigate?

<o​frnxmr:xmr.mx> No

<n​oname-user0:matrix.org> you are just mitigating short term orphan chains up to x blocks?

<n​oname-user0:matrix.org> in a way, that could work

<o​frnxmr:xmr.mx> Particularly over 10, but yes, we coukd use for all of their selfish mining, ans theyd be wasting $

<n​oname-user0:matrix.org> as long as it clearly done as a band aid short term and communicated that way

<o​frnxmr:xmr.mx> Waste enough $ and theyll have to find a new hobby or honest mine

<n​oname-user0:matrix.org> I still think a longer term change needs to be planned and tested as well

<o​frnxmr:xmr.mx> Obv

<o​frnxmr:xmr.mx> But any longer term change would be too take if we allow them to orphan everyones blocks

<o​frnxmr:xmr.mx> Too late*

<n​oname-user0:matrix.org> I think this reddit post lays it out reddit.com/r/Monero/s/8rcdpbWAHB

<n​oname-user0:matrix.org> so your suggestion is a medium term solution

<n​oname-user0:matrix.org> whereas renting hash rate and turning on miners seems to be the only short term way to mitigate

<o​frnxmr:xmr.mx> Except its the fastest, shortest term solution

<o​frnxmr:xmr.mx> Global hashrate hasnt changed much, if at all, likely because rented hashrate is already mining monero

<o​frnxmr:xmr.mx> So it goes from mining monero -> mining monero

<n​oname-user0:matrix.org> interesting... why are so many people continuing to mine at a loss?

<n​oname-user0:matrix.org> or are the base electric loads for these data centres so low that it's break even or profitable?

<n​oname-user0:matrix.org> I surely turned on the few computers i have onto xmr the past week but it's only like 15kh

<r​ucknium:monero.social> ofrnxmr: Try this: 185.141.216.147/data.mdb (http only)

<o​frnxmr:xmr.mx> Thanks 🙏

<p​-q:matrix.org> Because as you already know you can‘t trust the q-shit and their statements. At least most people try to hold it up till halving / end of august / first aid on the reorgs

<b​awdyanarchist:matrix.org> Dude, I was under a mistaken impression, and the smartGuys here very quickly helped me understand what that mistake was. Now it's your turn.

<o​frnxmr:xmr.mx> Rucknium got it, thanks

<r​ucknium:monero.social> Syncs ok? Not corrupted?

<o​frnxmr:xmr.mx> Started up fine, no peers yet

<o​frnxmr:xmr.mx> Not corrupted