<d​everickapollo:matrix.org> plowsof: Napoly and I are requesting to add btcpay update to today’s agenda. Thanks

<p​lowsof:matrix.org> deverickapollo: a new update or payout request @ repo.getmonero.org/monero-project/c…als/-/merge_requests/538#note_30318 ?

<p​lowsof:matrix.org> meeting in 1hr20~ mins monero-project/meta #1251

<p​lowsof:matrix.org> thanks for responding to the update rates on CCS request Rucknium. cc hinto vtnerd acx rottenwheel

<p​lowsof:matrix.org> gingeropolous

<d​everickapollo:matrix.org> Both - status check on M1 deliverable and a brief update on implementation for M2

<p​lowsof:matrix.org> Rucknium reg research bounties banned @ 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>

<p​lowsof:matrix.org> ke that even more problematic IMO, why not just keep open competitions on the CCS?

<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

<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.

<p​lowsof:matrix.org> other funding platforms are available* 😄

<s​gp_:monero.social> Getting this on the payment radar (no meeting discussion needed): repo.getmonero.org/monero-project/c…als/-/merge_requests/449#note_31074

greetings ACK sgp

<r​ucknium:monero.social> Hi

<p​lowsof:matrix.org> monero-project/meta #1251

<p​lowsof:matrix.org> Meeting time 👋

👋

<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

<p​lowsof:matrix.org> tevador has returned monero-project/research-lab #98#issuecomment-3170712102

<v​tnerd:monero.social> I just updated rates

<p​lowsof:matrix.org> and alot of fresh comments under kayabanerves issue for bolstering PoW to be resistant against 51% attack monero-project/research-lab #136

<p​lowsof:matrix.org> vtnerd again! (thank you)

<p​lowsof:matrix.org> so tevadors proposed solution could see pools increase fee's to 6% as an example

<r​ucknium:monero.social> I created moneroconsensus.info to visualize orphan blocks and alternative chains, which could indicate "selfing mining" behavior. Covered by press here and elsewhere: coinspeaker.com/is-monero-at-risk-5…locks-spotted-amid-qubic-mining-war

<r​ucknium:monero.social> Open source code here: github.com/Rucknium/xmrconsensus

<r​ucknium:monero.social> You can run it locally on your own machine.

rucknium quick to improve if any issues or suggestions found

has the deepest recent re-org been 2 blocks? Rucknium suggests it becomes exponentially harder the further you go?

<p​lowsof:matrix.org> he also shared that moneromooo added a re-org notifier along with --tx-notify, thank you

<p​lowsof:matrix.org> i wonders if our payment processors are aware of this

It with a minority hashrate. With a majority, i think you just need average luck

<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.

<r​ucknium:monero.social> With minority hashpower share, yes

<p​lowsof:matrix.org> ive never looked at the --reorg-notify to be honest docs.getmonero.org/interacting/monerod-reference/#accepting-monero

i think reorg-notify for merchants isnt necessary unless were getting to 10 block deep reorgs

<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" monero-project/research-lab #102#issuecomment-2402750881

<p​lowsof:matrix.org> something to put on the radar of btcpayserver perhaps, napoly / deverickapollo? you have a update to share?

while attacker could reorg with confirmed txs -> empty blocks, those txs would still be confirmed by an honest miner

<d​everickapollo:matrix.org> Ya that's a good idea actually.

and would only not be confirmed if 72hrs go by w/o a confirmation

(reorgs dont drop the tx from the txpool)

<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.

Isnt the plugin broken tho lol

<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.

<d​everickapollo:matrix.org> On existing work, we are addressing a few bugs that have plagued the environment.

<p​lowsof:matrix.org> Jberman has 3 outstanding payouts FYI plowsof

<d​everickapollo:matrix.org> btcpayserver/dockerfile-deps #119 - I've refactored our original dockerfiles to support upgrades.

The refactoe broke it tho, didnt it?

<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.

<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

<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

<p​lowsof:matrix.org> do you know if btcpayserver played any role in coincards recent security event?

<p​lowsof:matrix.org> likely not, as accounts where compromised. just checking

