Monero Research Lab Meeting - Wed 06 November 2024, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Join the Monero Matrix server if you don't already have a Matrix account.

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. FCMP++ tx size and compute cost and MAX_INPUTS/MAX_OUTPUTS

4. FCMP++ Optimization Competition.

5. Reviews for Carrot.

6. Discussion: preventing P2P proxy nodes.

7. Proposal for FCMP++ HF Activation Rule to Retroactively Ignore Future unlock_time

8. Any other business

9. Confirm next meeting agenda

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#1102

[Rucknium]

Logs:

< r​ucknium:monero.social > Meeting time! #1105

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

< rbrunner > Hello

< c​haser:monero.social > hello

< j​berman:monero.social > waves

< 0​xfffc:monero.social > hi everyone

< b​oog900:monero.social > Hi

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

< r​ucknium:monero.social > me: Analyzed p2p connection logs to provide more supporting evidence for the proxy node banlist and estimated the empirical risk to user privacy: monero-project/research-lab#126 (comment)

< 0​xfffc:monero.social > Like last week I was sick with covid19/flu, so haven't been that productive either. Only trivial reviews. Today I got back to work. First will review #9441, then fix issue raised at #9362

< r​ucknium:monero.social > 3) FCMP++ tx size and compute cost and MAX_INPUTS/MAX_OUTPUTS https://gist.github.com/kayabaNerve/c42aeae1ae9434f2678943c3b8da7898 monero-project/research-lab#100 (comment)

< r​ucknium:monero.social > kayabanerve kayabanerve : Anything to discuss today about this?

< j​berman:monero.social > me: Continuing local wallet tree building

< r​ucknium:monero.social > I haven't gone deeper into the MAX_INPUTS/MAX_OUTPUTS analysis yet because my main "database" process is occupied.

< r​ucknium:monero.social > 4) FCMP++ Optimization Competition. https://github.com/kayabaNerve/fcmp-plus-plus-optimization-competition

< r​ucknium:monero.social > Anything to discuss on this?

< k​ayabanerve:matrix.org > Apologies. I have nothing to add

< j​effro256:monero.social > Howdy, sorry I'm late. Daylight savings got me

< k​ayabanerve:matrix.org > On either topic, I haven't personally worked on Monero this past week.

< r​ucknium:monero.social > 5) Reviews for Carrot. https://github.com/jeffro256/carrot/blob/master/carrot.md

< r​ucknium:monero.social > jeffro256: , anything on Carrot today?

< j​effro256:monero.social > AFAIK, Cypherstack is still working on the review. No updates from them yet

< r​ucknium:monero.social > That reminds me that I wanted to note a personnel change that's relevant to MRL: About a month ago, Aaron Feickert (Sarang Noether) left Cypher Stack. At about the same time, Brandon Goodell (Surae Noether) joined Cypher Stack.

< r​ucknium:monero.social > 6) Discussion: preventing P2P proxy nodes. monero-project/research-lab#126

< k​ayabanerve:matrix.org > Rucknium: Do you want to add a research topic to these meetings re: making fee a pure fn of inputs/outputs/TX extra len? Or is that not an active discussion topic, solely a item of work for you?

< r​ucknium:monero.social > Yes I could do that

< k​ayabanerve:matrix.org > Sorry for interrupting you mid-topic, it's just kinda FCMP++ related and one thing I wanted to quickly check in on.

< r​ucknium:monero.social > Do you want to discuss now or next meeting?

< k​ayabanerve:matrix.org > If we have time today, we can open the discussion today. It should be brief. I'll leave you to decide when we get to it as the current agenda item is P2P proxy nodes :p

< r​ucknium:monero.social > Ok. We can put it in the "Any other business" item if there is time at the end of the meeting

< r​ucknium:monero.social > boog900: Do you want to open the discussion on p2p proxy nodes?

< b​oog900:monero.social > Sure, a few weeks ago I found some nodes displaying behavior which can only be explained by them being proxy nodes. These nodes make up a large portion of the network, 40% of the IPs I found and 75% of the IP:Ports.

