<bawdyanarchist:matrix.org> I'm about to publish my findings, of sweeping through the various selfish strategies. Which ones are more profitable, which ones are more disruptive. However, I want to pause and ask about the wisdom of this, given that Qubic monitors this chat.

It'd be reasonable to wait for the bandaid that is DNS checkpoints ... which is still blocked by an issue within monero code

<bawdyanarchist:matrix.org> Okay. If anyone is interested, I can send the results privately.

<monero.arbo:matrix.org> Why not tie it to the transaction? I'm thinking of something like view tags for wallets, a fast sort of pre-check to see if the TX is potentially valid. Preferably one that takes longer to generate than verify, in this case > <@articmine> Since the POW is not tied to the TX

<monero.arbo:matrix.org> seems more..... idk, natural, to me

<rucknium> MRL meeting in this room in 1.5 hours.

<rucknium> Meeting time! monero-project/meta #1278

<rucknium> 1. Greetings

<articmine> Hi

<hinto> hello

Hello

<jberman> waves

<rucknium> 2. Updates. What is everyone working on?

<rucknium> @jeffro256:monero.social: ping

<jberman> me: mostly fcmp++/carrot alpha stressnet bug squashing / investigating

<hinto> I've posted an implementation proposal for PoWER: monero-project/research-lab #133#issuecomment-3377869740

<rucknium> me: me: Helping get stressnet stressed. Squashed bugs in my R package to spam transactions on stressnet (github.com/Rucknium/xmrspammer). At least two other people are using it to spam. Keeping stressnetnode1.moneronet.info and stressnetnode2.moneronet.info collecting and displaying node performance data. Largest block so far was 10 MB in size AFAIK.

<vtnerd> Me: still testing carrot integration in lws. The balance key, including spend tracking has been tested as working , but the subaddress+carrot balance key testing and integration is still on going. Should've be too bad

me: updated own p2pool/monero libraries to support carrot/fcmp++ stressnet and provided some feedback on specific areas where p2pool might require changes (and changes were made, many thanks!). Made a light notes document for anyone making changes on mining related projects

<jeffro256> Howdy

<rucknium> @vtnerd:monero.social: Any thoughts about MyMonero shutting down?

<articmine> Me working on the parameters for the sanity median.

<articmine> Also researching un economical transaction attacks

<0xfffc> Hi everyone. Sorry for being late.

<vtnerd> We've been wondering what they would do with carrot changes, the upgrade was going to be painful. I feel a little responsible for forging ahead with lwsf instead of upgrading their stack - otoh upgrading lwsf for carrot will be much easier because it hooks into monero codebase unlike mymonero

<0xfffc> Me: I was fighting with a syncing issue I had in stressnet. Will be involved this week on stressnet.

<vtnerd> There's at least one lwsf based wallet in progress, but unclear whether it gets released, dtc

<rucknium> 3. Carrot follow-up audit (gist.github.com/jeffro256/12f4fcc001058dd1f3fd7e81d6476deb).

<rucknium> Anything about this item?

<jeffro256> No I think it can be closed now.

