they have another +5 ahead

<ofrnxmr:xmr.mx> Its not easy to get these leads

depth 6, monero couple behind

> monero heights 3489459 to 3489462 could be orphaned by qubic (possible 5 blocks, current 3 blocks)

from what I saw they wait until the actual max possible amount, or 9

sometimes they are too slow pushing their alt chain and monero overtakes them and they lose it

<ofrnxmr:xmr.mx> I cant help but think that they have >51% hashpower

they have been able to spot higher bursts

<vtnerd> They are likely doing bursts, as discussed earlier

22-02 UTC is when we tend to see it, coinciding with lowest monero power

<ofrnxmr:xmr.mx> ginger gave them the idea

<ofrnxmr:xmr.mx> :P

<vtnerd> It's somewhat obvious if the goal is max pr effort too

someone also gave them the idea about putting their own txs in :)

<ofrnxmr:xmr.mx> and about mining offline

really all the github PRs is about discussing not hypothetical anymore but having an active incident discussed in the open and giving attacker countermeasures

ok monero got there

5=5

reorg?

yep, reorg

aaand they are instantly +1

+2

<datahoarder> mrelay.p2pool.observer/p/ipbNuLAKVHFtODZW/1.txt (code snippet, 18 lines)

<datahoarder> how it looked just before reorg, if anyone wants to consider where checkpoints would have been nice

<ofrnxmr:xmr.mx> this is making 144 look defeatable

they don't care about profit

they care about the idea of showing profit

<ofrnxmr:xmr.mx> Since they are able to get 3 blocks ahead

but they are just burning xmr for PR, not giving to miners

<ofrnxmr:xmr.mx> They had a poll about doing 29 block reorgs lol

we have seen them get +11 ahead not just deep

yeah, maybe September as they say. they need more fresh PR as their doge and AGI training one is not really going much further

<ofrnxmr:xmr.mx> for the dns checkpoints, the dns is probably the weakest link

indeed

+3 ahead/deep

<ofrnxmr:xmr.mx> My node and your node might not see the same records, and definelty arent checking at the same time

yep, that's why I mentioned with rolling checkpoints at least the last N will coincide

maybe not exactly the tip

<ofrnxmr:xmr.mx> The main problem is if mining pools split, even temporarily, then start competing with one another

<vtnerd> there’s also the small amount of solo miners that will get split off. not sure what percentage that is though

<ofrnxmr:xmr.mx> DataHoarder: The problem is if any of the checkpoints are created from a reorg

I was writing a shim for the DNS updaters so they can point to each other and agree ahead of time what they see

and share alt blocks they see (which is why I was adding ZMQ for alt blocks)\

<ofrnxmr:xmr.mx> We had issue where 520 was good, 533 good, 525 reorged chain, 527 good, = broken

that way they are always aware of alts, and can select the chain

I don't see hashrate increase from their solution network

but this is defeatable, all they need is xmrig set with a custom higher difficulty

then it won't report shares that don't find blocks

so it will never be seen :)

<ofrnxmr:xmr.mx> @vtnerd: Was ~2-5%

need a consensus network for the DNS checkpoint nodes :')

monerod also has been veery sluggish the last hour

monero*

<ofrnxmr:xmr.mx> Or a patch for the checkpointing node to reject all reorgs 💀

it all adds up

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: this wont work

<datahoarder> Reorgs can come at different times indeed

<ofrnxmr:xmr.mx> there's gotta be a better way

<datahoarder> Something I noticed is that alt blocks don't really get broadcasted or travel around

<datahoarder> even if close to tip

<datahoarder> I have a few custom patches to push these

checkpointing nodes should be all aware of the same alt chains as each other to be able to make good selections

given they are selecting from a bit behind, as well, not just the tip

if they are aware of the existence of two for a height they have to stamp a checkpoint for, that's when they need a deterministic way (given equal states at that point) to select this and publish the dns records

that brings more issues, that monero alone currently doesn't sync this up (you need helpers/patches to push blocks via rpc, monitor alts and make these available to others)

<bawdyanarchist:matrix.org> Question about mining and timestamps. Do hashers in a pool update the header timestamp in real-time as they hash? Or do pools push a timestamp, and the hashers never change it?