the upgrade didnt break because of changinf 18.3.4 -> 18.4.0

It broke because of the refactor, afaict

<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.

<d​everickapollo:matrix.org> No, permissions were never properly handled for mounted volumes.

it worked before the refactor and not after

So you mean to say, reverting the refactor would still lead to broken upgrades?

<d​everickapollo:matrix.org> Note: sethforprivacy.com/guides/accepting…ons-on-btcpay-server-monero-daemons

<d​everickapollo:matrix.org> Permissions were never properly handled and vendors have been plagued with this issue in many different ways

<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>

<p​lowsof:matrix.org> lease take one free of charge."

<d​everickapollo:matrix.org> My PR introduces an entrypoint to ensure those files are accessible by monero user

<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.

Remove the "upload wallet file" functionality, right?

<p​lowsof:matrix.org> btcpay-monero/btcpayserver-monero-plugin #27 discussed here

<d​everickapollo:matrix.org> That's correct - its the other area of the integration that is poorly designed.

<d​everickapollo:matrix.org> I wanted to share this as it represents a significant change that customers will see in our first release.

<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

wait

fcmp++ news: jberman moved fcmp work to be based on the latest monero master

In my uneducated look, it seems that sync times are similar (byte-for-byte) with ringct

Stressnet is likely around the corner

<p​lowsof:matrix.org> jbermans latest CCS update repo.getmonero.org/monero-project/c…als/-/merge_requests/574#note_31061

<p​lowsof:matrix.org> spackle: senior stressnetter and ack-j

<p​lowsof:matrix.org> nice

<p​lowsof:matrix.org> a. [Monero Network Simulation Tool](repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589)

<p​lowsof:matrix.org> has been simplified to cover only the creation of monero sim tool assisted by our new intern Large Larry Montgomery

<p​lowsof:matrix.org> LLM-AI for short

I'm on the party of retroactive. A bunch of hallucinations etc

<p​lowsof:matrix.org> the repo is now also linked in the proposal github.com/Fountain5405/monerosim/commits/main

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

<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.

To vote yes before its completed*

<p​lowsof:matrix.org> it went through a major python re-write Fountain5405/monerosim 82b15a3

<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.

and llm did 100% of the rewrite too, even left its notes in there

Yeah, if he's not successful it becomes a jetfund

maybe this _should_ be a bounty

<p​lowsof:matrix.org> we need someone to review that its running 1000 nodes and not just echo;ing things :P

<p​lowsof:matrix.org> but sounds good to me

Need someone willing to run the 1million lines (literally) of LLM slop

<r​ucknium:monero.social> This thing will probably be run on one of MRL's research machines, for verification and production operation.

Its already rin on the MRL machines 😆

<r​ucknium:monero.social> The machines are administered by gingeropolous himself, so I assume he would be willing to have his machines run it :)

<r​ucknium:monero.social> Right

<r​ucknium:monero.social> But it should be verifiable by anyone, too. Do it in a VM if you are scared

<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

<p​lowsof:matrix.org> i thinks we can move on, no need to discuss gingers proposal again, merge after rate change?

<p​lowsof:matrix.org> moving on

<p​lowsof:matrix.org> f. [MoneroOS Resurrection](repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/596)

<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.

<r​ucknium:monero.social> By "well-defined" I mean the requirements are well-defined: Make `shadow` work with `monerod`.

<p​lowsof:matrix.org> reg MoneroOS the proposal remains open for feedback

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

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)

<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.

i'm not against raising funds for it, but i feel like this is bounty territory

<r​ucknium:monero.social> I remember when this was a Shell/Rust repo: github.com/Rucknium/monerosim

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

<r​ucknium:monero.social> Ok thanks.

<r​ucknium:monero.social> Sorry to overrun the other agenda items.

Np. (jk. Sorry too)

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

i think ravfx might have comment on moneroos

[CCS Proposals] Lee Clagett opened merge request #601: Mark vtnerd-2025-q1 as completed. repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/601

<p​lowsof:matrix.org> h. [Monero Python Maintenance](repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/598)

