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

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

<rucknium> 1. Greetings

<jberman> waves

<vtnerd> Hi

Hello

<spirobel:kernal.eu> hi

<articmine> Hi:

<spackle> Hi

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

Hi via IRC

monerosim. I was able to get some real topology data to create a realistic network for the simulation

<rucknium> me: Developing protocol and testing DNS rolling checkpoints monero-project/monero #10064 gist.github.com/Rucknium/daf4d52976fc4d32e378771f2e45f8f1 . Analyzing the 18-block re-org on September 14: gist.github.com/Rucknium/d055e95c92b66ba7109194720e9dff2e

I have updated the fee and large block analysis

<vtnerd> me: got carrot scanning into lws. Legacy, incoming, and balance keys are supported. LWS API only needed minor tweak. Testing is ongoing, and additional updates for subaddresses+incoming keys are needed

<vtnerd> Spending fcmp++ is the next big push after getting incoming funds to work

<spirobel:kernal.eu> looked at privacy expectations towards (remote) nodes and decoy selection code

me: produced a timeline of the 18-block reorg on Sept 14th with included full block headers and missing transaction blobs for anyone to replicate the data, and a second-by-second timeline from received events on my node and stratum observers. Includes Tari/P2Pool witnesses.

<jberman> me: opened PR for daemons to kick invalid txs from pool upon popping blocks (e.g. to handle a reorg) monero-project/monero #10085, and for wallets to identify spends in the pool upon restore/if they're not the sending wallet (monero-project/monero #10083), and continuing on the open fcmp++ refresh PR addressing review comments

<bawdyanarchist:matrix.org> Very close to beta release for the sim.

<rucknium> Ping @jeffro256:monero.social

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

<jeffro256> Howdy

<jeffro256> Cypherstack released the result last week, and I have been looking over it. Will probably okay it today or tomorrow

<rucknium> Can you link the result?

<jeffro256> It's a draft at the moment

<jeffro256> I would want to make sure that Cypherstack's okay with releasing it first

<rucknium> Ok. Any more on this item?

<jeffro256> No, hopefully should be wrapped out by next week

<jeffro256> *up

<rucknium> 4. Transaction volume scaling parameters after FCMP hard fork](github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-07.pdf).

<rucknium> I will limit discussion on this item to 30 minutes maximum.

I have updated the fee calculations

My recommended proposal is C

This keeps the penalty free zone unchanges

increases the reference transaction size to 20000 bytes. This effectively doubles the fees

can you provide the link? I don't see a "C" on that PDF

It does allow for transactions to scale with the low fee up to 20000 bytes or 8 input transactions

It was updated in this commit. The files are TXSize2025R03C.ods / TXSize2025R03C.xls but no pdf was uploaded ArticMine/Monero-Documents edd9ed7

There is a fee level increase for transactions above 20000 bytes of 4x

<jberman> It doesn't look like fees are increasing linearly relative to input count

Fees for a 2 in 2 out transaction will be at current market rates about 0.03 USD

There is a step function at 9 inputs

It is approximately linear if one compares say 1 input with 128 inputs

Similarly for verification time

vs fees

<hbs:matrix.org> ArticMine: What would the fee be for a 128 input tx?

7301 micro XMR

it is actually lower per input than 2 inputs

TXSize2025R03C.ods @ cryptpad.fr/sheet/#/2/sheet/view/mk…yhDr7PQbJUb6+vmOb-y4cGh5lZBxv8inArA

I do believe this addresses most of the concerns

<jberman> need more time to review it

I would suggest placing any more comments question in the GitHub thread This will also allow people to properly review this

Can you link the github thread?

so a ~120 input tx can add 147 kb to the chain, takes 3 seconds to verify, and costs 0.007 monero

<articmine> No 0.07 XMR

<articmine> Or about 3 USD

<jberman> tevador: seraphis-migration/monero #44

<articmine> Thank

<articmine> Thanks

 7007 / 1e6 = 0.007 right?

Thanks. I was looking under monero-project and couldn't find it.

same here

<hbs:matrix.org> 0.007 rather, very similar to the current fee for a 128 in / 2 out tx > <@articmine> No 0.07 XMR

I still see 1MB penalty free zone in the .ods file, which is an increase from the current value.

No whe onne factor in the change in tx size

7007, move the decimal over 6 places to the left, gives you 0.007 . what am i doin wrong

It is actually a reduction

<ywu999:matrix.org> hello

I think we can discuss this in the github thread.

if we increase the tx wight by a factor of 4X we should in crease the penalty free zone by a factor of 4x to keep fee scaling rate etc the same

so there a slight decrease

in goin from 1.2 MB to 1 MB

<ofrnxmr> Thats 21usd > <@articmine> No 0.07 XMR

It is 0.007 XMR

so about 2 USD

<ofrnxmr> Ok gotcha

Any more questions?