Pools push a blob, the blob has the timestamp

The miners just change the nonce field

usually pools push new tasks every few seconds

Why not make the dns checkpoints using .oinion addresses? So there is no worry about issue keys and seized domains

<gingeropolous> @rucknium:monero.social: , dunno if its easy to do, but might be cool for the moneroconsensus thing to show the timestamps of the blocks

TriggerCoder: not everyone has tor on their nodes

Onion address is effectively just one Ed25519 key

morning, seems qubic is having issues irc.gammaspectra.live/4fef6fbad228100a/7_deep_qubic_orphan.png

^ this happens when blocks are found in quick succession close to their tip

they tried to reorg but monero found rest of blocks faster than they could

they are really getting hit by their slow block propagation

<unt0ld:matrix.org> DNS checkpointing is giving to many the impression the devs are just centralizing the coin to themselves at this point. Doesn't all DNS checkpointing effectively do is let reputable miners collaborate? So why not have this as a separate project among legit miners to collaborate among themselves instead. Nothing to do with devs [... too long, see mrelay.p2pool.observer/e/7KOpybAKajZHR1pX ]

miners and big merchants

<monerobull:matrix.org> @unt0ld:matrix.org: we can also phone up supportxmr and the other big pools and tell them to 51% attack against qubic, same effect, simpler to do than developing anything new

<unt0ld:matrix.org> well miners can do a lot of things. for example if i was a big miner, to protest the low mining reward, i would create a cartel to not mine low fee tx lol

<unt0ld:matrix.org> Maybe it doesn't matter though. This collaboration feature can be included in monerod I guess. It doesn't have to be DNS records. Just give node addresses for your node to collaborate with and the nodes do it through zmq or something fast like that

<monerobull:matrix.org> reorg incoming

<unt0ld:matrix.org> "and they keep coming and the won't stop coming"

<monerobull:matrix.org> ok no reorg just a normal block

they lost it :) > <monerobull:matrix.org> reorg incoming

irc.gammaspectra.live/2cb6f98c8e4be398/image.png

this current one, they are depth +2 so they can at least take one out

<gingeropolous> though dunno if timestamp of the block itself or when it is seen by the node would be more relevant

<rucknium> @gingeropolous:monero.social: Done moneroconsensus.info

<rucknium> Only have timestamps on main chain blocks because get_alternate_chains RPC calls gives limited info about alt blocks. I think I would have to query for each alt block header individually by block hash to get timestamp data.

<rucknium> It's the same reason the app assumes alt blocks have nonzero txs.

that timestamp is quite verbose :D

<rucknium> I could reduce it to Unix epoch seconds :P

<rucknium> It won't collide with its height block at the same height since alt blocks don't have timestamps displayed.

<rucknium> There are several papers on checkpointing PoW blockchains. This looks like a good one: Karakostas & Kiayias (2020) "Securing Proof-of-Work Ledgers via Checkpointing" eprint.iacr.org/2020/173

<rucknium> I don't think there's time to read, evaluate, and implement one of these papers' proposals.

could assume utc and do like 28-11-25 11:25:56

Karakostas & Kiayias recommend appending a random nonce to each checkpointed block. That prevents the adversarial chain to mine ahead of the checkpoint.

a random nonce? in the block itself/pow?

but if checkpoints are delayed (set N heights from tip) how does that work

In their model, checkpoints are issued immediately and not delayed.

If there are multiple candidate blocks, the checkpointing nodes vote.

like, manually? user intervention?

yup, every 2 min.

i don't really know, every one here is much smarter than i. disregard.

The voting process is modeled with an abstract function in the paper. It's some blackbox that gets a list of blocks and nonces and spits out the selected block and a nonce.

yeah, that'd require changes to block emission, so for later than the bandaid

I think the nonce idea could simply use tx_extra.

If the checkpointing service outputs a nonce, the miner has to include it in tx_extra.

It proves that the block was mined after the checkpoint was issued.

(trying to dig through that paper ...) so could the checkpointing service just be grabbing a blockhash from bitcoin?

