<o​frnxmr:xmr.mx> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) is it possible to store less records?

<o​frnxmr:xmr.mx> like, only the most recent one

<o​frnxmr:xmr.mx> The 525 checkpoint was invalidated by a reorg before it broadcast

<r​ucknium:monero.social> Yes. I can reduce it from 10 to 1.

<o​frnxmr:xmr.mx> Somehow spintered into 3 chains

<o​frnxmr:xmr.mx> testnetnode4.moneroconsensus.info stopped due to checkpoints (i'm mining to it now, to try to surpass the following)

<o​frnxmr:xmr.mx> testnetnode3.moneroconsensus.info shows 2 chains. One of them is the old/organic hashpower split off from the checkpoints. One of of them is my attacking chain, now in the lead

<o​frnxmr:xmr.mx> then i locally have a checkpointed node at height 534, somehow

<o​frnxmr:xmr.mx> The 534 node has 18 peers

<g​ingeropolous:monero.social> selsta, based on the bill i got so far, its possibly to bring the cost down by a factor of 8 perhaps. But its spot instances, so its not a guaranteed thing.

<g​ingeropolous:monero.social> from the top four rigs on MRR, they can somehow offer between 40 and 50 MH/s for $171 / hour

<g​ingeropolous:monero.social> or $3.70 per megahash-hour

<t​esttank:matrix.org> At those rates it would cost 17k to 51% attack Monero for 1hr 😭

<t​esttank:matrix.org> That’s nothing

<b​arthman132:matrix.org> Yep it’s simply too easy for an attacker to get 51% for monero unfortunately. The reality is that qubic is still a problem, even though they’re basically doing everything they can to sobotage their attempts. Like doing a halving, which caused the price of their coin to collapse. But what do I know I guess. people were calling me an idiot and clowning on me for basically saying<clipped mess

<b​arthman132:matrix.org> Qubic is still a threat and today proved that to be true

is the tl;dr that they had "could" have re-org'd +10 and they only published +9?

<b​arthman132:matrix.org> They still orphaned almost 10% of blocks today, They were definitely underreporting their actual hashrate.

It would not cost 17k to 51% for 1h because MRR does not have that much HR to rent

you would need to use cloud providers which is significantly more expensive even with spot instances

<b​arthman132:matrix.org> True, but let’s just say it’s 50,000 dollars to achieve it in reality. That’s still not very much tbh

it's more than 50k

It's more than 150k

per hour

800k/h, you can get the price down with spot pricing but not sure how much spot they have available

@midipoet: Yes that seems to be the case, - tl;dr: The standard 10 confirmations is clearly not enough if 40+% hashrate utilizes selfish mining.

and yes, you can see their current baseline hashrate on explorer.jetskipool.ai/xmr-tracker - it's less than 2 GH/s. Everything else is what their rent for a really short time, a few hours at most. They rent it, bring hashrate to 4+ GH/s when Monero network is naturally slower (less than 4 GH/s) due to the time of day, then they do the

reorgs. Last night the whole extra hashrate was not reported because it didn't go through the Qubic network (except the found blocks) - it connected directly to their Monero node.

They also found 4x more Tari blocks than supportxmr during that period, which is a good indication of their real hashrate.

Me and DataHoarder will prepare a long blog post about everything that happened in August, because some of the information can be made public now

<b​arthman132:matrix.org> Yeah sure their qubic hashrate is around 2, but if they can rent double that. Then 4gh/s is pretty close to 51% of the hashrate of monero

<b​arthman132:matrix.org> It’s just disappointing they can just rent that much hashrate, which makes their qubic pool hashrate less relevant

It also breaks their narrative that it's all Qubic miners doing the thing. No, it's cfb renting hashrate for PR stunts.

<b​arthman132:matrix.org> I mean yeah, but what do you expect? the dude is a serial scammer and only cares about the green. They have shown the capability to rent a huge amount of hashrate and that is a problem in itself that is not easily solved other than just hoping they run out of money or just stop, because it’s unprofitable.

<b​arthman132:matrix.org> Now I have seen numbers thrown around that to take over the monero network it would require 75 million per day by people like Charles Guillemet, so it seems up for debate how much it would cost to truely take over the network.

that number is to acquire the hardware

which, they don't

<s​hortwavesurfer2009:monero.social> I was in contact with the RetuSwap administrator and he asked me to ask Woodser if it would be a good idea to increase confirmations to say 30, which would put us at 60 minutes, which is the exact same as Bitcoin.

<s​hortwavesurfer2009:monero.social> My question is, would this have a bad effect on the ring signature output distribution since that is heavily weighted towards recent blocks?

<b​arthman132:matrix.org> Ah ok that makes sense.

<s​hortwavesurfer2009:monero.social> An exchange, especially, does not need reorganizations causing problems.

currently qubic could get 30 using the same methods.

they drop the alt chains beforehand, but that's them deciding to do so and not because they were losing the race then

yesterday on discord they were seeking confirmation from exchanges setting conf count high to achieve 10+ deep reorgs (not just chains of their own found blocks)

<s​hortwavesurfer2009:monero.social> That is so not comforting. The fact that they could have very well done 10 plus reorgas and only chose not to

<m​onerobull:matrix.org> alright guys, pack it up, PoW is dead. lets move to PoS

<m​onerobull:matrix.org> Asic mining ends in total capture as proven by bitcoin

let's make it an even easier economical capture :D

<m​onerobull:matrix.org> CPU mining ends in cheap rented hash available to attack whenever you got a bit of money to burn

<m​onerobull:matrix.org> DataHoarder, stalling PoS on monero would require ~2B dollars

<m​onerobull:matrix.org> thats a loooot more than 50k worth of hash

of the monero equivalent, adjusted for price depending rest of community

<m​onerobull:matrix.org> buying enough stake to attack a PoS system gets exponentially more expensive

<m​onerobull:matrix.org> i would have no problem staking XXX XMR

<m​onerobull:matrix.org> i do have a problem spending 20k on a mining rig that can be overpowered with $20 worth of rented hash

remember qubic has achieved enough hashrate to disrupt at times even without the direct rentals. that is coming from end users

<m​onerobull:matrix.org> just proves my point of PoW being dead

the specific long reorgs had further help from extra rented hashrate. but otherwise, just pay people doing PoS more

the ones with established stake

<m​onerobull:matrix.org> if you hold 100k in xmr stake, you are less likely to sell out to attack XMR than if you have a botnet with tons of hash that you need to turn into money as fast as possible before it gets dismantled

<m​onerobull:matrix.org> an attacker wouldnt be able to pay enough to offset the potential losses from an attack

<m​onerobull:matrix.org> with PoW the miner has no real incentive if he can just move on to a different chain

on different topics, here's hashrate of qubic calculated from two sample groups irc.gammaspectra.live/f822af98ab93c…/marathon_hashrate_net_vs_found.png

black line is calculated using all their submitted shares flowing via the qubic network. these account for 640M each

<m​onerobull:matrix.org> sure, a long term botnet operator should ideally be smart enough to realize attacking monero hurts long term profits but clearly cashing out quickly is more important to them

numbers match what their calculations are on their own sites

<b​arthman132:matrix.org> Yeah that is true, if a person gets 51% of stake in monero. Then they’re essentially hurting themselves, because their monero would lose a ton of value. Qubic miners don’t have this problem, because they get payed in qubic. So the success of monero is meaningless to them.

<m​onerobull:matrix.org> turns out, PoS means people actually have a STAKE in the network itself

the dotted blue line is using the solutions that would have found a block (maybe not specifically found one) against monero difficulty

this is bucketed in 1h intervals

over that peak they found 30 blocks, in a short span (within 20-30m). Calculating over an hour gives 30-32 found blocks, where they would have found 13.6 estimated based on 12365 samples for 640M diff solutions

this is what sech1 refers as extra hashrate

this was seen again later to produce reorgs, following the pattern of extra high difficulty solutions (not matching the rate of incoming general solutions) and get ahead 10, 15 blocks

then these would stop/slow down, and normal hashrate would be finding a couple of extra blocks as well while monero chain got longer. once it hit their threshold, they released their altchain, however long it was then

X/Y axis are shit cause can't bother adding more markers, these plots will get better over time :)

here's the same plot over the entire duration of gathered data for these past weeks irc.gammaspectra.live/32166ad311982a59/qubic_hashrate.png

buckets of 4h, same meaning of lines. black, difficulty calculated using 640M "shares". Dotted blue, using their "high difficulty" solutions that would have found a block (not all do, for different reasons)

I'll try to get better X/Y markets later, github.com/gonum/plot makes it a bit hard to get relevant ones easy

Some areas on plots above might not be entirely accurate as they disabled reporting solutions on the network for a while, when they were trying to do selfish mining a few marathons ago

<b​arthman132:matrix.org> Well how would the POS system work in your view?

<m​onerobull:matrix.org> how does PoS work?

<m​onerobull:matrix.org> we have the tech with zk proofs to do anonymous staking

<b​arthman132:matrix.org> Well not all pos are the same. Like would we adopt a minimum stake like ethereum or not

<m​onerobull:matrix.org> yeah

<m​onerobull:matrix.org> put it at the sui stack

<m​onerobull:matrix.org> 18.73

<m​onerobull:matrix.org> or higher if needed

<k​ayabanerve:matrix.org> I'd propose a stack difficulty where the stake unit increases/decreases to match a target amount of validators, personally

<k​ayabanerve:matrix.org> Part of that's in response to how we don't have any numbers on distribution/how many people will stake

<k​ayabanerve:matrix.org> (if we moved to a pos bft system)

<m​onerobull:matrix.org> i love dynamic stuff like that

<m​onerobull:matrix.org> AAVEs lending cost is dynamic like that and it seems to work very well

<k​ayabanerve:matrix.org> Eh, that target validators would be the constant

<k​ayabanerve:matrix.org> *the targeted amount of validators

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

<s​hortwavesurfer2009:monero.social> Bft? I know proof of stake

<k​ayabanerve:matrix.org> Byzantine-fault tolerant

<s​hortwavesurfer2009:monero.social> Ah

<k​ayabanerve:matrix.org> barthman132: I consider including a PoS BFT finality layer as moving to a system which incorporates PoS BFT

<b​arthman132:matrix.org> Well if you can include a finality layer with a pos that would be a good idea.

<k​ayabanerve:matrix.org> My comments apply even if we don't move "solely to"

<b​arthman132:matrix.org> Well you’re considering doing a finality layer with the current pow anyway I believe

<k​ayabanerve:matrix.org> I'm advocating for a PoS BFT finality layer on top of the current PoW-advanced blockchain

<k​ayabanerve:matrix.org> PoS BFT finality layer on top of a PoS (as in Zano)-advanced blockchain wouldn't really make sense.

<k​ayabanerve:matrix.org> You'd presumably just have the finality layer also handle block production.

<k​ayabanerve:matrix.org> If your consensus algorithm is leaderless, for efficiency reasons, you may still want to reduce the amount of potential blocks? Instead of validators agreeing on 1 out of 500 potential blocks, due to 500 different mempools, you have then agree on 1 out of 3 blocks by requiring any candidate block have valid PoW?

<k​ayabanerve:matrix.org> But that's just optimizing a leaderless consensus protocol with a form of pseudo-leader election.

<k​ayabanerve:matrix.org> But sure, there you could use PoW, a round robin, a Verifiable Random Function, or even just apply Zano's CT PoS and call it a day. The finality layer itself wouldn't care.

<b​arthman132:matrix.org> Makes sense to me. Would anyone be allowed to stake their coins or only miners?

<k​ayabanerve:matrix.org> Depends on what the community decides?

<k​ayabanerve:matrix.org> I don't believe such a limitation reasonable

<b​arthman132:matrix.org> Well if it’s only going to be miners. Wouldn’t we want the entry level into the stake to be low, because like 98% of miners wouldn’t be able to participate if we set the minimum amount like at 32 monero or something like that

<t​esttank:matrix.org> The point of keeping pow is decentralization but as we are seeing in literally every Pow coin just two pools end up with more the 51%. So what’s the advantage of keeping Pow?

<t​esttank:matrix.org> Distribution?

ideology

<t​esttank:matrix.org> Guess who mines the most Monero

<t​esttank:matrix.org> Botnetd

<t​esttank:matrix.org> Botnets

<s​yntheticbird:monero.social> oh hey i love botnets

<t​esttank:matrix.org> Isn’t the idea to make Monero unstoppable? Doesn’t seem like it

<b​arthman132:matrix.org> There’s no point at this point. If a coin like qubic can threaten us then the pow wasn’t very decentralized tbw. Hell supportxmr had 40 to 50 percent of the hashrate before qubic, so we weren’t very decentralized, even before qubic.

<k​ayabanerve:matrix.org> It means the blockchain continues even if the finality layer stalls.

<t​esttank:matrix.org> What do you think would be a fair reward split in a hybrid system?

<s​yntheticbird:monero.social> plowsof could we agree to be realistic for once and ban the trolls

<m​onerodevsareslow:synod.im> Mentally ill bird

<m​onerodevsareslow:synod.im> ACK waiting to happen

<s​yntheticbird:monero.social> lol

<s​yntheticbird:monero.social> it's been a while

<s​yntheticbird:monero.social> were you on vacation ?

<b​arthman132:matrix.org> And who are the trolls you’re referring to?

<s​yntheticbird:monero.social> monerodevareslow

<s​yntheticbird:monero.social> why do you feel concerned?

<s​hortwavesurfer2009:monero.social> Is there a chance we just have our dials set too low?

<s​hortwavesurfer2009:monero.social> In bitcoin 6 confs (60 mins) is suggested to consider a tx final

<s​hortwavesurfer2009:monero.social> Newly mined coins (coinbase txns) require 100 blocks ~16.5 hrs before they can be spent.

<s​hortwavesurfer2009:monero.social> That would equate to a 30 block lock and 495 lock on coinbase coins

<m​onerodevsareslow:synod.im> Anyone who is concerned about Monero. Ignore what mentally ill bird says. This ill person is dealing with personal issues and bird is close to ACKing. They want to censor any concerns about Qubic to prevent their feelings from taking over.

<s​yntheticbird:monero.social> this so much true

<m​onerodevsareslow:synod.im> I'm not your therapist.

<m​onerodevsareslow:synod.im> PoW isn't dead; Monero is. Any tangible solution to the 51% threat will take months to implement in the best case scenario including DNS checkpointnig. Qubic will be attacking during this time, so by the time a solution is found, Monero will be toast.

<m​onerodevsareslow:synod.im> This is why my username is "monerodevsareslow". All talk no action and it has been 2 weeks. Qubic is only increasing their power.

the longer chart for today's marathon, including known orphan qubic blocks irc.gammaspectra.live/313cd68a7b0b344d/marathon_monday.png

<b​arthman132:matrix.org> The qubic pool has lost hashrate, but they’re making up for it by buying hashrate for a couple hours when the monero hashrate is down a little bit.

<m​onerodevsareslow:synod.im> People are trying to cope by labeling Qubic as a Ponzi scheme or claiming that they're renting hash power. NONE OF THIS MATTERS! Regardless of the origin of their hash power, Qubic can still 51% attack Monero. @barthman132:matrix.org is correct.

<s​hortwavesurfer2009:monero.social> I'm aware that this would make the network slower but could potentially be solved at the user interface level by, for example, splitting one Monero into 10 0.1 monero chunks. This would have an effect on privacy until FCMP was released because you would be able to see that there was 1 in and 10 out, for example.

<j​ack_ma_blabla:matrix.org> their pool are being ddos'd so hashrate drops

the rented bursts do not go to their pools, so that's not relevant

compared to qubic or other places, monero is decentralized both in scope and well, ownership. someone can't just force upgrade everyone's nodes same day

<b​arthman132:matrix.org> Even still they’re massively disrupting the network and they almost got 10% of blocks orphaned, so even if they can’t achieve a 51% attack they’re massively damaging monero

<m​onerodevsareslow:synod.im> Who cares where they're getting their hash power from? The details of orphaned blocks are irrelevant. The fact that Qubic has already demonstrated its ability to reorganize 10+ blocks makes it clear. Monero is waiting for a solution, but one that won't come soon enough because the developers and community are complacent.

the DNS checkpointing seems to be what is the short term bandaid, and it's been tested in testnet over the past few weeks as well. As unhappy as I am as well about it not being there yet, releasing a broken system would bomb monero more than anything qubic can do

<m​onerodevsareslow:synod.im> I don't trust ofrnxmr the scammer

<s​yntheticbird:monero.social> we should have a botmoneroisovercirclejerk subreddit

<m​onerodevsareslow:synod.im> He is taking charge of DNS checkpointing with Rucknium from Nigeria

<m​onerodevsareslow:synod.im> Scammers are coming up with the DNS checkpointing solution. RIP MONERO

DNS checkpointing is in the code and has been there already

unrelated to any random beliefs you have about them

the current system is opt in, the move is to make opt out (?) and test rough edges with faster chekpointing, which was not designed for

<m​onerodevsareslow:synod.im> I'm talking about testing DNS checkpointing

<m​onerodevsareslow:synod.im> "it's been tested in testnet over the past few weeks" -> this is being lead by ofrnxmr and Rucknium

and everyone else, plus all testnet nodes, plus all the points of presence. you could also join in, and make your own altchains there

<m​onerodevsareslow:synod.im> How do I join in>

run a testnet node, it's open

there's no "appointed" tester, be glad you got someone to go through it this soon as otherwise in monero world it could indeed have taken months to reach consensus

<s​yntheticbird:monero.social> DataHoarder, why feeding the troll?

<s​yntheticbird:monero.social> he obviously do not care about your answer and your time

<m​onerodevsareslow:synod.im> Mentally ill bird shut up

<m​onerodevsareslow:synod.im> I'm going to run a testnode node now thank you DataHoarder

run monerod --testnet

<s​yntheticbird:monero.social> lmao

<m​onerodevsareslow:synod.im> 28080

i'd love to know how many qubic folk have joined this chat since this whole thing started. sometimes it feels like its +51%

<s​hortwavesurfer2009:monero.social> I just blocked the troll because I know that Monero will survive this.

<m​onerodevsareslow:synod.im> Is that the correct TCP port?

you want DNS checkpoint enforcing

also in that list

I think so

testnetnode4.moneroconsensus.info / testnetnode3.moneroconsensus.info etc. report altchains from their point of view

<m​onerodevsareslow:synod.im> <m​idipoet> I'm not a Qubic troll mentally ill bird can even confirm

you probably want to run a recent version from github.com/monero-project/monero but unsure exactly if any specific changes have been made on monero itself yet, I think all were done around DNS infrastructure

add --enforce-dns-checkpointing to test them being enforced

12:47:57 <m-relay> <s​yntheticbird:monero.social> DataHoarder, why feeding the troll?

at least the information on joining testnet and observing testing ongoing is probably useful for more people

on that topic, I should bring up my testnet node as well :)