<rucknium> 5. FCMP alpha stressnet planning (seraphis-migration/monero #53#issuecomment-3053493262).

<rucknium> Work continues on seraphis-migration/monero #81 , which is the last code to merge before alpha stressnet can occur, AFAIK.

<ofrnxmr> There is another pr that builds on 81 as well (the parallel verification)

<jberman> Yep, continuing on 81

<ofrnxmr> I think, for the most part, its ready for a larger testnet. I still have periodic issues, but maybe easier to diagnose with a larger sample size. I might also spin up a normal private testnet to see if i can reproduce on master (txpool and double spend errors)

<kayabanerve:matrix.org> I'd like to propose an update to the FCMP++ of a 10,000-output limit on miner transactions, which is absurd and >300KB, and accordingly shouldn't be a problem.

<kayabanerve:matrix.org> (I bring it up now as we're discussing the new FCMP network and it's one slight tweak to the rules I'd like to have included)

<kayabanerve:matrix.org> Any objections to the idea/chastisement for derailing the conversation?

<ofrnxmr> yes. 300kb is too low. The penalty zone is proposed to move to 1000kb sir

^ That's up for discussion.

<jberman> No objection from me. sech1 probably has the most relevant opinion since p2pool is the only miner making multiple coinbase outputs per tx

<ofrnxmr> Is there a limit today?

<kayabanerve:matrix.org> 300KB for the _miner transaction alone_, which is currently allowed to be of infinite size.

<kayabanerve:matrix.org> The block size itself.

<ofrnxmr> the problem with too many is that thr outputs will be unspendable

<kayabanerve:matrix.org> So you can request a TX, and a node can tell you it's 10 GB, and you won't know if that's true or not because you can't verify it until you've received all 10 GB.

<kayabanerve:matrix.org> Hence why I'd like to set a bound on the per-TX size, which we have for non-miner TXs (1 MB).

<ofrnxmr> .6/10000=0.00006, less than the fee to include the output

<kayabanerve:matrix.org> But miner TXs are unbounded, so I'd like to introduce a bound so we can finally say TXs as a whole have a bound.

<kayabanerve:matrix.org> 10,000 is just an absurd number no one should object to? I'm fine with lower, but P2Pool may want at least 1,000 in theory.

<ofrnxmr> @ofrnxmr: The other side of this, is if the blocj rewards is large due to fees

<kayabanerve:matrix.org> So I don't think we can immediately agree on 1,000, but we should be able to immediately agree on 10,000 as without issue.

<ofrnxmr> @kayabanerve:matrix.org: I think p2pool is 2160 cc @datahoarder sech1

<jberman> Personal preference is lowest that p2pool is ok with

Why set a limit on the number of outputs and not the tx size?

Depends on parameters. Usually 2160 unless dynamic difficulty kicks in

<kayabanerve:matrix.org> Personal preference is 16

<kayabanerve:matrix.org> :p

<kayabanerve:matrix.org> tevador: Ugh, you're right, miner TXs still have extra unless the 1060 rule is also applied to miner TXs.

Coinbase outputs are relatively cheap (view tag + output key + amount) as there are no expensive inputs

<kayabanerve:matrix.org> 1060 is being promoted into consensus with FCMP++. I'd ask jberman to check if that covers miner TXs.

<articmine> I was suggesting 160000 hard cap on TX size

checked, only different one is nano but they all have a PPLNS window of 2160 which gives that amount of outputs + a bit more due to uncle blocks

<articmine> 160000 bytes

<kayabanerve:matrix.org> You're right I just want a miner TX size limit though. While extra + output bounds are the most straightforward way to achieve that IMO, I'm also fine saying miner TXs can't exceed 300KB.

700+ outputs is about 48 KiB in p2pool block header

27 KiB for 700+ on coinbase alone p2pool.io/explorer/tx/6d44248a92458…1e43730e03c59386f792196f06bd0003150

<kayabanerve:matrix.org> So 300KB would be ~7000

<kayabanerve:matrix.org> I'm also fine saying all TXs must be <~150 KB for the record.

<articmine> I still say 160 KB

quick math gives about 92 KiB for 2160 outputs with some rough estimates

if needed p2pool can change parameters around hardfork time, as miners will have to update regardless. has been done for view tags.

<ofrnxmr> coinbases on fcmp are the same size as current?

it's an ephemeral pubkey output

<kayabanerve:matrix.org> FCMP++ shouldn't change the size of the miner transactions.

<jeffro256> @kayabanerve:matrix.org: as written, I don't think the FCMP++ rules assert the size of tx extra on contains, but I think it's a good idea and it could be updated relatively easily

<kayabanerve:matrix.org> Oh, CARROT commentary.

A general 160KB tx size limit would probably work. Enough for a 128/16 tx or >4000 miner outputs.

<jeffro256> @kayabanerve:matrix.org: Carrot adds 18 bytes per output

however, p2pool miners sweeping coinbase will blow their txs sizes under FCMP

<kayabanerve:matrix.org> So, 1060 extra to miner transactions and transactions, 10,000 output limit to miner transactions _at a minimum_, and sounds like we're continuing to discuss ~150KB as a global rule?

I don't know if a special kind of miner coinbase sweep would be allowed without privacy (if common p2pool case is desired) that coalesces all to one output

Keep it in mind that sweeping 2160 outputs will take 2160/K transactions of K inputs

Was discussed here: monero-project/research-lab #108

we already have miners doing almost daily sweeps hitting the max size for tx

<rucknium> If possible, I think special transparent sweeps for coinbases is OK.

I bring it up each time, but if FCMP will limit that massively it can affect specifically current form of p2pool more than it does fee wise, and push people to centralized pools. I think it's fine discussing this outside the scope of this meeting, linked issue can be revived

<rucknium> Maybe a can of worms has been opened.

<ofrnxmr> @rucknium: Always has been

<kayabanerve:matrix.org> @rucknium:monero.social: I'm not hearing objections to 10,000 outputs as a limit for miner transactions so I'm taking my victory there.

It's just not as much of a problem now but it's one of the main cons people talk about p2pool or which p2pool to select.

<ofrnxmr> DataHoarder: 128input sweeps arent much bigger than 146 rct sweeps

<rucknium> Yes, always has been opened, but at this specific meeting where Qubic response still needs to be discussed.

<jberman> tevador: Worth double checking max tx size when there are n layers in the tree we're satisfied with. Current code has a limit of 12 layers, which supports a max of ~100 quadrillion outputs in the chain

10k outputs sounds more than reasonable, 2160 was selected due to limit on size broadcasted around

<jberman> (the more layers in the tree, roughly the larger the FCMP++ proof)

It would actually be better if the "coinbase consolidation" tx didn't use ring signatures and only had one output. Such transactions would be very small and fast to verify (no membership proofs and range proofs needed) and would not leak any useful information since one output means the outputs have not changed ownership.

^ quote from #108

<articmine> DataHoarder: This would be applied to the transaction weight, which needs to be fixed for FCMP++ membership proofs. An increase in the tree must not change the weights of the proofs

<articmine> @jberman: I was referring to this comment

<articmine> So yes the actual size in bytes can increase over the 160000 byte limit

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

<rucknium> I posted about rolling DNS checkpoints on monero.town: monero.town/post/6680879

<rucknium> MoneroResearchL on Twiter posted about it too: xcancel.com/MoneroResearchL/status/1967336540037636427

<rucknium> I think there is some community support and no major objections. Given the 18-block re-org on September 14, I think it should be deployed.

<rucknium> I now have testnet checkpointing at these seven domains using a delegated DNS server though monero-highway: checkpoints2.redteam.cash checkpoints2.moneroconsensus.info checkpoints2.moneronet.info checkpoints2.townforgepool.net checkpoints2.townforger.net checkpoints2.moneroresearch.info checkpoints2.bchmempool.space

<kayabanerve:matrix.org> My CCS still hasn't even been merged. That's fun for me.

<rucknium> That matches the number of moneropulse checkpointing domains that will be used for the next release.

<rucknium> DataHoarder: and @ofrnxmr:monero.social are working with binaryFate to deploy testnet checkpoints on the moneropulse domains managed by the Core Team.

<sgp_> I'm for checkpoints as a temporary measure, with the understanding that them being enabled is bad long-term. I consider them being relied upon as an "emergency" and not something we should be complacent about

<kayabanerve:matrix.org> I have objections to it, I just don't see value in voicing them.

<kayabanerve:matrix.org> The concept is so centralizing I'd say it's unacceptable.

<kayabanerve:matrix.org> And so on and so on

yeah i just don't see any other immediate options

<sgp_> People who don't enable checkpoints could be forked off on a different network, which is a real concern. It's not really "opt-in"; there will be consequences for those who don't opt in (those who don't will potentially be on a different network)

<articmine> There is a major misunderstanding here. The checkpoints are advisory. It is up to the miners to implement them. The latter is decentralized

As a key part of their deployment, they remain opt-in. Using them will depend on also gathering a consensus of miners to back them and exchanges (if they desire to stay pinned)

It's probably enough if 4 pools enable them.

The main change is that miners that don't opt-out of warnings might get warned in logs on their hourly fetch, but will not enforce them

<articmine> It ultimately comes down to what the economic majority chooses. This is what happened in 2018 with Bitmain

That is, if they are on a divergent chain.

yeah but to sgps point, what does happen if a user's node doesn't have checkpoints enabled and they get the qubic chain

<kayabanerve:matrix.org> Ethereum as a decentralized checkpoint server.

<monerobull:matrix.org> @articmine: an optional staking layer is "optional"

<boog900> It would be good to have an RPC method on monerod to add a checkpoint so that solutions acn be worked on without touching the core repo like @kayabanerve:matrix.org has suggested

rucknium, DataHoarder: I'm ready to run some checkpointing script on testnet for moneropulse domains. Just not sure what's most up to date or what everybody decided to use for now. I think both of you had some work in progress?

binaryFate: we do. we can talk after the meeting

<articmine> ETH has serious centralization problems

if they are not opt-in (default) they get warned hourly if they are still on their chain guest55

if they are opt-out (no warnings) they don't get them

i guess, based on qubics behavior, that chain would eventually stall out, and the node would find the real chain?

<kayabanerve:matrix.org> But DNS servers don't @articmine:monero.social: ?

<sgp_> I fundamentally disagree that checkpoints meant to disrupt re-orgs are "opt-in". Those who don't opt in will likely find themselves on the wrong network

both will stay there until altchain with checkpoint grows past qubic's

<rucknium> @boog900:monero.social: That would be good. Yet, there is a workaround with the undocumented checkpoints.json file.

but because monerod is ban heavy, would they ever make it back?

<kayabanerve:matrix.org> (I know that isn't your position, but Ethereum is undeniably more decentralized)

<monerobull:matrix.org> @articmine: they have 70% of validators running OFAC MEV bots on a fully transparent network and still fail to censor effectively

Users who don't enable checkpoints will see the qubic's alt-chain for a couple blocks and then reorg back.

guest55: I made it back on testnet after mistakenly releasing a 400+ alt chain while I was offline :)

<rucknium> binaryFate: I had some prototype scripts for testing. I think DataHoarder 's scripts are best for production deployment. Thanks.

<boog900> @rucknium: TIL

and testnet has fewer nodes

A contrarian position would be to let Qubic make a few more >=10 reorgs until something breaks i.e. an exchange boots their coin off, and they are forced to stop

+1 on having RPC method for querying runtime (not bundled) checkpoints and managing them

that'd ease solutions on later stages if bandaid can be decentralized a bit more or altered while proper mid/long term solutions are in the works

the first implementation is fail-safe with quite the sanity checks, failure mode is not issuing checkpoints

<rucknium> guest55: guest55: The draft PR would reduce to 5 minutes the ban time of nodes banning because of incoming blocks inconsistent with the checkpoints. I think that should allow the network to heal quickly.

<rucknium> @boog900:monero.social: Check reddit.com/r/Monero/comments/2ixfe4…_missives_weekly_report_october_6th

could we "just" increase the 10 block to 30?

late answer to the ping, but: P2Pool doesn't use more than 2160 outputs in coinbase tx, so it's <= 2160*40 = 86400 bytes

<articmine> @monerobull:matrix.org: Censorship that does not work is actually worse than censorship that works. If the censorship does not work it leads to false accusations of innocent people

the reality is if temporary rolling checkpoints are deployed, it might get them also attacked over time

guest55: hardfork!

<ywu999:matrix.org> If the DNS checkpoints is "opt-in", the qubic networked can still control 51% of the "non-opt-in" hash power, can

also still doesn't fix it, they just need to target 30+ now

harder to do, but they have been able to do more in the past, and released "early" before reaching the optimal height

<spackle> Considering the objections, could there be an explicit time limit that this bandaid is in place? Perhaps set things so 1 year from now checkpoints return to normal?

<ofrnxmr> They end up on the longest chain, so unless wubic has 51% hashrate indefinitely, theyll get forked back onto the longer chain > <guest55> yeah but to sgps point, what does happen if a user's node doesn't have checkpoints enabled and they get the qubic chain

<rucknium> @ywu999:matrix.org: Yes. Read "Paths to majority hashpower" section of monero-project/monero #10064

<kayabanerve:matrix.org> How secure are these DNS servers? What quorom is required? What happens if conflicting checkpoints are issued? what happens if a later checkpoint reorgs a former checkpoint?

I think a maximum time (like eth's difficulty bomb lol) would at least keep conversations more focused spackle. But I think it's also better to have a continuous dialogue on what form the bandaid should be deployed as it's an exception, not the norm

<ofrnxmr> guest55: Its reduced to 5mins for mismatched blocks

<kayabanerve:matrix.org> Who exactly has the right to publish checkpoints? Who hosts the machines publishing checkpoints? Are their physical locations possible to identify?

20:25:14 <br-m> <kayabanerve:matrix.org> How secure are these DNS servers? What quorom is required? What happens if conflicting checkpoints are issued? what happens if a later checkpoint reorgs a former checkpoint?

checkpoints are not allowed to be issued if previous checkpoint is not part of the chain the new one is at

that is one of the explicit sanity checks

The quorum is 5/7 matching checkpoints.

<spirobel:kernal.eu> they are an old feature and have been activated before, right?

<kill-switch:matrix.org> right, as a p2pool miner I have no intention of enabling checkpoints as I'm opposed to them from a centralization perspective, but also it's not a hard forking measure and so not a ripcord scenario (for me) if the network majority follows the dns. Kayabanerve points out the practical security implications of such a centralizing measure of course

<ofrnxmr> @spirobel:kernal.eu: On testnet

They have been "active" but with old records in them

<articmine> Numerous times.

3/4 for current code, 5/7 with newer PR

<articmine> In the Bitmain case it was due to an over 90% attack

<ofrnxmr> Current code is >1/2+1, new is >2/3+1

<spirobel:kernal.eu> @articmine: was it a successful measure back then @articmine:monero.social ?

not to dig up old bones, but whats the problem with just a rolling 10 block finality thing? the boogieman of netsplit?

guest55: hardfork and takes a long time to implement properly

jah

There are ways to spread control over the issuing servers. Due to the way monero verifies the DNS records, it must be ensured that ALL records are published in a matching way to ensure the agreement (eventual consistency across DNS cache). This could change at a later patch but it's not the current form.

<ofrnxmr> DataHoarder: A rolling 10 block finality could be implemented by using the json file

true. or RPC.

The agreement on contents on this JSON can be done out of bounds (similar to what I was attempting on a branch on my DNS server)

DNS repository* not server*

A rolling finality would chain split. And no, that's not hypothetical.

Though without the ability to match records individually I abandoned that for a happier time

<bawdyanarchist:matrix.org> Rolling finality checkpoint right now is a terrible idea. Qubic then just has to target the checkpoint to split the network.

<rucknium> I have been experimenting with the checkpoints.json feature. Seems to work fine. You can set the update frequency as frequent as you want by modifying the source code.

<articmine> @spirobel:kernal.eu: Yes. Very much so

tevador: rolling as in, keep the last N records, not just last record

<rucknium> You just put the file in the same directory as the blockchain.

same behavior selected as of now

it doesn't work on DNS as of now, that is understood

<helene:unredacted.org> Is the checkpoints.json feature documented anywhere? Would be nice to have that around :)

<spirobel:kernal.eu> @articmine: if its just a temporary measure and they have been used before with success during the bitmain days, I am unsure how practical the concerns are regarding decentralization. that said when it comes to the long term the comment earlier by @sgp_:monero.social made a lot of sense

<spirobel:kernal.eu> should be an understanding that this is temporary and we need to do better.

<rucknium> @helene:unredacted.org: AFAIK, no. Except here: reddit.com/r/Monero/comments/2ixfe4…_missives_weekly_report_october_6th

<spirobel:kernal.eu> just a measure for honest pools and nodes to coordinate

<articmine> The other chain I believe is still around. It is called Monero Classic or Monero Original

I think as soon as stable checkpoints bandaid is there the focus of whoever worked on this is to have them work on moving away from them as soon as possible

i think we can come to a consensus that the blockchain is under attack

As the old dev that I am I just want to caution about the astonishing tendency of bandaids to become permanent

so in the spirit of why this dns system was created it seems logical

<ofrnxmr> Most ppl dont even know that monerod skips verification and sync most of the chain using centralized checkpoints (put there at every release)

I have to hop off now. Will be around in a couple of hours if binaryFate / rucknium / ofrnxmr are up for a setup

<sgp_> I see DNS checkpoints as effectively saying "we are becoming centralized until we come up with something better". And yes to kayaba's point, using ETH or BTC in the interim would be more decentralized. Further, it's hard to be against PoS for "centralization" while running DNS checkpointing

<ofrnxmr> Dns checkpoints add dns / networking, but otherwise are trusted just as your release binary is

(Except difficulty is not checked)

hash/height is

<spirobel:kernal.eu> under attack sounds a bit dramatic. there is an entity that thinks purposely creating long reorgs is a good idea. dns checkpointing is a coordination tool by honest participants to get together and and remove this entity from the equation.

<sgp_> dns checkpoints may seem like an easy option, but they are a seriously damaging option with serious potential consequences

<kayabanerve:matrix.org> Will adding DNS checkpoints be used as a reason to shut down research into a finality layer and then become permanent because 'there's no reason to remove them' and 'we have no alternative'?

<ywu999:matrix.org> Could Qubic person in this chat as a "fierce" opponent of the discussion? The root problem is the economic incentive any way.

but again DNS checkpointing isn't permanent.

re: PoS comparison

<spackle> At the very least there needs to be an explicit time limit.

<ofrnxmr> @kayabanerve:matrix.org: Ofrn says no

<kill-switch:matrix.org> and not a hard fork eh

<kayabanerve:matrix.org> We can soft fork a decentralized finality layer @spackle:monero.social:

<bawdyanarchist:matrix.org> @sgp_:monero.social: I so rarely want to advocate acting in the interest of PR, but checkpointing to another chain is probably worse PR than a temporary activation of a backstop that was designed for this exact problem.

<kayabanerve:matrix.org> guest55: not spackle

20:36:36 <br-m> <kayabanerve:matrix.org> Will adding DNS checkpoints be used as a reason to shut down research into a finality layer and then become permanent because 'there's no reason to remove them' and 'we have no alternative'?

<ofrnxmr> @spackle: Miners opt out whenever miners feel like it

<kayabanerve:matrix.org> Sorry, wrong person replied to

I will personally push for removing checkpoints in DNS as priority

<spirobel:kernal.eu> @sgp_: this coordination tool could be more resilient and decentralized, but at the same time it does not mean "we become centralized by using it" quite the opposite

<kayabanerve:matrix.org> I'd be much less against DNS checkpoints if we had someone explicitly working on other designs for a finality layer and we had an agreement to form a transition plan completely off DNS checkpoints, whether better PoW or a decentralized solution

<ofrnxmr> They can already opt-in today. The question is "when do we stop updating them"

<helene:unredacted.org> > <@kayabanerve:matrix.org> Will adding DNS checkpoints be used as a reason to shut down research into a finality layer and then become permanent because 'there's no reason to remove them' and 'we have no alternative'?

<helene:unredacted.org> I'm interested in the finality layer research, and I do hope your proposal gets merged soon because I would be interested in knowing about the possible solutions you come up with :)

<sgp_> spirolbel I'm just trying to emphasize that these checkpoints are highly centralizing, even more so than the other considered options

<kill-switch:matrix.org> for a hard fork, I much prefer as a first step, improving PoW to the state of the art as far as possible, which I am under the impression that PoP and lucky transactions targets that approach?

We still have the option to only activate if Qubic actually makes another >=10 reorg. Which may happen, or not.

we're talking about finalizing a 10 block deep state

How is this called? It has a name

<spirobel:kernal.eu> maybe the reason people are scared about the finality layer ccs is that it is the only alternative proposed at the moment for the long term.

<ofrnxmr> The transition plan off of dns checkpoints: step 1. Stop pushing updates to them

<spirobel:kernal.eu> there should be more

<ofrnxmr> rbrunner: Grim trigger?

Yup!

the network has already decided on finality. 1 centralized entity thinks otherwise.

<rucknium> @kayabanerve:matrix.org: I think there is general agreement that better PoW (& other) solutions should be investigated. They are being investigated.

<kill-switch:matrix.org> with PoW in mind, has anyone on the MRL had any contact from Dr.K of Quai, regarding his PRS workshares proposal, that PR he was putting together?

<rucknium> The grim has already been triggered.

<spirobel:kernal.eu> @sgp_: @sgp_:monero.social: the checkpoints itself are not centralizing. the way they are communicated is through less than perfect means.

Rucknium: "The grim has already been triggered" Well, that's a matter of opinion. There is no threat yet, no?

<rucknium> @kill-switch:matrix.org: Yes. Check log of #monero-research-lounge:monero.social

<kayabanerve:matrix.org> @rucknium:monero.social: Yes and no. I'm personally pissy and being a bitch about about how my CCS still isn't merged, and on a personal level, taking it as a rejection of my desired discussion topics.

<spirobel:kernal.eu> @kayabanerve:matrix.org: dont take it personally. things take time

<kayabanerve:matrix.org> So we can dismiss this as my personal frustrations, but fundamentally, we are not investigating a finality layer other than DNS checkpoints at this time.

<spirobel:kernal.eu> and are messy some times

<ofrnxmr> rbrunner: 55 double spends and 115 invalid txs

<rucknium> @kill-switch:matrix.org: also available here: libera.monerologs.net/monero-research-lounge

<kill-switch:matrix.org> ty

ofrnxmr: Yes. But that trigger works with a threat. We don't have one yet, in my opinion

<kayabanerve:matrix.org> My offer to, a month ago, wasn't accepted and now we're here discussing DNS checkpoints without the benefit of having such research on hand.

<helene:unredacted.org> @spirobel:kernal.eu: They have reasons to take it personally from the discussions I've seen, but I do find the treatment they get for a CCS odd considering what they've done for Monero and how involved they are; even if I don't agree on everything with them.

<kayabanerve:matrix.org> But I'll agree we're investigating DNS checkpoints and other non-finality-layer solutions.

one perspective is that the honest mining participants should be coordinating this response

<spackle> I am unhappy with this bandaid going into effect without explicit time constraints. People offering assurances or loose plans are not a substitute for knowing there is a hard limit to the action being taken.

<spirobel:kernal.eu> @helene:unredacted.org: the issue is that people are hesitant about the finality layer if its going to be presented as the only solution. it feels to them that it might be forced down their throat.

<rucknium> @kayabanerve:matrix.org: I think you may direct your comments at luigi1111 and perhaps @articmine:monero.social instead of the meeting participants as a whole.

<ofrnxmr> @spackle: Its already in effect, sir

Well, do we have a decision *when* the decision about merging kayabanerve's CCS will be taken? Don't think so.

<ofrnxmr> Dns checkpoints can be updated at this very moment. They are already love in the codebase and have been for 10yrs

<helene:unredacted.org> @spirobel:kernal.eu: My understanding was that it was supposed to be an investigation and comparison between many of the possible options, but maybe I misunderstood.

<spirobel:kernal.eu> I would say: activate dns checkpoints. merge the finality layer ccs. encourage people to propose more solutions besides the finality layer

<rucknium> @spackle:monero.social: I would be OK with a maximum time limit equal to a conservative guess of deploying PoS finality layer, which is the longest-term of the proposals AFAIK.

<spackle> @ofrnxmr: only if you insist on thinking of things in a way to confuse the issue. There are clear differences to what is being discussed, I don't feel the need to type them out.

<ofrnxmr> The only thing being discussed is pushing updates to them, and coordinating with pools to have them opt-in to respecting them

20:39:24 <rbrunner> We still have the option to only activate if Qubic actually makes another >=10 reorg. Which may happen, or not.

The second grim trigger, no the third, no the fourth...

<kayabanerve:matrix.org> @rucknium:monero.social: Completely fair. Thank you for pinging them.

<helene:unredacted.org> I think pushing updates to them is fine as-is, it's not like they're being enforced in the first place

<helene:unredacted.org> It's an opt-in feature that miners/pools might not enable at all

<spirobel:kernal.eu> @helene:unredacted.org: @helene:unredacted.org: we can not have one person do this comparison and then give one recommendation. the community needs to come to a solution as a whole. there needs to be a discourse.

<ofrnxmr> @helene:unredacted.org: We wont be pushing updates to them unless we have cooperation of >50% of global hash

how is that known?

<ofrnxmr> By contacting them

DataHoarder: I certainly get what you mean. Still I stubbornly insist there was no proper first threat put up and communicated cleary.

<rucknium> NOSH

<spirobel:kernal.eu> DataHoarder: this is a good point. only activate if they do another one

<helene:unredacted.org> @spirobel:kernal.eu: just because you have one person doing some research doesn't mean it's absolute and that it overrides your personal research and everyone else's :)

rbrunner: the threat was communicated and they even quoted us

<kayabanerve:matrix.org> NOSH?

about the damage that would be done if a 10+ reorg happened and invalidated transactions

<rucknium> Nanopool, MoneroOcean, SupportXMR, Hashvault (NOSH). That is almost always enough for majority global hashpower.

<rucknium> Check the 10064 issue plots that I made

<spirobel:kernal.eu> @helene:unredacted.org: in practice it does. and people are rightly concerned about that. other voices will simply be ignored if there is only this proposal and nothing else

<kayabanerve:matrix.org> At this point, I understand DNS checkpoints. I just feel we have to be unequivocally clear that even 'opt-in', it's a failure of our decentralization and needs to be a priority to remove.

14:11:44 <DataHoarder> CfB has also specifically quoted our IRC conversations from #monero-research-lounge after becoming aware of the damage any 10+ attempt would do on September 1st irc.gammaspectra.live/d7cfad5f3e1bdbac/cfb_goi_tech.png yet still went to attempt it.

agreed.

<kayabanerve:matrix.org> Thank you for the reminder. I remember the topic, I just forgot the acronym.

i don't think anyone wants DNS checkpoints.

we may need them tho

<ofrnxmr> Pools can coolude on their own if theyd like

<kayabanerve:matrix.org> Yes, but we need to be clear in our humility and tone IMO.

<rucknium> @kayabanerve:matrix.org: "Without a doubt, Monero's consensus mechanism would be less decentralized if rolling DNS checkpoints were enabled." monero-project/monero #10064

<rucknium> I think this is clear

<kayabanerve:matrix.org> This isn't just a response but a failure.

<bawdyanarchist:matrix.org> yes, a failure of NC

<kayabanerve:matrix.org> @rucknium:monero.social: I hear you. That isn't as far as I'm stating though.

<kayabanerve:matrix.org> But whatever, so long as we're on the same page

<helene:unredacted.org> @spirobel:kernal.eu: there have been many proposal in issues, and this is an odd way to see it if there's no one else to step up to contribute to this work in the first place...

<helene:unredacted.org> s/in issues/in github issues/g

Implementing a proper finality layer, even if on the table *today*, takes many weeks, if not months. That may become an awfully painful wait.

its an odd failure though. because as far as we know, they don't really have 51%.

and furthermore the mess created by the re-org is because of the "space saving" output index system

<helene:unredacted.org> it is certainly going to be a lot of dev time, testing, and audit time, yes...

<kayabanerve:matrix.org> Ethereum could be done within a few weeks rbrunner:

kayabanerve: Are you suggesting that we do nothing (and see more 10+ deep reorgs) until a proper solution is implemented and tested?

kayabanerve: True, but with maybe two or three such >=10 reorgs in each one of those weeks

kayaba can you update when delivery would be aimed at, given it's now a month later? The proposal looks mergeable to me (weighing support vs against), however I do share some of the concerns around the cost.

<kayabanerve:matrix.org> > At this point, I understand DNS checkpoints. I just feel we have to be unequivocally clear that even 'opt-in', it's a failure of our decentralization and needs to be a priority to remove.

<bawdyanarchist:matrix.org> I can see the headlines already: "Monero becomes vassal to Eth protection against Qubic!"

<spirobel:kernal.eu> if considering dns checkpointing a failure then monero has already failed long ago as they were used already against bitmain. its just a coordination tool for honest participants. The finality layer would be another coordination tool that makes this process not depend on the domain name system and the box to propose the checkpointing

<kayabanerve:matrix.org> I'd be much happier if we did DNS today and agreed we're open to transitioning to Ethereum as the server.

<spirobel:kernal.eu> yeah eth checkpointing is not worth the extra effort

y not do both

<ofrnxmr> Yeah, lets not stuff eth into the codebase

I'm against using Ethereum. There are other possible solutions.

<kayabanerve:matrix.org> luigi1111: same as before, a few weeks to a month.

yes. and other alternatives or at least distributed issuance should come as priority > it's a failure of our decentralization and needs to be a priority to remove.

And stuff their blockchain full with our blocks, oh what fun :)