so with publish or perish, im curious if we could make the k dynamic. so like, in a rolling window of n blocks, if the node hasn't observed much orphaning, then the default of k=3 is used.

but if during the same window, the rate of orphans (or depth of orphans?) increases, then k is increased

because as someone mentioned, qubic seems quite capable of producing 3 blocks

I think a paper I read recently has this dynamic k.

19:44:35 <tevador> I think the nonce idea could simply use tx_extra.

yeah, I guess if it's something only the checkpoint servers need to see that could work

just not the rest of the network that mines on its own

gingeropolous: this one arxiv.org/abs/2307.00529

noice, thanks

Just ignore their block weight function, which is useless, and imagine PoP instead.

huh tevador for some reason my bridge can't see your messages

I'll debug in a second

yeah i noticed that too DataHoarder

<datahoarder> for @rucknium:monero.social / @ofrnxmr:xmr.mx here's currently a DNS server for the sole purpose of serving DNS checkpoints. Can be setup just on a subdomain of any domain with your own keys git.gammaspectra.live/P2Pool/monero-highway

seeing this conversation on checkpoints, it seems like we have another bifurcation of mitigations (perhaps). There's 1) preventing selfish mining attacks, and 2) preventing deep devastating reorgs.

<datahoarder> Also allows AXFR zone transfers so it can be setup as master DNS with other servers being able to serve records but not produce them, as they have no keys. So you can keep master server "secret".

DataHoarder: miners would verify that blocks mine on top of valid checkpoints *and* include the checkpointing hash in tx_extra.

because an adversary hellbent on #2 could easily overwhelm the PoP defense k-failsafe

<datahoarder> It has a simple api to update all txt records at once - any amount of them

<datahoarder> I have added a small README for setting it up somewhere, if you need help feel free to ping

tevador: ofc, that'd mean changing how miners mine

it's what I mean that not all could change *now*

Yes, that would require a change in the getblocktemplate function.

So probably not something we can roll out now.

>err="failed to invite in ensure joined: M_FORBIDDEN (HTTP 403): You don't have permission to invite users"

whoever is admin on #monero-research-lounge needs to add invite privileges to the @appservice-irc:monero.social account afaik

that's why it's currently failing to show tevador's messages

Qubic will start 20+ deep reorgs from tomorrow AFAIK.

even manual DNS checkpoints might help there

(in reply to "20:01:30 <tevador> Qubic will start 20+ deep reorgs from tomorrow AFAIK." for Matrix side)

They haven't proved they can reorg that deep though... the biggest reorg pulled off by them was what? 8 or 9 blocks? they haven't gotten over 10 iirc

they have stopped there. they have been able to be 14 depth

or 16, can't remember. then once monero reached "9" orphans they released their own chain, even when they were further ahead

i mustve been out of town or not watching my node i didn't noticed it.

that was a few days ago

tonight they had depth of 12

when are they going to focus on Doge or was that just another lie?

01:36:43 <DataHoarder> they could have done 11 on this one

^ depth of 12

months from now. don't read too much into their marketing

<datahoarder> also @rucknium:monero.social / @ofrnxmr:xmr.mx this brings TTL times to the minimum you want to support, ofc, pending middlemen DNS Resolvers / Forwarders users might be using via system DNS

looks like they done a 9 in the last 720 blocks

chill.mycotrip.tech/uploads/4814bc54ba29488d/image.png

<datahoarder> With my examples and a TTL of 300s (5m) it's all fine, but the records tend to update within 10s via mainstream dns servers

mycotrip: you are looking at the wrong thing. look when they pushed the blocks

not the chain they orphaned

when they orphaned those 9 blocks, they had 12 blocks

so they wasted a "couple" and could have waited longer for monero to catch up, and orphan 11

ahhh that makes sense! i am still learning. so please excuse my stupid questions / ignorance

thanks for the for clearing that up for me!

I believe it was this one irc.gammaspectra.live/d8ecb9bfd77f96bf/image.png

when they pushed the chain they had up to 3489628 mined

With 10+ deep reorgs, we will start seeing invalidated transactions.

what would the impact of that be? just a delay in the transaction or it being totally lost?

Totally lost.

global output indices get invalidated - meaning they are no longer valid and are lost