<p​rivacyx:monero.social> Isnt the dns checkingpoint already available i recall i have it enabled in my monerod conf

yes

it's just opt out, and it had not been tested with this cadence

opt in*

by default it only notifies users

<p​rivacyx:monero.social> Oh

<s​hortwavesurfer2009:monero.social> What cadence was it tested with and what cadence is it being tested with now?

here's the original design and purpose of this system docs.getmonero.org/infrastructure/monero-pulse

it's designed to fix consensus forks, not normal reorgs. so maybe one specific block if any bug arises

the cadence from what I saw on above posts on this channel was every 5-10 blocks regularly, which for that, DNS TTL was brought down to 5 minutes instead of hours

<s​hortwavesurfer2009:monero.social> Thanks

I see 1800 seconds on available ones so maybe they are testing with different DNS endpoints currently, but it was discussed if you want to search on matrix history or via libera.monerologs.net

(here and in lab channel, but lab is not for casual discussion)

<s​hortwavesurfer2009:monero.social> Yeah, I was looking for this channel earlier and stumbled upon a lab at first and realized that was definitely not the right place.

<s​hortwavesurfer2009:monero.social> The lab*

<m​onerodevsareslow:synod.im> Monero will switch to PoS if the research CCS is successful and the Monero community educates itself. Only a stupid minority support keeping PoW. Unfortunately, the time required to implement PoS is its only major disadvantage.