<rucknium> 4. Proof-of-Work-Enabled Relay ("PoWER") (monero-project/research-lab #133).

<hinto> Some things left in my proposal are picking the target difficulty, and penalties for misbehaving nodes

<articmine> My understanding is that PoWER was to be applied per connection

<hinto> I also thought about only including a nonce in the challenge instead of including a recent block hash

<jberman> Public RPC should expose it as an option as well

<hinto> @articmine:monero.social: it is

<boog900> @hinto: yeah I would suggest that

<articmine> Then only do it for large transactions?

<boog900> I would also make the nonce per connection

<hinto> If it's a public API and it the transaction's input count is greater than POWER_INPUT_THRESHOLD (set to 8), then PoWER is mandatory in the proposal

<articmine> @jberman: I was referring to the above

<jberman> "If it's a public API and it the transaction's input count is greater than POWER_INPUT_THRESHOLD (set to 8), then PoWER is mandatory in the proposal" -> this sgtm, spec makes it a little unclear in Interfaces section

<jberman> I think just nonce no hash also sounds reasonable

without a recent-ish hash these can be made well in advance, right?

or nonce per connection that requires these to be calculated then

<hinto> The point of the hash is to prevent building up PoW although with a large enough nonce (64 bits?) it should be okay?

each hop would require that nonce for any large tx

<boog900> @boog900: If you don't do this you allow multiple connections with 1 PoW solution

<articmine> DataHoarder: Just ROC?

<articmine> RPC

<boog900> @hinto:monero.social: the nonce is the challenge right?

<jberman> POWER_NONCE_WINDOW=60, POWER_NONCE_LEEWAY=1 -> as in, if a nonce is 100s old, it is accepted? but not if 130s?

<hinto> yes

RPC to node, this node then does PoW connections to other nodes... how do other nodes broadcast their txs? more PoW?

they have to pay the price for someone making big txs -> they might as well drop all big txs

<hinto> @jberman:monero.social: yes, the previous could be accepted as leeway

specially with dandelion++, where they spread it

<articmine> The big TX price is paid by the wallet if it is RPC

<boog900> I don't think we need a LEEWAY or a timeout on a nonce if per connection

if nonces can be reused per TX, that works. I'm talking about having it be per-connection

<jberman> @hinto: If the nonce has a max validity window of 120s, I don't see how block hash is better at preventing building up PoW unless I'm missing something

<articmine> Correction Pubic RPC

<articmine> Public

but you can also submit txs via P2P, right?

<boog900> @boog900: you can't build it up if you need to connect for your challenge first, unless I am missing something?

<hinto> @jberman: It must be a recent block hash, where as the nonce is just a integer that could be per-computed, although this might be fine too since I think it will be infeasible to do so

<jberman> @boog900: if you allow lazy proofs on relay after making the initial connection, it seems to make sense

<jberman> @hinto: gotcha, might as well go for 128 bits of randomness imo

<jeffro256> One issue I see with a fixed nonce per daemon per time-frame: is it just as easy to open 1000 connections as it is 1. As soon as the PoW for that nonce for that timeframe is used, it can be reused for the other 999 connections.

<hinto> @boog900: The leeway is for the brief interim when the daemon refreshes its nonce, similar to OTP systems allow the previous code

<boog900> there is no need to refresh a nonce if it is per connection tho

<boog900> all connections have different nonces

<hinto> hmm okay... that does make the RPC/ZMQ more complicated to implement, the current proposal is stateless on the daemon side

<jeffro256> Also: timing it around a moving window is clunky. The daemon should generate a symmetric secret on startup. Then have an endpoint where it issues new nonce every single request, returning a MAC-ed message with a challenge, timestamp, deadline, and difficulty target. If you can submit PoW for that specific challenge by the dead [... too long, see mrelay.p2pool.observer/e/-PHu8rwKeGNNcHZ1 ]

<boog900> we can always have different behavior for P2P/RPC PoWER

<kayabanerve:matrix.org> Hello, sorry for being late, I received a time-sensitive email right and was replying as the meeting started. I have nothing I've worked on to publicly state yet other than more traditional development, and the hopes we'll have some paper work re: our Generalized Bulletproofs further touched up soon.

<boog900> but we are always going to need some sort of state to verify each connection has independent PoW

you can make the randomness be tied to a local counter + incoming address details

<articmine> Yes to avoid say 2000 connections using the same POW

ip/port/other side id + local incrementing counter

<articmine> BS company

<articmine> Blockchain surveillance

then you take a hash of this, that's the nonce, so you don't keep generating duplicates

<boog900> but you then need a counter which is state, right?

or purely randomly generating it, would work as well, using both sides chosen entropy to agree on a nonce

boog900: as a global counter to ensure it's not repeated, not per connection

<hinto> @jeffro256: would exposing that endpoint be an easy DoS vector?

<jeffro256> Shouldn't be. AES is pretty fast

<hinto> I'm not sure how much impl complexity is okay for the wallet/vendor side it was kept simple

anything other than deterministically calculating (hash this entropy) the nonce via connection parameters (and global randomness) would require state to be kept around, indeed

<boog900> DataHoarder: how would you keep track of what number you gave out?

<boog900> like if I keep responding to the PoW with the same number for the counter how would you tell its been used before?

you know the incoming connection addr/port (and target port), you know your global randomnness (which may be changed depending on time, the counter), and getting the current nonce is H(connection || randomness || counter)

you'd need to connect on same address/port with same origin IP and port. which in that case, the connection is not allowed

(if peer id is kept, that is additional state)

<boog900> no what if I send a bad tx, then I can reconnect and send another tx with the same PoW

aha. but that would ban the peer, right?

bad tx

<hinto> new nonce per unique connection does prevent PoW reuse, what would qualify as a "unique" connection?

<hinto> I have thought about this too although couldn't an attacker send multiple transactions under a single IP?

TCP connections are identified by the local ip/port + remote ip/port

<boog900> DataHoarder: true, I don't know how RPC would handle that but yeah

the key part is involving the ip/port

not just ip, as part of the nonce given out

<articmine> @hinto: No disconnect

<boog900> @hinto: for P2P, txs are verified one at a time

usually this source port is chosen randomly, so each connection on same ip would get different PoW nonces. In the case they reuse the same ip/port, this connection is not a valid TCP connection so it'd be refused

this is assuming TCP is used.

in case of Tor nodes, the ip/port combo is the local tor ip + random source port

so to clarify, say you are running monero P2P or RPC on TCP 1.2.3.4:100, you get an incoming connection from 7.8.9.1:4567 . H(1.2.3.4:100 || 7.8.9.1:4567 || global random || global time counter) gives you the current connection nonce, like TOTP

no other TCP connection can be concurrently active on the 1.2.3.4:100, 7.8.9.1:4567 pair

if your node exposes multiple IP addresses or ports they could connect to the second ip/port, but that would also change the nonce

regularly global time counter is increased like in TOTP > POWER_NONCE_WINDOW=60, POWER_NONCE_LEEWAY=1

TOTP is 30, +-1

<articmine> Is it possible here to get around a temporary ban after the first bad TX. I am not sure .

so it's quite similar with those parameters, allow previous+current

They could connect from a different ip, but that'd end up having to solve more PoW

<boog900> I'm not sure if this solves the complexity for hinto

<boog900> for p2p I think this is more complex

<boog900> but for RPC 🤷

<hinto> If the scope keeps increasing, I think it would be a much simpler impl if it was PoW per TX

RPC if connection is closed, it'd pick a different source port next connection. if connection is kept open (keep alive, or http/2) that'd allow multiple requests in

<boog900> rather than just generating a 16 byte value on connection and attaching it with the other connection details and using that for PoW

<articmine> PoWER for bad node behavior in general can actually be very useful

<articmine> No just a bad TX

<boog900> 👀

<jberman> challenge/response dependent on network protocol I think is overly complex

<jberman> single endpoint, add a little state per connection, I think is an acceptable level of complexity

they are currently all TCP :)