Tari was used as a Witness chain for the recent reorg to prove our orphaned blocks were made

<kayabanerve:matrix.org> Ethereum checkpointing is absolutely worth the effort compared to DNS.

but that was just pure merge mine

cool, deploy checkpoints, then move to eth kayabanerve:matrix.org?

then remove them. instead of rushing eth checkpoints or anything else

DNS checkpoints that had already been implemented in monerod are taking 1 month+ to test and deploy (first discussed in August). I doubt anything more complex could be done in a month.

<kayabanerve:matrix.org> Are we as a community willing to explore moving to Ethereum within the next few months? Can we get a show of support for that idea in this meeting? Should I change my work to explicitly be the design of Ethereum as a finality layer and prototype?

<ofrnxmr> tevador: And hard forked?

<kayabanerve:matrix.org> (with DNS checkpoints for now)

i don't understand the ethereum proposal so i have no idea

<kayabanerve:matrix.org> If we, widely, agree Ethereum is a better opt-in finality layer than Ethereum, and this is our priority, than I should re-scope accordingly.

Anthing but Ethereum...

<ofrnxmr> I see more against ethereum than for ..

<spirobel:kernal.eu> DataHoarder: what you said made sense as well. only deploy them if they do another long reorg.

kayabanerve: " Should I change my work to explicitly be the design ..." Strange question. I see the value of your book in *comparing* various approaches

