how is qubic orphaning twice :D irc.gammaspectra.live/2b71619b66c89b0a/image.png

-4 qubic irc.gammaspectra.live/d7dc823709f4f044/image.png

all of qubic's added transactions in their recent block attempts are solely composed of their own internal transactions, and none others

effectively back to 0 transactions mined, but with extra tx pollution

<anotherone:xmr.se> 3 days ago while qubic was mining my tx was struggling to get 10 confs for 40+ minutes and got resubmitted to mempool, loosing recipient address from wallet data... it was like I sent it, closed wallet, then opened again and there is delayed tx with unknown recipient

<anotherone:xmr.se> mrelay.p2pool.observer/m/xmr.se/YJEEOYNgpTGVGlpVgbDSQLbR.png (image.png)

<anotherone:xmr.se> I guess it was because of qubic :(

<anotherone:xmr.se> damn qubic

<17lifers:matrix.org> you got qubed

<lordx3nu:matrix.org> DataHoarder: Yeah this happened to me. Had to wait an hour for two transactions to go through because they got reorged and then delayed by the empty blocks.

<ofrnxmr:xmr.mx> @anotherone:xmr.se: Thx for reproducing

<monerobull:matrix.org> hey guys i just found out how to kill monero for good as a state actor without spending too much

<monerobull:matrix.org> > hoard a bunch of coins

<monerobull:matrix.org> > start mining secret chain via datacenters (not that expensive)

<monerobull:matrix.org> > sell hoarded coins

<monerobull:matrix.org> > get them all back after publishing the MOAR (mother of all reorgs)

<monerobull:matrix.org> community in shambles, more people start agreeing that PoW is dead and PoS implementation kicks into high gear

<monerobull:matrix.org> > take over PoS system with hoarded coins from way back

<monerobull:matrix.org> thats it, chain is done for, no path to recovery from that.

<monerobull:matrix.org> The only real mitigation is unironically to go PoS before the MOAR

<monerobull:matrix.org> The MOAR would crash the price so hard that you could probably take over a later PoS system without even needing the double spend the previous coins.

<monerobull:matrix.org> PoW assumes majority hash is honest

past few hours of mining irc.gammaspectra.live/24ec0087e43ec426/orphan_list.png

<monerobull:matrix.org> Majority compute is undeniably with Mega-Corps, not the people

<monerobull:matrix.org> The MOAR would cost a couple of millions at most

<monerobull:matrix.org> Attacking a PoS system the size of Monero would cost billions

<monerobull:matrix.org> Even for state actors thats a though sell

<monerobull:matrix.org> I fully believe that Monero will get destroyed if it remains RandomX only.

<monerobull:matrix.org> There might be some other schemes to make this less likely but PoS seems the most robust to me.

MsM Money securing Money

<lm:matrix.baermail.fr> @monerobull:matrix.org: billions to invest, 0 cost if successful.

<monerobull:matrix.org> it still costs billions?

<monerobull:matrix.org> you cant censor transactions on monero

<monerobull:matrix.org> so an attack can only disrupt

<monerobull:matrix.org> permanent disruption would make your billions in stake worthless

<monerobull:matrix.org> at worst a POS takeover is protocol-wide buy-out

What happened to pos is bad mkay thing?

Once you get a huge stake, you don't need to spend much resources to maintain it

Once you get 51% stake, you keep it forever

should have better nicks if users are identified and matches their connection

lol @ CfB x.com/c___f___b/status/1961409578442117519

Just use docs.getmonero.org/rpc-library/monerod-rpc/#send_raw_transaction via RPC!

can fetch tx pools from healthy nodes, or recent blocks, send back

But that's not the worst part, all their self-sent txs spam the decoy pool for users transacting normally

here's 1109 of their recent transactions doing so irc.gammaspectra.live/b6aae1a1eec6ec72/qubic-tx.txt

any decoy picked from these effectively can be discarded after a couple of days

FWIW, it should be fairly easy to discard outs from any set of blocks from considratoin when creating a fake out set for a new tx, if the daemon can maintain a list of known bad blocks.

Though the resulting time distribution might end up skewed.

This, of course, requires a new db table (or carving out a new bit in the block_info table).

it's not specifically bad blocks, some of these transactions end up on not their blocks due to how they are produced

but yeah, lately when they do selfish their blocks are solely composed of these

Could also be done in the wallet in fact.

if it has an extrinsic ground truth (which does not have to be perfect) for the list.

so effectively one of their blocks is 1 coinbase output + 3-7 of these txs, which are 2 out, so +6-14 outputs

plus any others that end up elsewhere

it's not in the levels of mordinals or when p2pool created all the outputs for main, yet

There's also the blackball system but I think it might have got removed.

rucknium right now the "% block(s) orphaned in last 720 blocks" changes when you move the slider on "Number of blocks to display after each orphan/altchain:"

moving it from 1 to 2 changes it as well as from 2 to 3, that is as far as I went

^ noticed it as well

<rucknium> Thanks. That's expected, given the architecture. The process to compute the number of orphaned blocks is inside the process to produce the plot, which is called when you change the sliders: github.com/Rucknium/xmrconsensus/blob/main/R/fct_alt_chains.R#L119

load-bearing plot

<rucknium> Shiny's reactivity architecture re-compute things when an input changes. This can be "delayed" by setting an input to only pass to the reactive function when a button is pressed. But for now, it reacts instantly as soon as an input changes.

which setting yeilds the correct %

<rucknium> The percentage is different depending on the input setting? That would be a bug.

<rucknium> I thought you meant it just refreshes

<rucknium> to the same value

choosing 1, 2 or 3 each gives a different value

<rucknium> That sounds like a bug. I will investigate. Thanks.

<rucknium> I think it's fixed. It was cutting off at 150 displayed main chain blocks. When there are a lot of orphans in the most recent 24 hours, it woudn't compute correctly. Thanks nioc and DataHoarder. Maybe I will count up known and unknown orphaned blocks

<rucknium> Because Qubic is losing a lot of the races and increasing the orphaned blocks count by being losers.

also fyi, I added an argument to monero-blocks to include external node-pool compatible apis

I sent you one of these urls over DM if you want to display qubic as qubic :)

