<c​howbungaman:matrix.org> Ok please do 🙏

<c​harlieere:matrix.org> Any Cashapp? Chime? Zelle? Btc? Usdt?Skrill? Apple Pay? Paypal? Venmo? BOA? Wells Fargo? Join my channel

<c​harlieere:matrix.org> t.me/+zEFPK-AiVFEyZDM0

<c​harlieere:matrix.org> 
Got any of these
Chase?
BOA?
Wells Fargo?
Navy federal?
Capital one?
Truist?
Att &t?
PNC?
TD bank?
Credit union?
M&T bank?
Santander bank?
Northwest bank?
Or any other local Bank
JOIN THE CHANNEL NOW TO GET PAID💯 ✅

<g​ingeropolous:monero.social> so i never know where i'll be at meeting time, so my updates for today re: monerosim : I think i have an mvp working. well, mvp might be too strong. the nodes start, make blocks, relay them, and im working on confirming that txs get created and relayed.

<g​ingeropolous:monero.social> so far though, my thoughts have wandered, and I ponder whether shadow is indeed the best approach for what we want. I think in some perspectives, what shadow offers can be helpful. But, for instance, for testing like the effect of FCMP load on the network, shadows design might be too ... simulated. For instance, they treat CPUs as having infinite speed. So I think the best route f<clipped me

<g​ingeropolous:monero.social> or the network as a distributed computational network might be best simulated via some docker thing i came across (we lose reproducability, but I think that can be augmented by just performing repeat sims... like a monte carlo kinda thing). However, if we're interested in how txs and blocks get slung around the network, then I think shadow is the way, due to its internal tick tock<clipped me

<g​ingeropolous:monero.social> of events. We might get the best of both worlds by using shadow and figuring out how to simulate the time required for each kind of computation, but for me that is down the line.

<r​ucknium:monero.social> MRL meeting in this room in about two hours.

<s​yntheticbird:monero.social> 9zsjcz.gif

<g​ingeropolous:monero.social> deterministic. thats what i wanted. not reproducible. well, i guess they are related.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1235

<r​ucknium:monero.social> 1) Greetings

<v​tnerd:monero.social> Hi

<a​rticmine:monero.social> Hi

<s​gp_:monero.social> hi

<j​berman:monero.social> *waves*

Hello

<a​ntilt:we2.ee> seas

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<r​ucknium:monero.social> me: Improvements to the reachable node network scanner. Thread-safe database writing, added Autonomous System (AS) data, AS treemap and concentration index, domain data for the nodes that use domains for public remote nodes, better performance with default static image treemaps, and searchable/filterable table of individual node data in the webapp: moneronet.info

<v​tnerd:monero.social> Me: docs for LWS, rounding out the lwsf implementation, then getting a fork prepped for lwsf+monero_c

<j​berman:monero.social> me: continuing scan_tx for FCMP++ (in discussions with jeffro256 , we agreed it would make sense to remove the ability to scan *future* txs relative to the wallet's current sync height, and to implement ~instant restore at arbitrary height so wallets don't sit downloading any block hashes, see: seraphis-migration/monero #49) and other PR wrangling

<j​effro256:monero.social> Howdy

<j​effro256:monero.social> Me: catching up on math for divisors review and getting back to working on hot/cold wallets

<r​ucknium:monero.social> `lwsf` = Light-wallet server frontend.

<s​gp_:monero.social> great! I'm looking forward to the fork/PR

<g​ingeropolous:monero.social> heya, i made it. copy pasta from above for the logs: me: so i never know where i'll be at meeting time, so my updates for today re: monerosim : I think i have an mvp working. well, mvp might be too strong. the nodes start, make blocks, relay them, and im working on confirming that txs get created and relayed.

<g​ingeropolous:monero.social> so far though, my thoughts have wandered, and I ponder whether shadow is indeed the best approach for what we want. I think in some perspectives, what shadow offers can be helpful. But, for instance, for testing like the effect of FCMP load on the network, shadows design might be too ... simulated. For instance, they treat CPUs as having infinite speed. So I think the best route f<clipped me

<g​ingeropolous:monero.social> or the network as a distributed computational network might be best simulated via some docker thing i came across (we lose reproducability, but I think that can be augmented by just performing repeat sims... like a monte carlo kinda thing). However, if we're interested in how txs and blocks get slung around the network, then I think shadow is the way, due to its internal tick tock<clipped me

<g​ingeropolous:monero.social> of events. We might get the best of both worlds by using shadow and figuring out how to simulate the time required for each kind of computation, but for me that is down the line.

<r​ucknium:monero.social> Thanks for the updates, everyone.

<r​ucknium:monero.social> 3) [SLVer Bullet: Straight Line Verification for Bulletproofs](github.com/cypherstack/silver-bullet). [Cypher Stack review of divisors for FCMP](github.com/cypherstack/divisor_deep_dive).

