<freddypa:matrix.org> Ig would be the best idea even if you just have to pay 2$ > <@ofrnxmr> maybe posdible to make it a paid server? Would discourage ppl from burning their $

<ofrnxmr> Yea. Like 0.01xmr "prove you're one of us" > <@freddypa:matrix.org> Ig would be the best idea even if you just have to pay 2$

meeting time monero-project/meta #1264

<plowsof:matrix.org> Greetings hi

<spackle> hello

<hbs:matrix.org> Hello

<syntheticbird> hi

<plowsof:matrix.org> comment from binaryFate under Ruckniums "Temporary Rolling DNS checkpoints" issue monero-project/monero #10064#issuecomment-3259592231

<plowsof:matrix.org> "if the community decides on a certain course of action, I am happy to help with moneropulse domains admin"

<plowsof:matrix.org> a tldr from datahoarder reg what these checkpoints will help with libera.monerologs.net/monero-research-lounge/20250906#c580466

<plowsof:matrix.org> iiuc simply adding a checkpoint for the most recent blockheight in the recent release @ monero-project/monero #10020/files would be proof of shaking the cobwebs off

<ofrnxmr:xmr.mx> Nah thats probably dangerous

yeah, matching release checkpoints would be a start

highest height in DNS Checkpoints is 1680000 / 898c0e0b338edc5edd850d241578027f489167cf7b3edb33ed9d08274e15e20e

that's 2018

<ofrnxmr:xmr.mx> Dont need dns checkpoints for released checkpoints

<plowsof:matrix.org> would it be dangerous?

<ofrnxmr:xmr.mx> for a recent checkpoint, yes, particularly if during a reorg

<ofrnxmr:xmr.mx> The minority of nodes that use --enforce will get forked off onto a potentially dead chain

say for height 3088000

<plowsof:matrix.org> ADD_CHECKPOINT2(3468000, "c4024dbfa9d4b2e54ed129b413946d2d5af36eef5ab4a93abe5cb552de985f5a", "0x6d067f3e550a29b");

or yeah, 3468000

Start of August there

<ofrnxmr:xmr.mx> For the release height, it shouldnt make any difference

but that's what plowsof means, using a release checkpoint to dust off DNS checkpoint records

<ofrnxmr:xmr.mx> The checkpoints only need to be enforced by miners, and nice-to-have gor exchanges

<ofrnxmr:xmr.mx> DataHoarder: Just to test updating them?

<ofrnxmr:xmr.mx> That can be done for testnet

yeah, dust off, prove we control them

testnet is a good choice 👍

I think they share setup at the moment

<ofrnxmr:xmr.mx> We need to figure out w good way to choose the heights that we checkpoint on mainnet, that cant be gamed too easily

<plowsof:matrix.org> can reflect the testnet checkpoint in release @ dns then to show proof of existence

yeah, making a test engine for that ofrnxmr

<plowsof:matrix.org> this is literally step 0 before considering everything else, nice to see happen

<ofrnxmr:xmr.mx> Like, if we push every block 10 9 8 7 6, it might be possible for an attacker to always try to reorg on the 6th block

<ofrnxmr:xmr.mx> @plowsof:matrix.org: assuming we use moneropulse domains at all

<plowsof:matrix.org> step 0.1 allow clients to input their chosen DNS servers rather than needing to modify source?

<ofrnxmr:xmr.mx> Discussions are leading towards having multiple records run by different ppl (like seed nodes), and requiring 2/3 + 1 of them to agree

<ofrnxmr:xmr.mx> I think step 0 is figuring out the best recipe for "how to update them properly"

<plowsof:matrix.org> what does the +1 mean there btw?

<plowsof:matrix.org> from the pool of public nodes?

<ofrnxmr:xmr.mx> 2/3 + 1 means 1 more than 2/3rda

2/3rds +1

of %

same as 50%+1

so there is a "majority"

<plowsof:matrix.org> ah ok

ofrnxmr: is the point to totally close off selfish mining, or make the 10+ reorgs infeasible

<ofrnxmr:xmr.mx> to me, its to make 10+ reorgs impossible

<ofrnxmr:xmr.mx> lesser to punish selfish miners for attempting deep (like 4+) reorgs

with rolling, say, 2 from tip, and checkpointing every to every couple of blocks there up to 10 rolling checkpoints

the max they can reorg is the tip-2

rolling is needed due to DNS, as otherwise, single record will not match across differing servers depending on config (even if they "match" they might not in the client network)

so with rolling, some of the previous checkpoints will be seen by all

and pass the "majority" rule that is decided

<ofrnxmr:xmr.mx> the problem with rollibg ia that some nodes might checkpoint a higher height, and othera rolled back further

or the checkpointing nodes can be sharing this information with each other

so when issuing checkpoints, they all have access to the same information

<ofrnxmr:xmr.mx> anyway, i think step 0 is figuring out how to agree on checkpoints ^ yeah