< b​oog900:monero.social > The only reason I can think to run proxy nodes is to try and link IPs to transactions.

< r​ucknium:monero.social > A "proxy node" is an IP address that pretends to run its own node, but actually it just relays messages between a "victim" node and another node (possibly honest node or controlled by the adversary)

< b​oog900:monero.social > They use 6 main IP ranges, all under the LionLink-Networks ASN

< j​effro256:monero.social > 40% is nuts. I want to link this Bitcoin issue here: bitcoin/bitcoin#16599. Seems like some people might have already done some research in this area. ASN bucketing would almost certainly help here

< r​ucknium:monero.social > A lot of the threat models for network integrity and privacy assume that it is expensive for an adversary to run many nodes. Basically a proxy node reduces this expense by appearing to run a real node, but not actually running it

< r​ucknium:monero.social > In my p2p log data, from April-May 2024, about 15% of outbound connections of the honest nodes are to IP addresses in the ban list, so the privacy risk isn't as high as 40%, probably.

< k​ayabanerve:matrix.org > We could add a PoW puzzle to any network requests which can be MITMd but not without replicating the work. I don't like the idea of PoW for any P2P req but also, it makes proxy nodes expensive again.

< k​ayabanerve:matrix.org > The question is is that an asymmetric cost or does it just make every node more expensive while massively degrading the P2P network.

< r​ucknium:monero.social > Connections to the banlist IP addresses have a shorter duration. And the node software prefers to connect to IP addreses ranges that are not in the same subnet

< b​oog900:monero.social > If they operated the node being proxied they could probably get around this right?

< 0​xfffc:monero.social > This is very interesting approach. Particularly there is every kind of PoW defense available. But for adversary with $, this is not going to solve the problem.

< r​ucknium:monero.social > I don't know what the long-term solution is, but in the short term, monerod could be hard-coded with the LinkingLion IP addresses and instruct monerod not to establish outbound connections to them. Inbound connections could be allowed, so no "innocent" nodes would be excluded from the network. Outbound connections are the privacy-sensitive ones for Dandelion++

< k​ayabanerve:matrix.org > It'd also need PoW on responses :/

< r​ucknium:monero.social > LinkingLion has been publicly discussed for years, yet they have not changed their IP addresses. Maybe something prevents them from doing so. Maybe an IP address hardcode would stop them for a while.

< k​ayabanerve:matrix.org > They'd serve 10x the responses if they have 10 nodes, even if they only make 1x the requests for their one node

< c​haser:monero.social > you can't prevent it from happening, but raising the fence is a good idea IMHO.

< k​ayabanerve:matrix.org > We could discuss introduction of a mixnet as an alternative to D++

< r​ucknium:monero.social > I don't know if a mixnet would prevent eclipse or network partitioning attacks.

< k​ayabanerve:matrix.org > I think that'd be excessively long-term and I'm not immediately sure it actually solves the problems we have

< j​effro256:monero.social > Yes but that would mean either 1) the proxy is doing the PoW which makes it expensive, or 2) the central node is doing all the PoW which will bottleneck the operation after a certain period of time

< r​ucknium:monero.social > Wasn't Kovri the "mixnet" attempt in the past?

< b​oog900:monero.social > I would support banning every IP under LionLink-Networks, even the ones not currently running proxies.

< 0​xfffc:monero.social > I agree. As short term solution, right? eventually we want to have a better defense for this.

< rbrunner > Kovri was just a I2P implementation, as far as I remember.

< r​ucknium:monero.social > u/oh-chase on Reddit posted this: https://xmr.nodes.pub/ It cross-references node IP addresses with ASNs. "LIONLINK-NETWORKS" is 55% now.

< b​oog900:monero.social > If the PoW was also for responses yes but if the PoW is only for requests then by using their own main node they can just ignore the PoW requirement for their proxies.