Maybe I misunderstand however ...

@spirobel:kernal.eu I was joking there. they already did one. The checkpoints must be ready if they ever reach another 9+ height

<kayabanerve:matrix.org> rbrunner: It's a priority issue.

this can be monitored AND deployed to be there within minutes

<kayabanerve:matrix.org> Else, luigi1111: As I said, a few weeks, and if the price is too much of an issue, please let me know where you want me to come down.

<ofrnxmr> DataHoarder: Also, simply ENABLING checkpoints should discourage them from even attempting

<kayabanerve:matrix.org> tevador: Ethereum has proven its censorship resilience and has the requires block space. Bitcoin, the only larger network, can't fit Monero blocks.

I have half focus here and elsewhere, better to check here later

<kayabanerve:matrix.org> We would have to publish the blocks onto the network. Else someone can say

<kayabanerve:matrix.org> Checkpoint block X

<kayabanerve:matrix.org> But never publish block X, and stall the chain

DataHoarder suffers a chain split :)

<kayabanerve:matrix.org> Ethereum will let us do that for pennies. Bitcoin only has 1 MB every 10 minutes, which is insufficient throughput.

That's such an ugly, ugly hack

Those our blocks in their blockchain

<kayabanerve:matrix.org> I can write a book on a finality layer in some weeks to a month, and that sounds to be the plan. If we requested, I could re-prioritize to Ethereum as an opt-in finality layer. That was all I was saying. Again, the plan on my end seems to be the book however.

