<barthman132:matrix.org> x.com/monero/status/196367547168793…ing%20a%20malicious%20remote%20node.

<barthman132:matrix.org> Does this permanently fix the issue of using a malicious node that takes your ip to de anonymize you?

<fr33_yourself> I know my opinion likely doesn't matter to most people here, but I am against the idea of deploying rolling dns checkpoints. Chain with most accumulated Proof of Work should rule even if it is Qubics.

<fr33_yourself> I was also the person who suggested the idea of all "honest" monero mining pool admins colluding to orphan off all of Qubic's blocks. Upon further consideration I think this is a bad idea as it is a "political" solution to target Qubic for being Qubic. A "clean" solution is one that targets not a specific pool for their name, [... too long, see mrelay.p2pool.observer/e/882etLIKRlpvYWRn ]

<fr33_yourself> But regarding checkpoints, my opinion doesn't really matter. The opinions of the researchers, developers and particularly honest miners matter. As miners would be the important actors in determining how effective rolling dns checkpoints are and I'm not a big mining pool admin haha

<barthman132:matrix.org> @fr33_yourself: If they’re part of Qubic then I already consider them a liability and all money qubic miners lose to orphaned blocks will hurt them a lot, because the main reason why people mine qubic is because people get higher profit then mining monero. The “political” worries are all nonsense. It’s not like, th [... too long, see mrelay.p2pool.observer/e/-brrtbIKcXpBc2dq ]

<fr33_yourself> I see where you are coming from, but I still disagree. But then again the people who hold the cards right now are Qubic and the "honest" monero mining pool admins. Even though I think it's a political solution, if the "honest" admins want then there is nothing I can do to stop them from colluding into one pool and orphaning of [... too long, see mrelay.p2pool.observer/e/6sD4tbIKQUUySGxw ]

<fr33_yourself> Because even if Qubic gets majority hashrate and mines empty blocks, then people can just voluntarily raise the fees attached to their transactions to incentivize "honest" hashrate to come online. Or maybe CFB wouldn't want to turn down a five dollar transaction fee haha

<barthman132:matrix.org> @fr33_yourself: Honestly I think the pools should have orphaned as much of qubic blocks earlier. The pools are separate and they’re separately orphaning qubic blocks. I don’t really see why that’s a bad thing. The bad optics is the fact that Qubic is still a problem tbw and we have only now started to deal with them. [... too long, see mrelay.p2pool.observer/e/y5qTtrIKOFhvcVMz ]

<chowbungaman:matrix.org> PoW “Maxi” @mechanikalk of @QuaiNetwork on defeating selfish mining attacks in Monero by upgrading its PoW system with “Work Shares”. He is already working on the Pull-Request!! 🤯 Is this the way ??

<chowbungaman:matrix.org> x.com/douglastuman/status/196418301…05670?s=46&t=WeY1AyuT6Ir1FNBKKq_Beg

<fr33_yourself> You are correct that if the Pool admins had coordinated earlier to orphan Qubic's blocks then it would've nipped things in the bud. When I was at peak personal FUD or rattled by the Qubic nonsense, then I thought the only "silver bullet" was for all the honest hashrate to combine into one pool and orphan all of qubic's blocks [... too long, see mrelay.p2pool.observer/e/5o2qtrIKWlNaenlu ]

<fr33_yourself> @chowbungaman:matrix.org: Rucknium is also looking into Proportional reward splitting which is even more secure than "work shares" (fruit-chains) by themselves. But if my understanding is correct Proportional reward splitting with work shares is problematic for Monero in practice because of RandomX. And we should definitel [... too long, see mrelay.p2pool.observer/e/xeixtrIKWjhONjlB ]

<barthman132:matrix.org> @fr33_yourself: I mean yeah going into one pool to just get rid of qubic is overkill, but if they just don’t do that and just all simultaneously try to orphan qubic blocks. Then it’s not a problem and should have happened earlier. The fact is the monero community underestimated Qubic and only now we’re taking real measures against them.

<fr33_yourself> Qubic kind of blindsided everyone to be honest. I remember I saw a headline about them in mid-June, but thought nothing of it. Yeah I don't have a strong take on your opinion. I mean if that is what miners want to do, then so be it. But if Selfish Mining wasn't lucrative as it is currently then CFB's pool could've never grown [... too long, see mrelay.p2pool.observer/e/t8fGtrIKSGJxNlNf ]

<barthman132:matrix.org> @fr33_yourself: Yep and a big reason why Qubic is big is because it’s just more lucrative to mine qubic then monero. But if we orphan their blocks it removes an incentive to mine qubic in the first place.