<r​ucknium:monero.social> Are there update on this item?

<j​berman:monero.social> From an implementation standpoint, I believe kayabanerve is still working on implementing the proposed changes

<r​ucknium:monero.social> 4. [FCMP++ optimization coding competition](getmonero.org/2025/04/05/fcmp++-contest.html).

<j​berman:monero.social> Divisors still in review (no objections raised so far), helioselene contest ongoing with no new submissions. Reminder the new deadline is tomorrow (July 10, 17:00 UTC)

<j​berman:monero.social> New deadline for helioselene*

<j​berman:monero.social> Thanks to all for participating in last week's meeting and helping us settle on the decision to open the helioselene contest for all again for 1 additional week

<s​yntheticbird:monero.social> lightning fast meeting

<r​ucknium:monero.social> There are still three items :)

<r​ucknium:monero.social> 5. [FCMP alpha stressnet planning](seraphis-migration/monero #53).

<r​ucknium:monero.social> The link^ is to the overall FCMP checklist.

<r​ucknium:monero.social> It seems that putting the blinds cache implementation later in the schedule was a lucky decision.

<j​berman:monero.social> I wouldn't say lucky exaaaaactly, but yes :)

<r​ucknium:monero.social> Luck favors the well-prepared :)

<j​effro256:monero.social> I think that we could organize this TODO list in "must-haves" and "nice-to-haves" for a stressnet launch. For example, multisig and vendor-specific HW implemenations probably aren't exactly required for a stressnet

<j​effro256:monero.social> And both of those could take a very long time, it doesn't make sense to wait for those for stressnet

<j​berman:monero.social> Main must-have TODO's I'd say for a stressnet are: divisors re-impl from SLVer bullet, and settling on fabrizio's submission / pulling it into the code (so that blinds calculations don't take forever)

<j​berman:monero.social> The highest priority nice-to-haves I'd say are: optimizing prove, supporting >8 inputs per tx, helioselene contest optimizations, AND dynamic block weight / tx weight changes (ping ArticMine)

<j​berman:monero.social> Aside from that, I think the integration code is pretty much ready for an alpha stressnet

<j​effro256:monero.social> I would put >8-in on "must-have" for a stressnet, since >8-in would be extremely useful for stressing

<r​ucknium:monero.social> Sounds good to me. How much work is >8-in?

<j​effro256:monero.social> Other than that, I agree

<r​ucknium:monero.social> I wonder if >8-in could be scheduled for the "public" stressnet, later.