and for testnet, the ability to query/add checkpoints

<rucknium> If you think the API/system is stable enough, I would add it. I just don't want to be chasing a moving target.

the external api system is stable and allows people to add their own sources without editing the code

the URL I gave for qubic is also stable, I have been using it on my own instance

for the checkpoints, maybe wait, I want to add an option to remove all other pool fetching (for testnet all the pools are irrelevant)

relevant option is -nodejs-pools "qubic=1.2.3.4/api"

but multiple can be added separated by comma

rucknium it no longer changes but it currently display this: "150 (20.83%) block(s) orphaned in last 720 blocks" 0_o

which is an increase to what is was b4

quickly scrolling thru it may be correct

.shrug

maybe a % of orphan ownership could be something to add later

<rucknium> Aha. Got it working already.

<rucknium> > 71 (9.86%) block(s) produced by known pools have been orphaned in last 720 blocks (about 24 hours).

<rucknium> > 79 (10.97%) block(s) produced by unknown pools or solo miners have been orphaned in last 720 blocks.

<rucknium> If all those unknown blocks are mined by Qubic, does that mean that they are losing XMR by trying to selfish mine? (Yet, if you take difficulty adjustment into account, that may not be completely correct.)

they were losing quite a lot a few weeks ago

I don't have the exact numbers, that'd be report part 2 (selfish mining strategy data or so)

but yeah ... many races lost

<captaincanaryllc:matrix.org> if the default lock time was increased for mining rewards, would that affect qubic's ability to operate?

this last marathon was how it usually was for their normal reported hashrate

it'd affect nothing, unless we bump it to years :D

they already run with a week+ delay in handing out rewards on each pool

<captaincanaryllc:matrix.org> so their cashflow doesn't rely on constant reward payouts for operation? How long of a payout delay would be needed to start causing significant disruption to their operations?

users are paid in qubic. not XMR. pools pay qubic from their own rewards

xmr earned is used to buy qubic on exchanges, then burn it

<captaincanaryllc:matrix.org> but qubic needs revenue from the monero they're mining themselves, presumably?

no. qubic again doesn't pay that monero directly. they pay in self-generated qubic

the expectation is that buying qubic by core via XMR rewards and burning it effectively brings the price up for everyone

there's also a % threshold for 50% or 100% rewards

<captaincanaryllc:matrix.org> what would happen if they didn't have xmr rewards to spend on qubic for a week?

<captaincanaryllc:matrix.org> for example

price of qubic would fall