<fr33_yourself> I would much rather see mining pool admins collude and coordinate than see rolling checkpoints get deployed. And I would even prefer rolling checkpoints to any form of Proof of stake even if it is a hybrid. I think I'll probably leave Monero if Proof of stake gets implemented in any form. Unless I see some of the key concerns [... too long, see mrelay.p2pool.observer/e/2JPOtrIKMlB5QWlv ]

<fr33_yourself> @barthman132:matrix.org: This is slightly inaccurate. It is true that Qubic was / is paying more to mine Qubic than XMR directly. It is not true that orphaning Qubic blocks effects the total block reward in Qubic. But it does reduce their total Monero reward which is used by CFB to buy back their own coins and prop up the price. So it indirectly kills Qubic. yep.

<fr33_yourself> The value of Qubic's emission is dependent on qubic's price which is dependent on CFB selling Monero to buy then burn Qubic to prop up the price. So your overall point stands it just takes a little bit of time for the effects of Qubic losing hashrate and rewards to "bear fruit".

<barthman132:matrix.org> @fr33_yourself: Well don’t the miners have to burn the monero to get the qubic in the first place?

<fr33_yourself> I don't think so, but I could be mistaken. I'm pretty sure CFB and higher-ups are the only ones who get to decide when and how much of the mined Monero is sold. The hashers on the proof of work themselves don't get a say in the matter if my understanding is correct.

<barthman132:matrix.org> @fr33_yourself: That’s what I thought, because of this quote

<barthman132:matrix.org> Qubic’s uPoW turns mining into a deflationary engine: every XMR and Tari reward is sold for USDT, buys QUBIC, and is burned. With our hashrate climbing past 10% of Monero’s, we’re rapidly approaching a new era of decentralized compute value.”

<barthman132:matrix.org> * Alberto Fernandez, Head of Qubic Ecosystem & Partnerships[... more lines follow, see mrelay.p2pool.observer/e/lbGEt7IKdWlaUUJk ]

<fr33_yourself> They don't immediately sell the Monero and buy back Qubic though. I'm pretty sure CFB and the higher ups do that at that their personal discretion. But yes they need sell the Monero they make from mining to Prop up the value of Qubic. Basically they need to mine another coin to survive because their own coin is useless. Like how a tick lives on a host animal.

<barthman132:matrix.org> @fr33_yourself: Ah ok, because qubic a price has taken a beating for awhile and with the halving. Their miners are just not making as much as they used to.

<fr33_yourself> Right because they had a recent halving (if my memory is correct), then their block subsidy has fallen because the price hasn't doubled recently. So CFB is in the hotseat at the moment. Which means he may also make some desperate moves. I personally think if we can make it through their next halving then we should be fine. CFB [... too long, see mrelay.p2pool.observer/e/ramet7IKd1RNVUNH ]

<barthman132:matrix.org> @fr33_yourself: When is their next halving? Because honestly he probably wants to quickly move on to dogecoin right now, because he milked as much clout from monero as he could and now the monero community is orphaning his blocks. It’s a problem for him, because the halving didn’t go as well as he hoped, because instea [... too long, see mrelay.p2pool.observer/e/kN6tt7IKWGkwN3JD ]

<fr33_yourself> I'm not too sure, because I'm not too worried honestly. I think we're probably smooth sailing from here. And even if CFB mines empty blocks and goes crazy then dark net buyers will just pay higher fees. Unless they really think its worth it to save a few dollars on fees and use a transparent coin like litecoin haha. I think they'll pay up for privacy if they need to.

<fr33_yourself> The above scenario is predicated on the assumption that if people pay high enough fees then some honest pool somewhere will allocate more hash to overcome the censor and scoop up all the fees as rewards

<fr33_yourself> High fees are how majority hash empty block attack is (possibly) thwarted. Doesn't require any magic from the researchers or developers. But the selfish mining issue is a pain point

<barthman132:matrix.org> Well because monero isn’t a worthless shitcoin. The fact is monero has a baseline value due to its nature as the only realistic privacy coin on the market that anyone takes. There simply just no realistic replacement for monero on the current market.

<fr33_yourself> Yes, but there is also a point at which the fee required (to entice honest hash) would be high enough to push people into a transparent coin. But this is all theoretical territory. The closest we would've come to seeing something like that would've been during high network congestion on BTC when it was still the primary coin u [... too long, see mrelay.p2pool.observer/e/z_LRt7IKc2gwRENJ ]

<barthman132:matrix.org> @fr33_yourself: But that’s the thing. The Dark web always is more hesitant to accept transparent coins due to their transparent nature. The fact that monero is private. Does give it intrinsic value over something like bitcoin, which only really goes up in price due to name recognition and the most the pushed crypto coin.