Yeah. Sadly that time is longer than shorter

There's still people on previous hardforks in p2pool network I see regularly

or people with versions from 2 years ago

they just never check back on it, even upgrades announced with 6 months ahead notice get people stuck behind

<m​onerodevsareslow:synod.im> Quantum hard fork is going to be interesting then...

<s​hortwavesurfer2009:monero.social> If I remember correctly, it's recommended in the P2 pool configuration sections to turn off DNS checkpointing, which seems kind of odd to me.

<p​rivacyx:monero.social> Real its not showing on my end i got it turned on

<p​rivacyx:monero.social> Reallly its not showing on my end i got it turned on

that has changed now, shortwave

in the past DNS lookups blocked the main thread so tx verification was slower

<s​hortwavesurfer2009:monero.social> ./monerod 2 Dashzmq-pub tcp: 2 Slash127.0.0.1:18083 2 Dashout-peers 32 2 Dashin-peers 64 2 Dashadd-priority-node=p2pmd.xmrvsbeast.com:18080 2 Dashadd-priority-node=nodes.hashvault.pro:18080 2 Dashdisable-dns-checkpoints 2 Dashenable-dns-blocklist

that caused delay in block propagation

<s​hortwavesurfer2009:monero.social> From p2pool.io/#help

that was fixed in monero before this, but sech1 has not updated that recommendation yet

I brought this up in #monero-dev

<m​onerodevsareslow:synod.im> Is sech1 still trying to downplay Qubic?

<m​onerodevsareslow:synod.im> on Discord

when? I don't think he would, he has the same data and visibility as I did on them :)

<m​onerodevsareslow:synod.im> CFB sent me a screenshot of sech1 claiming that the Qubic hashrate is fake, stating that he had successfully attacked them somehow. He hasn't spoken much since then, so I suppose it's just more cope.

<p​rivacyx:monero.social> So does dns checkpointing have any effect on pools attempting selfish mining?

a note on that, we also did some trolling back :)

<m​onerodevsareslow:synod.im> I think he posted this in the Monero Discord.

the sech1 backdoor is totally imaginary

<m​onerodevsareslow:synod.im> Okay CFB took it seriously.

no, he takes anything to use as an excuse

<l​ordx3nu:matrix.org> No he didn't lol

that "fake" 2GH/s that showed up a few marathons ago, was real, just suppressed

CfB learned and no longer shows it when renting and just mines to nodes directly

<m​onerodevsareslow:synod.im> Thanks for clarifying

13:08:11 <m-relay> <p​rivacyx:monero.social> So does dns checkpointing have any effect on pools attempting selfish mining?

it prevents deep reorgs

they probably can still do a couple reorgs, depending on parameters. but what is trying to get fixed is the ability to do deep reorgs to double-spend

note that orphaning of blocks happens even during normal conditions

<s​asha:monero.social> Im intecested in understanding how discussion around workshares progressed. Did it actually go anywhere?

<p​rivacyx:monero.social> Yea but around 3-4 ?

also @lordx3nu:matrix.org x.com/xenumonero/status/1960117361240838241 I am active around these lands, but what is a member of MRL mean? I don't think I'm one :D

<s​asha:monero.social> Im interested in understanding how discussion around workshares progressed. Did it actually go anywhere?

depends on parameters privacyx, also note blocks could come quick. the checkpoints could be set to a previous block, then that could cover it. I would suggest you check the history on this room to see what specific times they are testing