I'll keep writing my testbed for this then, has ... highly configurable parameters for testing these

<plowsof:matrix.org> the checkpoint nodes can not have public rpc, that goes without saying, easy ddos - but i assume they will be subject to generic ddos attacks should their ip's be known

<plowsof:matrix.org> 99% uptime 😬

<ofrnxmr:xmr.mx> the checkpointing nodes should be private

yeah. you can issue DNS in secret :)

<ofrnxmr:xmr.mx> No need for them to even be connected to the internet

they can also take more points of view across other monero nodes

<ofrnxmr:xmr.mx> Selfish checkpointing

<plowsof:matrix.org> the hash is delivered via animated QR codes

<plowsof:matrix.org> Rucknium shared a diagram of a possible setup / flow of data between the secure dns server and pools/clients

<plowsof:matrix.org> uhm

<plowsof:matrix.org> update to v0.18.4.2 as it fixes a privacy leak when using remote nodes getmonero.org/2025/08/26/post-mortem-of-find-and-save-rings-bug.html

<plowsof:matrix.org> ccs.getmonero.org/funding-required

brb

<plowsof:matrix.org> lets cover the ccs ideas

<plowsof:matrix.org> a. MoneroOS Resurrection (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/596)

<plowsof:matrix.org> monero is being attacked, this proposal aims to put a mining operating system into the hands of the masses... simple monero miner, hassle free,,, no need to touch your underlying OS. why isnt this merged?

<plowsof:matrix.org> opened on 9th July, any one care to comment? else we can move on

<plowsof:matrix.org> at least there is a comment from Cyrix126 to respond to, we can move on, it is open for feedback

<plowsof:matrix.org> b. [hbs] EVM Atomic Swaps (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/597)

<hbs:matrix.org> I'm available to answer questions if there are any.

Many questions were answered on the proposal

<plowsof:matrix.org> after you clarified some of my confusions in the comments, im stuck at the contract you have re-implemented having no one knowledgeable look over it. this is a very technical proposal and it seems to be going through the community / social momentum route to merge

<plowsof:matrix.org> rather than the dev community signing off on this

MoneroOS ended up unmainted that first time around. Would the new version stay longer after release?

<hbs:matrix.org> The proposal is for the GUI, should the contract need some modifications this would not impact the GUI as long as the ABI of the contract stays the same, even if details in its implementation change.

Matrix issues

Probably going to get some late messages from me there re moneroos

<hbs:matrix.org> The GUI is not tied to a specific contract deployment, just to the ABI of the contract

<plowsof:matrix.org> yetanotherminer: yes, if you merge the proposal i will maintain it (is this what you want to hear from the proposer?)

<ofrnxmr:xmr.mx> Imo its not a solution to any problems > <@plowsof:matrix.org> monero is being attacked, this proposal aims to put a mining operating system into the hands of the masses... simple monero miner, hassle free,,, no need to touch your underlying OS. why isnt this merged?

<ofrnxmr:xmr.mx> Its just a persistent livecd wirh xmrig on it. like cyrix said, the webgui is the biggest part of it. The rest is like 15mins to create

<ofrnxmr:xmr.mx> Having to purchase usb sticks and write isos and configure xmrig, i dont see how this reduces friction. repo.getmonero.org/monero-project/c…als/-/merge_requests/596#note_30658

<ofrnxmr:xmr.mx> (The above msgs probably coming in late. Internet bad)

<plowsof:matrix.org> so its just a GUI, gui's looks nice, so its going to be merged and funded more than multisig vulnerabilities

<plowsof:matrix.org> what a time to be alive

<hbs:matrix.org> As I've said in the proposal, if there is a community demand for contract audit then such an audit can be funded by another CCS.

<plowsof:matrix.org> and then later the ccs will fund an audit? have yo uexperience of arranging audits hbs

<plowsof:matrix.org> do you have experience of monero-oxide use?

<plowsof:matrix.org> to increase the automation?

<hbs:matrix.org> I'm not convinced this should be the way to automate the swaps at this point.

<plowsof:matrix.org> ok

<plowsof:matrix.org> no reason not to merge this GUI then?

<plowsof:matrix.org> moving on

<hbs:matrix.org> I'm more thinking that automation will be something market makers will want to have, and once there are enough market makers then swaps will be very quick to complete

<ofrnxmr:xmr.mx> I think if the goal is ease of use (as comparted to the original) that no-automation isnt going to be very nice

<hbs:matrix.org> @ofrnxmr:xmr.mx: The initial ETH-XMR atomic swaps had automation, but what was in the way of adoption I think was the need to run something specific to do swaps

<ofrnxmr:xmr.mx> One of the biggest things i hated about basicswap (and still do about haveno) is the interactivity requirment

<hbs:matrix.org> @ofrnxmr:xmr.mx: As swap state is stored onchain there is no need for participants to be online at the same time

<ofrnxmr:xmr.mx> well bsx didnt require manual interaction, but was the default... so essentially every swap ends up dead because someone forgot to check their computer