@fr33_yourself even with rolling checkpoints they will be able to do selfish mining, and their blocks would go in. what DNS checkpoints are attempting is prevent 10+ reorgs that will break made transactions for a week before they can be resent, or allow double-spends

it's also not specifically going for qubic specifically, this bandaid is generic for anyone attempting this, at least until more permanent solutions are found (which most require upgrades or hard forks, which will take very long)

couldn't the rolling checkpoints be determined by some form of consensus/percentage/quorum of miners/nodes?

nodes switch instantly at the moment, midipoet

but yeah. as they are currently, you already need a Majority of the systems controlling each separate DNS domain to have that checkpoint trigger

50%+1, 4 domains, need 3 to have same values

there would be already a query of not single nodes for data gathering, indeed

they switch instantly to mine the next block, but couldn't there be a separate process for agreeing the checkpoint? i.e, the checkpoint doesn't have to be every ~2 mins, it could be every third/fourth block, etc

(though to be honest, i am not sure i understand enough about this)

I think it's less about checkpointing it every N minutes and checkpointing it every N heights instead, once agreed upon

not on tip, but a few heights from tip

> not on tip, but a few heights from tip << yes, i just described it as 2m == block (apologies)

3 blocks could come in one second or in 50 minutes :)

Ideally, each moneropulse domain would be controlled by a different person and we'd require a BFT quorum of 2/3+1 to create a checkpoint. That's the most "decentralized" mitigation that can be deployed quickly.

<ofrnxmr:xmr.mx> the code already calls for a majority, but not +1

It should be changed to 2/3+1. That's minor patch.

<ofrnxmr:xmr.mx> I think its this line

<ofrnxmr:xmr.mx> if (good_record == record_count.end() || good_record->second < dns_urls.size() / 2 + 1) change to something like