< k​ayabanerve:matrix.org > Rucknium: Every however often, we can have a node declare a mix. In this mix, every participating node submits an encrypted TX or an encryption of nothing. The publishing node of a TX becomes any one of the honest nodes in the network per cryptography (regardless of network analysis).

< r​ucknium:monero.social > Isn't that just broadcast a tx by proxy, which was already analyzed by the D++ designers?

< k​ayabanerve:matrix.org > That would also mean any one node can DoS the mix. We'd need a local reputation system for selecting mixes and a way to decline participation (if spammed with participation requests).

< k​ayabanerve:matrix.org > Possibly? "any one of the honest nodes" sounds stronger than simply using a proxy.

< k​ayabanerve:matrix.org > Eh. Presumably, the mix would only be conducted within the locally connected to region of the network. That means you can identify a TX as belonging to a subgraph of the P2P network. With D++, the fact it travels multiple hops prevents that.

< j​effro256:monero.social > I see what you're saying, since creating a stem would be a request made by the honest node to the spy node in this case

< r​ucknium:monero.social > > A natural strategy for breaking symmetry about the source is to ask someone else to spread the message. That is, for every transaction, the source node chooses a peer uniformly at random from the pool of all nodes. It transmits the message to that node, who then broadcasts the message. More generally, the network could forward each message a few hops (each hop choosing a new no<clipped message

< r​ucknium:monero.social > de at random) before diffusing it. We call this approach diffusion-by-proxy, and it is conceptually equivalent to propagating over a line that changes for every transmission. Diffusion-by-proxy might seem like it should have low precision because the graph is so dynamic, but that intuition turns out to be false.

< r​ucknium:monero.social > ^ D++ paper

< r​ucknium:monero.social > A long term solution will require time to research and develop. Can we discuss boog900's proposal to hardcode the banlist in monerod?

< k​ayabanerve:matrix.org > I'll leave my commentary as the idea and decline to claim to be knowledgeable enough to continue the discussion.

< j​effro256:monero.social > But even if adding PoW to D++ stem creation, it really doesn't happen that often, so it wouldn't be that much of a deterrent without crippling tx propagation for all nodes

< r​ucknium:monero.social > ^ since that is a short-term solution that can be acted on quickly

< j​berman:monero.social > I can't recall, is there precedent for including a hardcoded ban list?

< r​ucknium:monero.social > I don't see any downsides to preventing nodes from establishing outbound connections to the proposed banlist nodes.

< rbrunner > I think so far we carefully avoided any such things

< r​ucknium:monero.social > I don't think there is precedent

< 0​xfffc:monero.social > this time seems a little bit different. scale is huge IMHO. Please feel free to correct me.

< 0​xfffc:monero.social > I have another question. If we implement such approach. https://xmr.nodes.pub/ are we losing 55% of nodes basically?

< r​ucknium:monero.social > Those nodes aren't real

< s​yntheticbird:monero.social > they are proxies so no

< j​effro256:monero.social > Why hardcode it in over propogating a banlist file with a concise explanation?

< rbrunner > If we really take that drastic measure, maybe also create a new command-line switch to disable that hardcoded banlist? To uphold people's freedom to decide.

< 0​xfffc:monero.social > Ah, yes. thanks for clarification.

< j​berman:monero.social > The main downside is risk of centralized censorship decisionmaking. Other downside is "what if they're honest for reasons we aren't seeing". Although generally I think it's reasonable / "within ethos" to seek to seek to ban centralized chokepoints

< r​ucknium:monero.social > A non-hardcoded banlist file can possibly be used for corrupt purposes without a node running updating their software. Probably

< rbrunner > And the reach and effect of such a separate file would certainly be smaller

< j​effro256:monero.social > Huh? Banlist files already exist though

< r​ucknium:monero.social > I think it's fine to have a switch that allows users to disable the banlist. But have it on by default IMHO

< rbrunner > Yes, that's what I meant: on by default

< r​ucknium:monero.social > jeffro256: I know. But they aren't on by default

< b​oog900:monero.social > To be clear I want to hardcode a banlist for LionLink-Networks, not all IPs in the ban list.