<m​onerodevsareslow:synod.im> <D​ataHoarder> Orphaning typically occurs under normal conditions, but the orphan rate exceeds 10% over a 24 hour period only if a malicious mining pool chooses to engage in selfish mining. This does not happen normally

checkpoint flag bandaid applied on my test/main net nodes 🩹

<p​rivacyx:monero.social> xenu: i worked how to p2pool on mrr

correct, just mentioning that 1/2 orphan chains can just be normal

the higher rate of occurrence, not

as plowsof did you can do your part and opt-in to enforcing DNS checkpoints on nodes you run, if you want to be prepared if/when this system is to be used

this exists on monerod today, just opt-in by default

<s​hortwavesurfer2009:monero.social> Would you recommend me going ahead and enabling enforce DNS checkpoints on my mainnet node? I mine p2pool with it and use wallet rpc over tor for monero.com on my phone

feel free, should not add any latency nowadays according to sech1

at least you can remove the --disable, so you will get notified only (but not enforced)

<s​hortwavesurfer2009:monero.social> K

<p​rivacyx:monero.social> I have enabled and mine p2pool

<p​rivacyx:monero.social> No issues

<m​onerodevsareslow:synod.im> There are three valid proposals:

<m​onerodevsareslow:synod.im> * Implementing a full PoS finality layer, which should be a long-term goal taking years to research and implement.

<m​onerodevsareslow:synod.im> * DNS checkpointing as a temporary solution, currently being tested and showing promising results. Anyone can run a testnode to see how it works.

<m​onerodevsareslow:synod.im> * Tevador's proposal to modify the PoW in the mid-term, which hasn't been discussed much recently due to distraction from other proposals, such as Detective Mining submitted by fluffypony the fed. This is flawed and wouldn't work because Qubic can simply make its pool inaccessible.

<s​hortwavesurfer2009:monero.social> Cool. Will enforce them then

<p​rivacyx:monero.social> 👍

The detective/pow changes is around preventing overt selfish mining, not hidden indeed. Then there are suggestions to mix other partial pow into what monero has

<l​ordx3nu:matrix.org> Sorry datahoarder I didn't know how else to refer to you lol. I can issue a correction if you'd like

I don't recollect hearing any sort of consensus there, just, ideas come up and they tend to fail or introduce other errors

feel free to have me as a "regular" :D

or note that I run the p2pool observer, if that has more weight

<l​ordx3nu:matrix.org> Yeah there are some reliability issues (my internet not being reliable, mostly) that make this not a good option.

<b​arthman132:matrix.org> The qubic marathon is almost over for now at least

<l​ordx3nu:matrix.org> Some rigs don't really play nice with p2pool as well

they stopped doing selfish this marathon quite some hours ago

<p​rivacyx:monero.social> Note some rigs failed with p2pool

you probably want to set fixed difficulty with them :)

<s​hortwavesurfer2009:monero.social> Okay, I now have enforced Dines Checkpointing enabled.

<p​rivacyx:monero.social> Not sure why so i just asked for refund

<s​hortwavesurfer2009:monero.social> Dns*

<p​rivacyx:monero.social> Yes I did that but still failed it was only rig

<s​asha:monero.social> Im no dev, but workshares seem like a pretty interesting option. Its strange to me that its not being considered. Would love to know why not.

<m​onerodevsareslow:synod.im> WRONG. CFB said that Qubic will run marathons 3 times a week for at least four months. They will not stop until Monero is 51% attacked, after which they will redirect their focus towards another chain, such as DOGE, in pursuit of a better marketing reach.

<m​onerodevsareslow:synod.im> We're short on time.

<b​arthman132:matrix.org> I meant temporarily.

<p​rivacyx:monero.social> This why we need plug this up urgently

<m​onerodevsareslow:synod.im> Okay sorry I thought it was cope again.

<m​onerodevsareslow:synod.im> Every single day that passes without implementing a solution, the likelihood of a 51% attack on Monero increases.

marathons as of their code, run 12 to 12 UTC on Mondays, Thursdays, Saturdays

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

good enough :)

I think I underestimate the data I bring sometimes but better to err on the side of caution

<b​arthman132:matrix.org> One thing I think helps us is that they’re moving on to dogecoin, so they’re not planning on mining monero for the long term at least

<m​onerodevsareslow:synod.im> It really doesn't. Their moving to DOGE only after 51% attacking Monero.

when monero changed to RandomX, that took a few months and there was an actor mining 80-90% then 24/7 in secret

<l​ordx3nu:matrix.org> Yeah no problem, sorry about that. By the way, I have some data from rigs I was renting during the major reorgs. I could send that your way.

<s​hortwavesurfer2009:monero.social> Still something we definitely need to fix. If they were able to do it, that means a state actor would be able to do it.

<m​onerodevsareslow:synod.im> <D​ataHoarder> Bitmain != Qubic

<s​hortwavesurfer2009:monero.social> And a state actor would not limit themselves to a nine block reorganization. They would be wanting to purposely kill the network.

correct. Qubic is overt and actively wants to do this

<m​onerodevsareslow:synod.im> Qubic will 51% attack Monero and orphan all blocks for show. I doubt they will double spend. That's the best case scenario if we keep waiting.

<b​arthman132:matrix.org> CFB is no state actor and have done things like a halving that wouldn’t make any sense for a state actor to do

remember, their halving doesn't matter much, cfb can just pay up. It's again based on marketing hype, moving to more news, etc.

<b​arthman132:matrix.org> It just shows that he is doing small things that wouldn’t make any sense for a state actor to do.

<m​onerodevsareslow:synod.im> I think surfer is saying this attack shows state actors how easy it is to ruin Monero. About the halving, Qubic is not a blockchain at all. It's fully centralized and their tokenomics can change if CFB decides to.

PR is what they are good at as well, that is the part that is ruining it better than anything

<b​arthman132:matrix.org> Agreed if CFB was a state actor, they likely would have been able to pull off a 51% attack already

<m​onerodevsareslow:synod.im> Qubic has "ticks" instead of "blocks".

state actors would just ... go straight for 90%, kill it, reorg everything in secret

they have been able to do 51%, specially when boosted

<m​onerodevsareslow:synod.im> @boog900:monero.social Does cuprate impl support the checkpoint flag?

<b​arthman132:matrix.org> Yeah, but the state actors know that eventually keeping the price of monero will enable somebody to eventually do a 51% attack on the monero network without the direct intervention of the state. I think that’s a big reason why monero has been delisted by so many exchanges. It’s a way to suppress the price and eventually somebody will take monero down

<s​hortwavesurfer2009:monero.social> Is there a way to distribute Monero Pulse DNS checkpoint records over an onion or I2P domain? Because I noticed that while there are several domains at several different registrars, the state could still just demand them be taken down.

<s​hortwavesurfer2009:monero.social> .se, .org, .net, and .co

these depend on DNSSEC signatures

so you could broadcast them

I don't think there's any other distribution method currently, maybe P2P signed messages could be used, but that brings another attack vector

<b​oog900:monero.social> No

<s​hortwavesurfer2009:monero.social> One thing I could possibly see going wrong with that if you could distribute it over an onion or I2P site would be if the onion and I2P had a different record for some reason from the clear net ones, and so the clear net nodes that only saw the clear net domains were on one fork and the other nodes that were using the onion addresses were on a different one.

only checkpoints where all sources agree are used

<s​hortwavesurfer2009:monero.social> Ah, ok

<m​onerodevsareslow:synod.im> DNS checkpointing is only temporary. I doubt the state will attack within the next few months until a robust mid-term solution is implemented.

<s​hortwavesurfer2009:monero.social> And even if your system is totally using Tor for everything, your system can still contact the ClearNet through Tor to query the ClearNet domains, whereas somebody on the ClearNet could not query the onion domains without Tor.

it's effectively repurposing a feature that exists for a bandaid

<m​onerodevsareslow:synod.im> I don't get the people who support opt out DNS checkpointing but not PoS.

<m​onerodevsareslow:synod.im> @preland:monero.social Especially you.