it's more complex than that

it'd delay the burn, or however they want to do that

but people in epoch 174 are being paid with future rewards of epoch 175 already

it'd just offset their burn time

> > moneromooo (static.82.87.47.78.clients.your-server.de) changed their display name to moneromooo

:D

see this weird flowchart they have raw.githubusercontent.com/qubic/out…utsourcedComputing_MoneroPOC_v2.png

they just sell offhand the XMR on USDT pairs, then buy qubic with USDT

which then is burned

miners are always paid with qubic.

each pool can pay users in different ways btw, but most do the same

weird nick changes D:

<captaincanaryllc:matrix.org> based on that flowchart, if they can't process/swap/payout from their xmr rewards in x amount of time, looks like they'd be dead in the water. Unless they have a surplus of funds they can pull from. But that would last only x amount of time. If the rewards payout delay is > x, then what?

what do you mean? miners are still paid in qubic

if people sell qubic, price goes down yes. something else could change it

XMR rewards are the same now but qubic ones are halved

<captaincanaryllc:matrix.org> this is just mining rewards I'm talking about, other txs on the network would not need a delay

it wouldn't do much

they know how much xmr they have, they could do out of pocket :)

and that's only against qubic. someone doing something for themselves (not paying people) would not be affected

if they were paying people directly, it'd do some, but only against specifically qubic, not any other kinds of attacks. but it's already disconnected and mostly doing price pressure

<captaincanaryllc:matrix.org> I don't know how many others rely on xmr mining rewards, considering it is usually only to secure the network and results in no profit

p2pool :)

<captaincanaryllc:matrix.org> it's the "out of pocket" part I'm wondering about: how much runway do they have? If you can make them run out their runway, it doesn't matter if they will have the rewards later, because it will put pressure on qubic miners to switch to mining another coin in the meantime

it'd require a hardfork and consensus, for no noticeable change against qubic and no change against hidden attackers that don't care about the incoming XMR

there is no runway agai

price of qubic would go down if people sell and there isn't pressure

but ... it could also not

the xmr there is just doing some buy pressure, not being given directly

it'd take long to do the hardfork than it'd get them to get bored

longer*

or reach the next halving they have, maybe :D

it's not just "qubic qubic" but measures taken should be relevant for different classes of attackers if they are to be permanent

<captaincanaryllc:matrix.org> I mine monero like most people probably do on the network, p2pool, so I don't need the little payouts in a timely way. You could hold them for 6 months and I doubt it would affect most xmr miners

it'd affect all other pools, too :)

but again, what effect would it have about someone trying to do what qubic is doing, but literally just burning money away in secret

they don't care about the block reward

<captaincanaryllc:matrix.org> yeah if the xmr reward isn't something they're relying on for operation, it wouldn't matter

as well: qubic isn't relying on XMR reward for operation

the qubic gets generated regardless

it just hints price pressure via burns, which probably does more than just handing it out directly

the halving of rewards in qubic did more against than any delay would

<captaincanaryllc:matrix.org> it's hard to believe that's the case, though, considering the hashrate they're achieving, they must be getting a lot of xmr rewards worth a lot of $ to their operation

last epoch, 175, from their numbers XMR: 737 | XTM 6M

a bit below $200k

in a week

in the past they were giving people 2x-3x this amount when measured in qubic

there's already a disconnect there, even now when it's vastly lower past their halving, what they get in XMR and what they pay is disconnected

hype on their coin > what they get in XMR

<captaincanaryllc:matrix.org> I'm guessing there's no proof they're actually buying/burning qubic with their monero. Supposing that generating qubic is essentially free for qubic creator, could he not just be stealing all the monero rewards?

they do release some of their proofs/transactions later on

it's a bit more spotty as they had issues recently with exchanges they used no longer accepting XMR deposits 😆

<captaincanaryllc:matrix.org> To clarify, if I'm the creator of qubic:

<captaincanaryllc:matrix.org> 1. I mint tokens for myself for free (qubic)

<captaincanaryllc:matrix.org> 2. I tell people to mine monero and in exchange I will give them my shitcoin (qubic) I just created

<captaincanaryllc:matrix.org> 3. I'm rewarded with an actually valuable untraceable cryptocurrency (monero)[... more lines follow, see mrelay.p2pool.observer/e/obq3_68KaHI3TlZZ ]