<articmine> I say trigger PoWER after:

<articmine> 1) A significant time out

<articmine> 2) Specific bad node behavior

it could still be generated like this, or be state, I think how to generate this randomness can be left for out of meeting or later discussion, no? as long as we can guarantee for further topics that it is "unique" within relevant time periods

<articmine> Or above

<boog900> For p2p we can pass in the handshake different values for difficulty depending on what the connecting node wants to do

<boog900> i.e. tx_relay_difficulty, minimum_difficulty etc

<boog900> but I would leave this for a later discussion

<articmine> Yes

<hinto> okay, I'll update the proposal further, I think we can move on

<jberman> ty hinto

<rucknium> 5. Transaction volume scaling parameters after FCMP hard fork (github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-07.pdf). Revisit FCMP++ transaction weight function (seraphis-migration/monero #44).

<jberman> @rucknium:monero.social: what was that huge block size on stressnet again?

<rucknium> Almost 10MB

<rucknium> stressgguj7ugyxtqe7czeoelobeb3cnyhl…ae2t3avd5ynepid.onion/block/2850011

<rucknium> ^ Tor browser required

<jberman> 10MB blocks in <5 days of heavy stressing

<rucknium> Mostly 1in/16out because of the spam pattern at the time.

<rucknium> Penalty was almost completely used since I set those txs to highest fee.

<articmine> My one comment here is that the penalty is quadratic with transaction weight. This leads to quadratic transaction fees with weight.

<articmine> This being said the penalty does not have to be quadratic with number of inputs, size, verification time etc

<articmine> What happened with the 10 MB blocks?

<articmine> On stressnet

<jberman> Just saying on my end, 10MB block seems kind of high to me in less than a week

<jberman> I still haven't had the chance to go through the latest proposal. But I'll be curious to see what max growth would look like under the latest

<articmine> @jberman: One actually needs ~20x factor to accomodate holiday shopping. This is the experience with VISA

<articmine> At least before the advent of widespread delivery with a ~ week time factor

<articmine> Delivery apps are like in store purchases here

<rucknium> You can grow the block limit rapidly by paying high fees, which has happened on stressnet. When fees are set to their minimum, blocks grow very slowly.

<jeffro256> @jberman: Tbf, last time I checked, the sum total of XMR in mempool fees was ~5.9 XMR, ~9.8x higher than block subsidy

<jeffro256> Normal fees are ~3% of block subsidy

<articmine> So what is stopping stressnet is a lack of "spam"

<articmine> To pay the fees

<articmine> @rucknium: That is by design

<articmine> It also comes into play when one reaches the long term median cap

<articmine> On the short term median

<rucknium> AFAIK, on stressnet there have been three fee strategies. By default, my large-volume spam pays the min fee (tier 1). That level of fees can keep the txpool full and still fill blocks to their penalty-free limit so that the progress toward larger block sizes is not lost. @ofrnxmr:monero.social 's spam pays tier 3 fees I think. [... too long, see mrelay.p2pool.observer/e/0_CU9LwKZHhhcmJI ]

<rucknium> AFAIK, you would not get to 10MB blocks without paying very high fees. The 10MB block had fee total 10.8 XMR because most or all txs paid the tier 4 fee.

<articmine> Are you limited by the amount of stressnet XMR?

<rucknium> @articmine:monero.social: It's manageable. Next stressnet, we should have a plan to systematically distribute XMR for spamming purposes.

I can mine larger blocks by loss of profit but burning up base reward :)