<ofrnxmr:xmr.mx> if (good_record == record_count.end() || good_record->second < (dns_urls.size() * 2 / 3 + 1) ?

<ofrnxmr:xmr.mx> L556 of src/common/dns_utils.cpp

14:12:08 <tevador> It should be changed to 2/3+1. That's minor patch.

and old ones would keep working at majority

which is backwards compatible

<freddypa:matrix.org> Hello

<ofrnxmr:xmr.mx> nohello.net

<freddypa:matrix.org> I am sorry

nosorry.xyz

<ofrnxmr:xmr.mx> +1 heheh

<fr33_yourself> > <DataHoarder> @fr33_yourself even with rolling checkpoints they will be able to do selfish mining, and their blocks would go in. what DNS checkpoints are attempting is prevent 10+ reorgs that will break made transactions for a week before they can be resent, or allow double-spends

<fr33_yourself> I probably am in the minority, and since I'm not a large pool admin my opinion doesn't effect what actually happens in Monero's system (whether or not they actually activate rolling checkpoints), but I still think it's a bad idea to deploy rolling checkpoints. I would actually rather leave the possibility of deep reorgs open t [... too long, see mrelay.p2pool.observer/e/r8DT07IKc2FZM29m ]

<fr33_yourself> I think the only change(s) that should be made (whether sooner or later) are ones that directly address selfish mining.

<fr33_yourself> The longest chain rule is not the problem. It is a good thing, and to the best of my understanding the best engineering decision possible for determining which chain is the "correct" one. The problem / issue is selfish mining (which can be leveraged to do monkey business with longest chain rule, specifically building long secret chains while doing selfish mining).

They cannot be increased without hardfork

That is what the bandaid changes, time until hardfork

A long reorg WILL break the transactions, even if you increase confirmation times

<fr33_yourself> No bandaid. Just leave the vulnerability open until hardfork. Can you specifically explain how a long reorg breaks transactions? Ofrn said that it can cause transactions to get stuck in the transaction pool until the user clears everything. Is that the entire extent of the issue?

transactions refer others and decoys via global output index

Global output index depends on the block the tx was found and order

A reorg past 10 txs will make these invalid, meaning all transactions that refer decoys or inputs here are invalid and can be double spent again

And

<ofrnxmr> Increasing conf times is a bandaid

The transactions cannot be recreated again, either

Until it goes out of mempool by miners

<ofrnxmr> Just like 10 was a bandaid, 20 is just a bigger one

Which is a week+

Additionally these txs can break a chain of txs

<ofrnxmr> the issue isnt longest chain, its that a 35% minority can act maliciously as a majority

<fr33_yourself> correct the key images just mean that in absolute worst the transaction would be stuck for a week + That is the entire extent of the issue.

Not worst

<ofrnxmr> Wrong

You enable anyone to double spend

<ofrnxmr> right dh

Everyone gets a free double spend that is within those transactions

<ofrnxmr> not just double spend, but can revoke transactions that have been genuinely spent

Within 20+ or so

<fr33_yourself> This is my exact point. So attempting to over-ride longest chain rule via rolling checkpoints is gimmicky. Let Mr. CFB have at it. My position may sound crazy, but I prefer leaving the possibility open to CFB then a centralized bandaid > <@ofrnxmr> the issue isnt longest chain, its that a 35% minority can act maliciously as a majority

<ofrnxmr> no it isnt

<ofrnxmr> Your position is crazy, it doesnt just sound like it

<ofrnxmr> We already have checkpoints

<ofrnxmr> We also already have dns checkpoints

<fr33_yourself> Yes, I would actually be in favor of increasing the 10 block lock time over rolling checkpoints. But this is a big pain in the ass for everyone so it probably wouldn't happen > <@ofrnxmr> Just like 10 was a bandaid, 20 is just a bigger one

<ofrnxmr> As ive said elsewhere, this is just a poor-mans finality layer, and requires an actual majority hashpower

<ofrnxmr> @fr33_yourself: It doesnt fix anything

<fr33_yourself> DataHoarder: Can you explain exactly how those transactions in the deep reorg could double spend? I thought the transaction key image would be in the transaction pool which would mean their new transaction would get rejected?

<ofrnxmr> Why 20? Why not 200?

<ofrnxmr> @fr33_yourself: easily..

fr33_yourself: someone can mine a tx themselves

this is just a mempool tx

you can even have the two txs in differing mempools ready

<fr33_yourself> But not rolling checkpoints enabled by default > <@ofrnxmr> We also already have dns checkpoints

<ofrnxmr> And txpool only respecrs the first tx it has seen

<ofrnxmr> @fr33_yourself: Were not enabling by default

I'll be back in a bit

<ofrnxmr> The only things changing is the frequency that they are checked, and the frequency which they are updated

<fr33_yourself> Depends on how deep you think CFB can go? These are all gimmicky solutions. Really I think it's worth doing nothing until hard fork is ready that addresses selfish mining. What is the problem with fluffy's detective mining proposal? Because that wouldn't require a hard fork or soft fork if my understanding was correct > <@ofrnxmr> Why 20? Why not 200?

<ofrnxmr> who cares about cfb

<ofrnxmr> This is about finality and mitigations to minorities rewriting the chain

<ofrnxmr> The longest chain is the checkpointed chain. If everyone selfish mined, you could have 5 chains constantly reorging 100 blocks deep

<ofrnxmr> the status quo is a bad design

<ofrnxmr> Its not such a bad thing for bitcoin etc, because their txs arent invalidated

<fr33_yourself> > <@ofrnxmr> The only things changing is the frequency that they are checked, and the frequency which they are updated

<fr33_yourself> So it won't actually be enabled by default for miners and node runners? Miners will have to actively switch it on? If that is the case I'm not as offended by it, but still think it is a gimmicky solution. But my opinion isn't the one that will count, but rather whether or not "honest" pool admins decide to switch them on or leave them off.

<ofrnxmr> Ringct/fcmp require finality

<ofrnxmr> @fr33_yourself: Correct. It wont be enabled by default. Yes, it is opt-in

<ofrnxmr> Honest pools should be inclined to switch them on, because they wont lose their blocks to a minority who wanted to release a shadow mined chain to rewrite the blockchain

<fr33_yourself> Finality should be probabilistic as per Satoshi's whitepaper and as things are now with Longest Chain Rule. Correct, selfish mining in secret lets people with minority hashpower publish and get merged deep reorgs. But the selfish mining is the issue, not the fact that deep reorgs can happen. > <@ofrnxmr> This is about finality and mitigations to minorities rewriting the chain

<ofrnxmr> For miners, the issue is that blocks are stolen by opportunistic luck. For users and exchanges, funds are currently at the mercy of a minorty to extend their reorgs to even 11 blocks

<fr33_yourself> True, if all pool selfish mined then there would be lots of reorgs and things would chaotic and messy. Which is why selfish mining is the pain point. > <@ofrnxmr> The longest chain is the checkpointed chain. If everyone selfish mined, you could have 5 chains constantly reorging 100 blocks deep

<ofrnxmr> checkpoints or max reorgs ( finality ) mitigate the ability to maintain multiple chain splits

<fr33_yourself> I disagree. It is well designed. It just doesn't have a way of neutralizing selfish mining via incentives or mechanics yet. > <@ofrnxmr> the status quo is a bad design

<ofrnxmr> You must publish them before the checkpoints finalize the public chain

<ofrnxmr> @fr33_yourself: Its ass

<ofrnxmr> if it was well designed, zcash would need a finality layer, bch would need a max reorg depth, and qubic wouldnt be able to delete 15 sequential blocks everyday

<ofrnxmr> The longest chain design assumes that blocks are published right away

<ofrnxmr> It is not designed for "what if the chain is split 33 33 33 and each 33% decides to mine their own chain, and only publish to delete their competitors"

<fr33_yourself> > <@ofrnxmr> Honest pools should be inclined to switch them on, because they wont lose their blocks to a minority who wanted to release a shadow mined chain to rewrite the blockchain

<fr33_yourself> Yes, if they are prioritize practical profits and limiting CFB's influence on the chain then they will be incentivized to switch them on. But if they are lazy, unconcerned, or married ideologically to longest chain rules then they will not. But now when I put it that way, I can see why most admins will likely switch them on. B [... too long, see mrelay.p2pool.observer/e/16es1LIKeXpyNzVf ]

<ofrnxmr> Selfish mining is just witch speak for stealing blocks and rewriting history

<fr33_yourself> I think you may have persuaded me to change my mind. Basically the deployment of rolling dns checkpoints will enable honest miners to more easily socially coordinate around a chain without deep reorgs.

<ofrnxmr> Honest mining is what the longest chain was designed for

<ofrnxmr> A bit of finality isnt as centralizing as it sounds. The blocks that dns finalizes are the longest chain as determined by >51% of the hashpower

<fr33_yourself> Can you explain what would happen in a scenario where all of the large honest pool admins have switched rolling dns checkpoints on, but CFB tries to do a 13 block reorg? How would things unfold in this hypothetical scenario? > <@ofrnxmr> checkpoints or max reorgs ( finality ) mitigate the ability to maintain multiple chain splits

<ofrnxmr> The proof is that, cfb cannot maintain a longer chain. So even if his malicious chain is longer for a couple minutes, the honest chain will overtake it. The dns just skip the reorgs and allows honest miners to follow an honest chain (which, at the end of the day, will always end up longer)

<fr33_yourself> Yes, it was designed without consideration for selfish mining. I agree. > <@ofrnxmr> The longest chain design assumes that blocks are published right away

<fr33_yourself> I wonder what Satoshi thought about selfish mining.

<ofrnxmr> @fr33_yourself: in order:

<ofrnxmr> 1. The checkpointed nodes will ignore the reorg entirely. They will see the reorg, and temporarily (5min) ban the nodes that sent them

<ofrnxmr> 2. non-checkpointed nodes will get reorged onto the attacking chain

<ofrnxmr> 3. The checkpointed nodes will grow a longer chain than the attacking chain[... more lines follow, see mrelay.p2pool.observer/e/4s3B1LIKc0stS1dn ]

<fr33_yourself> @ofrnxmr: The proposed depth of the rolling checkpoints is 10 blocks correct?

<ofrnxmr> 5 - cfb loses all of the selfish blocks

<ofrnxmr> @fr33_yourself: Undecided. in honest history, 3 blocks is the deepest reorg weve had in years (potentially ever). 3 blocks from tip would work as mitigation to selfish mining, 10 blocks as mitigation to invalidating txs

<ofrnxmr> Cfb could still selfish mine, but would have to keep it to < 3 blocks

<fr33_yourself> > <@ofrnxmr> The proof is that, cfb cannot maintain a longer chain. So even if his malicious chain is longer for a couple minutes, the honest chain will overtake it. The dns just skip the reorgs and allows honest miners to follow an honest chain (which, at the end of the day, will always end up longer)

<fr33_yourself> I don't fully understand this situation. Can you elaborate on how rolling dns checkpoints would work in a scenario where CFB does attempt to reorg deeper than 10 blocks? Wait, the answer to my question is that it would cause a brief period of two competing chains, and if we assume CFB keeps mining his deep reorg chain by himse [... too long, see mrelay.p2pool.observer/e/n4bS1LIKRFRvdmFU ]

<ofrnxmr> yes

<ofrnxmr> There will be a brief period where honest miners keep their chain, and cfb forks non-checkpointed nodes onto his chain. Honest miners build on their chain, overtake cfb's, and cfb's gets discarded

<fr33_yourself> @ofrnxmr: I think 3 blocks is too extreme, too tight. The closer to 10 but not greater than 10 the better. I am now convinced that rolling dns checkpoints are a kosher solution as long as it is opt in.

<ofrnxmr> This works, because the people who got forced onto cfb's chain, are victims. Their txs were removed, invalidated, etc. When the honest chain overtakes, those txs and blocks are pout back where they belong

<ofrnxmr> @fr33_yourself: 3 blocks is, imo, sane, since we dont have honest reorgs deeper than that

<fr33_yourself> @ofrnxmr: One last question on this scenario, at what point do the miners "give up" and switch to one chain or the other? To be specific, how long does the "race" between the miners following the checkpoints versus the attacker need to go on before one is clearly considered to have the most proof of work - the longest chain

<ofrnxmr> As soon as it overtakes

<ofrnxmr> The honest chain is public. As soon as it is longer than the attacking chain, the attacking chain will be reverted back to the honest chain

<ofrnxmr> Cfb would have to reset and only try to selfishmine the tip 3 blocks

<ofrnxmr> (Which is a lot of work)

<ofrnxmr> Probably more profitable if he honestmines than if he fails to overtake within 3 blocks, and has to keep discarding his own work

<fr33_yourself> I'm still having a hard time getting my head around this last point. when exactly the attacking chain is discarded. Let's say it's close to a 50/50 split between miners on the dns checkpointed chain vs. CFB's chain. What would determine and when would it be determined which chain becomes the main chain?

<fr33_yourself> I am convinced that my initial take was wrong and that opt-in dns checkpoints are fine. I hadn't thought through all of the mechanics and didn't appreciate that it just gives miners a way to more easily resist selfish mining in the context of the current situation with CFB

<fr33_yourself> I still don't understand the exact convergence or settlement mechanism in the hypothetical reorg scenario though haha, but if you have other stuff to do don't worry about I can figure it out later with an LLM

<ofrnxmr> Lets say block heights are 110

<ofrnxmr> Honest chain goes 110a-121a

<ofrnxmr> Selfish chain goes 110b-122b, then releases. Causes non-checkpointed nodes to drop 110a-121a and replace with 110b-122b.

<ofrnxmr> [... more lines follow, see mrelay.p2pool.observer/e/va_21LIKeGJPODBh ]

<ofrnxmr> (assuming cfb's chain is still at 122b)

<fr33_yourself> @ofrnxmr: Ok I see, but the premise in this example is that miners on honest chain continue to build only on the honest chain even after CFB releases correct?

<ofrnxmr> Yes

<fr33_yourself> The premise is that the "honest" miners never switch to building on the deep reorg chain

<ofrnxmr> The checkpointed miners will only mine on the checkpoint chain

<fr33_yourself> So eventually if the total amount of honest miners building solely on dns chain is greater than 50 percent then it all works out fine and dandy

<ofrnxmr> @fr33_yourself: Checkpointed nodes reject any attempt to reorg beyond a checkpoint

<ofrnxmr> @fr33_yourself: Yup, tested on testnet

<ofrnxmr> it has to be opt in, because this is like a miner soft fork

<fr33_yourself> Out of curiosities sake, let's say CFB even managed to maintain his lead on his deep reorg chain for an additional 20 blocks. Would the honest miners still continue to only build and work on the checkpointed chain? Basically my question is, "will honest miners continue to build only on the checkpointed chain even if CFB is further ahead of them on top of his deep reorg chain"?

<ofrnxmr> If only users use checkpoints, then users end up stuck on an orphan chain

<ofrnxmr> @fr33_yourself: Yes

<fr33_yourself> @ofrnxmr: correct

<ofrnxmr> but his chain would need >51% of the global hashrate to be able to maintain an indefinite lead - which is why we need to coordinate with mining pools(which should be easy)

<fr33_yourself> @ofrnxmr: So basically once the miner has enabled the checkpointing, they would only defect to the reorg chain manually? Otherwise they automatically and continuously build on the checkpointed chain irrespective of how far the attacker is on their deep reorg chain? even if the attacker's chain is still ahead after an entir [... too long, see mrelay.p2pool.observer/e/0YGQ1bIKWTNKYXJs ]

<ofrnxmr> yes, their node wont even acknowledge the reorg chain. It sees it as an invalid chain and blocks the peer temporarily

<fr33_yourself> @ofrnxmr: This basically seems like a less risky version of my initial idea to have all the pool combine into one pool and totally orphan off CFB's pool haha. The outcome is similar and isn't as centralized.

<ofrnxmr> Yeah, this doesnt unleash pools to ask them to attack. This joins forces with pools to offer them finality

<fr33_yourself> Ok I'm onboard with the idea now. So basically there just can't be bugs in the code and someone has to persuade a majority of total mining hashrate that it is in their best interest to enable checkpoints and follow the checkpointed chain. I think I understand it all now. But I still think it's best to have the checkpointing oc [... too long, see mrelay.p2pool.observer/e/r5ab1bIKSTFsUnc4 ]

<fr33_yourself> Does this update even require that users update their nodes? Or only pool admins? Because pool admins could change the code themselves and run even tighter checkpoints if they wanted haha

<ofrnxmr> Users no, pool, yes

<fr33_yourself> I guess the advantage and appeal of tight checkpoints to honest miners is that CFB can't capture as many blocks via selfish mining

<fr33_yourself> Is my above statement correct?

<ofrnxmr> Yes

<ofrnxmr> When selfish mining, you are mining your private chain, hoping to get lucks enough to have a longer chain. If you can get ahead, the damage can be increased if you can maintain the lead for 3 4 5 6 7 etc blocks

<ofrnxmr> Forcing him to release in 3 blocks or less means cutting the attack / luck short

<fr33_yourself> I see then you've succeeded in completely changing my mind. I'm still not sweating it if the pools decide not to enable checkpoints for some reason though. I think CFB isn't willing to incur the financial damage he would cause to his own bags if the chose to repeatedly do deeper than 10 block reorgs

qubic is already paying more than they get for mining xmr

they burn xmr, not pay with it

<ofrnxmr> at this point, its not just about cfb, but about people who are taking notes, who might not be as.. friendly when it comes to invalid txs

ofc, this has decreased in recent weeks. but the chance that it may be used to make more marketing, more news, that's what drives them

<ofrnxmr> Cfb has said he'd go for 29 block reorgs, so i'm not holding my breath to assume he wont kick the can just to do it

he also explicitly pointed out these conversations we are having about invalidated global output indices ofrnxmr as the reason not to do them

<fr33_yourself> But what would be a very interesting scenario would be a scenario where honest miners all enable the checkpoints and then after this happens, CFB somehow manages to actually legitimately maintain greater than 50% of total network hash and mine on a deep reorg chain

<ofrnxmr> Telling peopke to wait 30 blocks doest fix that unrelated txs can be invalidatdd due to decoys changing

then he'd be double spending merchants that will not even accept his coins

<fr33_yourself> Like how would that play out? Where the honest miners are the minority of total net hash following a checkpointed chain, but the attacker actually does indeed have sustained majority hash

and earn nothing at the end of the epoch

as they do marathons, then times of off/on mining

<ofrnxmr> Exchanges will likely enable checkpoints as well

<ofrnxmr> So coins from his chain wont be valid

it'd be like someone forked monero 1000 heights deep, then built a chain but can't switch to it on most places

<fr33_yourself> > <DataHoarder> then he'd be double spending merchants that will not even accept his coins

<fr33_yourself> I see, so in a situation where he actually has majority hash he wouldn't be able to leverage it for double spends because all exchanges and merchants would follow the checkpointed chain as well. It's a social consensus defense mechanism that would theoretically eliminate his ability to double-spend assuming the counterparty strictly follows the checkpointed chain with the honest miners

effectively the point is eliminating 10+ reorgs

which also eliminate normal double spends

selfish mining would still be viable depending on parameters, and that's fine as even normal orphans happen regularly

so the highest part of the tip can get contested at times

<fr33_yourself> So to summarize the hypothetical game theoretical optimal scenario, check points would be followed by honest miners and all relevant / consequential economic actors of scale. This would mean CFB is playing donkey basketball on his own chain wouldn't be able to influence the main chain unless he decided to selfish mine and relase blocks below the checkpoint depth.

the lower part, say, a few heights deep, is normally uncontested. checkpoint there, the selfish miner needs to have a race

but the pools on their own still decide the top part

*"above" the depth

<fr33_yourself> And this would leave room for possible future solutions that more directly address selfish mining. > <DataHoarder> selfish mining would still be viable depending on parameters, and that's fine as even normal orphans happen regularly

yes, room and time

most of the reorgs they get are 1-2 deep qubic-snooper.p2pool.observer/tree

(they also get orphaned naturally)

<fr33_yourself> @fr33_yourself: Would you guys say the above scenario is accurate? Basically CFB can't double spend or do deep reorgs if all exchanges, merchants, and most honest miners follow a checkpointed chain. As to double spend effectively the victim would need to follow his chain. Which in this hypothetical scenario they would not

to double spend they'd need to follow his chain

<fr33_yourself> If the above situation is true, then I was sleeping on how effective rolling checkpoints can be a network defense mehcanism

<ofrnxmr> mrelay.p2pool.observer/m/monero.social/fvuNyDfXCBPtZPfsljdDuaBD.png (share_7461640226733040184.png)

they are trying :)

<ofrnxmr> shallow Checkpoints force them to play this game ^, where they lose as often as they win

<fr33_yourself> DataHoarder: But in my situation I presume they would not. So even if CFB had majority hash if all merchants followed the rolling checkpointed chain then CFB wouldn't be able to double-spend. That's some solid defense.

<ofrnxmr> mrelay.p2pool.observer/m/monero.social/EhmcuxjyicsZGYkCcciOHixb.png (share_3955047222033842564.png)

<ofrnxmr> And prevent this

indeed, and it's already semi-deployed besides dusting off the system and making the rest that doesn't require hard forks

fr33_yourself, this is why it has been sought for as a bandaid as it defends effectively the major pain point - while mostly keeping the power in miners hands

<fr33_yourself> @ofrnxmr: To be specific shallow checkpoints prevent a selfish miner from reorging a shallow amount which reduces his revenue and total blocks found relative to honest mienrs

effectively with the checkpoints N heights deep from tip, ensures the "first received" blocks at that point end up checkpointed

<ofrnxmr> Id prefer to frame is as reducing his ability to steal reve:ue from honest miners

it is likely that the depth they try for would be limited or timed, or they stick to pure mining

<fr33_yourself> DataHoarder: The power is pretty much entirely in the miners hands, because they can choose not follow checkpoints if they don't want to. It does introduce some centralization via the nodes producing the checkpoints, but if monero miners are concerned with that then they just don't enable checkpoints. Basically it only gives h [... too long, see mrelay.p2pool.observer/e/28vm1bIKZEwzRklW ]

<ofrnxmr> the "mine on our pool, its more profitable" is true, in part, because if you mine on an honest pool/ qubic is trying to revert your blocks

it's profitable cause they pay more

however ofrnxmr, according to data they are losing more than if they'd stick to pure mining

except on a few minor segments

as they aren't doing selfish or mining efficiently

<ofrnxmr> yeah, but i mean, they earn more xmr than normal, because they steal blocks w/o raising the difficulty

well. they still keep mining in normal intervals

at 50% but yeah

<ofrnxmr> Yeah

<fr33_yourself> Got it. This has been an insightful discussion and I look forward to seeing how the battle with CFB continues haha

<ofrnxmr> I wouldnt care if they mined normally and raised the difficulty to 7g

<fr33_yourself> I'm curious to see his tweets after this gets deployed

<fr33_yourself> See if he cries like a big baby

<ofrnxmr> i think we just need to iron out how they checkpoints are deployed and set

he will point out the centralization

as he already cried when they had their own system bugged

and instead blamed that other pools were selfish mining them

<ofrnxmr> hey, dns checkpoints CAN be done in a decentralized manner

<ofrnxmr> Just give nodes the option to checkpoint themselves

<ofrnxmr> Decentralized checkpoints may be mlre dangerous at the start, since the nodes can be targeted and forked off

<ofrnxmr> and consensus among nodes about which blocks to checkpoint can cause issues as well. With dns, all opt in nodes are agreeing to finalize the same blocks

<ofrnxmr> On a sidenote: its actually faster to mine empty blocks

to broadcast :)