1. they don't have minting as such, but they have some pools

4. could be. but they do publish some spend proofs when they transfer to exchange

and then publish the burned amount matches what value they transferred out

note this is not a classical token either as in ethereum or solana

it's their C++ code which changes every week :)

<captaincanaryllc:matrix.org> I'm wondering how much is actually proven to be traded/burned out of 100%

they publish these on pinned messages on Discord :)

<rucknium> I read a rumor that Qubic is funded by VC money. Any truth to this? If so, the VC money subsidizes everything.

or their own people pockets :)

<datahoarder> really if you want to check their data, go to their discord pinned messages and search for the specific announced transactions

<datahoarder> that's their consensus method for when things go wrong or "documentation". it's all pinned messages or search on discord.

<datahoarder> I'd check with my account I made to also join the monero discord, but it's in 5d timeout jail for joining, not even talking ofc

for epoch 173 their XMR wallet private keys are also available, not just view keys

so you can verify further there

bridge is so funny, someone is named "wallet" elsewhere and it auto-matches their nick on matrix side :D

<captaincanaryllc:matrix.org> smartest move would be to show proof of some trade/burn and then steal everything else

but they show burn of an equivalent amount

they could do that, they don't need to do so

their own qubic holdings probably cover anything they care to get

but for price discussion or what they could do to steal funds probably should move away from #monero-research-lounge

What is the status of DNS checkpoint testing? Might be needed soon. xcancel.com/c___f___b/status/1961356882028687738#m

regardless of depth being 9 or 10 or 15 or 29 whatever they decide, dns checkpoints as a bandaid to reorgs that could exploit double-spend even unintended is needed

<preland> Question: In the background I’ve been working on an upgrade proposal (post FCMP), and I’m currently divided between trying to finish it in its entirety before publicizing it or releasing it as is somewhere so it can be worked on. Any thoughts?

It depends on their real hashrate, which is unclear. 1-3 block reorgs are unlikely to result in double spends.

indeed, and that's the target of DNS checkpoints, prevent 10+ ones

tevador: real hashrate is able to do it, on demand

<rucknium> tevador: I think we're iterating toward a good protocol. I think we should enumerate all of the possible attack & network response scenarios and then run them several times each to make sure that the network responds as hoped and expected.

<rucknium> And we need to keep DNS delays in mind.

<rucknium> Right now the "protocol" is for the checkpointing node to record the block hash that is 2 blocks deep (i.e. if chaintip is zero, then the -2 block hash) in two different DNS records. The checkpointing node will not update the DNS record if its new chaintip rolls back, which can happen if the longest seen chain does not agree w [... too long, see mrelay.p2pool.observer/e/sMKDgLAKb2liRk1L ]

i'm available for any release that includes DNS checkpoint improvements

<rucknium> Thanks, selsta

the other part of such a release from what I remember is coordinating this being followed on exchanges and major pools if they'd like so

and that they have a proper DNS resolver that handles DNSSEC :)

<rucknium> Now I have two domains that are blacklisted by some strict DNS providers (moneroconsensus.info and moneronet.info) and two that seem to not be (townforger.net and townforgepool.net). I read somewhere that the big 3 TLDs (.com, .org, .net) are less likely to be blacklisted. I don't have any more of the big 3 TLDs, but I have a [... too long, see mrelay.p2pool.observer/e/5p2dgLAKdEVWUHFi ]

<rucknium> One of the strict DNS providers that is blacklisting those two domains: quad9.net

some ISPs/DNS providers straight up block tags

like monero

have you tried their "no malware blocking" ones? quad9.net/service/service-addresses-and-features

<rucknium> my moneroresearch.info isn't blocked, but it has been established for years.

<rucknium> I emailed Quad9 about a month ago to remove moneronet.info from their blacklist, but not response.

moneroconsensus.info works on quad9 without blocking

on their domains with blocking, it's blocked

tbh pools or exchanges should be running their own DNS Resolver

not give this to another entity

a recursive resolver, not a forwarder

<syntheticbird> shilling opportunity detected

<syntheticbird> Engagement initiated

<syntheticbird> github.com/hickory-dns/hickory-dns

as for DNS server latency, a custom dns server for explicitly just serving checkpoints would be interesting, hmm

how do the checkpointing servers agree on what entries to set?

are checkpoints placed in heights % <some number> (minus some delay for propagation)?