<s​asha:monero.social> I would expect that suffciant funds could be raised to get help from those who designed it.

raising funds for, DNS checkpointing?

the code is there already, it's changing meaning/cadence these would get published

<m​onerodevsareslow:synod.im> No workshares idea.

thanks lack of threading on IRC

<m​onerodevsareslow:synod.im> qu.ai/blog/proof-of-work-innovation-workshares

on that topic, maybe I should just deploy the "totally not prod ready" new bridge that has been running flawless for the last 6 months+ on p2pool channels

<s​yntheticbird:monero.social> YES

<s​yntheticbird:monero.social> YES

<s​yntheticbird:monero.social> YES

<s​yntheticbird:monero.social> PLEEEEEAAAASSSSSSSEEEEEEEEEEEEEEEE

unknown if it's matrix delays or you are just excited :)

<s​yntheticbird:monero.social> IM EXCITED

<s​asha:monero.social> Thanks for sharing that

<m​onerodevsareslow:synod.im> The price of Monero is not supressed. It's already hovering around $5 billion. Overpriced if you ask me

<m​onerodevsareslow:synod.im> (marketcap)

<s​hortwavesurfer2009:monero.social> Here's a question. What is the difference between Monero Pulse DNS checkpointing and a new release? Because I'm almost certain that each new release of the Monero daemon does some sort of checkpoint where it won't go any farther back than that.

<s​hortwavesurfer2009:monero.social> From just a simpleton point of view, it seems like the only difference would be the cadence.

<s​yntheticbird:monero.social> yes

<s​yntheticbird:monero.social> You won't release a new monerod version every 60 minutes

<s​yntheticbird:monero.social> you need a more streamlined approach

monero checkpoints are intended to speed up sync

and prevent very deep reorgs (years old)

monero pulse was originally designed to dynamically fix any discovered consensus fork (not orphaning altchains), but due to these being able to pop up anytime, they had to be dynamic

<s​hortwavesurfer2009:monero.social> So i assume cuprate will do a checkpoint upon their releases too. So then you would have staggered ones between monerod and cuprate where one could be more recent than the other

<m​onerobull:matrix.org> agreed. if you are already doing DNS checkpoints, you might as well go pos, it would be more decentralized

<b​arthman132:matrix.org> Idk about that. It is impressive that monero has the market cap that it still does, but being delisted from most exchanges does definitely hurt its market cap. Monero price has stayed pretty consistently 150 to 300 for many years now, so saying it’s overpriced is a sentiment I don’t share. The fact is people buy monero for a lot of reasons, because it provides a use that norma<clipped mess

<b​arthman132:matrix.org> l crypto simply cannot fill.

<m​onerobull:matrix.org> serai will set us free

<m​onerobull:matrix.org> the network itself is definitely worth 5B, seems very fairly valued tbh

<m​onerobull:matrix.org> just look at it through the lense of a company

<b​arthman132:matrix.org> If anything i would argue that it is undervalued, but that’s just my opinion.

<s​hortwavesurfer2009:monero.social> Here we are worried about 10 block reorganizations and the weed dealer on the darknet doesn't give a shit because it takes them a lot longer to get the product out in the mail anyway.

<b​arthman132:matrix.org> The average weed dealer on the dark web doesn’t even know what’s happening

<s​hortwavesurfer2009:monero.social> Exactly, they are totally unaffected by any of this.

But it is a problem if you run an exchange

<m​onerobull:matrix.org> yeah, the admins would just up conf times

<b​arthman132:matrix.org> Yeah, which is why a lot of exchanges have stopped monero deposits

But they can't put extra confs on withdrawels, which put them in a bit of a legal dilemma

<m​onero.arbo:matrix.org> PoW only ever guaranteed attacks were, within the system, unprofitable. PoW is working as intended. If anything, we get more hashrate then we should for our security budget. The problem is the low security budget relative to the size of the network which is a function is a bad emission curve that we can no longer change. The security budget for XMR is only, at present $113,000 dai<clipped mess

<m​onero.arbo:matrix.org> ly to secure a nearly $5 billion dollar coin. Other big PoW chains aren't in such a predicament because they followed reasonable emission curves. Price going up won't actually fix this, as the ratio between network size and emissions remains fixed at any price.

<s​hortwavesurfer2009:monero.social> It's just kind of ironic that the off-ramps and on-ramps, via exchanges, etc., are totally affected by this, and yet the peer-to-peer economy is barely affected at all.

<s​yntheticbird:monero.social> quick and easy solution: "multiply the block reward by 200x" 👍️👍️👍️👍️👍️👍️

<m​onerodevsareslow:synod.im> monerobull you're much smarter than xenu

<m​onerodevsareslow:synod.im> Copyright © 2023 Serai DEX

<m​onerodevsareslow:synod.im> I was looking at Luke's commits and it looks like he already forgot what he coded. It will take at least another year.

<s​hortwavesurfer2009:monero.social> What we are experiencing now is the exact same thing that's going to happen to Bitcoin once their block reward falls over the next several having cycles.

<m​onero.arbo:matrix.org> at least Bitcoin has a fee market

<m​onerobull:matrix.org> i have sold a large portion of my stack because i have a feeling it will only get worse before the people here finally realize that PoW is dead.

<m​onerodevsareslow:synod.im> I won't entertain any further price discussion as this is the wrong channel and I don't want plowsof to kill me.

<m​onero.arbo:matrix.org> PoW isn't dead, bad emission curves are dead

<m​onerobull:matrix.org> the situation wouldnt be much different with higher inflation

<m​onero.arbo:matrix.org> We'd literally be in a 10x better position at least if we followed the BTC emission curve

<m​onerodevsareslow:synod.im> I also sold using BSX so I'll give ofrnxmr the scammer where credit is due. He let me exit Monero. I think people will finally wake up and stop listening to articmine's ridiculous rants once Qubic starts 51% attacking and all blocks are controlled by them.

<b​arthman132:matrix.org> Monero hashrate has doubled from 2023 to now, but it’s still simply too low to be a significant deterrent.

<m​onerodevsareslow:synod.im> PoS fixes the problem.

<s​yntheticbird:monero.social> Welcome ofrnxmr to the PoS circlejerk channel

<m​onerobull:matrix.org> im still unsure if hybrid pos/pow is more secure than pure PoS, anyone got insights?

<m​onerodevsareslow:synod.im> Mentally ill bird why are you still here?

<m​onero.arbo:matrix.org> PoS will result in a chain split 100%, aside from all the new problems it creates

<o​frnxmr:monero.social> thx for ping, bebe

<m​onerodevsareslow:synod.im> GO WORK ON CUPRATE YOU LAZY DEV

<m​onerobull:matrix.org> if you have enough money to attack the PoS chain, you will have more than enough to attack the PoW chain or am i wrong?

<m​onerobull:matrix.org> especially since hash is basically just PoS as long as massive amounts can be rented cheaply

<m​onerodevsareslow:synod.im> Yes and Monero-PoW will turn into ETH-classic. Irrelevant as PoS takes over.

<o​frnxmr:monero.social> Jeez, yall really making us use DMs

<m​onerodevsareslow:synod.im> Why are you supporting botnets and ruining the environment?

<m​onerodevsareslow:synod.im> All because articmine said so? He knows nothing

<m​onero.arbo:matrix.org> Eth Classic didn't originate from ETH going PoS, EthPoW did, but the difference is Eth always had PoS in the roadmap

<m​onerobull:matrix.org> ive supported botnets right up to the point that they demonstrated their operators are retarded and not thinking of the long term

<m​onerodevsareslow:synod.im> When ETH switched to PoS classic gained short term resurgence as miners switch then it fell off immediately.

<m​onerobull:matrix.org> and moneros whole ethos is "change to improve"

<b​arthman132:matrix.org> The main advantage of POS is that the people who own stake in pos have an incentive to not do a 51% attack themselves. If a person gets a 51% in a pos the monero they hold lose lots of value, because their monero would be worth a ton less. That’s not the case with an actor like qubic, because qubic miners are paid in qubic and as such their effects on the monero network are irrelevant to the