< rbrunner > Rucknium: Not sure what you mean with "corrupt uses" for banlists?

< rbrunner > *corrupt purposes

< j​effro256:monero.social > I agree with this. It sets the wrong precedent to have the devs hard code in banned IPs

< r​ucknium:monero.social > There is a banlist that you can enable that checks a DNS record for which nodes to ban. If something like that is enabled by default, the DNS record could be hacked and har, the network

< r​ucknium:monero.social > The IPs wouldn't really be banned from the network. They could still establish their own outbound connections.

< 0​xfffc:monero.social > anyway to find out how many actual node are running? ( I want to understand what percentage of these 55% are proxies )

< r​ucknium:monero.social > IPV6 is already disabled by default because there is a sybil attack risk with IPv6. At least, that is the reason I have read.

< rbrunner > Somehow hardcoding IP4 numbers look like a grave defeat IMHO. And totally out of place.

< b​oog900:monero.social > I haven't found a node in the 6 subnets that passed the not proxy test.

< r​ucknium:monero.social > I get about 12,000 unique IP addresses in my log dataset from April-May that are not on boog900 's banlist.

< 0​xfffc:monero.social > my other question, how computationally intensive is to run proxy node? to rephrase, I assume running a proxy node is cheaper than running actual node?

< r​ucknium:monero.social > It really depends how you count. A lot of nodes that do not have open ports, so an active, short network scan wouldn't find them. And then nodes are turned off and on sometimes.

< j​effro256:monero.social > Note that nodes without open ports are not going to be part of a D++ stem anyways

< r​ucknium:monero.social > This spy node issue has been neglected for years. I assume because of dev resource constraints.

< rbrunner > Won't "they" just rent a botnet and then have proxy nodes all over the planet?

< 0​xfffc:monero.social > ( correct. so for simplicity let's not consider them in our discussion )

< rbrunner > With quickly shifting IP numbers as well :)

< 0​xfffc:monero.social > That is what I am trying to get at.

< 0​xfffc:monero.social > I think we have to impose computational cost (PoW) to proxy nodes.

< r​ucknium:monero.social > I get 4,600 non-banlist nodes with open ports in my dataset

< 0​xfffc:monero.social > because, if this assumption is correct, they can switch very easily (?)

< r​ucknium:monero.social > For some reason the adversary is still using Lion Link even though there has been public discussion of this for years. That may suggest that it is not easy for them to switch IP ranges.

< rbrunner > Hmmm, that approach so far had zero downside in the particular case of our network, no? Why switch then

< rbrunner > And it took years to becoming aware ...

< r​ucknium:monero.social > They are spying on the bitcoin network, too. I don't recall if bitcoin did anything about them. boog900 , do you know?

< rbrunner > Maybe the game will change now however

< r​ucknium:monero.social > Bitcoin has a much better ASM diversity logic

< 0​xfffc:monero.social > But privacy is not important aspect of Bitcoin.

< rbrunner > Yeah, what would you even spy there :)

< r​ucknium:monero.social > This is also a eclipse and network partition risk

< r​ucknium:monero.social > Bitcoin cares about that

< 0​xfffc:monero.social > Yes, that too. Makes sense.

< 0​xfffc:monero.social > So what did Bitcoin do? Leave them alone?

< b​oog900:monero.social > Some of their IPs have been on selsta's ban list for a while, you would think they would switch to get as many nodes as possible.

< r​ucknium:monero.social > Thinking back... isn't there precedent for this when there was a network attack in December 2020? Not hardcoded, but the DNS record banlist, etc

< r​ucknium:monero.social > But that was abigger threat to network stability than this

< b​oog900:monero.social > I don't but IIRC their main concern was a DOS vector due to these nodes just passively listening and not participating in normal tx flow: 0xB10C/banlist#1 (comment)

< r​ucknium:monero.social > This is a post about the 2020 attack: https://sethforprivacy.com/posts/moneros-ongoing-network-attack/

< r​ucknium:monero.social > > 2020-11-02 - PR6961 implemented to allow passing a banlist to monerod

