06:48:48 <br-m> <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 $
15:35:59 <nioc> https://ccs.getmonero.org/funding-required/
15:49:08 <br-m> <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$
16:00:03 <plowsof> meeting time https://github.com/monero-project/meta/issues/1264
16:01:21 <br-m> <plowsof:matrix.org> Greetings hi
16:01:28 <br-m> <spackle> hello
16:01:43 <br-m> <hbs:matrix.org> Hello
16:02:57 <br-m> <syntheticbird> hi
16:02:59 <br-m> <plowsof:matrix.org> comment from binaryFate under Ruckniums "Temporary Rolling DNS checkpoints" issue https://github.com/monero-project/monero/issues/10064#issuecomment-3259592231 
16:03:22 <br-m> <plowsof:matrix.org> "if the community decides on a certain course of action, I am happy to help with moneropulse domains admin" 
16:04:16 <br-m> <plowsof:matrix.org> a tldr from datahoarder reg what these checkpoints will help with https://libera.monerologs.net/monero-research-lounge/20250906#c580466 
16:06:49 <br-m> <plowsof:matrix.org> iiuc simply adding a checkpoint for the most recent blockheight in the recent release @ https://github.com/monero-project/monero/pull/10020/files would be proof of shaking the cobwebs off 
16:07:15 <br-m> <ofrnxmr:xmr.mx> Nah thats probably dangerous
16:07:30 <DataHoarder> yeah, matching release checkpoints would be a start
16:07:55 <DataHoarder> highest height in DNS Checkpoints is 1680000 / 898c0e0b338edc5edd850d241578027f489167cf7b3edb33ed9d08274e15e20e
16:07:58 <DataHoarder> that's 2018
16:08:16 <br-m> <ofrnxmr:xmr.mx> Dont need dns checkpoints for released checkpoints
16:09:08 <br-m> <plowsof:matrix.org> would it be dangerous? 
16:09:29 <br-m> <ofrnxmr:xmr.mx> for a recent checkpoint, yes, particularly if during a reorg
16:09:45 <br-m> <ofrnxmr:xmr.mx> The minority of nodes that use --enforce will get forked off onto a potentially dead chain
16:09:48 <DataHoarder> say for height 3088000
16:09:57 <br-m> <plowsof:matrix.org> ADD_CHECKPOINT2(3468000, "c4024dbfa9d4b2e54ed129b413946d2d5af36eef5ab4a93abe5cb552de985f5a", "0x6d067f3e550a29b");
16:10:02 <DataHoarder> or yeah, 3468000
16:10:22 <DataHoarder> Start of August there
16:10:27 <br-m> <ofrnxmr:xmr.mx> For the release height, it shouldnt make any difference
16:11:00 <DataHoarder> but that's what plowsof means, using a release checkpoint to dust off DNS checkpoint records
16:11:05 <br-m> <ofrnxmr:xmr.mx> The checkpoints only need to be enforced by miners, and nice-to-have gor exchanges
16:11:38 <br-m> <ofrnxmr:xmr.mx> DataHoarder: Just to test updating them?
16:11:56 <br-m> <ofrnxmr:xmr.mx> That can be done for testnet
16:11:59 <DataHoarder> yeah, dust off, prove we control them
16:12:08 <DataHoarder> testnet is a good choice 👍
16:12:33 <DataHoarder> I think they share setup at the moment
16:12:44 <br-m> <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
16:12:54 <br-m> <plowsof:matrix.org> can reflect the testnet checkpoint in release @ dns then to show proof of existence 
16:13:31 <DataHoarder> yeah, making a test engine for that ofrnxmr 
16:13:33 <br-m> <plowsof:matrix.org> this is literally step 0 before considering everything else, nice to see happen
16:14:13 <br-m> <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
16:14:38 <br-m> <ofrnxmr:xmr.mx> @plowsof:matrix.org: assuming we use moneropulse domains at all
16:15:26 <br-m> <plowsof:matrix.org> step 0.1 allow clients to input their chosen DNS servers rather than needing to modify source?
16:15:27 <br-m> <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
16:16:29 <br-m> <ofrnxmr:xmr.mx> I think step 0 is figuring out the best recipe for "how to update them properly"
16:16:30 <br-m> <plowsof:matrix.org> what does the +1 mean there btw? 
16:16:41 <br-m> <plowsof:matrix.org> from the pool of public nodes?
16:16:44 <br-m> <ofrnxmr:xmr.mx> 2/3 + 1 means 1 more than 2/3rda
16:16:48 <DataHoarder> 2/3rds +1
16:16:51 <DataHoarder> of %
16:16:55 <DataHoarder> same as 50%+1
16:17:00 <DataHoarder> so there is a "majority" 
16:17:07 <br-m> <plowsof:matrix.org> ah ok
16:17:09 <DataHoarder> ofrnxmr: is the point to totally close off selfish mining, or make the 10+ reorgs infeasible
16:17:35 <br-m> <ofrnxmr:xmr.mx> to me, its to make 10+ reorgs impossible
16:18:06 <br-m> <ofrnxmr:xmr.mx> lesser to punish selfish miners for attempting deep (like 4+) reorgs
16:18:12 <DataHoarder> with rolling, say, 2 from tip, and checkpointing every to every couple of blocks there up to 10 rolling checkpoints
16:18:24 <DataHoarder> the max they can reorg is the tip-2
16:19:15 <DataHoarder> 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)
16:19:28 <DataHoarder> so with rolling, some of the previous checkpoints will be seen by all
16:19:42 <DataHoarder> and pass the "majority" rule that is decided
16:19:49 <br-m> <ofrnxmr:xmr.mx> the problem with rollibg ia that some nodes might checkpoint a higher height, and othera rolled back further
16:20:39 <DataHoarder> or the checkpointing nodes can be sharing this information with each other
16:20:58 <DataHoarder> so when issuing checkpoints, they all have access to the same information
16:21:14 <br-m> <ofrnxmr:xmr.mx> anyway, i think step 0 is figuring out how to agree on checkpoints ^ yeah
16:21:46 <DataHoarder> I'll keep writing my testbed for this then, has ... highly configurable parameters for testing these
16:22:32 <br-m> <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 
16:22:49 <br-m> <plowsof:matrix.org> 99% uptime 😬
16:22:50 <br-m> <ofrnxmr:xmr.mx> the checkpointing nodes should be private
16:22:53 <DataHoarder> yeah. you can issue DNS in secret :)
16:23:08 <br-m> <ofrnxmr:xmr.mx> No need for them to even be connected to the internet
16:23:14 <DataHoarder> they can also take more points of view across other monero nodes
16:23:18 <br-m> <ofrnxmr:xmr.mx> Selfish checkpointing
16:23:28 <br-m> <plowsof:matrix.org> the hash is delivered via animated QR codes 
16:24:13 <br-m> <plowsof:matrix.org> Rucknium shared a diagram of a possible setup / flow of data between the secure dns server and pools/clients
16:24:14 <br-m> <plowsof:matrix.org> uhm
16:25:01 <br-m> <plowsof:matrix.org> update to v0.18.4.2 as it fixes a privacy leak when using remote nodes https://www.getmonero.org/2025/08/26/post-mortem-of-find-and-save-rings-bug.html 
16:25:21 <br-m> <plowsof:matrix.org> https://ccs.getmonero.org/funding-required/
16:26:11 <DataHoarder> brb
16:26:41 <br-m> <plowsof:matrix.org> lets cover the ccs ideas 
16:26:45 <br-m> <plowsof:matrix.org> a. MoneroOS Resurrection (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/596)
16:27:34 <br-m> <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?
16:28:39 <br-m> <plowsof:matrix.org> opened on 9th July, any one care to comment? else we can move on 
16:31:32 <br-m> <plowsof:matrix.org> at least there is a comment from Cyrix126 to respond to, we can move on, it is open for feedback
16:31:44 <br-m> <plowsof:matrix.org> b. [hbs] EVM Atomic Swaps (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/597)
16:31:49 <br-m> <hbs:matrix.org> I'm available to answer questions if there are any.
16:33:11 <nioc> Many questions were answered on the proposal 
16:33:35 <br-m> <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 
16:33:53 <br-m> <plowsof:matrix.org> rather than the dev community signing off on this 
16:33:55 <yetanotherminer> MoneroOS ended up unmainted that first time around. Would the new version stay longer after release?
16:34:50 <br-m> <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.
16:36:06 <ofrnxmr> Matrix issues
16:36:18 <ofrnxmr> Probably going to get some late messages from me there re moneroos
16:36:25 <br-m> <hbs:matrix.org> The GUI is not tied to a specific contract deployment, just to the ABI of the contract
16:36:34 <br-m> <plowsof:matrix.org> yetanotherminer: yes, if you merge the proposal i will maintain it (is this what you want to hear from the proposer?)
16:36:46 <br-m> <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?
16:36:47 <br-m> <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
16:36:48 <br-m> <ofrnxmr:xmr.mx> Having to purchase usb sticks and write isos and configure xmrig, i dont see how this reduces friction. https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/596#note_30658
16:36:49 <br-m> <ofrnxmr:xmr.mx> (The above msgs probably coming in late. Internet bad)
16:37:47 <br-m> <plowsof:matrix.org> so its just a GUI, gui's looks nice, so its going to be merged and funded more than multisig vulnerabilities 
16:37:56 <br-m> <plowsof:matrix.org> what a time to be alive 
16:38:42 <br-m> <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.
16:38:44 <br-m> <plowsof:matrix.org> and then later the ccs will fund an audit? have yo uexperience of arranging audits hbs
16:39:08 <br-m> <plowsof:matrix.org> do you have experience of monero-oxide use?
16:39:18 <br-m> <plowsof:matrix.org> to increase the automation?
16:39:40 <br-m> <hbs:matrix.org> I'm not convinced this should be the way to automate the swaps at this point.
16:40:06 <br-m> <plowsof:matrix.org> ok 
16:40:34 <br-m> <plowsof:matrix.org> no reason not to merge this GUI then? 
16:41:08 <br-m> <plowsof:matrix.org> moving on
16:41:18 <br-m> <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
16:41:28 <br-m> <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
16:42:27 <br-m> <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
16:42:38 <br-m> <ofrnxmr:xmr.mx> One of the biggest things i hated about basicswap (and still do about haveno) is the interactivity requirment
16:43:15 <br-m> <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
16:43:43 <br-m> <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
16:45:00 <br-m> <plowsof:matrix.org> people look at their phones and use cake wallet so it wont be an issue 
16:47:42 <br-m> <plowsof:matrix.org> any further discussions?
16:48:17 <yetanotherminer> I support merging the EVM proposal 
16:48:59 <br-m> <plowsof:matrix.org> c. Monero Python Maintenance (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/598)
16:50:02 <br-m> <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 
16:50:36 <br-m> <everoddandeven> Hello, I'm here if you have any questions
16:51:38 <br-m> <everoddandeven> @plowsof:matrix.org: I have included docker build support in the proposal
16:52:44 <br-m> <plowsof:matrix.org> https://woodser.github.io/monero-cpp/doxygen/classmonero_1_1monero__wallet__full.html is everything stressnete testers need and it should carry over to FCMP++ https://github.com/woodser/monero-cpp/issues/88#issuecomment-3253654177
16:53:42 <br-m> <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
16:53:48 <br-m> <freddypa:matrix.org> Is monero python up to date or had somebody issues because I want to implement it into my backend?
16:55:21 <br-m> <everoddandeven> @plowsof:matrix.org: Sorry, would you like a demonstration of the working build?
16:55:30 <br-m> <everoddandeven> https://github.com/everoddandeven/monero-python/blob/main/.github/workflows/build.yml
16:56:24 <br-m> <everoddandeven> @everoddandeven: Otherwise I'll try to make the docker file, I think it's quite quick, because these are the instructions to build
16:57:08 <br-m> <everoddandeven> @freddypa:matrix.org: Now using v18.4.0, maybe you will find some issues when using rpc clients
16:57:17 <br-m> <everoddandeven> Like MoneroDaemonRpc and MoneroWalletRpc
16:57:54 <br-m> <everoddandeven> The proposal focuses on code consolidation and test writing
16:58:12 <br-m> <everoddandeven> In order to create stable packages
16:58:53 <br-m> <everoddandeven> If you've ever played with monero-ts, monero-java, or monero-cpp, this library is the same thing
16:59:26 <br-m> <plowsof:matrix.org> as long as a performance increase vs using monero monero-wallet-rpc can be observed 
17:00:09 <br-m> <everoddandeven> Exactly, you could avoid launching multiple processes for multiple monero-wallet-rpc
17:00:28 <br-m> <everoddandeven> and manage multiple wallets with a single process, using MoneroWalletFull class
17:00:32 <br-m> <plowsof:matrix.org> i need people to see that , and believe 
17:01:23 <br-m> <ofrnxmr:xmr.mx> ofrn needs poc opening 30 subaccoints and sending from all of them at once 
17:02:12 <br-m> <plowsof:matrix.org> we can move on, thanks for joining everoddandeven, while we have time left
17:02:14 <br-m> <plowsof:matrix.org> d. kayabaNerve Finality Layer Book (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604)
17:03:01 <br-m> <plowsof:matrix.org> whats wrong with a bit of research between friends? 
17:03:46 <br-m> <plowsof:matrix.org> i think feedback has been exhausted for this proposal? 
17:04:36 <br-m> <plowsof:matrix.org> e. v1docq47 - monero konferenco 2025 voice-over and working on xmr.ru (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/607)
17:05:00 <yetanotherminer> 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 
17:05:29 <v1docq47> yup, i am ready to answer questions
17:05:39 <br-m> <plowsof:matrix.org> thank you for the feedback yetanotherminer 
17:05:49 <br-m> <ofrnxmr:xmr.mx> @plowsof:matrix.org: the monerokon videos arent even out yet
17:06:12 <br-m> <plowsof:matrix.org> i seen a monerokon tweet and a terrible anti meme saying they would be out soon
17:06:22 <br-m> <ofrnxmr:xmr.mx> (are they?)
17:06:46 <v1docq47> they come out gradually, just in time for our pace of work
17:06:53 <br-m> <plowsof:matrix.org> http://x.com/MoneroKon/status/1963770737694511121?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Etweet
17:06:59 <v1docq47> a new video was released recently
17:07:03 <br-m> <hbs:matrix.org> The first video has been published, the others will follow at regular intervals. Sorry for the delay
17:07:44 <br-m> <plowsof:matrix.org> there we go https://x.com/MoneroKon/status/1963770737694511121?
17:08:01 <br-m> <plowsof:matrix.org> we're gunna get the monero gospel said no one
17:08:15 <br-m> <ofrnxmr:xmr.mx> No need to apologize, i just dont see how youre going to do voiceovers for videos that arent available
17:08:29 <br-m> <plowsof:matrix.org> they will be available* :D
17:09:21 <v1docq47> 5 videos are already available and more will be released
17:09:57 <v1docq47> https://www.youtube.com/playlist?list=PLsSYUeVwrHBlZQl6YKwK_mCBmOxkZv1zn
17:13:36 <br-m> <plowsof:matrix.org> perhaps monerokon could release an audio only version + speaker slides next year , while we wait for video to be reviewed / edited 
17:14:23 <br-m> <plowsof:matrix.org> thanks for joining v1docq47, any other comments
17:15:01 <br-m> <plowsof:matrix.org> https://xmr.ru/ he even has the latest release up and translated xD
17:15:53 <v1docq47> of course, i follow all the latest news :)
17:16:33 <v1docq47> and try to publish news without delay
17:17:51 <br-m> <plowsof:matrix.org> f. selsta part-time monero development (3 months) (18) (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/609)
17:19:37 <yetanotherminer> no reason not to merge
17:21:09 <br-m> <plowsof:matrix.org> will you be my friend yetanotherminer
17:22:21 <yetanotherminer> if you wish to :)
17:27:47 <br-m> <plowsof:matrix.org> thanks all for attending x
17:30:02 <br-m> <ofrnxmr:xmr.mx> Same place and time in 2 weeks?
17:30:35 <br-m> <plowsof:matrix.org> yes that would be the 20th september 
17:36:39 <yetanotherminer> Thanks 
17:38:22 <br-m> <freddypa:matrix.org> Noice
18:54:41 <br-m> <ofrnxmr> @monerobull:monero.social  https://x.com/monero/status/1964400250665234879
18:54:41 <br-m> <ofrnxmr> Gui release was finally announced
18:59:26 <plowsof> 🚀
20:02:40 <nioc> so exciting