<j​berman:monero.social> Well, integration side for >8-in is mostly done, it's optimizing prove that I'd say is the main impediment (prove currently is extremely slow far many-input txs when it's not supposed to be)

<a​rticmine:monero.social> Noted regarding scaling TX weight dynamic blocksize

<j​berman:monero.social> ArticMine possible we can get a pdf like you made for last hf that documents proposed changes? monero-project/monero #7819#issuecomment-889795966

<a​rticmine:monero.social> Yes

<r​ucknium:monero.social> jeffro256: Do you want to take change of an alpha stressnet TODO list?

<j​effro256:monero.social> Yes I can do that today, and just post a distilled list as a comment under the original issue. Would that be good?

<r​ucknium:monero.social> Here? I don't see it: seraphis-migration/monero #53

<j​effro256:monero.social> Yes that's the GH issue I was talking about. I haven't made the comment yet

<r​ucknium:monero.social> Ah, I misunderstood. Sounds good to me. Thank you.

<r​ucknium:monero.social> 6) [Spy nodes](monero-project/research-lab #126).

<r​ucknium:monero.social> I improved the network node scan webapp: moneronet.info

<r​ucknium:monero.social> Source code here: github.com/Rucknium/xmrnetscan

<r​ucknium:monero.social> I improved the network crawler itself. It's thread-safe now and writes most of the data to a SQLite database instead of just a text file.

<r​ucknium:monero.social> The first version had to run in a single thread because many threads writing to the same text file caused "corruption". The single-threaded version seemed to not completely finish the scan in a 24-hour window. The new thread-safe implementation, using the `tokio-sqlite` Rust crate, uses 10 threads and finishes in about 3 hours.

<r​ucknium:monero.social> I added Autonomous System (AS) data by making API calls to Team Cymru. I got data on the (few) domains that may be associated with remote nodes from ditatompel's API: xmr.ditatompel.com/remote-nodes

<r​ucknium:monero.social> I added an AS treemap and timeline of AS concentration (the Herfindahl-Hirschman Index). You can see from the AS treemap that all suspected spy nodes seem to be in just three ASes: LionLink, Hetzner, and DigitalOcean. There are also honest nodes in Hetzner and Digital Ocean, but no honest nodes in LionLink.

<r​ucknium:monero.social> I also added a searchable/filterable table of individual nodes. From there, you can see if specific remote nodes (with domains) are using the MRL and/or DNS ban lists. I have started to contact some remote node operators to see if they would enable the spy node ban list.

<r​ucknium:monero.social> Next, I want to do a write-up of why it may be a good idea to rotate out a few IP addresses from the DNS ban list, which is at maximum capacity, and put in at least the big subnets from the MRL ban list.

<r​ucknium:monero.social> And I removed the part of the stacked line graph with the unreachable node data, since there is not really a reliable way, yet, to estimate the number of unreachable nodes.

<r​ucknium:monero.social> If you have any ideas about more data and/or plots to add, let me know.

<r​ucknium:monero.social> The Herfindahl-Hirschman Index is used in economics to measure market concentration. It is supposed to be a basic metric of industry competitiveness and the risk of large firms using their market power to harm consumer interests.

<c​haser:monero.social> this tool is very neat, thank you Rucknium!

<g​ingeropolous:monero.social> yeah, really cool. can use it to find "trustable" remote nodes :P

<r​ucknium:monero.social> You compute the square of the market share of every firm in a market, then sum those squares.

<r​ucknium:monero.social> I was thinking that maybe the info on enabling ban lists can be pulled back into ditatompel's remote node table.

<s​yntheticbird:monero.social> would be actually interesting to see on the map which nodes are registered by monero.fail

<s​yntheticbird:monero.social> maybe there is some overlap with the spy nodes?

<s​yntheticbird:monero.social> They have their RPC port open

<r​ucknium:monero.social> This webapp can get far more interactive. The server side of it runs an ordinary R process. Now, it is set up as a dashboard, but it can go further, within reason.

<r​ucknium:monero.social> monero.fail has a simple API, but I would have to query each of the domains to get the IP addresses.

<s​yntheticbird:monero.social> yes

<s​yntheticbird:monero.social> or maybe you could do a reverse dns yourself

<s​yntheticbird:monero.social> expanding outside of monero.fail

<s​yntheticbird:monero.social> just check which ip have a dns record associated to it

<r​ucknium:monero.social> Ah, another thing I did was to confirm that the RPC ports were actually enabled and open. I ping every RPC port that the nodes claim to have. If it responds appropriately to a `get_info` request, then it is counted as having RPC available. Before, I just assume that each node was telling the trust in its Levin handshake.

<r​ucknium:monero.social> I looked into reverse DNS. It is more complicated than I thought.

<s​yntheticbird:monero.social> fyi, spy nodes have 4 rpc ports opened on the same ip

<j​effro256:monero.social> The webapp has a beautiful visualization BTW

<j​effro256:monero.social> Were any nodes lying about their RPC port being open? Perhaps some people didn't set up their ports correctly

<r​ucknium:monero.social> A "standard" reverse DNS does not get domains. You have to get an API key to a proprietary service like VirusTotal to actually get domains.

<r​ucknium:monero.social> I originally wanted to do a full "reverse DNS", but the proprietary API stopped me. Then I went to ditatompel's API.

<s​yntheticbird:monero.social> I'm honestly surprised by that

<r​ucknium:monero.social> I think it went down from 30% to 25% of honest nodes having RPC, after I did the port RPC calls.

<j​effro256:monero.social> Who would we contact about this?

<g​ingeropolous:monero.social> i wonder how possible it would be to add this filtering to the gui simple mode.

<j​effro256:monero.social> Are you talking about the deduplication change?

<r​ucknium:monero.social> My rucknium.me node actually says during its Levin handshake that it doesn't have an RPC port enabled, but I actually do. I think it's just piped through NGINX. Maybe I should check my config (hypocrite 😁). Or, wait, maybe it does say it during the handshake, but i have ports locked down

<j​effro256:monero.social> Or DNS ban list?

<r​ucknium:monero.social> jeffro256: AFAIK, Core manages the DNS records.

<g​ingeropolous:monero.social> something. currently it just uses the advertised rpc on the monero p2p network. im not sure if it has the DNS ban list to remove the ones from the p2p

<r​ucknium:monero.social> I just checked the full database. No, my node even says during the handshake that it does not have the RPC port enabled.

<r​ucknium:monero.social> gingeropolous: That's those nodes with the `--public-node` flag enabled, right?

<g​ingeropolous:monero.social> yeah

<j​effro256:monero.social> I would have to check if bootstap daemons are not used if on the banlist ..

<j​effro256:monero.social> i would hope so

<r​ucknium:monero.social> Does anyone know anything about the opennode.xmr-tw.org remote node domain, by the way? Its DNS record points to three IP addresses, one of which is plowsof 's monerodevs.org remote node IP

<r​ucknium:monero.social> Is the webapp loading OK now? I tried to make it load faster in this iteration.

<g​ingeropolous:monero.social> yeah, the name of the dude that runs it will come to me eventually. i think its lza menace, or is that the monero.fail guy...

<s​yntheticbird:monero.social> that's comfortable enough to use

<s​yntheticbird:monero.social> 7.5/10

<r​ucknium:monero.social> The data exclude the few nodes with IPv6 IP addresses. I will have to decide how to handle them.

<s​yntheticbird:monero.social> promising

<s​yntheticbird:monero.social> will be back

<s​yntheticbird:monero.social> will return

<r​ucknium:monero.social> lza menace runs monero.fail AFAIK

<g​ingeropolous:monero.social> or lafudoci . github.com/Lafudoci/moneriote-python

<g​ingeropolous:monero.social> they used to run the moneriote script and have it populate the DNS of that domain in a geo-located manner, but i guess they just handpicked after the infestation

<r​ucknium:monero.social> 7) CCS proposal: [Monero Network Simulation Tool](repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589).