< rbrunner > Yes, introduction of banlists I would say. Totally optional and fully under user control, I would say. Nothing like a hardcoded opt-out banlist

< v​tnerd:monero.social > Sorry I'm late as well, daylights savings tripped me up too. Not much report really, same as last week

< r​ucknium:monero.social > I forgot to say thank you to boog900 for uncovering this proxy node issue :D

< rbrunner > Now we all have one worry more :)

< 0​xfffc:monero.social > Sorry for this digression, any of you is familiar with DNS TXT messages and how they work? I will DM you to ask few general questions.

< r​ucknium:monero.social > We are past the hour. One more hopefully quick one:

< r​ucknium:monero.social > 7) Proposal for FCMP++ HF Activation Rule to Retroactively Ignore Future unlock_time . monero-project/research-lab#125

< r​ucknium:monero.social > jeffro256 suggested that this be discussed for hopefully the last time at this meeting

< rbrunner > For asking whether somebody changed their mind or had some really new insights, arguments, etc?

< j​berman:monero.social > none from me

< r​ucknium:monero.social > "<j​effro256:monero.social> I propose tentatively setting ignore-unlock-time block index J to 3401782, with threat of setting earlier. monero-project/research-lab #125#issuecomment-2448077632. We can discuss this in the next meeting, though" https://libera.monerologs.net/monero-research-lab/20241030#c453599

< r​ucknium:monero.social > I am ok with the proposal from last time

< c​haser:monero.social > I would prefer an earlier J date to minimize the risk of potential harm.

< rbrunner > None from me either.

< j​effro256:monero.social > I think I like kayaba's approach of activating after a median block timestamp

< c​haser:monero.social > this is the part from jeffro's write-up that see as a source of risk: "If everything is within acceptable bounds, we ship the code using the wallet locked output cache as designed. If not, we go back to the drawing board." (emphasis mine.) there are ~6 months left and 70% of the hash rate seems to mine time-locked transactions, ignoring the relay rule.

< r​ucknium:monero.social > To be absolutely clear, this isn't a soft fork, right? Therefore, there is nothing to activate at the time point. Just something to write in the code that would take effect retroactively when the FCMP++ hard fork is activated, correct?

< j​effro256:monero.social > Yes

< j​effro256:monero.social > Yeah I guess we will have to see what happens

< j​effro256:monero.social > It all takes place retroactively, we're not actually deploying code at the moment, so we can also change the rule retroactively as long as people support it

< r​ucknium:monero.social > If a malicious actor starts packing blocks with txs with nonzero unlock time before 6 months, then the credible threat can be carried out: move the ignore date earlier. That's how I understand the proposal.

< k​ayabanerve:matrix.org > Hi. I'm so sorry. I had something come up personally and had to dip out.

< k​ayabanerve:matrix.org > I prefer announcing a time and using programmatic rules when the time comes than hardcoded constants.

< k​ayabanerve:matrix.org > I have a strong distaste for coding constants across networks and having to deal with that.

< j​effro256:monero.social > Yes. Since we can ignore anything locked, the only annoyance in the case of moving the ignore height back would be to the people who honestly wanted to use the feature, even though deprecated

< c​haser:monero.social > Rucknium's data shows that there is already a near-zero on-chain interest in non-zero time locks. retroactively changing the cut-off date seems to be arbitrary, wouldn't look good IMHO.

< j​effro256:monero.social > I agree it wouldn't be ideal, but at the end of the day we're announcing and getting rough consensus to remove unlock_time, this proposed ignore date is mainly just a nicety

< r​ucknium:monero.social > chaser seems to have a concern about the proposal's details. Hopefully it can be addressed before next meeting. If not, I will put this on the agenda again. How does that sound?

< c​haser:monero.social > Rucknium I'm okay with continuing the discussion in the MRL issue

< r​ucknium:monero.social > Ok. Let's end the meeting here.

< j​effro256:monero.social > Thanks everyone !