the "mining" part itself is the same length

<ofrnxmr> probably obvious, but i noticed on fcmp, that the larger the block is, the more time it takes to process it. Empty empty block, i might mine in 0.01 seconds, but a 15mb block takes 0.5

yeah, tx verification time :D

I guess it retriggers for mempool txs?

<ofrnxmr> If i script a start -> stop mining, occasionally i'll mine 2 empty blocks, but never 2 full ones

<fr33_yourself> > <@ofrnxmr> and consensus among nodes about which blocks to checkpoint can cause issues as well. With dns, all opt in nodes are agreeing to finalize the same blocks

<fr33_yourself> Yep and if someone has a problem with it and wants to checkpoint differently then they can created their own checkpointing reference, change the code, and try to persuade other miners to join. It basically is just a tool that helps miners coordinate about additional non-consensus rules that they want to enforce / follow

<ofrnxmr> I'm not sure the reason, but i also messed up and took 1-2 seconds and accidentally mined 100+ blocks

<ofrnxmr> Set me back a couple days (i could have popped the blocks off, but decided not to). Back at 15mb blocks now, should hopefully hit 30 by tomorrow (which i believe is the limit)

how many testnets do you have :)

<ofrnxmr> For fcmp, just one

<ofrnxmr> Hit a bottlenect somewhere. Not sure if its running 30 wallet-rpc's, all of them connected to the same node, or what

I have seen monerod RPC slow over the days with a high volume of calls

<ofrnxmr> I shoukd probbbbaly stop the loop, reduce wallets in use and see if it helps. or connect half of the wallets to a different node

<ofrnxmr> The first thing i noticed after going to 15->30 was that a bunch of the wallets had connection issues with the node

<ofrnxmr> Bah humbug. I'm going to split this up and see if it increases the throughput