<r​ucknium:monero.social> gingeropolous: Thanks for making progress on Shadow-Monero. I agree that Shadow isn't necessarily suited for replacing a live stressnet. Still, it can help a lot with testing new network code that doesn't have to go through a full stressnet.

<g​ingeropolous:monero.social> i put the main update above in the status, but briefly, i have something working. I wouldn't say its production ready at all.

<g​ingeropolous:monero.social> yeah, i think i was hoping more for a stressnet-in-a-can kinda thing

<r​ucknium:monero.social> Were you able to talk with 0xfffc about requirements and comparison with...that other system?

<g​ingeropolous:monero.social> but i also see the value is shadows ability to test dandelion parameters or clover or etc

<g​ingeropolous:monero.social> no, they are busy at the moment.

<g​ingeropolous:monero.social> but if anyone has any requested features of a monero shadow network sim, please let me know so i can bake them in early

<j​effro256:monero.social> After skimming the p2p code, the candidates for the RPC bootstrap daemon are collected from the public RPC entries in the P2P peerlist. When one opens `monerod` with a ban list, the spy nodes are evicted from the P2P peerlist and put on a blacklist from being added back in. So since the P2P peerlist is filtered of spies, the RPC bootstrap daemon candidates should be filtered of spies.

<j​effro256:monero.social> ... I think, haven't tested yet