<sgp_> personally I'd rather see effort spent on the finality layer

kayaba it "seems" like an issue, I can't say for certain, but 100-150 is a more comfortable level. I'm unsure if this discussion is steering the direction of it(?) or if it's "ready to go" regardless

<kayabanerve:matrix.org> @rbrunner No. Ethereum explicitly supports this because of their layer twos.

<kayabanerve:matrix.org> @sgp_:monero.social: The ethereum finality layer or finality layer book?

<sgp_> finality layer book; Monero considering options for its own finality layer

<sgp_> that's just my opinion

<kayabanerve:matrix.org> luigi1111: It seems like we're merging the book, but I opened a can of worms that will need another fifteen minutes to resolve. I'm willing to come down on the price, especially given recent increases, even though it could trend back the other way and screw me over.

<kayabanerve:matrix.org> The book, got it, thank you for clarifying.

Well, if everything gets compared, I wouldn't mind working on that Ethereum abomination first :)

<venture> was Mainline DHT assessed as DNS/eth alternative?

<rucknium> @venture:monero.social: AFAIK, no. What's that?

<sgp_> @kayabanerve:matrix.org: maybe you and luigi can speak after the meeting and try to come to agreement on the price, then they can merge?

<ofrnxmr> DHT isnt decentralized either iiuc

