hello good day, i am dealing with some buffer overflow, set watermark of buffer max size thingy in jt-grassies pool.c . Since i know there is a strict block limit size at any given time, is there a rpc call to the monerod that gives me that size wrt the current tip?

get_info

The limit is 2x the recent "average".

curl -L 192.168.0.152:28081/getinfo

is that it ?

"block_size_limit": 600000,

Yes. Looks like it's already x2'd for you.

wow that was nice simple and easy :D

yes because the average would be given by : "block_size_median": 300000,

what about the block weight does that exceed the block size?

"block_weight_limit": 600000,

i mean could it exceed the block size? are thouse limits the same or is the weight strictly less or equal?

weight is basically size, with an extra bump in cases where a bulletproof would have extra bytes were it a linear proof. Weight is what is used as a block size limit.

I think "size" here is just backward compat.

great so i will use this as the MAXLINE : "block_weight_limit": 600000,

thx

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

hum

another thing, how do i find out what the minimum tx size is? i searched online and 1,4 kb seems the min ( because this buffer deals only with block_template wich deals only with tx ids i want to divide 600000/(min tx size), and then multiply that by 32. whats the answer?

if i take 1500 as the min size for a tx, then 600000÷1500 = 400. then 400 *32 = 12800 . Grr thats not right need to know how to define the MAXLINE based on the block_size_median ...

<r​ucknium:monero.social> s​lave_blocker: That is a good question for the #monero-dev room. This is the MRL room.

<0​xfffc:monero.social> Hi everyone

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

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

<a​rticmine:monero.social> Hello

hello

<g​ingeropolous:monero.social> hi

<v​tnerd:monero.social> Hi

<a​ntilt:we2.ee> hi

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

<a​ck-j:matrix.org> hi

<c​haser:monero.social> hello

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

<0​xfffc:monero.social> Working on addressing reviews / comments on new tx relay v2

<0​xfffc:monero.social> monero-project/monero #9933

<j​effro256:monero.social> Howdy

<a​ntilt:we2.ee> finished brief rundown (20 lines) of scoring methods found in ~50 papers for today

<r​ucknium:monero.social> me: Analysis of subnet deduplication for node peer selection as a countermeasure to spy nodes. I simulated a network with 90 percent unreachable (closed-port) nodes and found that honest reachable nodes would have 133 median inbound connections with the status quo algorithm and 182 median inbound connections with subnet deduplication. This would put more load on the honest reachable nodes.

<r​ucknium:monero.social> Docs here: rucknium.github.io/xmrpeers/reference/gen.network.html

<j​effro256:monero.social> me: still working on cold/hot wallet stuff. I had to re-work a big part of the carrot_impl lib to get a clean solution for some problems, but I think I should be wrapping it up soon within the next couple of days

<j​berman:monero.social> me: Finished FCMP++ scan_tx, an RPC endpoint to fetch paths by global output id, and worked on getting all tests to pass with the latest code

<v​tnerd:monero.social> Me: fixed all remaining send tx issues with lws-frontend except priority fees, which requires Daemon+LWS api changes. Otherwise fees are correctly computed now, and txes can be split if there is a high number of destinations just like wallet2

<r​ucknium:monero.social> 3) FCMP++ & divisors. github.com/cypherstack/divisor_deep_dive

<r​ucknium:monero.social> Is Liam Eagen here? xmrack invited him.

<r​ucknium:monero.social> Any Cypher Stack staff here? There is a new document from them:

<r​ucknium:monero.social> Goodell, B., Salazar, R., Slaughter, F., & Szramowski, L. (2025). A Further Review of the DL Gadget Of Interest. moneroresearch.info/268

<d​iego:cypherstack.com> hi

<a​ck-j:matrix.org> Rucknium: I’m not sure, they said they would be free but I havent seen them join

<r​ucknium:monero.social> I read the new doc ^ and have some questions and comments.

<d​iego:cypherstack.com> Question and comment away

<r​ucknium:monero.social> The divisors would use probabilistically checkable proofs (PCP). Does this open a new potential attack vector or does Monero already use this type of technique somewhere critical?