< j​berman:monero.social > If we propose 3 months and someone spams in 2 months, it arguably looks even worse. I think 6 months is more reasonable in enabling lingering voices to be heard on the issue, and the option is still there to retroactively cut off

< 0​xfffc:monero.social > Thanks everyone

< r​ucknium:monero.social > A relevant issue and PR for ASN diversity: monero-project/monero#7090 monero-project/monero#7935

< c​haser:monero.social > thank you all!

< c​haser:monero.social > jberman: granted, it could happen at any time. why do you think it's worse though with 3 months? as for lingering voices, I have seen has been barely any since that post in September on Github.

< c​haser:monero.social > and as for practical interest: there were 46 non-zero time locks during Sept 1 and Oct 13, out of which only one looked intentional (= locking for more than 10 blocks).

< j​berman:monero.social > "We've moved up the timeline 3 months to reduce chances of an issue" issue would look a bit like incompetence. Moving the timeline doesn't make it significantly harder to pull off, unless we move it to a retroactive date, which the option is on the table to do still

< c​haser:monero.social > yes, I see value in reducing the chance. (that's all that can be done aside from a retroactive decision.) as a rough consensus has already formed around May 1, I think the issue is I haven't voiced my concern in an explicit way earlier.

< j​berman:monero.social > Re: hardcoding a banlist. Here is the DNS banlist PR, feature is disabled by default and enabled with --enable-dns-blocklist: monero-project/monero#7138

< j​berman:monero.social > Here are the hardcoded domains pointing to the banlist: https://github.com/monero-project/monero/blob/893916ad091a92e765ce3241b94e706ad012b62a/src/p2p/net_node.inl#L2030-L2038

< j​berman:monero.social > IP's blocked by 1 as an example: https://www.nslookup.io/domains/blocklist.moneropulse.org/dns-records/txt/

< j​berman:monero.social > For starters seems it makes sense to add boog900 's list there?

< 3​21bob321:monero.social > Make it personal choice, your force a banlist and it might not be correct

< b​oog900:monero.social > These nodes are defiantly not running monerod. I have 0 doubt. They are also almost certainly proxies, it's the only explanation of their behavior.

< b​oog900:monero.social > I do not see a valid reason to run a proxy node.

< 0​xfffc:monero.social > The key point is it is extremely cheap for them to run these proxies. We have to return the favour and attack there, make it costly. Some kind of PoW. Problem with that is ordinary nodes are going to pay a little bit of extra computation.

< 0​xfffc:monero.social > IMHO

< 0​xfffc:monero.social > Although if the attacker has a huge budget. That’s not gonna hurt either.

< b​oog900:monero.social > I don't think a PoW that prevents proxies is possible. I did have one idea which is kinda like a mini proof-of-storage:

< b​oog900:monero.social > If nodes build a lookup table of values using a sufficiently hard function, with the input being their address, then other nodes could request values from this table and verify their correctness. The function to create the table would have to be hard enough where nodes can't generate the values on the fly. Now if we say the table has to be 10GB big, for every address they need to

< b​oog900:monero.social > create a 10GB lookup table.

< b​oog900:monero.social > The problem is we are now adding 10GB to every nodes storage and it might take a while to startup the first time as the table is generated.

< b​oog900:monero.social > And also it is still economical to run proxies, it's just more expensive now.

< 0​xfffc:monero.social > Yes, you are right. They don’t even need to run all the proxies.

< sech1 > boog900 you're thinking in the right direction, but I think it should be different. We need to find something monerod can do but a proxy can't do. For example, accessing some random bytes from the blockchain when connecting. It can't be proxied because real monerod will refuse this request for an already established connection, and it doesn't allow

< sech1 > new connections from the same IP.

< 0​xfffc:monero.social > How would the client verify the monerod answer? Random bytes from blockchain.

< 0​xfffc:monero.social > By asking randomly from multiple other nodes (?) maybe.

< sech1 > The client would ask for random bytes they already have themselves

< b​oog900:monero.social > If they run the nodes they could just ask the main node for the bytes though

< 0​xfffc:monero.social > s/asking/verifying/

< 0​xfffc:monero.social > Yes, but I am thinking about cases where they don’t have it.

< sech1 > right, they could ask their own node (which is modified), or they could just share a common network drive with the blockchain

< sech1 > back to square one

< 0​xfffc:monero.social > But nevermind.

< b​oog900:monero.social > Proof of storage is the only actual way I think, stuff like the 10GB lookup table could be used to make it more expensive.

< j​effro256:monero.social > Proof of storage doesn't prove that you're not running a proxy, just that you're running at least one node

< 0​xfffc:monero.social > Quick question. This is the scenario I was thinking about.

< 0​xfffc:monero.social > Imagine you have one proxy application. And you have 800 IP address that redirecting to that proxy application.

< 0​xfffc:monero.social > Exactly. I was thinking about that and you beat me to it :))