<m​onerobull:matrix.org> if PoS is better at securing the network than PoW, monero shoudl move to PoS

<m​onero.arbo:matrix.org> then let's change the emission curve

<m​onerodevsareslow:synod.im> PoW is not sustainable

<o​frnxmr:monero.social> It's not

<o​frnxmr:monero.social> You cant undo that >100kxmr were mined in the first 3 days

<s​yntheticbird:monero.social> the if is what is hard to prove

<m​onero.arbo:matrix.org> I'd support 50% merging with LTC waaaaaay before I could support going PoS

<m​onerobull:matrix.org> while id agree that a percentage based tail emission would be better than a static one: no that is insane. economics is the one thing you cant touch.

<m​onero.arbo:matrix.org> nope, can only change the current inflation rate without rebooting the network

<s​asha:monero.social> arxiv.org/abs/2503.10185 this liks to a paper on workshares

<m​onero.arbo:matrix.org> "change to improve"

<m​onero.arbo:matrix.org> "no not like that!"

<s​yntheticbird:monero.social> lmao

<m​onerobull:matrix.org> lzya its completely different if you touch the economics

<o​frnxmr:monero.social> this doesn't "fix" anything

<m​onerobull:matrix.org> that breaks teh entire social contract

<m​onerodevsareslow:synod.im> How?

<o​frnxmr:monero.social> by changing some lines of code

<o​frnxmr:monero.social> Making tail emission 50xmr

<m​onerobull:matrix.org> merge mining is not an option either

<m​onerodevsareslow:synod.im> No I mean in what way

<m​onerobull:matrix.org> neither asics nor randomx work in the world that we now live in

<o​frnxmr:monero.social> increasing inflation will 100x the market cap /s

<m​onerodevsareslow:synod.im> This is the stupidest idea I've ever heard. Bitcoin has an emission rate of over $50 million per day and the top 2 pools almost control 51% of the hash rate. All they need to do is collude and they can affect Bitcoin the same way Qubic is affecting Monero.

<m​onerobull:matrix.org> the only logical solution is PoS, maaaaaybe PoS/PoW hybrid but not really

<m​onerodevsareslow:synod.im> Full PoS. Hybrid adds complexity and Monero is already complex enough...

<m​onero.arbo:matrix.org> Guys. Guys. My point wasn't that I actually want to change emissions. It was that "change to improve" as an argument to ignore significant schisms within the community around changing core propositions of Monero is umm, not a good one

<b​arthman132:matrix.org> I think kayabaNerve solution makes the most sense and it’s the best proposed solution right now

<m​onero.arbo:matrix.org> PoS is as much of a non-starter as changing emissions

<m​onerobull:matrix.org> ive said it before, i can put up XXX XMR of stake. I will never buy a $20k mining rig that gets out-hashed by spending $20 on renting hash.

<m​onero.arbo:matrix.org> all you get from going PoS is two coins, we really don't want a contentious fork

<o​frnxmr:monero.social> Ok, i agree with you

<m​onerobull:matrix.org> yeah it keeps the PoW diehards happy even though its cope

<m​onerodevsareslow:synod.im> Who cares. We can let the market decide which one will survive.

<m​onerodevsareslow:synod.im> If Monero sticks with PoW I'm switching to Zcash

<s​hortwavesurfer2009:monero.social> I would be somewhat open to a proof of stake solution, but only after we've done literally everything we can to improve proof of work first. If that is the case and we literally cannot figure out any way to make it work, then I would support going proof of stake.

<m​onerodevsareslow:synod.im> At least they're smart enough to use PoS

<m​onero.arbo:matrix.org> you are not a serious person bruh stop trolling

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

<m​onerodevsareslow:synod.im> Lyza you're a nobodyuu

<m​onero.arbo:matrix.org> if you really wanna push PoS at least make a concrete proposal, go code something, damn

<m​onerodevsareslow:synod.im> PoS is supported by 99% of people except a vocal minority and articmine

<m​onerobull:matrix.org> shortwavesurfer2009: can you really ever make PoW a secure system if the majority of compute on this planet is held by a few US companies?

<o​frnxmr:monero.social> Says the nym..

<s​hortwavesurfer2009:monero.social> Time weight ala bawdys proposal appears to be sensable with research

<o​frnxmr:monero.social> Honestly "monerodevsareslow"

<m​onerodevsareslow:synod.im> Says ofrnxmr with his sockpuppets

<m​onerodevsareslow:synod.im> Who says I'm not doing that already? You don't know who I am

<o​frnxmr:monero.social> I came here to collaborate on some bugs found during dns checkpoint testing

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

<o​frnxmr:monero.social> And im met with spam

<m​onero.arbo:matrix.org> you're sure not doing it right now, right now you're too busy trolling to be coding anything

<m​onerodevsareslow:synod.im> Zcash has PoW right now

<m​onerobull:matrix.org> PoS has bad rep because of how other projects used it as a de-facto dev tax

<s​yntheticbird:monero.social> we lack moderators in this channel

<m​onerodevsareslow:synod.im> Which is why they're switching to PoS

<m​onerobull:matrix.org> monero has been around for 14 years

<s​yntheticbird:monero.social> and also lack the balls to ban trolls

<s​yntheticbird:monero.social> somehow

<o​frnxmr:monero.social> 11?

<m​onero.arbo:matrix.org> 11? 2014?

<m​onerobull:matrix.org> kek sorry

<m​onerodevsareslow:synod.im> I'm running a testnode node for DNS checkpointing and you're doing nothing about Cuprate

<s​yntheticbird:monero.social> bait harder

<m​onerodevsareslow:synod.im> You're the troll who only comes around to dictate what people can or cannot say

<o​frnxmr:monero.social> what block is your node on

<m​onerodevsareslow:synod.im> I'll DM

<o​frnxmr:monero.social> And are you running my patch?

<m​onerodevsareslow:synod.im> Screenshot and more

<m​onerodevsareslow:synod.im> Don't dox me ofrn

<m​onerodevsareslow:synod.im> I already have your voice remember

<o​frnxmr:monero.social> my voice is on youtube, champ

<s​yntheticbird:monero.social> he means my voice

<o​frnxmr:monero.social> And in your moms whatsapp voice notes

<m​onerodevsareslow:synod.im> These are the arguments against PoS

<m​onerodevsareslow:synod.im> Insults

<b​arthman132:matrix.org> It really isn’t unfortunately. We have the minority position in the community

<m​onerodevsareslow:synod.im> I'm talking about the people who drop 100s of XMR on CCS proposals. Not only devs

<o​frnxmr:monero.social> Seriously lol. Most devs ive spoken to, especially in private, are leaning against pos

<m​onero.arbo:matrix.org> why would somebody spend time re-hashing the same tired arguments from 5+ years ago with you, of all people

<b​arthman132:matrix.org> It’s still pretty split their too

<m​onerodevsareslow:synod.im> If Luke's research proposal goes through, look how fast it will get funded

<s​yntheticbird:monero.social> Your "seriously" point will soon be burden under 30 metric ton of trolling bullshit

<s​yntheticbird:monero.social> thanks for participating in this discussion

<m​onerodevsareslow:synod.im> Just send me a blog post that's convincing. I've seen the arguments already and they're all shit

<m​onerodevsareslow:synod.im> And/or research report

<m​onero.arbo:matrix.org> I'm not wasting time on obvious trolls bro

<b​arthman132:matrix.org> Look I support Luke’s proposal, but I wouldn’t say it wouldn’t be controversial

<m​onerodevsareslow:synod.im> No arguments

<m​onerodevsareslow:synod.im> ethereum.org/en/developers/docs/consensus-mechanisms/pos/pos-vs-pow

<m​onero.arbo:matrix.org> "You won't even debate me!" the chorus of trolls everywhere

<m​onerodevsareslow:synod.im> For anyone interested in why PoS is actually better

<s​yntheticbird:monero.social> shortwavesurfer2009: is the smartest of us all for muting him