<rucknium> I have a lot of stressnet XMR because I had a lot of main-testnet XMR. And of course it transfer to the hard forked stressnet.

<articmine> @rucknium: Lower the difficulty on stressnet

<rucknium> kico made a faucet, too

<articmine> This may be issue here

<rucknium> We are still in the scaling parameters agenda item

<boog900> surly you only need to pay as much XMR as the block reward spread across all txs to cause the block to increase?

<boog900> *cause the block to be the max size

<articmine> Actually to max it out one needs 4x

<articmine> The block reward

<rucknium> faucet.xmr.pt

next time just 1000x reward :')

<boog900> @articmine: ah ok

<rucknium> Should we move on to the stressnet agenda item?

<articmine> Realistically we should be looking at BSV max transactions rates to test this out

<articmine> Sure

<rucknium> 6. FCMP alpha stressnet (monero.town/post/6763165).

<rucknium> Several bugs have been identified already. Some fixed.

<jberman> Will be pushing a fix for the edge case you identified of 2 block reorg immediately after wallet creation today, continuing investigation into connection issues that mostly seem to revolve around brushing up against byte size limits

<jeffro256> I'm currently looking into the higher-than-expected memory usage

<articmine> coingeek.com/152-million-transactio…in-a-day-another-new-record-for-bsv

<rucknium> The FCMP transaction CPU verification efficiency has exceeded my expectations :)

<articmine> @rucknium: Still on a single thread?

<rucknium> @articmine: @articmine:monero.social: Higher tx volume than now is possible, but nodes are already having connectivity issues, so it make not be useful to push it beyond where it is now.

<articmine> What kind of bandwidth per node?

<jberman> Could be wrong here, but seems like blocks the past day or so have been smaller than before. Some problems w/byte size limits trigger around 4mb, but it seems like people are still having connectivity issues the past day even though blocks haven't been that big?

<rucknium> Yes, still single-threaded AFAIK. But, not too much worst than last year's RingCT stressnet, byte-for-byte. Of course, FCMP txs are larger than RingCT, so tx-for-tx it is much worse.

<rucknium> @jberman:monero.social: txpool is larger. I think that's the problem.

<articmine> How is TX pool stored

<rucknium> Yesterday, block size ran up and then the txpool was exhausted. That sends the block limit lower once the 100-block trailing median falls.

<rucknium> @articmine: We still have the mainnet tx relay that sends the whole tx to every peer. Bandwidth is a lot.

<articmine> So then what are the limitations?

<jberman> bugs

<spackle> I'd like to briefly highlight the txpool self-limiting. It is visible on Rucknium's monitor node.

<rucknium> And preventing different threads from blocking each other. I want to get cuprate on the next stressnet for a RingCT stress to compare.

<jberman> @spackle: that one has been on my list to tackle for a bit

<rucknium> I think for next FCMP stressnet, the new tx weight and scaling parameters need to be implemented and PoWER.