<r​ucknium:monero.social> And does it make it harder to compute the N bit security of Monero's cryptography?

<b​randon:cypherstack.com> hello everyone, sorry about my delay

<b​randon:cypherstack.com> PCPs are not problematic on their own, it's just a description of what sort of algorithm it is.

<b​randon:cypherstack.com> like a sigma protocol just describes a 3-round interaction, a PCP just means "this is a proof which is probabilitically checkable" (and therefore should be parameterized so that probabilities of security problems are negligible)

<r​ucknium:monero.social> On the Schwartz-Zippel Lemma discussion: Usually, mathematicians love to generalize things. The fact that the SZ Lemma has not been generalized to the multivariate case makes me think that it is very hard to generalize, or cannot be generalized, period. How solid is Bassa's alternative approach that substitutes for the SZ Lemma?

<r​ucknium:monero.social> 4.3.1 Developer watermarking

<r​ucknium:monero.social> > This means that a malicious developer can insert additional points, or remove certain points, from a

<r​ucknium:monero.social> statement. This won’t be detected if the proof remains valid, and the cryptographic size of G ensures that stashing a single random element in a divisor is essentially undetectable.

<r​ucknium:monero.social> Check this paper. Maybe this malicious watermarking is already possible in RingCT: Guo, S. 2024, Secure Monero on Corrupted Machines with Reverse Firewalls. Paper presented at International Conference on Data Security and Privacy Protection. moneroresearch.info/245

<r​ucknium:monero.social> Abstract:

<r​ucknium:monero.social> > Monero is known as a cryptocurrency for its ability to provide greater anonymity. At its core is the RingCT protocol that can hide the sender and the amount of money in a transaction. However, the Snowden revelation alerts us that the implementation of cryptographic algorithms in practice might be substituted covertly which would result in a complete breach of the security of th<clipped message

<r​ucknium:monero.social> e cryptosystem. In this work, we turn to evaluate the potential hazards of algorithm substitution attacks (ASAs) against the RingCT protocol and explore feasible countermeasures. In specific, we first present the ASA model for RingCT where the goals of adversary include diminishing sender anonymity and recovering the spending key, then propose concrete ASAs against RingCT protocol<clipped message

<r​ucknium:monero.social> s that are undetectable in terms of the output of algorithms. Finally, we show how to thwart ASAs on RingCT protocols with reverse firewalls.

<b​randon:cypherstack.com> Re: Schwartz-Zippel: Generalizing to the multivariate case isn't hard. Bassa's work was insufficient in showing that the problem appropriately fits into that context, and the details of how it does so inform quantified assessments of probability of success

<b​randon:cypherstack.com> malicious watermarking is admittedly hard to defend against. at least in this case, it would be checkable if code were doing that, but it could lead to fingerprinting and more. just like developer choices in terms of payment IDs in the past could be used to split monero's anonymity pool into puddles

<b​randon:cypherstack.com> also, i believe we have nailed down some calculus problems in the specific divisor algorithms which don't impact completeness but impact soundness

<r​ucknium:monero.social> Yes. I would be more concerned about accidental watermarks from custom implementations, but I don't know how likely custom implementations may be for this part of Monero's cryptography, deep in the system.

<b​randon:cypherstack.com> getting into greater detail about that is still a little premature; we are deriving all equations rigorously from scratch

<r​ucknium:monero.social> Theorems 2 & 3 in the document: Shouldn't these be labeled as conjectures instead of theorems?

<b​randon:cypherstack.com> Yeah, that'd be more appropriate

<b​randon:cypherstack.com> although we have a proof of theorem 2 now

<b​randon:cypherstack.com> and theorem 3 is not far behind either

<r​ucknium:monero.social> Great!

<b​randon:cypherstack.com> it would be shocking to me if these were not true conjectures

<f​reeman:cypherstack.com> I agree, intuition dictates it. But might as well be certain

<r​ucknium:monero.social> This is a self-directed comment to MRL, not really Cypher Stack: I finally looked at Eagen's divisor paper:

<r​ucknium:monero.social> Eagen, L. 2022. Zero Knowledge Proofs of Elliptic Curve Inner Products from Principal Divisors and Weil Reciprocity moneroresearch.info/index.php/269

<r​ucknium:monero.social> Eagen says that the argument for his divisors technique is similar to the argument for Bulletproofs++. However, over a year ago, Aaron Feikert (sarang) reviewed BP++ and said there were questions about its validity: moneroresearch.info/217

<r​ucknium:monero.social> So, MRL assumed that Eagen's divisors were OK despite the BP++ work falling short. And there was not much action taken on backup plans.

<j​effro256:monero.social> The moneroresearch.info/index.php/269 link is broken I think btw

<r​ucknium:monero.social> Does someone else have questions and comments about the latest divisor's analysis?

<r​ucknium:monero.social> Thanks, should be moneroresearch.info/269

<r​ucknium:monero.social> Papers and document relevant to FCMP are collected here by the way: moneroresearch.info/index.php?actio…CORE&method=subcategoryProcess&id=1

<j​berman:monero.social> Would need more time to review the paper, but the general takeaway from it is the same as has been discussed in past meetings: divisors require more academic rigor and work and may fall short under further scrutiny, and CS appears to be continuing that work

<j​berman:monero.social> "And there was not much action taken on backup plans." -> Luke was pretty clear on the backup from the start, which is that divisors could be swapped out in the impl. The vast majority of the meat of FCMP++ and code we've been working on is still useful in that backup scenario

<r​ucknium:monero.social> I don't know if I would have been a +1 vote on the FCMP optimization competition timeline if I had investigated and thought about it more. Of course, cryptography is not my field, so I would tend to defer to others on those questions, anyway. And programming isn't my field either :)

<r​ucknium:monero.social> Anyway, that is water under the bridge

<s​yntheticbird:monero.social> Regarding the competition, i'm not shy to say the ban of the r/rust post was dramatic for reaching out potential competitors

<j​berman:monero.social> I think in hindsight, maybe would have made sense to do a more general academic approach on divisors from the start with an open timeline, rather than the more piece-meal approach. Hindsight is 20/20

<r​ucknium:monero.social> From what I understand now, Cypher Stack's review of Bassa's work has turned into much more: needing to prove things and make scientific progress. MRL is very thankful for that.

<s​yntheticbird:monero.social> not xmrack fault (I think it was xmrack idr for sure), but it's been mostly our only card of reaching other communities

I think as long as CypherStack makes progress and does not declare defeat nothing is ultimately lost yet ...

<r​ucknium:monero.social> surae, Freeman Slaughter , Luke Szramowski , Diego Salazar : Do you need anything specific from MRL at this time?

<d​iego:cypherstack.com> Give us dominos pizza gift cards, please and thank you.

<r​ucknium:monero.social> To MRL: Is there specific action/decisions that MRL needs to take about divisors? Proposals?

<r​ucknium:monero.social> I assume that if there were news about non-divisor FCMP implementation, it would appear

You mean from third parties?

<j​berman:monero.social> Nothing from me. Sorry, will share as soon as I have news to share on non-divisor impl

Ah, no, our own alternative

<g​ingeropolous:monero.social> so does the non-divisor FCMP implementation need its own audits etc?

<j​effro256:monero.social> Yes

<j​effro256:monero.social> It would have a different cryptographic construction and needs to be audited separately

<s​yntheticbird:monero.social> Will some parts benefits from the prior audit? or is this audit "practically" done from scratch again?

<j​berman:monero.social> AFAIU we would need security proofs with the new construction and a new audit for that component, but most of the prior non-divisors research should be unaffected (like GBP research). Pinging kayabanerve to clarify

<r​ucknium:monero.social> More comments or questions on FCMP divisors?

<j​effro256:monero.social> SyntheticBird: A lot of non-membership-specific academic is reusable. If you look at moneroresearch.info/228, the SA/L proof doesn't have to be re-proved, the section 7 "composed proving system" doesn't have to be re-proved, and the general higher-level security properties of the system (section 8) don't have to be re-proved. We would basically just need to audit that the <clipped messag