<ravfx:xmr.mx> I see moneroconsensus.info blocked on quad9

<ravfx:xmr.mx> Just by using the most used of there DNS resolver, 9.9.9.9

<ravfx:xmr.mx> mrelay.p2pool.observer/m/xmr.mx/zHKuclHKmFkhZZEnsIxtGJaT.png (clipboard.png)

I tried their 9.9.9.10

yes, most used is blocked, just confirming it's their blocklist and not other unrelated DNS issues

<rucknium> You can input a domain here and it will tell you why it's blocked: quad9.net

<rucknium> > Blocked

<rucknium> > Threat Intelligence Providers who have listed this domain

<rucknium> > DOMAINTOOLS Hotlist

<rucknium> > False Positive?

<rucknium> > Please contact us

<rucknium> Are you talking about my code? > <DataHoarder> how do the checkpointing servers agree on what entries to set?

I assume so. I can run similar code within "mainnet" to see what reorgs could have been avoided or state

<rucknium> That's a good point. Some scenarios can be tested directly on mainnet.

<ravfx:xmr.mx> Did you take a look at who told Quad9 it's bad?

<ravfx:xmr.mx> "About the DomainTools risk score

<ravfx:xmr.mx> DomainTools Risk Score predicts how likely a domain is to be malicious, often before it is weaponized. The score comes from two distinct machine learning algorithms:

<ravfx:xmr.mx> Proximity — how closely a domain is connected to other known-bad domains"

<ravfx:xmr.mx> PROXIMITY

<datahoarder> mrelay.p2pool.observer/m/monero.social/htXjNPnakRVIqheIfPMEPUsf.png (image.png)

<syntheticbird> AI again

<datahoarder> unrelated: the matrix bridge resolved that "reply" and converted it to a quote on IRC side

always AI syntheticbird :D

<rucknium> : I saw that and I was confused. It's pointing to the same server as other "good" domains.

<ravfx:xmr.mx> But it also point to the same as moneronet.info, I was wondering

I run the snooper qubic-snooper.p2pool.observer/tips.txt and it tracks how far ahead they are and attempts, so could have history of when checkpoints would be done and which side their reorgs land at

<rucknium> Probably the "monero" name plus recency of its registration are big factors.

ofc, last night they didn't try many long ones

<rucknium> DataHoarder: Here is the checkpointing code. It only works for Njalla's API and is messy because it used to update 10 TXT records instead of 1: gist.github.com/Rucknium/b298325e3beaf84f1d884d6fe4e84fc6

ah, I'll make a standalone dns server that does that then

<rucknium> Maybe you can see the logic.

R :)

<rucknium> If you can see past the R, you'll see the logic :P

I'll take a look later, thanks

<rucknium> The domains are "synced" to the same checkpoints because they are just iterated through in the loop.

I wonder, should ZMQ pub get a new channel for notifying of alt blocks?

Otherwise that method is RPC only

I have some scripts that use ZMQ for incoming new block headers but I need to poll manually /get_alt_blocks_hashes

then have my own logic to fetch new ones

<vtnerd> the existing interface was designed specifically to allow this extension

yeah, lemme see if I can get a quick patch

my monerod already has a couple of patches to effectively be able to handle old altchains via RPC so what's one more :)

totally untested irc.gammaspectra.live/524116ac52fe6…in_alt-and-json-minimal-chain.patch

same structure as current block notify, doesn't notify of txs in it explicitly

so full + minimal are supported

I'll run this with a couple of logging on a client

<unt0ld:matrix.org> What are the real cons of merge mining with BTC or LTC&DOGE? What does "becoming a vassal" mean? Compared to other solutions, it looks like merge mining will greatly raise the security budget while preventing Monero from being singled out thanks to the plausible deniability of mining it. Here's an argument for it:

<unt0ld:matrix.org> boards.4chan.org/biz/thread/60863030#p60866023

<unt0ld:matrix.org> boards.4chan.org/biz/thread/60863030#p60866069

<unt0ld:matrix.org> boards.4chan.org/biz/thread/60863030#p60866128

<unt0ld:matrix.org> boards.4chan.org/biz/thread/60863030#p60866383[... more lines follow, see mrelay.p2pool.observer/e/nPfIgrAKSUFiLUpn ]

<jwinterm:matrix.org> good q, I guess it would 1) dilute the brand a bit, and 2) kill the romantic notion of everyman securing the network with their smart tv and toaster