<rucknium> @0xfffc:monero.social and @boog900:monero.social 's tx relay efficiency implementation could be good to test in the stressnet, too.

<jberman> Worth mentioning, the issues we're seeing now for the most part don't seem to stem from FCMP++ (except that obvious reorg bug)

<articmine> @rucknium: I expect this to have a significant impact

<rucknium> There was no complete network chaos and netsplits like the beginning of last year's stressnet. The main problems that caused that have been fixed AFAIK.

<rucknium> @jberman: @jberman:monero.social: Good point to mention :)

<jberman> tx weight and scaling 100%, I don't think PoWER is a requirement. PoWER is mostly a DDoS repellent, not expected to have an impact on node perf > <@rucknium> I think for next FCMP stressnet, the new tx weight and scaling parameters need to be implemented and PoWER.

<rucknium> More about stressnet? Stressnet discussion happens in #monero-stressnet:monero.social on Matrix and ##monero-stressnet on Libera IRC.

<articmine> I would not use PoWER on stressnet, at least for now

<rucknium> 7. Mining pool centralization: Temporary rolling DNS checkpoints (monero-project/monero #10064), Share or Perish (monero-project/research-lab #146), and Lucky transactions (monero-project/research-lab #145).

<rucknium> Qubic did some selfish mining recently. Any more comments, DataHoarder?

Not more comments other than they seem to get more hashrate recently (1.8 GH/s) but then also went down

they stopped selfish mining now.

<rucknium> DNS checkpoints implementation is stalled because of a edge case bug that is being tracked down. AFAIK, @0xfffc:monero.social was working on it.

<rucknium> I can't debug C++, so I cannot help there.

<rucknium> I don't know how to push it toward completion. I think other devs either don't want to get distracted from their current work to try to finish implementing rolling DNS checkpoints, or don't fully agree with the approach. Or they agree but don't want to get blamed if it's deployed and something goes wrong 😉

<rucknium> Or are maybe like tevador and agree with the approach, but only wants to code in clean pure C instead of getting into dirty C++ 😛

<rucknium> Once stressnet can "coast", I hope to look more closely at Share or Perish, especially trying to implement a Markov Decision Process to analyze it.

<rucknium> Any more discussion on this agenda item?

<bawdyanarchist:matrix.org> I have preliminary results for selfish mining simulation under realistic network modeling and difficulty adjustment, sweeping through a range of permutations (strategies) they could use.

20:40:29 <br-m> <rucknium> I can't debug C++, so I cannot help there.

I tried to reproduce, but I don't have a proper repro case

<bawdyanarchist:matrix.org> Ready to pubish, but I'm not sure if it's the best idea to give Qubic free analysis on which strategies are best for network disruption. It might not be real problem, but I thought I'd at least ask the question before publishing

<rucknium> @bawdyanarchist:matrix.org: How does it compare to results already published in the literature? Is the difference that you consider difficulty adjustment, but MDP papers do not?

<bawdyanarchist:matrix.org> In terms of profitability, simulation corroborates the Eyal-Sirer (classic) selfish mining MDP, but diverged from the stubborn mining publication. The simulation models realistic network delays and difficulty adjustment. Gamma for example, is an output of the sim, not an input. Honest forks are created by modeled latency, as opposed to heuristics.

<rucknium> Is this the first research where gamma is endogenous?

<bawdyanarchist:matrix.org> As far as I'm aware, yes.

<rucknium> (Endogenous means that the variable is determined inside the system, not a variable of the system that is assumed to have a particular value.)

<spirobel:kernal.eu> what is this held back by now? monero-project/monero #10075#discussion_r2407941460 saw this comment regarding monotonic time vs wall clock > <@rucknium> DNS checkpoints implementation is stalled because of a edge case bug that is being tracked down. AFAIK, @0xfffc:monero.social was working on it.

<bawdyanarchist:matrix.org> When running with purely honest hashpower, and ping set at 70ms, I'm replicating Monero's natural fork rate, at about 0.24%. This is running with 9 total pools, mirroring hashrate distirbution we normally see.

<bawdyanarchist:matrix.org> And yes, gamma is a derivative of the simulation, a byproduct of stochastic latency

<rucknium> Maybe share it with me and DataHoarder. We (especially DataHoarder) can evaluate the risk of Qubic getting useful info from the research. Others could help, too.

<rucknium> @spirobel:kernal.eu: A specific sequence causes nodes that enforce checkpoints to fail to sync new blocks.

<bawdyanarchist:matrix.org> Yes, I think it would be good for at least one other person to take a look privately first. The report is ready to go, and not terribly long.

I can take a look 👍. Qubic already implemented other countermeasures from previous public discussions so they should be delayed (a reasonable time, not forever) until bandaid is there

<rucknium> Sounds good to me. Thank you, @bawdyanarchist:matrix.org , for working on this! It should be interesting.

<rucknium> Any more discussion?

<spirobel:kernal.eu> @rucknium: so a second PR is necessary to address this part ? quoting ofrnxmr from the PR description here: Note: there is an issue unrelated to the PR that can leave nodes in a bad state

<spirobel:kernal.eu> Node is reorged

<spirobel:kernal.eu> Node receives a checkpoint that references the now orphaned chain[... more lines follow, see mrelay.p2pool.observer/e/kpfP9bwKa185UE53 ]

<rucknium> @spirobel:kernal.eu: Yes, I think that is it. It would be great if you wanted to help :D

<rucknium> @ofrnxmr:monero.social , DataHoarder, and I could get the sequence running again on testnet

in a bit. I tried attacking myself as well

<spirobel:kernal.eu> @rucknium:monero.social: i am busy with wallet code. Not going to promise anything :D

<rucknium> We can end the meeting here. Thanks everyone.

<spirobel:kernal.eu> the logic of handling checkpoints should be separated from handling reorgs because of longest chain rule. It seems like part of the struggle is that those two consensus rules are intermingled.

<spirobel:kernal.eu> This should also be a topic interesting for kaya as the same situation would apply to the finality layer

<articmine> Thanks

<spirobel:kernal.eu> my understanding is, (correct me if I am wrong) that a finality layer would be a more decentralized version of checkpointing. So practically its important to figure out the logic of this codepath and how to untangle it.

<0xfffc> monero-project/monero #9933#issuecomment-3382892067

<ofrnxmr> @spirobel:kernal.eu: Yeah. There is 2 different codepaths that handle the reorg. The first goes through the conditions on L2090 of blockchain.cpp, and i believe the first is_a_checkpoint should be triggering here. But it always evaluates as false

<ofrnxmr> The latter (i dont remember where it is) causes the chain to roll back to a block before the checkpoint (instead of switching to the alt chain that has the checkpoint). After which the node blocks a) incoming blocks that dont match the checkpoint b) incoming blocks that do match the checkpoint, but are orphaned c) newly mined blocks, because they dont match the checkpoint