<j​effro256:monero.social> new non-divisor FCMP membership construction can prove the relation in section 5

<r​ucknium:monero.social> 4) Unit test for implementation of subnet deduplication in peer selection algorithm. github.com/Rucknium/misc-research/b…onero-peer-subnet-deduplication.pdf

<r​ucknium:monero.social> Like I said in updates, I simulated a network with 90 percent unreachable (closed-port) nodes and found that honest reachable nodes would have 133 median inbound connections with the status quo algorithm and 182 median inbound connections with subnet deduplication. This would put more load on the honest nodes.

<r​ucknium:monero.social> During last year's suspected black marble tx flooding, nodes with many connections had trouble keeping up with the blockchain.

<g​ingeropolous:monero.social> what was total size of network?

<r​ucknium:monero.social> I don't know if the projected increased load is something to really worry about. Anyway, the simulation assumes that all nodes update, which usually doesn't happen

Well, you can always limit the number of incoming connections with a parameter

<r​ucknium:monero.social> With the 90 percent unreachable assumption, there would be 44,000 total honest nodes. That seems high, but some people who run reachable nodes report about 150 inbound connections, which would be roughly consistent with the 90% unreachable assumption, if everyone followed the status quo default peer selection algorithm and 12 outbound connections default.

<r​ucknium:monero.social> 0xfffc's work on the more efficient tx transmission protocol would help here

<r​ucknium:monero.social> If nodes start limiting inbound connections, then other honest nodes would have to pick up the slack.

<r​ucknium:monero.social> Now, the network is using spy nodes as a crutch.

Hopefully mostly people with weak systems, or limited bandwidth, would limit

<r​ucknium:monero.social> Since those spy nodes are absorbing a lot of those connections that "should" be going to honest nodes.

<0​xfffc:monero.social> Quick update, for anyone not in the loop: I am addressing the reviews and concerns about the code. No deal breaker. Hopefully the new implementation will be push in a day or two.

<a​rticmine:monero.social> What is the current level of inefficiency? Name Ly how many times is the same transaction data, transmitted during transaction propagation and finally during propagation of the mined black ?

I think we will have to just try and see. Not bringing a better algorithm into service and continuing to connect to a lot of spy nodes can't be the solution :)

<r​ucknium:monero.social> By the way, boog900 and my MoneroKon 2025 presentation on defeating spy nodes, which will include subnet deduplication analysis, is now scheduled for June 22. Abstract here: cfp.twed.org/mk5/talk/AE7CWF

<a​rticmine:monero.social> Getting a handle on this will go a long way to help overburdened nodes

<0​xfffc:monero.social> Congrats, looking forward to seeing it.

<b​oog900:monero.social> Over 90% of tx broadcasts are redundant

<r​ucknium:monero.social> A full txpool makes it worse, because the node will re-broadcast unconfirmed transactions half a dozen times, at intervals.

<r​ucknium:monero.social> Which is probably one reason why the spam last year was so tough on nodes.

<r​ucknium:monero.social> rbrunner had an update on his investigations of the peer connection code, I think.

Yeah, found a sweet bug that made most connection retries basically a waste of time internally. Without that bug finding new peers works faster and with a better success rate

<r​ucknium:monero.social> Thank you, rbrunner :)

We probably live with that bug for about 6 years :)

<a​rticmine:monero.social> So an inefficiency of 10x to 20x

<r​ucknium:monero.social> I suspected that the connection attempts were failing too quickly from what I saw in the logs, but I could not read the C++ code

Yes, finding it was a nice teamwork. I can give back thanks, Rucknium!

<r​ucknium:monero.social> We can move on to the next agenda item unless there are more comments/questions on this one.

<a​ntilt:we2.ee> #9933 fits in nicely here.

<r​ucknium:monero.social> 5) Web-of-Trust for node peer selection.

<r​ucknium:monero.social> flip flop: What did you find?

<a​ntilt:we2.ee> Brief rundown of peer scoring found in ~50 papers. References on request.

<a​ntilt:we2.ee> 1) Data collection:

<a​ntilt:we2.ee> 1a) Subjective scoring: node keeps track of /quality of service/ of its peers and never reveals its scores to others (bitcoin ban score, peerinfo_manager) Decay factors used to smooth. "Good scores" preferred to "Ban Score" metrics to avoid eclipse, DoS and defamation attack vectors. Reliable. Relatively low requiremets.

<a​ntilt:we2.ee> 1b) Recommedation based (pgp, GossipTrust, EigenTrust): in addition to a), nodes poll their peers requesting their subjective scores. Authors point out that a well defined "good" init state should exist: then malicious collectives may be broken up by cross-checking. Otherwise lying nodes may break the system with 21%-40% malicious addresses. Some authors suggest data structures <clipped message>

<a​ntilt:we2.ee> or a parallel p2p network to store extensive reputation data.

<a​ntilt:we2.ee> 1c) Data driven: in addition to b) compagnion apps are used to collect big data, querying regular nodes and building a graph represented by nodes, edges and flow metrics (bandwidth, timing). Machine learning is used to detect outliers. Authors tend to promote their own models avoiding self-criticism. Potentially very powerful (yet expensive). May not scale to many nodes.

<a​ntilt:we2.ee> 2) Actions:

<a​ntilt:we2.ee> 2a) The derived metrics may or may not inform /peer selection/: Some authors use scores to prioritize peers, gossip and ban others.

<a​ntilt:we2.ee>

<a​ntilt:we2.ee> 2b) At least three Authors design a PBFT based consusus algorithm centered around reputation scores (1b). Roles may be defined by reputation score, such as supernode, verifier, leader, witness, etc. One paper suggests a dual PoW and reputation-based PBFT consensus with variable weight.

<a​ntilt:we2.ee>

<r​ucknium:monero.social> (1c) seems not feasible given that Monero p2p graph edges are deliberately hidden.

<a​rticmine:monero.social> How do we identify nodes? Just based up IP address?

Can we say that part of PR #9933 is a case of 1a)?

<0​xfffc:monero.social> Yes.

<a​ntilt:we2.ee> absolutely!

<0​xfffc:monero.social> It has a separate peer info management mechanism. Which I track every interaction. Missed, announced, received, send, etc. we can use that data to calculate a score. So far I am only using 70% rule. If they announce 100, but delivery fall less than 70, we drop them.

<0​xfffc:monero.social> But the data is there, ready for other calculations.

<a​ntilt:we2.ee> two weeks ago, researchers mapped the net... i take this as viable

<r​ucknium:monero.social> IMHO, systems that have been battle-tested in adversarial environments should be considered more seriously than those that have not. I am afraid of systems that would seem to work well in theory, but have hidden flaws that could blow the system apart.

<0​xfffc:monero.social> There was concern from vtnerd to not add it, and integrate it to our existing limited scoring mechanism. Right now I am looking into this.

<a​ntilt:we2.ee> i was amazed to find this! no need to lobby any further... :)

<r​ucknium:monero.social> 0xfffc: Could you explain details of Monero's current limited scoring mechanism?

<a​rticmine:monero.social> One issue I see is that some ISPs change dynamic IPs on residential connections with a frequency of under 4 hours.

<r​ucknium:monero.social> Originally I thought it was a binary system: One bannable offense gets you banned.

<0​xfffc:monero.social> That is the part I have started today. So my report will not be accurate. But I will write a doc and report send it to this group once I have (more) clear understanding. One of the big problems with our existing scoring is it is tightly integrated into low level networking code.

<0​xfffc:monero.social> I wanted completely abstracted away. Taking that logic out of our low level networking code is the hassle.

<a​ntilt:we2.ee> >Failure Detection: Penalizes peers for: Unresponsive behavior

<a​ntilt:we2.ee> The intuition is to ban spy nodes, but

<a​ntilt:we2.ee> Wenjun Fan et. al [1] and [2] warn that a "good-score" is more effective -- given entries in white_list would be prioritized.

<a​ntilt:we2.ee> So called "defamation attacks"... not shure if relevant, adversary might try to eclipse "superodes": dos'ing its peers, then inject fake entries in superode's gray_list.

<a​ntilt:we2.ee> [1] The Security Investigation of Ban Score and