<jwinterm:matrix.org> it seems like pretty straightforward and low risk approach tho

Could the first bitcoin pool to add monero mm instantly 51% monero ?

<ofrnxmr:xmr.mx> yes

<torir:matrix.org> : I believe merge mining requires a hardfork, which we cannot do fast enough to respond to the present attack. If we have to hardfork anyway we might as well also research other solutions that don't rely on other cryptocurrencies.

<ofrnxmr:xmr.mx> Merge mining doesnt stop any of this

<torir:matrix.org> I think was actually referring to checkpointing via another chain, not merge mining. I should have clarified what I meant.

<torir:matrix.org> That still requires a hardfork, right?

<ofrnxmr:xmr.mx> where are all of these cucked (literally) ideas coming from

<ofrnxmr:xmr.mx> Why would monero become a sub-chain to litecoin?

<ofrnxmr:xmr.mx> If we wanted to be scrypt, we would have bowed to bitmain years ago

<ofrnxmr:xmr.mx> monero is the premier hash on randomx. Dogecoin is just litecoin's(the pimp's) prostitute

<ofrnxmr:xmr.mx> Doge is a useless coin with 1 purpose: fund litecoin miners by dumping doge on retail

<ofrnxmr:xmr.mx> nobody uses doge

<ofrnxmr:xmr.mx> merge mining with doge just means that monero is at the mercy of litecoin miners

<ofrnxmr:xmr.mx> And litecoin is arguably monero's most viable competition in the space. Why would ltc miners want to secure monero? Instead of zcashing it (75% on 1 pool) and dogeing it (dumping it) for litecoin gains?

<boog900> need to get wownero merge

<boog900> merge mining monero*

<ofrnxmr:xmr.mx> That, i agree with ^

<torir:matrix.org> A checkpointing solution using Litecoin or Ethereum would be to have Monero still use RandomX and publish checkpoint transactions on another chain. It wouldn't be mining on that chain at all. Rather, miners would be required to publish a transaction on the other chain containing a Monero block hash. There are probably a few va [... too long, see mrelay.p2pool.observer/e/grPvg7AKbS1xZEVY ]

<boog900> you have to publish the whole block FWIW

<torir:matrix.org> ... yes, I think that is the case.

<boog900> otherwise you can publish a hash while withholding the block only to reveal the block later

<torir:matrix.org> Otherwise Qubic could publish their reorg block hashes without publishing the actual blocks and still do the attack.

<torir:matrix.org> Also this requires miners to pay transaction fees in another coin. And requires them to run full nodes for that coin.

<torir:matrix.org> And those fees won't be cheap if we are publishing whole blocks.

<torir:matrix.org> We're talking about embedding one coin's entire block in the blockchain of another coin. And Monero blocks are not small either.

<unt0ld:matrix.org> What are the most promising other solutions right now?

<torir:matrix.org> Short-term: DNS checkpointing has some centralization but is promising as a solution to the Qubic situation.

<torir:matrix.org> Medium-term: I don't know.

<torir:matrix.org> Long-term: A lot of solutions are being discussed. The one that seems most likely to be implemented to me is a PoS finality layer. That doesn't mean that Monero becomes PoS, it doesn't replace PoW. It just means using PoS as a way of checkpointing mined blocks.

<unt0ld:matrix.org> Would the whole chain stop if the PoS finality layer is attacked, or would it only get involved to resolve PoW conflicts somehow and the chain would continue as long as PoW is also not attacked?

<torir:matrix.org> I'm not sure. I think it could be set up to act mainly just as checkpointing, in which case the chain would not stop if PoS failed.

AIUI it would not stop the chain, merely revert to the current state where a long reorg is possible.

<ofrnxmr:xmr.mx> #144 is the most promising imo

<torir:matrix.org> This one? monero-project/research-lab #144

<unt0ld:matrix.org> Doesn't do anything for 51% attacks though.

<torir:matrix.org> Yeah, good for a medium term solution only.

<rucknium> : checkpoints.redteam.cash and checkpoints.moneroresearch.info are now getting the checkpoints.

<rucknium> Sometimes I see WARNING: no majority of DNS TXT records matched, I assume due to DNS cache latency. I wonder if only some of the records matched, i.e. if we had multiple-depth rolling checkpoints again, if the node would still consider the ones that matched valid.