<ofrnxmr> Forcing is_a_checkpoint = true, seems to solve the issue. So thats as far as i understand whats going on

<spirobel:kernal.eu> @ofrnxmr: the logic really shouldnt be in this function as these two things are not related. Longest chain rule is normal operation, while checkpointing is above that. It is a separate rule so why should it be handled in the same function?

<spirobel:kernal.eu> also we are in big trouble btw if the 6 dns domains give conflicting checkpoints. Are there measures in place to prevent this and assure there is consensus among the checkpointing nodes?

<rucknium> The checkpointing script serves the same checkpoints to all domains. The only problem can happen with DNS record latency. If a supermajority of records received by a node that enforces the checkpoints don't match, then the node just doesn't bind the checkpoint.

<spirobel:kernal.eu> We also have to separate here between nodes that miners operate and nodes that users rely on. Checkpointing is a tool for honest hashrate to coordinate and form the longer chain, even if a malicious party with a large amount of hashrate tries to disrupt the network.

<spirobel:kernal.eu> Another aspect is that currently the blocking behavior is intermingled with this as well. We have 3 topics that need to get untangled: the two consensus rules and blocking behavior.

<ofrnxmr> @spirobel:kernal.eu: They have to be 2/3+1 agreeing before the node accepts them

<ofrnxmr> So, in practice, 5/7 have to match

22:13:08 <br-m> <spirobel:kernal.eu> also we are in big trouble btw if the 6 dns domains give conflicting checkpoints. Are there measures in place to prevent this and assure there is consensus among the checkpointing nodes?

they will never set checkpoints that do not have previous checkpoint as part of their chain

<bawdyanarchist:matrix.org> @rucknium:monero.social: DataHoarder I DM'd you with the link to a private github repo with the report.

<datahoarder> You probably need to DM me @bawdyanarchist:matrix.org

This user is in IRC

So send to the Monero.social one (funny how the bridge makes that work so well)