< b​oog900:monero.social > It does. It connects an address to the storage so to have multiple address you must store the blockchain multiple times

< 0​xfffc:monero.social > Aha. You are generating some data based on the node specific address.

< 0​xfffc:monero.social > And the client will use that address to query authenticity of your node.

< j​effro256:monero.social > Oh so the order of the random data is bound to your IPv4 address?

< sech1 > Or IPv6 address, or TOR address

< j​effro256:monero.social > How does the requester verify a memory hard function bound to a network address without building the table for every single peer?

< 0​xfffc:monero.social > I am not sure. But I believe there should be a lot of algorithms for doing that kind of asymmetric thing.

< b​oog900:monero.social > it only has to compute a few of the values, randomly, not the whole table, and then request those values and check they line up.

< 0​xfffc:monero.social > Kind of zkp :))

< j​effro256:monero.social > Sounds like it

< j​effro256:monero.social > Guess I just gotta look into the moon math.....

< j​effro256:monero.social > Also sounds like an expensive operation for the prover. We then need some kind of PoW by the sender to start that computation....

< 0​xfffc:monero.social > Very innovative. Basically:

< 0​xfffc:monero.social > 1. Client should be able to verify with acceptable computation.

< 0​xfffc:monero.social > 2. Node has to have the data to be able to respond in time.

< 0​xfffc:monero.social > 3. Client will try as much as possible, say 100 times, to rest assure the node has the data.

< 0​xfffc:monero.social > 4. For node it should not be easy to just compute correct answer without the storage.

< 0​xfffc:monero.social > I see. Since it is expensive, it can introduce a new surface for another kind of DDoS.

< b​oog900:monero.social > ah if you are talking about proof of storage, then that is done by "encrypting" the whole blockchain using your nodes identifier/address and then to verify you requests random, sequential, blockchain data and check that you can decrypt it. The decryption should be fast and the encryption should be relatively slow.

< r​ucknium:monero.social > A --outboundConnection---> B

< r​ucknium:monero.social > With these types of things, an honest Node B is just going to reduce its incoming connection count if the connection proving step is too expensive. With the Linking Lion threat model, it's node B that needs to do the proving that it's a real node.

< r​ucknium:monero.social > Not a blocker to these types of proposals, but you have to look at incentives

< b​oog900:monero.social > The proving should be cheep once nodes encrypt the data/create the lookup table

< b​oog900:monero.social > FWIW I am not advocating for proof-of-storage, encrypting every new block is probably too expensive IMO for all nodes.

< b​oog900:monero.social > The lookup table could work to make it more expensive for them, but might not fully stop them.

< 0​xfffc:monero.social > Maybe we can have that as feature and optional layer of security.

< 0​xfffc:monero.social > If user does not want it can opt in. And client can decide whether they pass txis to that node or not based on the user input.

< 0​xfffc:monero.social > s/opt in/opt out/

< 0​xfffc:monero.social > Nah. Makes it too complicated.

< r​ucknium:monero.social > IMHO, if an opt-out list that avoids outbound connections is not acceptable, then the ASmap PR could be reviewed/updated and merged: monero-project/monero#7935