<p​lowsof:matrix.org> everoddandeven is currently busy with integrating i2p into the gui monero-project/monero-gui #4444/files

<p​lowsof:matrix.org> and this monero python should help vthor and Monero Signer on the pi - allegedly

greatings! reading in 7 minutes

<p​lowsof:matrix.org> no more monero-wallet-rpc , using python->monero-cpp bindings->wallet2

<p​lowsof:matrix.org> thanks vthor, your opinion on this would be great

I think everodd said it still uaes wallet-rpc

<p​lowsof:matrix.org> sorry yes, it has the option(al) to use wallet-rpc

<p​lowsof:matrix.org> but still everything the wallet2 api offers (everything monero-cpp offers)

<r​ucknium:monero.social> I wonder of this could be useful for stressnet spamming. Or worth a try, at least.

<p​lowsof:matrix.org> and some extra things that should be PR'd upstream to monero-cpp and reviewed 😬

<r​ucknium:monero.social> I wonder if this...*

i think wallet-rpc or prepating outpurs ahead of time is the most useful

<p​lowsof:matrix.org> the tldr is to just think of it as python being able to use github.com/woodser/monero-cpp

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

<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

<p​lowsof:matrix.org> and vthor can hopefully catch up shortly

+1 ruck, berman, vtnerd

<p​lowsof:matrix.org> i. [Rucknium Research II](repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/599)

<p​lowsof:matrix.org> j. [j-berman full-time development (4 months)](repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/600)

so, i'm here

<r​ucknium:monero.social> Yes I can take questions and comments about my proposal live here.

<p​lowsof:matrix.org> perhaps this can spring board DataHoarder into creating his ccs proposal finally

<r​avfx:xmr.mx> MoneroOs. Sorry for delay, just woke up.

<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... )

<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>

<r​avfx:xmr.mx> n one machine anyway.

<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.

<r​ucknium:monero.social> Yes DataHoarder helped me a lot with pool data collection for moneroconsensus.info . His code for the data gathering script is here: git.gammaspectra.live/WeebDataHoarder/monero-blocks

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).

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?

vthor thanks for checking - if there was a time machine, it would have helped you?

but for 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

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

yes, think so, probably I would still have to fight with compliling for the armv? (now I will look it up)6

<p​lowsof:matrix.org> i assume if monero-cpp compiles for armv woodser it wouldnt be a problem? i dont know

nope, but in OTS I added already Poolyseed, maybe worth a look before reimplementing

<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>

<r​avfx:xmr.mx> e then it should be OK with arch)

<w​oodser:monero.social> it should be able to compile to whatever wallet2 can compile to afaik

<p​lowsof:matrix.org> can end the meeting here i thinks, thanks all for attending 🙏

@rucknium github.com/Fountain5405/monerosim/blob/main/SHADOW_OPTIMIZATIONS.md for example

<p​lowsof:matrix.org> LLM NO... this is a tool for stress testing. DO NOT OPTIMISE things.

<p​lowsof:matrix.org> You're absolutely right

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

<g​ingeropolous:monero.social> log level 4 helped the bots debug some shit. it was wild watching it match timings between logs.

<g​ingeropolous:monero.social> my apologies for using git as a means to track changes and not whatever you imagine it to be

<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

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"

and again, i'm not against funding the deliverable, but the repo shoes that this is a lot of "jesus take the wheel"

<g​ingeropolous:monero.social> yeah i shoulda stuck to bash. stupid python

<g​ingeropolous:monero.social> at some point ima get that venv crap cleaned up. its just not important to me at this phase

Personally, id never let an llm make commits on my behalf

ofrnLLM Fountain5405/monerosim #1

this might delete your local venv (which youll have to recreate), YMMV

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

<g​ingeropolous:monero.social> when it gets to a clean working state im going to post it up fresh somehow

<e​ntre667:matrix.org> Is there a monero name service?

<e​ntre667:matrix.org> If so I'd be very interested in using it?

<g​ooseworld:matrix.org> Anyone here try keet.io ?