<ofrnxmr:xmr.mx> Only us a majority

<ofrnxmr:xmr.mx> If*

<ofrnxmr:xmr.mx> If 4 checkpoint records, i think at least 3 have to match

<unt0ld:matrix.org> How do they decide the valid chain?

<rucknium> : I am saying multiple TXT records per domain. Say that some of them match in all domains.

<rucknium> But not all of them, because some are too new and didn't propagate yet.

<rucknium> : Who is "they"?

<torir:matrix.org> The DNS checkpointing nodes.

<unt0ld:matrix.org> yeah

<torir:matrix.org> Currently it's the block two blocks behind the chain tip, correct?

<rucknium> : Right

<ofrnxmr:xmr.mx> Yeah, im pretty sure that the matching ones are valid. i think is how we got forked off on older heights > <@rucknium> : I am saying multiple TXT records per domain. Say that some of them match in all domains.

<unt0ld:matrix.org> Oh I get it.

<torir:matrix.org> The goal of DNS checkpointing is to prevent 10 block reorgs, not 2 block ones. It will not stop selfish mining, but it will prevent selfish mining from breaking the 10 block lock.

"Proof of DNS". Yes, 3/4 is the correct BFT quorum if we have 4 different domains.

<ofrnxmr:xmr.mx> The problem with going back too far..

<ofrnxmr:xmr.mx> node 1 sees 521 521 and 524 match

<ofrnxmr:xmr.mx> Node 2 sees 524 and 524

<ofrnxmr:xmr.mx> [... more lines follow, see mrelay.p2pool.observer/e/sMrGhbAKamVPV2JF ]

<ofrnxmr:xmr.mx> 🥲 i just had this happen

<ofrnxmr:xmr.mx> And idk who, but seems someone started mining testnet 💢. Other chain jumped like 15 blocks ahead

<br-m> <rucknium> Sometimes I see WARNING: no majority of DNS TXT records matched

is this selected to be the exact TXT records

or is this selected across all individual records/heights available

that way some nodes could be ahead - given these checkpoints effectively act like a ring buffer

one gets added at the front, oldest one leaves

<rucknium> DataHoarder: Right now, there is just one TXT record. Previously, I was setting 10 TXT records in a trailing fashion.

<rucknium> Here is the patch I'm running (applied to release-v0.18): privatebin.net/?352bfdedd4275501#4t…a6ob4kWgqhdxXDRz51KLvXWCxtfb1iFd8i3

<ofrnxmr> I'm trying to reason out how to get around nodes being out of sync

<ofrnxmr> node 1 checks and sees 242 242 242 241

<ofrnxmr> Node 2 checks at a different time and sees 243 242 243 243

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

<rucknium> Running on testnetnode3.moneroconsensus.info (--enforce-dns-checkpoints) and testnetnode4.moneroconsensus.info (--enforce-dns-checkpoints and the checkpointing node) .

<rucknium> How does it end up on a conflicting chain if the block hash is also encoded in the DNS TXT record?

<ofrnxmr> I need to wrap my head around it

<ofrnxmr> But it happened earlier today

<ofrnxmr> My node was reorged before requesting the new checkpoints, then after getting the checkpoints, it rolled back but was throwing errors about a mismatch of a newer block hash

<ofrnxmr> So.. checkpoints at 245, but my node only knows about 242, is at height 247, and is reorged back to 243. After getting updated checkpoint, it throws errors about checkpoint 245.. or smthn. I'll try to reproduce

<ofrnxmr> I stopped testing bcuz someone was mining testnet very fast

does updating 242 to 245 also remove them for let's say, a few seconds?

or does it hold the lock continously

as removing the previous ones would effectively let it reorg to anything

if there is no "rolling" method this clears all checkpoints each change

afaik you can update all TXT records at once

<ofrnxmr> No, it just goes directly from 242->245, and (afaict) the node doesnt "forget" old checkpoints until restarted > <DataHoarder> does updating 242 to 245 also remove them for let's say, a few seconds?

<ofrnxmr> After the attacking reorg (which drops checkpointed 245), the node is at attacking tip. Then.. after receiving the 245 checkpoint (a block that it doesnt have), it pops back to 242.. ahh. I need to reproduce to see how this breaks

<ofrnxmr> All i know for sure, is my node was stuck, but rucks checkpointing node was not