<a​ntilt:we2.ee> Misbehavior Tracking in Bitcoin Network

<a​ntilt:we2.ee> par.nsf.gov/servlets/purl/10407054

<a​ntilt:we2.ee> [2] Positive Reputation Score for Bitcoin P2P Network

<a​ntilt:we2.ee> "focusing on the peer’s behavior in relaying unique/new blocks and transactions."

<a​ntilt:we2.ee> drive.google.com/file/d/17S4N3eJvUePvO92ob_cIseeusQSMG0ly/view

<0​xfffc:monero.social> We have score field. But we don’t use much IIRC.

<0​xfffc:monero.social> And the bigger issue imho is its integration to our low level networking. Which means you should not and cannot touch it unless you are pretty familiar with our low level networking stack ( asio, etc )

<0​xfffc:monero.social> (9933 it does have other parts than peer info management mechanism )

Would splitting this into two more single-thematic PRs be something? Might also speed up getting the better tx distribution through review and testing

Just brainstorming

<0​xfffc:monero.social> Possible, might be even a good idea. But there is mutual dependency. You need 70% rule for tx relay v2.

<a​ntilt:we2.ee> @rucknium:monero.social you had a concern with Tx Relay v2 and D++ ?

<0​xfffc:monero.social> I will talk to [boog900](matrix.to/#/@boog900:monero.social)about this though.

<b​oog900:monero.social> I suggested splitting the new code for accepting these messages from the code that initiates them. But the code that initiates is like 5% of it.

<r​ucknium:monero.social> flip flop: I think the benefits outweigh the potential risks. I wrote a GitHub comment about it.

Initiates what?

<a​ntilt:we2.ee> thats what i thought, too

<b​oog900:monero.social> rbrunner: tx broadcasts.

<b​oog900:monero.social> pretty much the code in levin_notify

<0​xfffc:monero.social> Separate peer info management mechanism, with accurate data for every interaction with the nodes, is something we can use a lot. Does that look like something useful to you [Rucknium](matrix.to/#/@rucknium:monero.social)

<0​xfffc:monero.social> Let’s call it Scoring mechanism. Not peer management ( at this point )

<r​ucknium:monero.social> It was mostly about discovery of the p2p network's edges (connections between each node). And apparently the Zurich researchers were about to get a weekly estimate of that from just the white_list peer selection behavior (which could be changed, but the estimate is not very useful to an adversary, as it stands.)

<0​xfffc:monero.social> Every missed, every send, every received, speed. Etc.

<r​ucknium:monero.social> Here was my comment: monero-project/monero #9334#issuecomment-2307824031

<a​ntilt:we2.ee> it possible to track block delivery, right?

<0​xfffc:monero.social> In hypothetical scoring mechanism, absolutely. I don’t see why not.

<0​xfffc:monero.social> We don’t want to keep the actual data ( that is huge ). We want to keep track of metadata.

<r​ucknium:monero.social> 0xfffc: IMHO, it could probably help if spy nodes are trying to save bandwidth by not relaying as many txs and blocks.

<b​oog900:monero.social> spy nodes could just not send any invs to save bandwidth, currently we only keep track of this info to stop nodes from advertising txs and then not responding with them when asked.

<a​ntilt:we2.ee> the 30 point window could be reduced by a 1-pole recursive filter.

<0​xfffc:monero.social> This is one area I think we don’t use much. I have to talk to boog and other devs more. But data is gold. Once we had the data, we can detect behaviour or the peers.

<0​xfffc:monero.social> And keeping that data is very simple. It is strange we don’t have more robust mechanism for that.

<b​oog900:monero.social> I somewhat disagree if I am honest, I think for now it can complicate the system. Once the structure is agreed on how this data is stored we can track more as needed.

<a​ntilt:we2.ee> Again, i think of good behavior a spy node might avoid. And scoring that.

<0​xfffc:monero.social> Yes. The mechanism to keeping that data in code base is gonna be controversial.

<0​xfffc:monero.social> Anyway, I am here in case anyone had any questions. Don’t want to monopolize the meeting time.

<b​oog900:monero.social> also vtnerd just suggested to put the current per-peer data that is kept in `peer_info_manager` inside the `connection_context` which i think is reasonable.

<0​xfffc:monero.social> Yes. We have to add all those data to `connection_context`.

<b​oog900:monero.social> we already have other monero protocol stuff in there, not just underlying p2p protocol stuff.

<g​ingeropolous:monero.social> i mean, a malicious entity could just act good to get in the good graces of the network, and then launch an attack of some kind, right?

<a​ntilt:we2.ee> personally i'd prototype stuff like scoring in a compagion app. we only need to reveal the data - taking action is a lot more complex and must be simulated

<a​ck-j:matrix.org> Rucknium: Liam messaged me back, there was a miscommunication with times and our MRL meeting conflicted with his Bitcoin conference talk. I’ll try to see if he can join sometime in the next few weeks. Sorry about that

<r​ucknium:monero.social> xmrack: Sounds good. Thanks. Try to clarify the goals of his appearance so we know if Cypher Stack staff should be specifically invited.

<g​ingeropolous:monero.social> i guess i'm just hoping to clarify what it is we're defending against. Spy nodes? lazy nodes? ddos?

<r​ucknium:monero.social> gingeropolous: They can do that now without acting like honest nodes. Though, I would be concerned about an adversary manipulating the scoring system to lower the score of honest nodes. For example, showing even _higher_ bandwidth use than an honest node would.

<b​oog900:monero.social> for 9933, a sort of DoS. Nodes could advertise a tx and never send it leaving our node waiting for it until we re-request it after 30 seconds.

<g​ingeropolous:monero.social> yeah. i mean, with 9933, it seems there's a need for some scoring system, because if you need to request txs from a peer, then you should drop peers that don't respond.

<b​oog900:monero.social> although now thinking about it, it should be windowed, i.e. should only take into account the last 100 txs.

<g​ingeropolous:monero.social> and i feel like there's gotta be some middle ground between our current "blast all trasnactions everywhere all the time" and "lets just take a little sip of some data here, and some there"

<g​ingeropolous:monero.social> efficiency and resilience are uh.... not the best bedfellows.

<r​ucknium:monero.social> We can end the meeting now. Feel free to continue discussing items. Thanks everyone.

<s​yntheticbird:monero.social> thanks

<s​yntheticbird:monero.social> delicious meeting as always

<a​ntilt:we2.ee> thanks

<0​xfffc:monero.social> Thanks everyone

<g​ingeropolous:monero.social> thanks all!

<b​oog900:monero.social> this probably is the middle ground, we could go even further with protocols like erlay

<a​ntilt:we2.ee> if a spy node /demonstrates/ a lot of bandwidth and bandwidth is the only metric... that would be a problem of course.

<s​yntheticbird:monero.social> Some will quickly start to realize that I love heuristics, but wouldn't it possible to estimate a median of response time from a specific node and estimate that after say a factor of this median we discard this request and ask for tx from another node

<s​yntheticbird:monero.social> "respond in your usual time, or i'll forget you"

<s​yntheticbird:monero.social> a little like Tcp round-trip time

<b​oog900:monero.social> what if a node never responds

<s​yntheticbird:monero.social> well then disconnect

<s​yntheticbird:monero.social> why would you stay connected to a node that don't respond

<b​oog900:monero.social> but they might have just innocently dropped the tx from their pool

<a​ck-j:matrix.org> Have we used tools like shodan or censys to fingerprint nodes before? Rather than looking at peer connections.

<a​ck-j:matrix.org> shodan.io/search?query=%22Monero%22+port%3A18081

<s​yntheticbird:monero.social> sorry, i've assumed that nodes would send a response saying that they do not know the tx being requested

<a​ntilt:we2.ee> it does not get promoted... if innocent, they are not punished by disconnecting at least

<s​yntheticbird:monero.social> if it do not send such then it effectively can't work

<a​ntilt:we2.ee> but have a lower rank in white_list

<s​yntheticbird:monero.social> No because no one here have shodan keys

<s​yntheticbird:monero.social> but that promise to be interesting

<b​oog900:monero.social> what if they say they don't know the tx after 25 seconds, meaning we waited on them to tell us they don't have it, during which we can;t request from other peers.

<b​oog900:monero.social> They are still within the 30 second limit and will be responding after a constant time meaning it wont be below the median

<a​ck-j:matrix.org> I have a bunch of keys if anyone wants

<s​yntheticbird:monero.social> 30 second would be an upper bound without a doubt. what im saying is that we should measure the round trip time to this particular node and ask for other nodes after say 10x this delay. But if nodes mostly respond in dozens of milliseconds, we could forget them before 2 seconds pass

<s​yntheticbird:monero.social> So if nodes*

<s​yntheticbird:monero.social> and ask other peers

<s​yntheticbird:monero.social> oh sorry last sentence

<s​yntheticbird:monero.social> mhm yeah that's not wrong

<s​yntheticbird:monero.social> I guess it needs to be coherent with the other peer request

<b​oog900:monero.social> I think you are still thinking in terms of honest nodes, we are trying to protect against people being malicious.

<s​yntheticbird:monero.social> that's indeed what im trying to do

<s​yntheticbird:monero.social> If the node take 25 sec to send a requested tx, but respond to your timesynced in under 100 milliseconds i mean come on

<s​yntheticbird:monero.social> it is malicious

<b​oog900:monero.social> now my timed sync takes 25 seconds :)

<s​yntheticbird:monero.social> requested tx = batch of requested txs

<a​ntilt:we2.ee> how does this work?

<s​yntheticbird:monero.social> you would never sustain a connection with a node that slow

<s​yntheticbird:monero.social> in a real world scenario

<b​oog900:monero.social> sounds like a challenge :)