<m​onerodevsareslow:synod.im> I was being sincere. I really don't care anymore.

<m​onerodevsareslow:synod.im> PoS will win and you'll either have to switch or stick to the irrelevant PoW chain

<m​onero.arbo:matrix.org> ok chief

<s​hortwavesurfer2009:monero.social> I just don't feed trolls.

<s​yntheticbird:monero.social> I'm mentally ill they says, i can't help myself feeding them

<m​onerodevsareslow:synod.im> ofrnxmr node is on block 2820193 orphaned

<s​yntheticbird:monero.social> no one cares

<m​onero.arbo:matrix.org> I remember selling half my ETH for BTC when it went PoS at 0.068 BTC/ETH lol

<o​frnxmr:xmr.mx> I'm not attacking testnet right now

<m​onerodevsareslow:synod.im> 2820193 had 0 txs

<o​frnxmr:xmr.mx> The checkpointing node creashed

<m​onerodevsareslow:synod.im> Where is your patch?

<m​onerodevsareslow:synod.im> github.com/nahuhh

<m​onerodevsareslow:synod.im> I can't find it on your gh

<m​onerodevsareslow:synod.im> It really isn't. Your listening to a vocal minority

<m​onerodevsareslow:synod.im> Just wait for Luke's proposal to go into funding. You'll see how quick 200 XMR will be dropped

<o​frnxmr:monero.social> Its not on github

<o​frnxmr:monero.social> Its in this room somewhere

<m​onerodevsareslow:synod.im> I'll look for it

<b​arthman132:matrix.org> Look I have no doubt that it would be funded, but saying switching to something other than POW wouldn’t be controversial is not going to happen. I actually support the research, but I just want to be realistic on what solution we can go towards.

<s​yntheticbird:monero.social> good boy

<s​yntheticbird:monero.social> obey to ofrnxmr the scammer from nigeria or whatever you said

<p​reland:monero.social> The fuck did I do?

<m​onerodevsareslow:synod.im> You did not support Luke's proposal for research into PoS

<m​onerodevsareslow:synod.im> Finality layer

<m​onerodevsareslow:synod.im> on Gitlab

<b​arthman132:matrix.org> Well Luke’s proposal is more of a hybrid than pure pos

<m​onerodevsareslow:synod.im> His research will cover multiple options

<m​onero.arbo:matrix.org> people holding the most XMR would benefit the most from PoS so we will not be voting by how much somebody can pay to get their way

<o​frnxmr:monero.social> Why are yall in _research lounge_v

<o​frnxmr:monero.social> This is like, general chat, or telegram tier

<p​reland:monero.social> This

<m​onerodevsareslow:synod.im> I seriously don't care anymore. Working on DNS checkpoint right now

<b​arthman132:matrix.org> Just like pow. The whales get the largest share and that’s always going to be the case no matter what solution we come up with

<s​yntheticbird:monero.social> "working"

<m​onerodevsareslow:synod.im> I blocked the other mentally ill bird

<m​onerodevsareslow:synod.im> Spamming the chat

<s​yntheticbird:monero.social> he didn't

<p​reland:monero.social> The reason I didn’t is because of something I’m working on personally

<p​reland:monero.social> Nothing against kayaba’s idea;

<m​onerodevsareslow:synod.im> ofrnxmr What is this? What did you mean by this should do it?

<m​onerodevsareslow:synod.im> ```{"errcode":"M_MISSING_TOKEN","error":"Missing access token"}```

<m​onerodevsareslow:synod.im> `{"errcode":"M_MISSING_TOKEN","error":"Missing access token"}`

<o​frnxmr:xmr.mx> More logs

<o​frnxmr:xmr.mx> Whats that from? Matrix? Doesnt look like a monero error

<m​onerodevsareslow:synod.im> Maybe I downloaded dns_testpoints.diff is that supposed to be the patch?

<m​onerodevsareslow:synod.im> I think it's a Matrix error because the size is only 1kb and it's supposed to be 3.1kb

<o​frnxmr:xmr.mx> Rip matrix

soon(TM)

<m​onerodevsareslow:synod.im> matrix.monero.social/_matrix/media/…oad/xmr.mx/XgfLqvSEKYzhbWeyvXidzgfS

next marathon is Thursday.

<m​onerodevsareslow:synod.im> Definitely an error from Matrix this was the original patch

<m​onerodevsareslow:synod.im> Can't fetch it

IRC to the rescue irc.gammaspectra.live/9583593fbcd47748/dns_testpoints.diff

<m​onerodevsareslow:synod.im> Thank you <D​ataHoarder>

<m​onerodevsareslow:synod.im> <D​ataHoarder> Why does Qubic's hashrate suddenly drop to 0 H/s? CFB says it's due to DDOS attacks from sech1 and others

lol

they are out of marathon

they mine 24h

<m​onerodevsareslow:synod.im> What?

then it goes into 676 ticks of mining XMR

<b​arthman132:matrix.org> They stopped their marathon until Thursday

then 676 of mining their own thing

<m​onerodevsareslow:synod.im> Oh okay

+2 in one of them, can't remember

> CFB says it's due to DDOS attacks from sech1 and others

remember half is lies other half is trolling with truth

<m​onerodevsareslow:synod.im> explorer.qubic.org/network/tick/31804106

<m​onerodevsareslow:synod.im> Is it possible to tell what tick is mining what?

<m​onerodevsareslow:synod.im> From their explorer I can only see transactions for each tick

? ticks don't mine

yeah, not that straightforward. blogpost at some point :)

<m​onerodevsareslow:synod.im> 676 ticks of mining XMR then 676 of mining their own thing

<m​onerodevsareslow:synod.im> How do you know this then? Okay I'll wait for the blogpost

ah

it's % 676 + 676+1/2

#define INTERNAL_COMPUTATIONS_INTERVAL 676

#define EXTERNAL_COMPUTATIONS_INTERVAL (676 + 1)

<m​onerodevsareslow:synod.im> Thanks

when getTickInMiningPhaseCycle returns < INTERNAL_COMPUTATIONS_INTERVAL

that means it's XMR mining

when greater or equal, it's qubic mining

exception is marathons github.com/qubic/core/blob/main/src/public_settings.h#L105-L113

this is what flips in between github.com/qubic/core/blob/main/src/qubic.cpp#L1909-L2001

for example

it's going to switch to XMR mining in about 10 seconds

they are now mining, tick 31804297

<s​yntheticbird:monero.social> yo tallhatdoug are you the real one

<k​ayabanerve:matrix.org> monerobull: Can you tell me what I coded last week :( I've already forgotten :(((

<k​ayabanerve:matrix.org> Oh, BTW ofrnxmr @ofrnxmr:monero.social: 128-in FCMPs are now 5x faster :) I hope that helps your testing.

<k​ayabanerve:matrix.org> Apologies you prior pulled out multiple computers, thanks for all your effort.

<o​frnxmr:xmr.mx> Yeah i saw that they are 1min instead of 7mins 🥲🥲🥲

<k​ayabanerve:matrix.org> The rate of CCS funding is not a good indicator for support/merit

<o​frnxmr:xmr.mx> I think id need to build against your pr? Or against a separate branch?

<s​yntheticbird:monero.social> prove or verif?

<k​ayabanerve:matrix.org> preland: Care to elaborate your work? Sorry if I forgot it/know if it and just didn't realize it was 'yours'

<m​onerobull:matrix.org> I know you don't but I'd be stranded like coming back to a Skyrim save after a week long break

<k​ayabanerve:matrix.org> ofrnxmr @ofrnxmr:xmr.mx: Yes, you would, except my PR is failing as jeffro replicated a constant in C++ that I changed.

<k​ayabanerve:matrix.org> I was working on a patch to the C++ to fix that, but hit some C++ build errors with the test suite. I can put out a patch correcting the src but leaving the tests broken immediately, or you can restore the original constants for now (allowing continued use of an existing network).

<k​ayabanerve:matrix.org> SyntheticBird: Prove, but there's a branch which also optimizes verify by some notable % (20 or 40, I forget which)