Once the tx get invalidated with the deep reorg, the sender needs to open their wallet again and make a new transaction.

txs refer to mined outputs via the 64-bit output index :)

<ofrnxmr:xmr.mx> @plowsof:matrix.org > <DataHoarder> whoever is admin on #monero-research-lounge:monero.social needs to add invite privileges to the @appservice-irc:monero.social account afaik

With FCMP, the situation will get even worse. Once the anchor block gets invalidated with a 10+ deep reorg, *all* transactions constructed with that anchor become invalid, i.e. all transactions made in the last 20 minutes or so.

<ofrnxmr:xmr.mx> datahoarder, it might be because the room is invite-only

<datahoarder> yes, as mentioned :). This was fixed on other channels when there were raids last night

<datahoarder> So people that didn't disconnect overnight kept the invite in, people that reconnected or dropped from IRC can't get their nicks to rejoin

<ofrnxmr:xmr.mx> Other channels have invite user = default?

<datahoarder> well, #monero:monero.social got invite-only enabled

<ofrnxmr:xmr.mx> Or does the room have to he set back to public

<datahoarder> I can't remember. But bot is able to invite users that need inviting as long as the rights are set (unless the rights need to be set on the user)

<ofrnxmr:xmr.mx> Then the easy solution is to allow existing users to send invites

<ofrnxmr:xmr.mx> Else can set invite to pwr lvl 1, and set the bot to lvl 1

now moneromooo is out of the room too, :D

Do I need to read the scrollback ?

tl;dr room is invite only and bridge can't bring your user into matrix side

nick change or quit/join does that

<ofrnxmr:xmr.mx> @xmrscott:monero.social @plowsof:matrix.org

Btw, is there a github issue on the checkpointing solution? Are the checkpointing nodes going to blindly checkpoint any block they see?

"reposting" 20:58:31 <tevador> Btw, is there a github issue on the checkpointing solution? Are the checkpointing nodes going to blindly checkpoint any block they see?

or the ones working on that on the other side won't see it :)

Ack, Invite only just needs to be removed , it was enabled temp last night

test

works, the next time they speak they should get autojoined

<ofrnxmr:xmr.mx> should still change the invite power level so that the next time we have to close the room due to noise, the bridge doesnt go on life support

let's revisit that if the new bridge gets deployed further

<rucknium> tevador: My outline for the issue I'm writing is:

<rucknium> 1. Brief on situation.

<rucknium> 2. What rolling checkpoints will do and will not do

<rucknium> 3. Pros[... more lines follow, see mrelay.p2pool.observer/e/xsbx2LAKWGJSOExR ]

I think the checkpointing solution will need to somehow ignore qubic's blocks. Otherwise qubic with >50% hashpower can just trickle-release blocks and still orphan everyone.

<rucknium> They would be able to selfish mine and mine empty blocks, but not perform deep chain re-orgs if they have majority hashpower, right?

<rucknium> The checkpointing code identifying Qubic blocks and ignoring them would definitely sharpen the defense.

Yes, they could just mine 100% of empty blocks, which is not a good outcome of checkpointing.

<jwinterm:matrix.org> another idea I think kinda similar to tevador's that a friend shared with me hackmd.io/@Forgetmemd/SkM8x5l5xx

<jwinterm:matrix.org> but expand beyond coinbase tx

This can't work. Qubic can just create full blocks of their own transactions.

doesn't that seem kind of short sighted? just identifying qubic? what if some other actor tries this?

<rucknium> Well, the whole point of DNS checkpoints is that they are short-sighted.

<rucknium> Temporary, until better countermeasures can be analyzed, implemented, and deployed.

i guess if we view the DNS checkpoints as a band-aid it makes sense.

<unt0ld:matrix.org> For rising fees: An idea for being able to more frequently adjust transaction fees with node upgrades and not network upgrades: 1. Change the tx anonymity pools to be infinitely scalable, with consistent limited selections to be offered by wallets. Essentially the min relay fee will become the base level fee pool. This needs t [... too long, see mrelay.p2pool.observer/e/tZDf2bAKVHB5cXdE ]

i'm pretty ignorant around all of this so if i don't make sense or miss something super obvious let me knw.