<s​yntheticbird:monero.social> the most intense delay you would ever experience with honest nodes would be at the extreme most 5 sec

<s​yntheticbird:monero.social> more than that bro is streaming morse code through low frequency radio

<s​yntheticbird:monero.social> At 2 sec you would have at least 50% packet drop

<b​oog900:monero.social> it wouldn't be like that, I would just sleep before sending the whole message after 25 seconds

<s​yntheticbird:monero.social> mhm

<b​oog900:monero.social> tracking amount of missed tx requests is much easier :)

<s​yntheticbird:monero.social> in the current state of things monerod would just blindly accept it. My stance is that this type of node should be disconnected from

<s​yntheticbird:monero.social> 25 seconds is ridiculously high

<s​yntheticbird:monero.social> yes that can do it too without a doubt

<s​yntheticbird:monero.social> but the DoS could be operated during a short period of time

<s​yntheticbird:monero.social> at least reduce the upper bound of response latency to limit the damage in that small period

<s​yntheticbird:monero.social> no honest nodes would take more than 10sec to responid

<s​yntheticbird:monero.social> even a potato computer

<b​oog900:monero.social> we can do that

<b​oog900:monero.social> maybe we should give them a very short ban too

<b​oog900:monero.social> like 10 mins

<s​yntheticbird:monero.social> sounds good

<s​yntheticbird:monero.social> we wouldn't penalize accidental ISP blackout of honest nodes

<s​yntheticbird:monero.social> "Your Internet is down? DIE SPY NODE DIE!!!!"

<s​yntheticbird:monero.social> more like ISP occasional latency. If the internet was down, the connection would be reset i suppose.

<s​yntheticbird:monero.social> I'll call it Internet Weather™️

<a​ck-j:matrix.org> Censys has a monero_p2p filter already which returns 8,987 nodes.

<a​ck-j:matrix.org> search.censys.io/search?q=services.…e%3D%22MONERO_P2P%22&resource=hosts

<a​ck-j:matrix.org> We can query for monero p2p nodes within the LinkingLion ASN which returns 1,596 unique IPs.

<a​ck-j:matrix.org> search.censys.io/search?resource=ho…stem.name%3D%60LIONLINK-NETWORKS%60

<1​7lifers:matrix.org> censys mentioned!

<1​7lifers:matrix.org> we the security community <3 you

<1​7lifers:matrix.org> we the cybersecurity community \<3 you