<plowsof:matrix.org> people look at their phones and use cake wallet so it wont be an issue

<plowsof:matrix.org> any further discussions?

I support merging the EVM proposal

<plowsof:matrix.org> c. Monero Python Maintenance (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/598)

<plowsof:matrix.org> i can not for the life of me get monero-cpp to install atm due to my machines ppa's and other issues - i want to make a proof of concept script but the hurdle of instillation is too big. i personally would need a docker

<everoddandeven> Hello, I'm here if you have any questions

<everoddandeven> @plowsof:matrix.org: I have included docker build support in the proposal

<plowsof:matrix.org> woodser.github.io/monero-cpp/doxyge…monero_1_1monero__wallet__full.html is everything stressnete testers need and it should carry over to FCMP++ woodser/monero-cpp #88#issuecomment-3253654177

<plowsof:matrix.org> if i can create a dockerised install and show a simple script (or recreate some simple churning script_ i know for a fact that more people will be enthusiastic about this proposal

<freddypa:matrix.org> Is monero python up to date or had somebody issues because I want to implement it into my backend?

<everoddandeven> @plowsof:matrix.org: Sorry, would you like a demonstration of the working build?

<everoddandeven> github.com/everoddandeven/monero-py…ob/main/.github/workflows/build.yml

<everoddandeven> @everoddandeven: Otherwise I'll try to make the docker file, I think it's quite quick, because these are the instructions to build

<everoddandeven> @freddypa:matrix.org: Now using v18.4.0, maybe you will find some issues when using rpc clients

<everoddandeven> Like MoneroDaemonRpc and MoneroWalletRpc

<everoddandeven> The proposal focuses on code consolidation and test writing

<everoddandeven> In order to create stable packages

<everoddandeven> If you've ever played with monero-ts, monero-java, or monero-cpp, this library is the same thing

<plowsof:matrix.org> as long as a performance increase vs using monero monero-wallet-rpc can be observed

<everoddandeven> Exactly, you could avoid launching multiple processes for multiple monero-wallet-rpc

<everoddandeven> and manage multiple wallets with a single process, using MoneroWalletFull class

<plowsof:matrix.org> i need people to see that , and believe

<ofrnxmr:xmr.mx> ofrn needs poc opening 30 subaccoints and sending from all of them at once

<plowsof:matrix.org> we can move on, thanks for joining everoddandeven, while we have time left

<plowsof:matrix.org> d. kayabaNerve Finality Layer Book (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604)

<plowsof:matrix.org> whats wrong with a bit of research between friends?

<plowsof:matrix.org> i think feedback has been exhausted for this proposal?

<plowsof:matrix.org> e. v1docq47 - monero konferenco 2025 voice-over and working on xmr.ru (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/607)

I think kayaba‘s proposal could be pushed to a later time. The higher price tag was justified by competing priorities and urgency but given rolling DNS and tevadors PoP proposal, finality layer exploration could happen in the future

yup, i am ready to answer questions

<plowsof:matrix.org> thank you for the feedback yetanotherminer

<ofrnxmr:xmr.mx> @plowsof:matrix.org: the monerokon videos arent even out yet

<plowsof:matrix.org> i seen a monerokon tweet and a terrible anti meme saying they would be out soon

<ofrnxmr:xmr.mx> (are they?)

they come out gradually, just in time for our pace of work

<plowsof:matrix.org> x.com/MoneroKon/status/196377073769…ogle%7Ctwcamp%5Eserp%7Ctwgr%5Etweet

a new video was released recently

<hbs:matrix.org> The first video has been published, the others will follow at regular intervals. Sorry for the delay

<plowsof:matrix.org> there we go x.com/MoneroKon/status/1963770737694511121?

<plowsof:matrix.org> we're gunna get the monero gospel said no one

<ofrnxmr:xmr.mx> No need to apologize, i just dont see how youre going to do voiceovers for videos that arent available

<plowsof:matrix.org> they will be available* :D

5 videos are already available and more will be released

<plowsof:matrix.org> perhaps monerokon could release an audio only version + speaker slides next year , while we wait for video to be reviewed / edited

<plowsof:matrix.org> thanks for joining v1docq47, any other comments

<plowsof:matrix.org> xmr.ru he even has the latest release up and translated xD

of course, i follow all the latest news :)

and try to publish news without delay

<plowsof:matrix.org> f. selsta part-time monero development (3 months) (18) (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/609)

no reason not to merge

<plowsof:matrix.org> will you be my friend yetanotherminer

if you wish to :)

<plowsof:matrix.org> thanks all for attending x

<ofrnxmr:xmr.mx> Same place and time in 2 weeks?

<plowsof:matrix.org> yes that would be the 20th september

Thanks

<freddypa:matrix.org> Noice

<ofrnxmr> @monerobull:monero.social x.com/monero/status/1964400250665234879

<ofrnxmr> Gui release was finally announced

🚀

so exciting