Obviously, we'd have to whitelist blocks rather than blacklist.

<jwinterm:matrix.org> tevador: but the txs would use tx_extra to reference previous block(s), right?

<jwinterm:matrix.org> I don't think it is completely fleshed out idea, but they asked me to share

Qubic would fake their own secret transactions that would reference their secret blocks.

<jwinterm:matrix.org> tevador: sure, but all "economic" transactions would reference the legitimate chain, so...I guess economic nodes would be incentivized to stay on the chain with their pool payouts, exchange deposits, etc. I think is the idea, doesn't require hardfork and allows users making txs to help signal which chain is "legit"

There is no decentralized way to identify "real" transactions.

<jwinterm:matrix.org> I tend to agree, but here we are discussing checkpoints...so just thought I'd share

<totally_not_a_fed:matrix.org> Hi. I'm wondering about Luke's proposal - Local PoW. It only got mentioned briefly in one MRL github issue and somehow got swept under the rug. To me it looks like an elegant solution without the downsides of PoS and not being a half-measure like Publish or Perish: mining remains CPU-centric while (presumably) cheap ASICs elim [... too long, see mrelay.p2pool.observer/e/_Zzf2rAKV1pFNXZr

<ofrnxmr:xmr.mx> I can only speak for myself: thats a no from me

<kayabanerve:matrix.org> Local PoW, which doesn't actually have a good proposal on how to achieve it, and merge-mining have arguably been underdiscussed

<countbleck:matrix.org> Wouldn't requiring ASICs mean there'd be higher friction to mine Monero?

<torir:matrix.org> Problems with requiring ASICs:

<torir:matrix.org> * Makes it hard to mine in countries where there are no ASICs supplies or mining is illegal

<torir:matrix.org> * Adds additional friction to mining

<torir:matrix.org> * Adds a dependency on ASIC manufacturers, who might be pressured by governments[... more lines follow, see mrelay.p2pool.observer/e/gdS23LAKdHEyZ2Ni ]

<torir:matrix.org> Advantages of requiring ASICs:

<torir:matrix.org> * Kills botnet mining (this may be a disadvantage depending on who you ask)

<torir:matrix.org> * May makes attacks more costly since ASICs are a limited resource

<torir:matrix.org> In my opinion ASICs might lead to centralization of ASIC production. We'll end up with one or two manufacturers, unless we somehow create an ASIC design that can be made at home.

<captaincanaryllc:matrix.org> if asics, which algo?

<jwinterm:matrix.org> @torir:matrix.org: using existing ASICs (user above mentioned bitaxe) eliminates this issue, there are already many more than two manufacturers of bitaxes and knockoffs, let alone sha256 bitcoin asics in general

<torir:matrix.org> github.com/bitaxeorg/bitaxegamma >At the heart of the bitaxeGamma is a BM1370 Bitcoin mining ASIC from the Antminer S21 Pro from Bitmain. It's not open source.

<torir:matrix.org> Bitaxe appears to be everything but the actual ASIC.

<jwinterm:matrix.org> right, but there are more than a couple makers of double sha256 asics now

<jwinterm:matrix.org> there is apparently open source hw on the horizon to compete with big three existing chip makers also cryptotimes.io/2025/05/03/jack-dors…nch-open-source-bitcoin-mining-chip

I saw that... kind of interesting but I don't think it will pop off and really be worth anything.

<torir:matrix.org> I will agree that using a SHA256 ASIC for Local PoW is more likely to increase availability of mining hardware for users mining Monero than other algorithms. Still, the supply chain for ASICs is absolutely something governments can crack down on. Microchip production requires specialized equipment; we can't just have users make their own chips.

<torir:matrix.org> Countries that ban crypto mining might already be on the lookup for ASIC orders.

man i just wanna know what the soft fork PoP needs to be ... ready

<torir:matrix.org> The good news for Local PoW is we don't need the latest and greatest ASIC chip. We just tune the algorithm such that it requires double SHA at a faster rate than CPU or GPU can produce so that you need an ASIC, but it doesn't need to be the best ASIC available.

I think checkpointing will not achieve much without at least PoP. We could do PoP with k=∞.

<torir:matrix.org> In regards to merge mining, I don't understand merge mining all that well but I believe it would require running both a Monero node and a node for the other coin?

Isn't Tari already merge mined?

<antilt:we2.ee> hard to outcompete standart hw with niche-specific hardware (FPGAs). True, we may face a situation where an adversary owns too much CPU for longer, not only in bursts. PoP is a good option imho

There is synergy between PoP(k=∞) and checkpointing. Checkpointing will remove the chain splitting weakness of PoP(k=∞) and PoP will ensure the checkpointing node won't checkpoint the selfish chain.

<ofrnxmr:xmr.mx> Tevador, qubic has been able to get like 11 blocks ahead though

Try infinity blocks.

<antilt:we2.ee> mycotrip: Tari mined 20% empty blocks. MM is a gamble: btc or ltc may have +51% instantly

<gingeropolous> yeah with a k of infinity that would be addressed @ofrnxmr:xmr.mx

<gingeropolous> we just lose network recovery from netsplits

<ofrnxmr:xmr.mx> Duh, i have a short memory, sorry

<ofrnxmr:xmr.mx> I read that infinity, went to reread proposal, and forgot about infinity 🥲

<rucknium> Cross-posting from #monero-research-lab:monero.social : I created an issue for Temporary rolling DNS checkpoints to thwart deep blockchain re-orgs: monero-project/monero #10064

<rucknium> ^ A good place for more organized discussion

<gingeropolous> the hard truth is that selfish mining is what an economically driven miner would do with a certain % of hashrate

<gingeropolous> why drive up the diff when you don't have to

<totally_not_a_fed:matrix.org> > <@torir:matrix.org> I will agree that using a SHA256 ASIC for Local PoW is more likely to increase availability of mining hardware for users mining Monero than other algorithms. Still, the supply chain for ASICs is absolutely something governments can crack down on. Microchip production requires specialized equipment; we can't just have users make their own chips.

<totally_not_a_fed:matrix.org> That concern about governments strangling the supply is something to look into for sure. I don't know how realistic it is, but anyway: since we're basically looking for some unusual piece of hardware that doesn't automatically ships with a PC to enable Local PoW, I guess theoretically we're not even limited by ASICs

<gingeropolous> imo asics are just another level of permission, but its our permissionless nature that got us here so .shrug_guy

Is the merge mining idea that Monero becomes a coin that is merge mined from/with some other larger coin (LTC/BTC)?

<torir:matrix.org> Instead of an ASIC, we should use a closed source tamper resistant device produced by the Monero dev team that reads computer memory to confirm the computation was done locally then signs the blocks. The Monero dev team can promise that proceeds from sales of the device will go into reinvesting into Monero development and definitely won't be used to purchase expensive automobiles. /s

<ofrnxmr:xmr.mx> midipoet: Midi, yes

<ofrnxmr:xmr.mx> Ltc isnt always larger, its doge or doge+ltc that is

Then, yeah, I think that deserves more discussion. It's as valid as any other of the ideas I have heard. I think we all have to admit that any solution to this is pretty much going to be antithetical to "Monero's original ideology". Admitting that, would allow us to just pick the most secure mitigation/fix, without getting lost in all the other philosophy.

<torir:matrix.org> I view merge mining as a potential medium term solution, but not a long term one. It could be long term, but I think with research we can probably find an acceptable solution that better fits with Monero's values.

<rucknium> The first mining pool to adopt merge mining of Monero could easily gain majority hashpower alone. You could have multiple algorithms to try to avoid that (50% block RandomX, 50% Scrypt merged mined with LTC/DOGE). Most projects that have or planned to merge mine with Monero do not have merged mined RandomX as the sole algorithm AFAIK, for this reason.

<rucknium> e.g. townforge.net/proof-of-settlement

<boog900> could we make a merge mining chain that is just used for mining, so like 5 to 10 second block times with monerod following whatever the top block in the merge mining chain references as the previous.

<boog900> After a certain amount of time the blocks from the side chain could be removed so short term we have fast blocks which makes large reorgs harder but we don't have the negatives of fast blocks for the whole network?

<jwinterm:matrix.org> midipoet: I kinda like this one too, but I think it's offputting to people because it at least partly means that the big-brains over at dogecoin made a better decision a decade ago while xmr has kind of muddled along and mucked things up

Well, the way it is now, a lot of people have made better decisions than Monero

<boog900> it wouldn't prevent 51% attacks but should make selfish mining harder right?

<rucknium> Dogecoin has a huge security budget because its tail emission is huge.

I think you could mitigate the first mover pool attack by some form of phased/staggered introduction. I am not sure how it would be designed, but I am sure it would be doable.

<rucknium> @boog900: I may be mixing things up, but IIRC Bitcoin-NG, which the founder of Qubic is supposed to have been involved in, was designed to do something like that.

@rucknium: I'll check that github issue. Also additional question, why 4 and not 5 nodes (for classic 3/5 need to agree)?

<rucknium> DataHoarder: 4 domains are in the code now.

I guess it's based on the numbers of people who were deemed agreeable to host the servers

Yes, aware they are hardcoded, just pondering why it's 4 (eg based on number of people available, not specific choice)

<gingeropolous> i don't think all the solutions end up antithetical to moneros original whatever

<gingeropolous> publish or perish addresses a critical flaw of nakamoto consensus that has been brushed under the rug

<gingeropolous> selfish mining

<gingeropolous> even if you have over 51%, the probabilistic magic might still might allow the honest network to continue

<gingeropolous> because just because you have a massive amount of HR doesn't guarantee you will find the next block

<boog900> @rucknium: having a quick look, they have "microblocks" and "key blocks", where microblocks don't used PoW. So similar in the sense that they use blocks with shorter timestamps between main blocks, but different because with the side chain idea the blocks will use PoW and wont affect the mainchain beyond nodes using it to decide what mainchain blocks to follow.

<boog900> it would only be a soft fork too

gingeropolous: as I understand it, PoP only fixes the specific selfish mining attack. It doesn't do anything towards mitigating the ability for an attacker to devise a mining/emission based scheme that incentivises malevolent behaviour from "crowd sourced" CPUs to attack specific coins. Whereas, merge mining would mean the whole attack strategy is defunct.

Please correct me if I am wrong!

would it be advisable to enable dns checkpointing on my local monerod?

<rucknium> IIRC, there are similar ideas analyzed in Zhang, R., Preneel, B. (2019) "Lay down the common metrics: Evaluating proof-of-work consensus protocols’ security." doi.org/10.1109/SP.2019.00086

<rucknium> @boog900: ^

<ofrnxmr:xmr.mx> It has a huge security budger because on elon** > <@rucknium> Dogecoin has a huge security budget because its tail emission is huge.

<ofrnxmr:xmr.mx> Midi: any POW coin is susceptible to the qubic strategy, as long as qubic can pay more than the previous sum

<ofrnxmr:xmr.mx> its essentially merge mining, but where you get paid in a different token than the ones you are mining

<captaincanaryllc:matrix.org> if monero could be mined on sha256 or scrypt miners, I would buy more asics just for more monero. I'm not sure how many people would do the same, but the result might be a more secure network with many more people running relatively inexpensive miners in their own home to secure the monero network. And, with merge-mining suppo [... too long, see mrelay.p2pool.observer/e/6f2R37AKUkE0VGht ]

<captaincanaryllc:matrix.org> Right now, to support monero, the best I can do is maybe 10KH on machines with spare compute.I can also buy monero, but I'm already doing that. If I could merge-mine, that would be an exciting and bigger way for me to support the network

<ofrnxmr:xmr.mx> litecoin miners only mine doge for profit / to dump on retail. As a litecoin miner, would you rather mergemine doge using the qubic pool, and get paid 50% extra? Or merge mine doge directly and leave the gains on the table. Note: you dont care about doge, you care abiut USD

<captaincanaryllc:matrix.org> as a litecoin miner I would swap to monero

<ofrnxmr:xmr.mx> Right, so why wouldnt you mergemine on a pool that earns you more?

<ofrnxmr:xmr.mx> industrial miners have a bottom line, and its not idealistic. Switching algos doesnt change the psychology around this attack

<captaincanaryllc:matrix.org> not in every case. I'm already mining monero just to support the network. If I could merge-mine monero/doge/ltc, I wouldn't do it on qubic's pool. I would still make more monero than I do now presumably, so I don't need to max it out.

<captaincanaryllc:matrix.org> it incentivizes mining monero more than current system, so more people would mine.

<ofrnxmr:xmr.mx> you wouldnt, but you're not a litecoin pool that already mines and dumps doge because doge is trash

<captaincanaryllc:matrix.org> how many more monero people would buy asics in the question for me

<captaincanaryllc:matrix.org> *is

<ofrnxmr:xmr.mx> 12

<captaincanaryllc:matrix.org> maybe sha256 then

<ofrnxmr:xmr.mx> compared to the hashrate existing, monero-first miners would probably be like sub-1%

<ofrnxmr:xmr.mx> Sha256 would be worse. Bitcoiners would probably try to 51% us on day 1

<ofrnxmr:xmr.mx> Didnt workout too great for other sha256 coins. Bch has max reorg depths etc, because btc can 51% at any time

<midipoet> ​Well, the way it is now, a lot of people have made better decisions than Monero <<>> it seems that they chose transparency and compliance, nobody is perfect

<captaincanaryllc:matrix.org> more people would also mine if p2pool rewards were significantly higher than any other type of mining. I know it's been discussed at some point

<captaincanaryllc:matrix.org> coinbase txs netting higher rewards

but then p2pool gets too much HR no?

<captaincanaryllc:matrix.org> better p2pool than any other alternative I have heard

<captaincanaryllc:matrix.org> even if p2pool had 90% HR they would not be able to perform qubic-style attacks iiuc

p2pool can't have too much hashratw

01:36:54 <mycotrip> but then p2pool gets too much HR no?

it's distributed

it's not a "pool" that can be controlled by an unique entity

each miner is doing its own selection and verification

individual participants could try, but they would also need to withhold their shares from p2pool, which would cause them to get orphaned there

no different from solo mining

<captaincanaryllc:matrix.org> the fix is already built? Raise block rewards for p2pool miners high enough to get more people mining at home. Then qubic strat wouldn't work again with p2pool dominance

you can't just "raise" reward

that's a full hard fork that takes months, and goes against everything else. you can "drop" reward elsewhere

but then qubic could still just do p2pool, again

they would just say "we pay 10x now!!!!!!" for the marketing

<ofrnxmr> Mhm. They can run their own p2pool. and run qubic pool on that. Idk why people dont realize that

<ofrnxmr> there are already centralized pools on p2pool

<ofrnxmr> Nothing stopping them from creating their own p2pool

^

and they can just create their own secret p2pool, yeah

<captaincanaryllc:matrix.org> ty for clarifying for me

<captaincanaryllc:matrix.org> same thing for solo mining, ie qubic can game any extra incentives for solo miners?

first, also hard fork, so months+

<ofrnxmr:xmr.mx> If we paid extra to p2pool, qubic would definitely become 1000+% bigger p2pool than our existing p2pools

second, even if they solo mined due to block signing or similar, they could just ... make a pool, send private keys to subsets, take the hit that someone claims the reward

yet they still manage to selfish mine :D

you are looking at monetary incentives

qubic's incentive is hype, as what they get from XMR does not cover what they pay ofc. it gets burned in their coin

they pay in their token, they can adjust payment to what they desire as needed to achieve a marketable result

<p-q:matrix.org> mergemining wownero will fix all this problems over night.. trust me

<ofrnxmr:xmr.mx> the ultimate troll chain

<ofrnxmr:xmr.mx> Maybe wownero can hard fork soon to allow mergemining with monero @jwinterm:matrix.org

hard fork wownero to allow mergemining with p2pool only

:D

they mergemine their sidechain not monero directly

as a side effect also monero is obtained

<captaincanaryllc:matrix.org> all that considered, is there a possible way to incentivize significantly more people to mine monero individually, in order to distribute HR more evenly? At some point, with enough people wanting to mine naturally due to incentives, that would eclipse even qubic's budget/hype

monero gets mostly used not speculated which ends up with different incentives than most boom "mined" coins, and the ones that remain profitable are few