<spirobel:kernal.eu> honestly didnt see the price as an issue. it seems like the objections are a result of being afraid that this will be presented as the only alternative that the community has to swallow without a proper discourse

<kayabanerve:matrix.org> rbrunner: It's the concept of data availability.

<kayabanerve:matrix.org> To checkpoint a block, we need to ensure it's valid. we can do it locally if we have the block. The issue is how do we get the block? Do we now have the block because of an issue with our internet, or was it never published?

<kayabanerve:matrix.org> Ethereum, if we publish onto Ethereum, can assert the block is accessible.

<sgp_> it's research, and other things can be researched too. We aren't deciding to pick the nondescript finality layer

and is there a point where our native hashrate is high enough to nullify the need for any of this

<kill-switch:matrix.org> I would strongly prefer a soft fork approach even if DNS opt-in, followed by a hard fork first priority that improves our PoW NC from the simple ~35% to approaching a more robust ~50% using PRS/PoP/etc, and after that a hard fork that removes or supplants objective consensus with alternative finality, I would follow the PoW-on [... too long, see mrelay.p2pool.observer/e/idi8lLYKS2dVMzNj ]

FWIW, I'm planning another proposal that is a soft fork, decentralized and works against selfish mining and long reorgs if the attacker is <50%. Requires about 500 bytes of data in miner's tx_extra per block. PoW only.

<kayabanerve:matrix.org> Because a variety of blockchains defer to Ethereum for finalizations (their layer twos), Ethereum added an explicit 'blob storage' API to store blocks and attest their accessibility. We'd presumably use that.