<o​frnxmr:monero.social> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) two things: your checkpointing node died, and can you reduce the checkpoints to 1 plz n thx

<o​frnxmr:monero.social> When greater than 1, its possible for me to reorg after you push the checkpoint but before it goes live or you may push 2 checkpoints before it goes live. Your following checkpoint is then on a different chain, and we end up with alt chain checkpoints mixes with main chain checkpoints (525 is an orphaned chain)

have we ever consider funding our own open source CPU hardware design, a bit like bitmain has does with the X5 but making barebone design open source ?

(using risk5 chip)

<d​uggavo:matrix.org> I don't think it makes much sense.

if we really want to stay PoW I think it should become something to consider long term

<d​uggavo:matrix.org> I think there is a strong business model for us developping our own hardware

helping bring the security price down

hardware cost is too high for xmr, it could be reduce with homebrew RiskV design

saw people building +128 riskV core design on youtube, I believe with little bit of funding something more directed toward monero can be develop

anyway would be worthless if we switch for finality layer or pos, so depend which direction we are going

I guess we gonna have to wait for ricknium and kayaba ccs 3 month to give result

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

oh we have those specific channel thx

<o​frnxmr:xmr.mx> oh.. irc

<o​frnxmr:xmr.mx> Idk if its on irc

<r​ucknium:monero.social> ofrnxmr: I think it's alive again. main chain block production rate is slow. I set it to only update one TXT record. I didn't delete the 9 other "old" TXT records.

<o​frnxmr:xmr.mx> They need to be deleted, if possible

<o​frnxmr:xmr.mx> 525 and maybe a few others are invalid and cause failures

<r​ucknium:monero.social> I will delete them. I think block production is slow because network hashrate jumped to 1.6kH/s because of testing activities.

<o​frnxmr:xmr.mx> When i was trying to reorg, it took me like 5 tries with 1kh. Maybe someone else started mining as well

<o​frnxmr:xmr.mx> Main chain keys getting way ahead of me

<o​frnxmr:xmr.mx> Kept* getting

<r​ucknium:monero.social> ofrnxmr: Other 9 TXT records has been deleted from all domains.

<r​ucknium:monero.social> You can use MRC for more hashpower if you need it.

<o​frnxmr:xmr.mx> Perfect thx

<r​ucknium:monero.social> Make sure you don't re-org deeper than 100 blocks because testnet wallets connected to nodes would have to reset `--max-reorg-depth` manually.

<o​frnxmr:xmr.mx> 101 blocks incoming

<o​frnxmr:xmr.mx> Jk

<r​ucknium:monero.social> I could change the behavior to set DNS checkpoints a few blocks deep. Now, it just takes the top block when it polls.

<o​frnxmr:xmr.mx> Probably 2 blocks deep would work. Takes a few mins for dns to update as well

<o​frnxmr:xmr.mx> not likely to see organic reorgs deeper than that

<o​frnxmr:monero.social> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) the dns record changed from 237 to 234 👀

<o​frnxmr:monero.social> Now 232

<r​ucknium:monero.social> Yes, fixing 😅

<r​ucknium:monero.social> The intended behavior is: If chain tip is height `0`, then the DNS checkpointing is now setting the checkpoint to height `-2`.

<r​ucknium:monero.social> Now it should be going up, not down.

<o​frnxmr:monero.social> It looks like they are 38 now. Also seems thr dnstxt can update much faster than 5min

<o​frnxmr:monero.social> I was seeing new values every few seconds

<o​frnxmr:xmr.mx> Is 185.141.216.147:28089 running --enforce ?

<o​frnxmr:xmr.mx> That node seems to have been forked off onto my attacking chain

<o​frnxmr:xmr.mx> And then made new checkpoints for the attacking chain

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

<r​ucknium:monero.social> ofrnxmr: Oh. I forgot to start enforcing checkpointing on that one after fixing it. Now it is enforcing

If you'd like any specific data around qubic for the past few weeks (or derivation of them) feel free to ask, I'll try to get that as long as it doesn't impact much (otherwise we will be doing general reports and try to make data digestible)

<p​rivacyx:monero.social> Why is Qubic jumping in and out in short bursts in its mining of monero? It makes no sense

<p​-q:matrix.org> My first thinking about this was to cool down the difficulty.. So in the on-ramp action of qubic they have low difficulty („real network“ diffculty) because i think it is delayed a bit.. After heat up (the difficulty) they cut and cool down then again.. But i‘m not sure about this.. The difficulty is delay a bit or?

<p​-q:matrix.org> My first thinking about this was to cool down the difficulty.. So in the on-ramp action of qubic they have low difficulty („real network“ diffculty) because i think it is delayed a bit.. After heat up (the difficulty) they cut and cool down then again.. But i‘m not sure about this.. The difficulty is delayd a bit or?

<p​-q:matrix.org> My first thinking about this was to cool down the difficulty.. So in the on-ramp action of qubic they have low difficulty („real network“ diffculty) because i think it is delayed a bit.. After heat up (the difficulty) they cut and cool down then again.. But i‘m not sure about this..

<p​rivacyx:monero.social> Yea not sure if thats there reason because difficulty adjustment happens pretty quickly when hash rate increases

<o​frnxmr:xmr.mx> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) success

<o​frnxmr:xmr.mx> Aside from the mass-bans, the network healed

<o​frnxmr:xmr.mx> The checkpointed node just ignored the reorg, then banned all peers who sent the non-checkpointed chain.

<o​frnxmr:xmr.mx> after the honest chain surpassed the attacking chain, the attacking chain was reorged back onto the checkpointed chain

<r​ucknium:monero.social> So, for better behavior, only have one "active" checkpoint and set it -2 blocks deep.

<o​frnxmr:xmr.mx> no checkpoints:

<o​frnxmr:xmr.mx> testnetnode3.moneroconsensus.info

<o​frnxmr:xmr.mx> vs

<o​frnxmr:xmr.mx> checkpoints:

<o​frnxmr:xmr.mx> testnetnode4.moneroconsensus.info

<o​frnxmr:xmr.mx> Checkpointed node outright rejected reorgs deeper than 2 blocks, and non-checkpointed node was promptly yoinked back onto the checkpointed chain

<o​frnxmr:xmr.mx> the bans are the main remaining issue imo

<o​frnxmr:xmr.mx> I have 3 unique peers on my checkpointed node. I imagine a few more reorgs and my node will ban every non-checkpointed node

<o​frnxmr:xmr.mx> And the bans themself will cause a chainsplit that wont heal until ban timers run out (1 day)

<o​frnxmr:xmr.mx> And the bans themself will cause a chainsplit that wont attempt to heal until ban timers run out (1 day)

<o​frnxmr:xmr.mx> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) did 185 node ban all peers :P?

<o​frnxmr:xmr.mx> Oh nope, not yet

<o​frnxmr:xmr.mx> My checkpointed node did

<o​frnxmr:xmr.mx> My checkpointed node did

<o​frnxmr:xmr.mx> Edit: it found a peer after ~10mins

<r​ucknium:monero.social> I wonder what would happen if it was not a bannable offense.

<r​ucknium:monero.social> testnetnode4 banned a lot. I have 4 inbound peers and many recent `monerod is now disconnected from the network` messages.

<r​ucknium:monero.social> I can't figure out how to unban peers by RPC. Is it possible?

set_bans IIRC

<r​ucknium:monero.social> I must be using it wrong. I tried `"ban":false` and `"seconds":10`, separately, to try to lift a ban on a banned peer, but it did not work.

Should be functioal tests to see how it uses it.

<r​ucknium:monero.social> Ok. When I use the curl example, it works. Must be something wrong with how I am passing params. Thanks.

<o​frnxmr:monero.social> i think having it bannable is ok, but 86400 is too long

<o​frnxmr:monero.social> If not a bannable offense, probably lead to a ddos-like scenario, where you keep trying the same bad nodes

<r​ucknium:monero.social> I was missing a square bracket in the `set_bans` RPC call.