<r​ucknium:monero.social> Did you publish the XMRshadow code somewhere?

<g​ingeropolous:monero.social> again, this will be more focused on the network / p2p side of the monero protocol, not necessarily performance / blockchainy stuff

<r​ucknium:monero.social> (And what will this thing be called? XMRshadow, Shadow-Monero Monero-Shadow...?

its currently monerosim

sorry, element crashed

<r​ucknium:monero.social> jeffro256: The P2P peerlist being filtered of spies is the basis of my detection that a node is using either of the ban lists. If no IP addresses on the ban list appear in the peerlist shared during a P2P handshake, then it is assumed that the node has the ban list enabled.

<g​ingeropolous:monero.social> Rucknium: , and i haven't shared yet. the code is sorta in an embarasing state :

<r​ucknium:monero.social> Just post it under a CRAPL license

<r​ucknium:monero.social> matt.might.net/articles/crapl

<a​ntilt:we2.ee> @gingeropolous:monero.social can the dynamic aspects be simulated? For ex. If a supernode goes down - will others take their place?

<r​ucknium:monero.social> > It's not the kind of code one is proud of.

<r​ucknium:monero.social> > I think a lot of academics are embarrassed to release their code.

<r​ucknium:monero.social> > But, it doesn't matter. We should release our code, warts and all.

<r​ucknium:monero.social> (Technically I don't know if CRAPL satisfies the FSF requirements for an open source license. Check on that.)

<g​ingeropolous:monero.social> flip flop: , yeah. in shadow, you can create instances of things (thats the best name i have) with set parameters, so you could create an instance that is a supernode, set to start at time n, then set to die at time x, and see how the network responds.

<g​ingeropolous:monero.social> Rucknium: regarding sharing, im also not at a point to welcome PRs if anyone got ambitious. i dunno. this fiddlin on my own is my current comfort level

<r​ucknium:monero.social> I think if it is still in the CCS process, it would be a very good idea to give it an open source license and post it. CC: plowsof

<g​ingeropolous:monero.social> yeah it has the the same license as monero i think

<r​ucknium:monero.social> In Shadow you can also set network parameters like bandwidth and latency at the node and even connection level, IIRC. SO you can have some far away nodes and bandwidth-constricted node, etc.

<r​ucknium:monero.social> More discussion of `monerosim`?

<g​ingeropolous:monero.social> aight, well then, in the spirit of crapl, github.com/Fountain5405/monerosim

<r​ucknium:monero.social> Nice! Thank you, gingeropolous

<r​ucknium:monero.social> Any information about how much RAM one of the Monero nodes uses when it is in `monerosim`?

<r​ucknium:monero.social> I am interested in how it would scale.

<g​ingeropolous:monero.social> i dunno yet. Im not at the optimization stage. From what i gather from the bitcoin-shadow plugin (yeah, one exists), you can get thousands of nodes on one machine

<r​ucknium:monero.social> Any other business?

<a​ntilt:we2.ee> network topology:

<a​ntilt:we2.ee>

<a​ntilt:we2.ee> thought about Yu Gao's "supernodes" (pool operators) and how they might be hardened against gray_list spam: preparing a --add-priority-node might come in handy for pool ops if we don't want to slow down gossiping. And DDoS protection for fcmp++ of course

<r​ucknium:monero.social> IIRC, sech1 helped set up a network "backbone" between pool nodes.

<r​ucknium:monero.social> For faster block propagation IIRC

<a​ntilt:we2.ee> i heard that

not exactly helped, I just found pool nodes (both public and non-public ones), and added them all to my nodes' priority lists

so my nodes connect all major pool nodes with max 1 hop between them (pool 1 node -> my node -> pool 2 node)

<a​ntilt:we2.ee> iirc that prevents a eclipse already

<r​ucknium:monero.social> We can end the meeting here. Thanks everyone.

<a​ntilt:we2.ee> (connections_maker uses priority-node before gray_list)

plus my nodes run RandomX in fast mode, that saves another 10 ms on block propagation

<r​ucknium:monero.social> Interesting research on a 2023 BTC DDoS that seemed to cause an increase in the rate of orphaned blocks: b10c.me/observations/15-inv-to-send-queue

<a​rticmine:monero.social> May 2023 coincided with the second highest spike at the time in the Bitcoin fee in reward.

<a​rticmine:monero.social> This makes the Bitcoin network very vulnerable to a DDoS attack consisting of transactions that do not for the most part get mined.

<a​rticmine:monero.social> It can be relevant to Monero with transactions that on their own in large numbers would not get mined if the fee is too low for the transaction weight.

<g​ingeropolous:monero.social> Rucknium: , what would be super cool at some point is if we can bootstrap a monerosim configuration that uses the current snapshot of the network. I imagine we could use your recent work to create a connectivity map that we could plug into monerosim. I imagine we'd need some kind of database that has nodes and edges. Monerosim would parse that to craft a simulated network.

<r​ucknium:monero.social> Maybe some data could be obtained from the work of Gao et al. moneroresearch.info/267 moneroresearch.info/278

<r​ucknium:monero.social> Yu Gao ^

<j​ack_ma_blabla:matrix.org> Can xmr support rbf ? allow usage of same inputs/decoys, just the output amount would change which is private anyways.

<l​m:matrix.baermail.fr> AFAIK that's just rejected by nodes ? But you can say good bye to zero conf with rbf

<d​iego:cypherstack.com> RBF is also much less useful due to dynamic blocksize

<a​rticmine:monero.social> rbf does not address this type of spam attack

<a​rticmine:monero.social> The whole point of the spam attack is that the transactions are not muned

<a​rticmine:monero.social> Mined

<o​frnxmr:monero.social> RBF would only make sense, imo, if it was only possible to bump the fee w/o changing any other details of the tx

<o​frnxmr:monero.social> Dynamic blocks can still cause tx's to be dropped from the txpool under big spam attacks. Particularly when the fees of the spam attack are "normal" (lvl 2). There is a PR open to further elevate fees to "elevated" (lvl 3), to try to avoid having any dropped txs or delays longer than 12hrs

<o​frnxmr:monero.social> This pr should only elevate fees to "elevated" if there is a 12hr backlog at lvl 2. A spammed txpool of low fee wont cause the fees to elevate beyond "normal".

<d​iego:cypherstack.com> ye, hence why I didn't say useless

<d​iego:cypherstack.com> under ideal scenarios where nobody is attacking, RBF is less useful, because the blocks will expand until activity goes back down, so you won't have to wait as long even with a full mempool than with something like Bitcoin

<j​effro256:monero.social> You *could* prove that all the outputs are addressed to the same addresses with the same amounts, except for the "change" output amount, which has the same private spend key as all the inputs inside of a ZK proof........

<j​effro256:monero.social> but don't do that