Didn't know, interesting. The madness has system.

<kayabanerve:matrix.org> Anyways. My priority still seems to be the book, despite the can of worms I just opened. Sorry for opening it.

kayaba: kk. I'll try to follow along a little bit. And yeah pricing is always double edged

we all just need to mine more

<venture> @ofrnxmr: well.. DNS or Eth aren't either..

<venture> @rucknium:monero.social it's the DHT used by bittorrent

If you ask me kayabanerve should be able to work on that book for *at least* as much pay as those auditors got

<sgp_> this is not just a mining hashrate issue. It's a distinct disadvantage of a commodity mining algo. There will always be value in mitigating that risk, and I think finally getting new research into that is a good thing

all those FCMP++ reviewers and auditors, I mean

<kayabanerve:matrix.org> Ugh. luigi1111: I can't DM you from Matrix. 180 XMR would be about the same USD as a month ago, although XMR is currently dropping and the original proposal still had concerns about price. I'd accept the current volatility though and at least move down to 175. If it has to be 150 to move forward, I'd be unhappy, but I'd rather [... too long, see mrelay.p2pool.observer/e/w7LNlLYKNFNXeERk ]

<kayabanerve:matrix.org> rbrunner: I quoted <$200/hr if I worked on this _my_ full time and it takes about a month.

175 and clear up the ongoing "discussion" or whatever and let's proceed. To others, this is obviously not binding on what must be done on the protocol after publishing.

<kayabanerve:matrix.org> That's about an accessibly priced auditor.

<ofrnxmr> @kayabanerve:matrix.org: How many hours is full time for a few weeks-a month?

<kayabanerve:matrix.org> The ongoing discussion was on a book or on Ethereum. We do not have support for Ethereum lol, so that's resolved.

sgp, perhaps. But if we had 20 Gh/s on the network because monero's worth a bajillion then we wouldn't be having these conversations

<kill-switch:matrix.org> Has the possibility that qubics base hashrate potentially being botnet-heavy been discussed previously? If so, I've seen a PoW algo tweak recommendations that suits a more memory-heavy or other approaches to shift the balance back towards people that have real cost incentives in the mining rather than being quite as botnet-friendly

<kayabanerve:matrix.org> ofrnxmr: for me? I work 80-100 hours a week.

<kayabanerve:matrix.org> I don't go out much...

<bawdyanarchist:matrix.org> guest55: Selfish mining is a problem regardless of hashrate

<ofrnxmr> Maybe if you quoted it as 360hrs

yeah i agree on that. leave it to monero to have to deal with a flaw inherited from bitcoin

<ofrnxmr> Looking at it as 160hrs makes it look like 400/hr

<rucknium> I think some people are uncomfortable with DNS rolling checkpoints, but I don't recall anyone saying a flat "no". Am I correct?

<kayabanerve:matrix.org> I'm fine with acknowledging we failed and the immediate stop gap, a failure of its own, of DNS checkpoints.

That's a really nice way to put it

we failed to get the NGU so we have a high hashrate yep

<spackle> I wish to see a explicit time limit for the proposed changes, but yes I think that is correct.

<rucknium> Selfish mining was first modeled in 2014. Monero did not implement any countermeasures since then. This was a blindspot that an adversary has finally attacked.

<kayabanerve:matrix.org> It's brutal, but it's unfortunately my view and why I largely put so much focus on a finality layer. I'm unconvinced PoW is rescuable. I want to ensure we don't trend towards long-term acceptance of DNS checkpoints as 'a feature'

one question. are. u. mining.

<rucknium> I would be ok with an explicit time limit if @kayabanerve:matrix.org would give a conservative estimate for a PoS finality layer deployment, since that's the countermeasures that would seem to take the most time.

<kayabanerve:matrix.org> Ethereum as a finality layer? Within three months and unilaterally better than DNS.

<kayabanerve:matrix.org> Ethereum is a shortcoming, not a failure, as it would remain decentralized.

<kayabanerve:matrix.org> An independent finality layer? Year and a half.

<spirobel:kernal.eu> the ethereum thing is not going to happen

<rucknium> To deployment? Ok. 1.5 years

<bawdyanarchist:matrix.org> Becoming a vassal to Eth is 100% a failure

<kayabanerve:matrix.org> DNS is 200% a failure then.

<kayabanerve:matrix.org> We become a vassal _and_ a vassal to a centralized entity.

<bawdyanarchist:matrix.org> Do I misunderstand that you'd accept Eth checkpointing as a permanent solution?

<bawdyanarchist:matrix.org> Or you're saying it's a better temporary solution than DNS?

<kayabanerve:matrix.org> The latter.

I think that meeting may have run its productive course, more in the next meeting ...

<rucknium> rbrunner: Good! We can end the meeting here. Discussion can continue.

<kayabanerve:matrix.org> I don't believe Monero should forsake its consensus. I believe DNS checkpoints do so to a centralized entity and that demands immediate correction. Forsaking to a decentralized entity would not need to be immediately fixed, solely eventually.

<rucknium> We didn't get to lucky txs, but tevador is already brewing another proposal

<bawdyanarchist:matrix.org> In alot of ways I agree with you, that Eth checkpointing is more decentralized. But I dont think it's a PR move that Monero can afford to make.

<ofrnxmr> im not entertaining eth, but wondering: who posts the block on eth

<kayabanerve:matrix.org> luigi1111: Pushed reduction to 175 XMR, seems we are sticking with the current CCS as my priority.

<kayabanerve:matrix.org> And yet centralized DNS updates is an acceptable PR move?

<ofrnxmr> @kayabanerve:matrix.org: That would be true if the checkpoints were reactive

👍

<kayabanerve:matrix.org> ofrnxmr: whoever wants to checkpoint it, presumably the miner to ensure their block reward.

repo.getmonero.org/monero-project/c…als/-/merge_requests/448#note_27745 any updates on the FCMP++ dev reviews

Yes, you can't spin that as easily as running on the back of another freaking coin / blockchain. Just PR "logic"

<spirobel:kernal.eu> @articmine:monero.social: how was it perceived during the bitmain days? > <@kayabanerve:matrix.org> I don't believe Monero should forsake its consensus. I believe DNS checkpoints do so to a centralized entity and that demands immediate correction. Forsaking to a decentralized entity would not need to be immediately fixed, solely eventually.

<kayabanerve:matrix.org> Eh, we'd probably gain a lot of attention from the Ethereum community. It'd be interesting to see.

<kayabanerve:matrix.org> Anyways, it's not my priority and doesn't have to be discussed.

<sgp_> the news at the time around bitmain was mostly about the downsides of cpu algorithms

<spirobel:kernal.eu> @kayabanerve:matrix.org: monero becoming an eth l2 can already see the headlines