< j​effro256:monero.social > If we make it optional, then that's going to incentivize a higher fraction of spy nodes connections since honest, low-resource, node runners will opt out, but the spy nodes won't

< r​ucknium:monero.social > That could reduce the Linking Lion share of an honest node's outbound connections to 1/12 = 8.3%

< j​effro256:monero.social > This keeps looking like the best option with the fewest downsides: diversify outgoing connections with structural information about the network

< j​effro256:monero.social > And it has other decentralization benefits not related to spying

< 0​xfffc:monero.social > I vote + on asmap

< r​ucknium:monero.social > I did a quick search of research papers on proving you are not a proxy node. Didn't find anything promising. Maybe I will ask the lead author of the D++ paper if she has any ideas. D++ requires running a node to be expensive for the threat model defense to work.

< 0​xfffc:monero.social > But in addition to this discussion. I wish there was a way to verify the node is running monerod or not.

< 0​xfffc:monero.social > Basically proof of storage might worth it in long run:

< 0​xfffc:monero.social > 1. Client solves a hard puzzle. Send it to node.

< 0​xfffc:monero.social > 2. Node verifies that hard puzzle is correct.

< 0​xfffc:monero.social > 3. Proves to client that it is running monerod.

< 0​xfffc:monero.social > Appears to me this will be useful in many places.

< j​effro256:monero.social > Guys I've figured it out: captchas!!!

< 0​xfffc:monero.social > It is not fair. Ruck can use reaction. We can’t :)

< o​frnxmr:monero.social > asmap is a bad idea, i think

< r​ucknium:monero.social > Will any mods in this channel re-enable emoji reactions please.

< j​effro256:monero.social > I promise I won't abuse them.........

< r​ucknium:monero.social > Nym has some node proofing. Maybe I will go re-read their white paper to see if it could help the Monero case.

< knownsec > I know I'm not a dev but just wanted to say, asmap will reduce the risk of eclipse and Sybil attack but it also will reduce the overall network connectivity, overall I think it's a good short-term solution imho

< j​effro256:monero.social > why would it reduce overall network connectivity ?

< knownsec > because honest nodes can be "skipped", am I wrong?

< knownsec > maybe it's not critical

< r​ucknium:monero.social > If the ASmap criteria is used for outgoing connections only, probably it doesn't change the total number of connections in the network. Just changes the distribution, i.e. Hetzner nodes would get fewer incoming connections and nodes in ASNs with few nodes would get many more connections. You could hit the maximum feasible incoming connections, though.

< r​ucknium:monero.social > That's my hypothesis at least.

< r​ucknium:monero.social > Which reminds me of all sorts of papers about the effects of network connectivity distribution of gossip message propagation speed, etc. 😁

< j​effro256:monero.social > knownsec: depends on how the selection policy uses the ASN information. If we selected more nodes "close" to us, that might make propagation faster, but reduce decentralization. If we selected nodes "far" from us, that might open us up to more Sybill attacks. You can also select a mix of the two, or choose ougoing connections such that they have a "diverse" ASN makeup as a whole. <clipped messag

< j​effro256:monero.social > A good selection policy should be based in research, but there is probably some good balance of selecting IPs by ASN that allows for protecting from Sybill attacks and spy nodes, while also giving good connectivity

< j​effro256:monero.social > Assuming the ASN information is accurate

< knownsec > It's more complex than I thought : )

< j​effro256:monero.social > Yes, very. ASN information is just information. There's an infinite number of algorithms we could posit to make decisions based on that information, most of them probably bad. In short, the ASN info and the decisions we make based on the ASN info is largely separate. So importing ASN information by itself shouldn't make connectivity worse, although a bad algorithm using ASN inform<clipped messag

< j​effro256:monero.social > ation might make worse decisions than monerod currently makes

< s​yntheticbird:monero.social > only solution is test in production /s

< 3​21bob321:monero.social > Is there info on how these proxy nodes were identified ?

< s​yntheticbird:monero.social > the MRL github issue gives an explanation