13:56:18 <m-relay> <d​everickapollo:matrix.org> plowsof: Napoly and I are requesting to add btcpay update to today’s agenda. Thanks
14:39:56 <m-relay> <p​lowsof:matrix.org> deverickapollo: a new update or payout request @ https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/538#note_30318 ?
14:40:47 <m-relay> <p​lowsof:matrix.org> meeting in 1hr20~ mins https://github.com/monero-project/meta/issues/1251
14:42:02 <m-relay> <p​lowsof:matrix.org> thanks for responding to the update rates on CCS request Rucknium. cc hinto vtnerd acx rottenwheel
14:42:34 <m-relay> <p​lowsof:matrix.org> gingeropolous
15:13:15 <m-relay> <d​everickapollo:matrix.org> Both - status check on M1 deliverable and a brief update on implementation for M2
15:18:02 <m-relay> <p​lowsof:matrix.org> Rucknium reg research bounties banned @ https://bounties.monero.social/ , it would be better to have research bounties / competitions on the CCS where people knowledgeable set the criteria and decide who has completed. the fcmp++ competition was set up like this and we still had some confusion / rule clarifications and extensions toward the end. having this under bounties would ma<clipped message>
15:18:03 <m-relay> <p​lowsof:matrix.org> ke that even more problematic IMO, why not just keep open competitions on the CCS?
15:20:57 <m-relay> <p​lowsof:matrix.org> 'i need a life saving operation and i spent my last moments on earth to claim this bounty and it has been snatched from me. farewell world' are some appeals to emotion commonplace @ bounties , a competition with dates + awareness is much better
15:22:41 <m-relay> <r​ucknium:monero.social> I agree with you that research bounties should not be allowed on bounties.monero.social, at least not a return to free-for-all.
15:37:12 <m-relay> <p​lowsof:matrix.org> other funding platforms are available* 😄
15:47:54 <m-relay> <s​gp_:monero.social> Getting this on the payment radar (no meeting discussion needed): https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/449#note_31074
16:01:22 <plowsof> greetings  ACK sgp
16:02:20 <m-relay> <r​ucknium:monero.social> Hi
16:02:23 <m-relay> <p​lowsof:matrix.org> https://github.com/monero-project/meta/issues/1251
16:02:43 <m-relay> <p​lowsof:matrix.org> Meeting time 👋
16:03:11 <ofrnxmr> 👋
16:04:37 <m-relay> <p​lowsof:matrix.org> for ccs merges : waiting for hinto, vtnerd, acx, rottenwheel  to update rates) will bring up gingeropolous one last time as it had some requested changes
16:05:17 <m-relay> <p​lowsof:matrix.org> tevador has returned https://github.com/monero-project/research-lab/issues/98#issuecomment-3170712102
16:05:55 <m-relay> <v​tnerd:monero.social> I just updated rates
16:06:08 <m-relay> <p​lowsof:matrix.org> and alot of fresh comments under kayabanerves issue for bolstering PoW to be resistant against 51% attack https://github.com/monero-project/research-lab/issues/136
16:06:18 <m-relay> <p​lowsof:matrix.org> vtnerd again! (thank you)
16:11:47 <m-relay> <p​lowsof:matrix.org> so tevadors proposed solution could see pools increase fee's to 6% as an example
16:13:11 <m-relay> <r​ucknium:monero.social> I created https://moneroconsensus.info/ to visualize orphan blocks and alternative chains, which could indicate "selfing mining" behavior. Covered by press here and elsewhere: https://www.coinspeaker.com/is-monero-at-risk-5-orphan-blocks-spotted-amid-qubic-mining-war/
16:13:22 <m-relay> <r​ucknium:monero.social> Open source code here: https://github.com/Rucknium/xmrconsensus
16:13:33 <m-relay> <r​ucknium:monero.social> You can run it locally on your own machine.
16:13:49 <ofrnxmr> rucknium quick to improve if any issues or suggestions found
16:14:18 <plowsof> has the deepest recent re-org been 2 blocks? Rucknium suggests it becomes exponentially harder the further you go?
16:14:59 <m-relay> <p​lowsof:matrix.org> he also shared that moneromooo added a re-org notifier along with --tx-notify, thank you
16:15:02 <m-relay> <p​lowsof:matrix.org> i wonders if our payment processors are aware of this
16:15:06 <ofrnxmr> It with a minority hashrate. With a majority, i think you just need average luck
16:15:43 <m-relay> <r​ucknium:monero.social> According to my data, yes the deepest re-org recently has been 2 blocks deep. Deeper re-orgs are roughly exponential for each block depth, yes.
16:15:55 <m-relay> <r​ucknium:monero.social> With minority hashpower share, yes
16:16:17 <m-relay> <p​lowsof:matrix.org> ive never looked at the --reorg-notify to be honest https://docs.getmonero.org/interacting/monerod-reference/#accepting-monero
16:16:54 <ofrnxmr> i think reorg-notify for merchants isnt necessary unless were getting to 10 block deep reorgs 
16:17:22 <m-relay> <r​ucknium:monero.social> If you want exact formulas and exact tables for two different attack strategies with minority hashpower share, I direct you to my comment here:  "Success probability of a double-spend attack with minority hashpower share"  https://github.com/monero-project/research-lab/issues/102#issuecomment-2402750881
16:17:27 <m-relay> <p​lowsof:matrix.org> something to put on the radar of btcpayserver perhaps, napoly / deverickapollo? you have a update to share?
16:17:58 <ofrnxmr> while attacker could reorg with confirmed txs -> empty blocks, those txs would still be confirmed by an honest miner 
16:18:28 <m-relay> <d​everickapollo:matrix.org> Ya that's a good idea actually.
16:18:31 <ofrnxmr> and would only not be confirmed if 72hrs go by w/o a confirmation
16:19:10 <ofrnxmr> (reorgs dont drop the tx from the txpool)
16:19:14 <m-relay> <d​everickapollo:matrix.org> For our work, we're moving into milestone 2 now. We want request payout for M1 if all concerns have been addressed at this time.
16:19:29 <ofrnxmr> Isnt the plugin broken tho lol
16:19:30 <m-relay> <r​ucknium:monero.social> ofrnexmr: Exactly. The answer to that question only gets complicated if the re-org is 10 blocks or deeper. Then it is possible that a tx won't be valid on the other chain because, well, you can read the issue that I linked from the top.
16:19:37 <m-relay> <d​everickapollo:matrix.org> On existing work, we are addressing a few bugs that have plagued the environment.
16:19:50 <m-relay> <p​lowsof:matrix.org> Jberman has 3 outstanding payouts FYI plowsof
16:19:53 <m-relay> <d​everickapollo:matrix.org> https://github.com/btcpayserver/dockerfile-deps/pull/119 - I've refactored our original dockerfiles to support upgrades.
16:20:21 <ofrnxmr> The refactoe broke it tho, didnt it?
16:20:28 <m-relay> <d​everickapollo:matrix.org> We never properly handled permissions on mounted volumes so it has been common experience for merchants to fuss with permissions on the host.
16:20:54 <m-relay> <p​lowsof:matrix.org> side note: we need something like  "Support? join support alt coins @ btcpayserver mattermost" at the top of the proposal, i am in there now
16:20:58 <m-relay> <d​everickapollo:matrix.org> Refactor? It was an upgrade to the OS. We've seen this issue exposed many ways. It was always a bug. The upgrade only exposed it
16:21:20 <m-relay> <p​lowsof:matrix.org> do you know if btcpayserver played any role in coincards recent security event?
16:21:37 <m-relay> <p​lowsof:matrix.org> likely not, as accounts where compromised. just checking
16:21:50 <ofrnxmr> the upgrade didnt break because of changinf 18.3.4 -> 18.4.0
16:22:02 <ofrnxmr> It broke because of the refactor, afaict
16:22:04 <m-relay> <d​everickapollo:matrix.org> My understanding is there are no vulnerabilities related to the plugin that caused that incident. I would ask coincards to comment on that further.
16:22:39 <m-relay> <d​everickapollo:matrix.org> No, permissions were never properly handled for mounted volumes.
16:22:53 <ofrnxmr> it worked before the refactor and not after
16:23:20 <ofrnxmr> So you mean to say, reverting the refactor would still lead to broken upgrades?
16:23:34 <m-relay> <d​everickapollo:matrix.org> Note: https://sethforprivacy.com/guides/accepting-monero-via-btcpay-server/#fixing-issues-with-permissions-on-btcpay-server-monero-daemons
16:23:47 <m-relay> <d​everickapollo:matrix.org> Permissions were never properly handled and vendors have been plagued with this issue in many different ways
16:24:14 <m-relay> <p​lowsof:matrix.org> FWD from #monero-hardware:matrix.org MSvB "Saluton everyone, today Saturday (yesterday as well) 9 August 2025 at 10-18 in the Cryptocurrency areas of DEFCON 33 in Las Vegas USA we are distributing Kastelo enclosures free of charge. They are available in the Las Vegas Convention Center (LVCC) West Hall 4 on the ground level, very easy to find. If you are a Monero community member p<clipped message>
16:24:15 <m-relay> <p​lowsof:matrix.org> lease take one free of charge."
16:24:17 <m-relay> <d​everickapollo:matrix.org> My PR introduces an entrypoint to ensure those files are accessible by monero user
16:26:42 <m-relay> <d​everickapollo:matrix.org> From our end, M1 is complete. We are prepared to continue with M2. We plan to remove wallet file functionality and replace with viewkey. This will allow for a more seamless onboarding experience with wallets.
16:27:34 <ofrnxmr> Remove the "upload wallet file" functionality, right?
16:27:52 <m-relay> <p​lowsof:matrix.org> https://github.com/btcpay-monero/btcpayserver-monero-plugin/issues/27 discussed here
16:27:56 <m-relay> <d​everickapollo:matrix.org> That's correct - its the other area of the integration that is poorly designed.
16:28:37 <m-relay> <d​everickapollo:matrix.org> I wanted to share this as it represents a significant change that customers will see in our first release.
16:30:37 <m-relay> <p​lowsof:matrix.org> its in the payout queue, todo: if broken, fix - if not broken - add to the top of proposal "support available @ alt coin support" pointing to the mattermost instance, i think we can move on to the ccs ideas
16:30:51 <ofrnxmr> wait
16:31:18 <ofrnxmr> fcmp++ news: jberman moved fcmp work to be based on the latest monero master
16:32:03 <ofrnxmr> In my uneducated look, it seems that sync times are similar (byte-for-byte) with ringct
16:32:26 <ofrnxmr> Stressnet is likely around the corner
16:32:30 <m-relay> <p​lowsof:matrix.org> jbermans latest CCS update https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/574#note_31061
16:34:23 <m-relay> <p​lowsof:matrix.org> spackle: senior stressnetter and ack-j
16:34:25 <m-relay> <p​lowsof:matrix.org> nice
16:34:48 <m-relay> <p​lowsof:matrix.org> a. [Monero Network Simulation Tool](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589)
16:35:43 <m-relay> <p​lowsof:matrix.org> has been simplified to cover only the creation of monero sim tool assisted by our new intern Large Larry Montgomery
16:36:04 <m-relay> <p​lowsof:matrix.org> LLM-AI for short
16:36:09 <ofrnxmr> I'm on the party of retroactive. A bunch of hallucinations etc 
16:37:14 <m-relay> <p​lowsof:matrix.org> the repo is now also linked in the proposal https://github.com/Fountain5405/monerosim/commits/main/
16:37:23 <ofrnxmr> If completed successfully, i'm pro-merge. But based on the 98.7% LLM work that is filled with hopes and fantasies, i can't bring my self to vote yes
16:37:48 <m-relay> <r​ucknium:monero.social> > Milestones - I have edited this CCS to be just a single deliverable based milestone. I will request payout once I can run a simulated monero network with 1000 nodes, provide setup scripts and documentation.
16:37:50 <ofrnxmr> To vote yes before its completed*
16:37:52 <m-relay> <p​lowsof:matrix.org> it went through a major python re-write https://github.com/Fountain5405/monerosim/commit/82b15a3a575683d719a2cafc4f1323ec9c8293f6
16:38:35 <m-relay> <r​ucknium:monero.social> I suppose if gingeropolous isn't successful with running 1000 nodes, this basically turns into a bounty. That's the way that CCS is supposed to work.
16:38:44 <ofrnxmr> and llm did 100% of the rewrite too, even left its notes in there 
16:39:00 <ofrnxmr> Yeah, if he's not successful it becomes a jetfund
16:39:13 <ofrnxmr> maybe this _should_ be a bounty
16:39:19 <m-relay> <p​lowsof:matrix.org> we need someone to review that its running 1000 nodes and not just echo;ing things :P
16:39:23 <m-relay> <p​lowsof:matrix.org> but sounds good to me
16:39:39 <ofrnxmr> Need someone willing to run the 1million lines (literally) of LLM slop
16:40:19 <m-relay> <r​ucknium:monero.social> This thing will probably be run on one of MRL's research machines, for verification and production operation.
16:40:51 <ofrnxmr> Its already rin on the MRL machines 😆
16:41:05 <m-relay> <r​ucknium:monero.social> The machines are administered by gingeropolous himself, so I assume he would be willing to have his machines run it :)
16:41:10 <m-relay> <r​ucknium:monero.social> Right
16:41:39 <m-relay> <r​ucknium:monero.social> But it should be verifiable by anyone, too. Do it in a VM if you are scared
16:42:32 <m-relay> <p​lowsof:matrix.org> side note: how many hours of run time per year has the MRL used the machine, and is that possible to quantify (i have no idea) gingeropolous
16:43:11 <m-relay> <p​lowsof:matrix.org> i thinks we can move on, no need to discuss gingers proposal again, merge after rate change?
16:44:11 <m-relay> <p​lowsof:matrix.org> moving on
16:44:28 <m-relay> <p​lowsof:matrix.org> f. [MoneroOS Resurrection](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/596)
16:44:37 <m-relay> <r​ucknium:monero.social> I think it's a good idea to merge, given that it is a deliverable-based milestone and it would be great to have _someone_ write this well-defined software. I am not excited about the AI assistance, but you don't always get what's ideal.
16:45:42 <m-relay> <r​ucknium:monero.social> By "well-defined" I mean the requirements are well-defined: Make `shadow` work with `monerod`.
16:46:45 <m-relay> <p​lowsof:matrix.org> reg MoneroOS the proposal remains open for feedback
16:47:10 <ofrnxmr> Ruck, i'd implore you to take a look at the code that has been churned out. LLM seems to make a lot of incorrect assumptions, as well as yolo commiting a lot of nonsense
16:48:30 <ofrnxmr> I'm not confident that it will result in a viable solution, especially not one that can be run outside of the environment. At least not with the repo that is available (with 1 million lines of drunken llm commiting environment specific stuff)
16:49:07 <m-relay> <r​ucknium:monero.social> Could you point to a specific file or dir for me to look in? There are one million lines of code, after all.
16:49:08 <ofrnxmr> i'm not against raising funds for it, but i feel like this is bounty territory
16:49:18 <ofrnxmr> https://github.com/Fountain5405/monerosim/commit/82b15a3a575683d719a2cafc4f1323ec9c8293f6
16:49:56 <m-relay> <r​ucknium:monero.social> I remember when this was a Shell/Rust repo: https://github.com/Rucknium/monerosim
16:50:05 <ofrnxmr> This is a single commit. But after meeting (or during, let me get distracted for a few mins), i can pull up some of LLM's incorrect assumptions  
16:50:19 <m-relay> <r​ucknium:monero.social> Ok thanks.
16:50:33 <m-relay> <r​ucknium:monero.social> Sorry to overrun the other agenda items.
16:50:54 <ofrnxmr> Np. (jk. Sorry too)
16:51:17 <m-relay> <p​lowsof:matrix.org> g. [[hbs] EVM Atomic Swaps](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/597)
16:51:35 <ofrnxmr> i think ravfx might have comment on moneroos
16:52:39 <n1oc> [CCS Proposals] Lee Clagett opened merge request #601: Mark vtnerd-2025-q1 as completed. https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/601
16:53:08 <m-relay> <p​lowsof:matrix.org> h. [Monero Python Maintenance](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/598)
16:53:38 <m-relay> <p​lowsof:matrix.org> everoddandeven is currently busy with integrating i2p into the gui https://github.com/monero-project/monero-gui/pull/4444/files
16:55:18 <m-relay> <p​lowsof:matrix.org> and this monero python should help vthor and Monero Signer on the pi - allegedly
16:56:28 <vthor> greatings! reading in 7 minutes
16:57:19 <m-relay> <p​lowsof:matrix.org> no more monero-wallet-rpc , using python->monero-cpp bindings->wallet2
16:57:40 <m-relay> <p​lowsof:matrix.org> thanks vthor, your opinion on this would be great
16:57:46 <ofrnxmr> I think everodd said it still uaes wallet-rpc
16:58:03 <m-relay> <p​lowsof:matrix.org> sorry yes, it has the option(al) to use wallet-rpc
16:58:23 <m-relay> <p​lowsof:matrix.org> but still everything the wallet2 api offers (everything monero-cpp offers)
16:58:38 <m-relay> <r​ucknium:monero.social> I wonder of this could be useful for stressnet spamming. Or worth a try, at least.
16:58:47 <m-relay> <p​lowsof:matrix.org> and some extra things that should be PR'd upstream to monero-cpp and reviewed 😬
16:59:08 <m-relay> <r​ucknium:monero.social> I wonder if this...*
16:59:14 <ofrnxmr> i think wallet-rpc or prepating outpurs ahead of time is the most useful 
16:59:30 <m-relay> <p​lowsof:matrix.org> the tldr is to just think of it as python being able to use https://github.com/woodser/monero-cpp
17:00:17 <ofrnxmr> or rather, works as well as possible. Issue i'm having today seems to be that the output selected has changed. Somehow, most of my txmr has consolidated into single inputs 
17:00:54 <m-relay> <p​lowsof:matrix.org> more food for thought everoddandeven, while we reach the hour we can share Rucks prior to merge as he is present , maybe some has questions
17:01:08 <m-relay> <p​lowsof:matrix.org> and vthor can hopefully catch up shortly
17:01:24 <ofrnxmr> +1 ruck, berman, vtnerd 
17:01:26 <m-relay> <p​lowsof:matrix.org> i. [Rucknium Research II](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/599)
17:02:01 <m-relay> <p​lowsof:matrix.org> j. [j-berman full-time development (4 months)](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/600)
17:02:59 <vthor> so, i'm here
17:03:16 <m-relay> <r​ucknium:monero.social> Yes I can take questions and comments about my proposal live here.
17:04:16 <m-relay> <p​lowsof:matrix.org> perhaps this can spring board DataHoarder into creating his ccs proposal finally
17:05:01 <m-relay> <r​avfx:xmr.mx> MoneroOs. Sorry for delay, just woke up.
17:05:03 <m-relay> <r​avfx:xmr.mx> PXE boot capability should be a requirement for it to be more useful for me. (and probably other miners with many machine... )
17:05:05 <m-relay> <r​avfx:xmr.mx> Once Monero OS is booted, have a small script that allow creating PXE capabilities, that also print the required settings that need to be stuffed into the DHCP server. That way you could have one booted monero os on one of the machine then you can boot the 15 others thinkcentres from the network with a minimal image just for mining, no need to have the whole blockchain on more tha<clipped message>
17:05:07 <m-relay> <r​avfx:xmr.mx> n one machine anyway.
17:05:09 <m-relay> <r​avfx:xmr.mx> That's how I would use it personally, I don't know if that's possible considering there is already one milestone done.
17:05:31 <m-relay> <r​ucknium:monero.social> Yes DataHoarder helped me a lot with pool data collection for https://moneroconsensus.info/ . His code for the data gathering script is here: https://git.gammaspectra.live/WeebDataHoarder/monero-blocks
17:06:32 <vthor> So, it will probably not really help me, I have already the python wrapper for the OTS(offline transaction signing) library (C++/C-ABI), my biggest challenge ahead is to get the RandomX part compiled for armv6 (not right sure if it was v6 or v7, need to check).
17:08:43 <plowsof> ravfx is arch linux known for the odd bugs here and there? would miners care to deal with that? what about ansible giving updates / stats?
17:09:25 <plowsof> vthor thanks for checking - if there was a time machine, it would have helped you?
17:09:30 <vthor> but for https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/598 +1, this is what I in reality expected python-monero to do when I started with the XmrMiner, and of the SDK (modularized) I dream of is probably still lightyears away
17:10:12 <plowsof> python implementation of Polyseed which you created many moons ago, will not be required once polyseed is added into monero core  - accessible via python->monero-cpp 
17:12:08 <vthor> yes, think so, probably I would still have to fight with compliling for the armv? (now I will look it up)6
17:12:53 <m-relay> <p​lowsof:matrix.org> i assume if monero-cpp compiles for armv woodser it wouldnt be a problem? i dont know
17:13:10 <vthor> nope, but in OTS I added already Poolyseed, maybe worth a look before reimplementing
17:13:55 <m-relay> <r​avfx:xmr.mx> All distributions have they own possible quirks and/or issues. Assuming the maintainers can maintains the relevent monero stuff it should be OK. Personally I am fine with Arch. Alpine would be better considering it look like it's a "server" distribution (smaller footprint, more reliable updates in the long term but agains if it's only monero stuff and not used for a desktop usecas<clipped message>
17:13:55 <m-relay> <r​avfx:xmr.mx> e then it should be OK with arch)
17:16:39 <m-relay> <w​oodser:monero.social> it should be able to compile to whatever wallet2 can compile to afaik
17:17:00 <m-relay> <p​lowsof:matrix.org> can end the meeting here i thinks, thanks all for attending 🙏
17:23:05 <ofrnxmr> @rucknium https://github.com/Fountain5405/monerosim/blob/main/SHADOW_OPTIMIZATIONS.md for example
17:25:23 <m-relay> <p​lowsof:matrix.org> LLM NO... this is a tool for stress testing. DO NOT OPTIMISE things.
17:25:31 <m-relay> <p​lowsof:matrix.org> You're absolutely right
17:25:53 <ofrnxmr> Monero isnt 8out 64in by default. Log level 4 is absolutely brutal / not an optimization at all. P2p-use-ipv6=false is default, but this sets the flag to disable ipv6
17:54:44 <m-relay> <g​ingeropolous:monero.social> log level 4 helped the bots debug some shit. it was wild watching it match timings between logs.
17:55:06 <m-relay> <g​ingeropolous:monero.social> my apologies for using git as a means to track changes and not whatever you imagine it to be
17:58:40 <m-relay> <g​ingeropolous:monero.social> and the repo is by no means production ready or collaboration ready obvi. i shared it because it was requested. last time i do that
18:01:03 <ofrnxmr> No need to play the victim card when youre letting LLM commit the entire working directory¸ including multiple venvs and million of lines of "code"
18:02:21 <ofrnxmr> and again, i'm not against funding the deliverable, but the repo shoes that this is a lot of  "jesus take the wheel"
18:07:33 <m-relay> <g​ingeropolous:monero.social> yeah i shoulda stuck to bash. stupid python
18:08:34 <m-relay> <g​ingeropolous:monero.social> at some point ima get that venv crap cleaned up. its just not important to me at this phase
18:12:34 <ofrnxmr> Personally, id never let an llm make commits on my behalf
18:20:12 <ofrnxmr> ofrnLLM https://github.com/Fountain5405/monerosim/pull/1
18:20:54 <ofrnxmr> this might delete your local venv (which youll have to recreate), YMMV
18:23:41 <ofrnxmr> alternative: instead of having these massive commits in the history, i'd probably go back and modify the commit history and fix the commits that added in the first place
18:25:48 <m-relay> <g​ingeropolous:monero.social> when it gets to a clean working state im going to post it up fresh somehow
21:36:53 <m-relay> <e​ntre667:matrix.org> Is there a monero name service?
21:37:25 <m-relay> <e​ntre667:matrix.org> If so I'd be very interested in using it?
22:56:40 <m-relay> <g​ooseworld:matrix.org> Anyone here try keet.io ?