<sgp_> people chimed in saying that they were right, that nothing is actually asic resistant

<ofrnxmr> @ofrnxmr: this would mean that some centralized entity is forcing miners to roll back their blockchains

<ofrnxmr> But that is not the plan. The plan is to checkpoint the existing chain a few blocks deep, to prevent certain reorgs

<spirobel:kernal.eu> maybe some ethheads would actually buy and support monero. on the other hand their podcasts shill worldcoin and weird "proof of personhood" schemes

<spirobel:kernal.eu> also "soul bound token" is a term that they use without thinking twice how weird and dystopian that sounds

<ofrnxmr> So of a single miner can push a block to eth, this same miner is pushing a block to the dns operator, who is relaying said checkpoint to other miners

<bawdyanarchist:matrix.org> "Monero become an Eth L2" ... It's a stench that, even if just as a temporary measure, would be nearly impossible to clear from the social sphere

<kayabanerve:matrix.org> Miners would publish to and receive checkpoints from Ethereum if Ethereum was the finality layer.

Let's not waste time on Ethereum checkpointing please.

<venture> DataHoarder: Thanks for the timeline. Quick follow-up, were the qubic blocks all disclosed / published to the network all at once in the end, or continuously so that there were 2 publicly known branches at equal length and only at the end published 2 blocks to override?

<ofrnxmr> tevador, i was mostly trying to understand (for myself)

<ofrnxmr> Not entertaining it

all at once, venture

see the logs

<venture> will do, thanks

in monero no alt was seen until that point

I did not track when the transactions were sent exactly

<venture> DataHoarder: you would need multiple monero nodes to confirm that? and an alt of same height as is already incorporated, would you have caught that? monerod would simply ignore I assume?

I am querying couple nodes, and connected to a few thousand in several witness nodes

I query alt_block hashes or whatever it is

see blocks.p2pool.observer source code, as well

(linked in page itself)

<venture> ok, thanks

alt blocks don't broadcast well. so detecting them can be challenging

however, I can tell you their first blocks had withheld transactions and were not broadcasted until the entire chain was pushed

which makes the first blocks non-broadcasteable

<venture> ah okay, that confirms it

<charutocafe:matrix.org> hi, sorry i don't mean to hijack important discussion so feel free to ignore and continue along, but is the idea of a fixed standard fee/kB that is part of consensus one we've embraced or plan to embrace? i've seen it proposed many times in the past but nothing ever seemed materialize.

Fees set by consensus is a very bad idea. You'd need a hard fork for each fee change. AFAIK it has never been proposed.

<charutocafe:matrix.org> would you expect fees to require being changed more frequently than monero naturally hard forks?

<charutocafe:matrix.org> if each wallet effectively implements their own fee/kb it's a metadata "leak" that gets published on chain forever. i think it negatively impacts user privacy.

<charutocafe:matrix.org> maybe it was never proposed at consensus and i just assumed it was

A relay rule would probably be enough to get wallet developers to behave.

<charutocafe:matrix.org> yeah, that's probably wiser

21:02:17 <br-m> <venture> was Mainline DHT assessed as DNS/eth alternative?

I looked / suggested DHT, however, that can be killed easy. You could have it instead as part of P2P messages in monero, or well, as specially made monero transactions

21:10:39 <br-m> <kill-switch:matrix.org> Has the possibility that qubics base hashrate potentially being botnet-heavy been discussed previously?

quite some beefy machines on their network, thanks to nonce analysis

<venture> yeah, I had a hunch that DHT wouldn't be robust enough for checkpointing.. just wanted to bring it up (you never know)

<tigerix:matrix.org> I have just read this thread and am really surprised of the statements here.

<tigerix:matrix.org> How is it even considered to use a centralized DNS instead of Ethereum (a solid decentralized option) as a temporary measure?

<tigerix:matrix.org> We should always choose the best decentralized option available.

<tigerix:matrix.org> Be consistent. Be responsible.[... more lines follow, see mrelay.p2pool.observer/e/19PulrYKLVdyQlRQ ]

DNS checkpoints are being considered for them being available now, transitioning to another bandaid is fine as well as soon as possible. But none of these are *here*

Like. They exist in the code. They can start being issued. Everything else takes longer, and this discussion of "stall until something better" was had end of August. Monero consensus is slow

Bleeding while that is being decided, not so much

Note any non-centralized checkpointing approach requires either hardforks (to not require full txs) or it must include all txs

<spackle> For clarity's sake, I interpret 1.5 years to mean the final checkpoint published for this purpose shall be on or before 24 MARCH 2027. Perhaps a different deadline is desired, I just did not want to leave this conversation without being specific.

<ywu999:matrix.org> So this meeting ends??

<ywu999:matrix.org> So the weekly meeting always lasts about 4 hours, doesn't it? New here, not knowing what is the protocol of th emeeting.

Not 4 hours, it ends as it needs, and people keep talking

<rucknium> @ywu999:matrix.org: Most meeting are about an hour. Meetings have been longer recently because of the selfish mining by Qubic.

<rucknium> @ywu999:matrix.org: The #monero-research-lounge:monero.social room is good for casual chats.

<ywu999:matrix.org> Thank for the response.

<articmine> There was a strong community consensus and unity > <@spirobel:kernal.eu> @articmine:monero.social: how was it perceived during the bitmain days?

<articmine> As for the aftermath there was a chain split. Most of the community members ignored the XMC/XMO Bitmain chain. A few of us myself included extracted the Bitmain chain and dumped it

<articmine> DNS checkpoints are a temporary solution while the community reached consensus on one or more permanent solutions

<articmine> It also allows for the consensus process to proceed without a gun to our heads

the gun on our heads has been shot already

<articmine> ... and missed

now they keep holding it and digging out further :)

missed?

I mean it happened as exactly as expected

invalidated transactions, double spends later

<321bob321> Currently where playing battleship

<articmine> I remember when Bitcoin required 6 confirmations. This is like 30 for Monero

no we are doing game theory and a pigeon is shitting around

and loudly saying "it didn't happen" while we consider if getting shot again while we develop a full new ballistic shield powered by the gods energy around us is better than using a pocket shield you had all along, just need to insert batteries, not good enough but it's there

this feels more like lounge convo anyhow

<articmine> In my view we need to prioritize those solutions that are most likely to get consensus, instead of arguing over the most controversial solutions.

<articmine> POS to put it bluntly is maximum controversy as is checkpoints on POS chains

<spirobel:kernal.eu> we should make sure that this is communicated clearly. that DNS checkpoints have been used before, that it was uncontroversial and resulted in the other chain dying. > <@articmine> As for the aftermath there was a chain split. Most of the community members ignored the XMC/XMO Bitmain chain. A few of us myself included extracted the Bitmain chain and dumped it

<monero.arbo:matrix.org> @articmine: this is what I've been saying