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

<r​ucknium:monero.social> Yu Gao, first author of recent paper ["Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network"](moneroresearch.info/267) has joined the room. Welcome, Yu Gao !

<r​ucknium:monero.social> The paper will be the first agenda item of the meeting in two hours.

<0​xfffc:monero.social> Hi everyone.

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

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

<y​ugao:ifi.uzh.ch> Hello, ALL, thanks for the warm welcome, glad to talk with you here.

Hello

<v​tnerd:monero.social> hi

<s​yntheticbird:monero.social> Hello

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

<y​ugao:ifi.uzh.ch> my coauthor is joining also

<s​packle:monero.social> hi

<r​ucknium:monero.social> Yu Gao: Wonderful. Thanks.

<a​rticmine:monero.social> Hi

<s​gp_:monero.social> hello

<s​yntheticbird:monero.social> Proposal: when an author join the meeting rucknium should replace "Greetings" section with "MRL. Assemble!"

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

<m​atijapiskorec:matrix.org> Hi everyone!

<v​tnerd:monero.social> me: mostly lws-frontend stuff, with some odds-and-ends in monerod

<r​ucknium:monero.social> Matija Piskorec is also an author of [Gao, Y., Piškorec, M., Zhang, Y., Vallarano, N., & Tessone, C. J. (2025). "Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network".](moneroresearch.info/267)

<0​xfffc:monero.social> Thanks to help from [boog900](matrix.to/#/@boog900:monero.social) I have started working on new tx relay protocol.

<0​xfffc:monero.social> Few general PRs on the side.

<j​berman:monero.social> me: shared analysis on the FCMP++ weight calculation and proposed an algorithm (seraphis-migration/monero #26#discussion_r2057203539), continuing on including the FCMP++ tree root in the PoW hash (after discussions with jeffro, I'm currently working on keeping the tree 9 blocks ahead of the tip i.e. growing the tree with outputs that unlock 10 blocks higher <clipped message>

<j​berman:monero.social> than the tip which includes normal outputs from the tip block, so that SPV sync via block headers can have solid assurance the latest usable tree root for FCMP++ txs has multiple blocks of PoW on top)

<r​ucknium:monero.social> me: Working on the "unit test" of subnet deduplication for peer selection. I have something that seems to be working well for the `white_list`, but maybe not for the `gray_list`.

<j​berman:monero.social> Also if if a monero twitter account handler is watching, would be good to announce the FCMP++ optimization contest is now open for submissions

<r​ucknium:monero.social> jberman: "SPV" means a wallet using a remote node?

<j​berman:monero.social> It could. It means "Simplified Payment Verification": wiki.bitcoinsv.io/index.php/Simplified_Payment_Verification

<r​ucknium:monero.social> Here is the link for the FCMP++ optimization contest, by the way: web.getmonero.org/2025/04/05/fcmp++-contest.html

<r​ucknium:monero.social> Yes, SPV is usually a term used in BTC-like blockchains. I was wondering how it is explained in Monero.

<r​ucknium:monero.social> I mean, you are trying to have nodes "prove" to wallets that they are not being malicious, right?

<j​berman:monero.social> You could sync block headers, and then verify that the user is spending an output that is a member of the chain by checking it against the FCMP++ root included in the block header (that is PoW-verified)

<r​ucknium:monero.social> AFAIK, wallet2 did some checks on the outputs distribution histogram to try to detect if nodes were giving bad distributions for ring construction

<j​berman:monero.social> Or on the wallet side, the wallet can have stronger assurance the tree it's using to construct the proof is the correct tree (i.e. a malicious node has to provide PoW to feed fake tree data to the wallet)

<s​yntheticbird:monero.social> sounds awesome

<r​ucknium:monero.social> Sounds great. Is this related to the issue that tevador found in the current PoW?

<r​ucknium:monero.social> I mean, is it a way to reduce/eliminate that issue?

<r​ucknium:monero.social> And are you talking with sech1 about it?

<j​berman:monero.social> Another interesting benefit: a node can sync block headers first, checking PoW, and then start doing verification/tree building in parallel with a solidly optimal construction that maximizes CPU utilization (how I believe evoskuli is doing for Bitcoin)

<j​berman:monero.social> Not familiar, what issue are you referring to there?

<r​ucknium:monero.social> Let's move on to the agenda items. Maybe pick this back up after

<r​ucknium:monero.social> 3) [Gao, Y., Piškorec, M., Zhang, Y., Vallarano, N., & Tessone, C. J. (2025). "Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network".](moneroresearch.info/267)

<r​ucknium:monero.social> There was some initial discussion of this paper in #monero-research-lounge:monero.social : libera.monerologs.net/monero-research-lounge/20250424#c520278-c520470

<r​ucknium:monero.social> And now, thanks to xmrack , we have two of the paper's authors here: Yu Gao and Matija Piskorec

<r​ucknium:monero.social> Welcome!

<m​atijapiskorec:matrix.org> Me and Yu Gao read the discussion that you linked!

<r​ucknium:monero.social> Great. Well, how do you want to discuss? Any way is fine.

<m​atijapiskorec:matrix.org> We are open to answer any questions you might have

<y​ugao:ifi.uzh.ch> We have already read it before

<r​ucknium:monero.social> If I recall correctly, the paper wasn't completely clear on whether you were measuring just outbound connections or both inbound and outbound. Of course, one node's outbound is another's inbound, so you can estimate the whole graph, still. But if you wanted to focus on a specific node's connections based only on its data, then you may want to know its inbound connections, too.

<r​ucknium:monero.social> So can you directly measure an node's inbound connections?

<y​ugao:ifi.uzh.ch> We regard each "connection" as an undirected link; to detect the architecture is the primary task, and we didn't include the incoming or outgoing detection.

<m​atijapiskorec:matrix.org> We don't get information about whether a peer is outgoing or incoming from a peer list. So we cannot distinguish between the two

<r​ucknium:monero.social> I see. Thank you. Like I stated in the #monero-research-lounge:monero.social discussion, I am skeptical that an adversary could use the topology measurement to harm the network's integrity or privacy because the topology estimate must be taken over a long period of time, e.g. a week. By the time an adversary has that information, it is not useful for malicious behavior.

<s​pirobel:kernal.eu> would the good nodes find each other again in case there is a network shutdown? do you expect the topology to reappear or could it end up differently?

<j​effro256:monero.social> I guess you could rule out incoming by connecting to that peer and seeing if its ports are open, yeah? Would distinguishing between incoming/outgoing make a meaningful difference to partitioning attacks? It might make a privacy difference for Dandelion++...

<m​atijapiskorec:matrix.org> I agree with this - we have to collect data for a period of time in order to calculate a statistic

<a​ntilt:we2.ee> i stumbled upon 8 outbound cx you chose. Isn't the default 12 ?

<r​ucknium:monero.social> flip flop: I also noticed that. I assume it was a typo (BTC uses 8).

<m​atijapiskorec:matrix.org> We don't know whether the topology would be identical between the shutdowns. I would assume most probably not. However, this depends on how peers (white and gray lists) are stored in the node between different runs. I guess that these lists can be used to try to reestablish the connections, but it is not guarantied that this will succeed, so topology would probably be different (e<clipped mess

<m​atijapiskorec:matrix.org> specially is enough time elapsed)

<y​ugao:ifi.uzh.ch> My understanding is that, from the graph theory perspective, it is not really a big issue, but of course, from the security perspective, it is meaningful, because it allows incoming connections to pose risks.

<a​ck-j:matrix.org> Hey Yu and Matija thanks again for joining the meeting. I was wondering if you were aware of the large number of Monero proxy nodes discovered by boog900. Would these “fake” nodes have an impact on your analysis?

<a​ck-j:matrix.org> Feel free to continue your discussion and come back to my question later

<r​ucknium:monero.social> I think some of the in/out measurement depends on what actions, exactly, trigger an update to `last_seen`. Actually, recently I have been investigating how that all works.

<m​atijapiskorec:matrix.org> I think this is a typo, you are right!

<a​ntilt:we2.ee> The only way to find out is to observe the network under real stress. Simulations (i've done those) are notoriously hard to do and need to be optimized against real-world case studies.

<a​ntilt:we2.ee> Would it be feasable to collect data regularily ?

<y​ugao:ifi.uzh.ch> Do these fake nodes play an active role in the network?

<r​ucknium:monero.social> From what I understand of the paper, if inbound connections do not trigger an update to `last_seen`, then the method may only be measuring a specific node's outbound connections (but all connections of reachable nodes if this is measured at all reachable nodes).

<r​ucknium:monero.social> Yu Gao: It seems that these nodes only accept inbound connections, but do not establish their own outbound connections

<j​effro256:monero.social> They become potential outgoing connections for honest nodes, just like any other node.

<s​yntheticbird:monero.social> There are no reasons to believe that they don't participate in block propagation and consensus requirements.

<s​yntheticbird:monero.social> but yeah, they are just here to grab poor ignorant nodes and weaken tx anonymity.

<r​ucknium:monero.social> Info on the suspected malicious nodes: monero-project/research-lab #126

<m​atijapiskorec:matrix.org> We are continuously collecting peer list data from the three Monero nodes that we are running from various locations

<r​ucknium:monero.social> MRL has recommended that node operators ban the suspected spy nodes from having connections to their nodes: monero-project/meta #1124

<y​ugao:ifi.uzh.ch> Network shutdown is a chance for an eclipse attack, they can refresh the peerlist, top grey_list with fake IPs. The shutdown is a base for this kind of attack

<r​ucknium:monero.social> There were some recent patches to vulnerabilities that could crash nodes through p2p communication.

<s​yntheticbird:monero.social> don't forget to say it's padillac who found it. I know he want this to be insisted upon.

<m​atijapiskorec:matrix.org> We were not aware of these fake proxy nodes! Is there a way to identify them?

<s​yntheticbird:monero.social> great question

<j​effro256:monero.social> The method to identify them hasn't yet been made public

<r​ucknium:monero.social> Matija Piskorec: Yes. Last MRL meeting, it was loosely decided to disclose the method to detect the nodes once an intermediate countermeasure is written.

<r​ucknium:monero.social> Which will hopefully happen in a few months or less.

<a​ntilt:we2.ee> Looking foreward to the next stressful event... ! Seriously, this data will be helpful.

<0​xfffc:monero.social> Until we have counter measures ready, it is naive to disclose the method.

<s​yntheticbird:monero.social> 0xfffc tbf there are other methods available

<r​ucknium:monero.social> Info about the recent p2p crash vulnerability patches are in the release nodes: github.com/monero-project/monero/releases/tag/v0.18.4.0 and HackerOne disclosures: hackerone.com/monero/hacktivity?type=team

<y​ugao:ifi.uzh.ch> there is, like active methods

<r​ucknium:monero.social> Matija Piskorec: If you look at your data again, these spy nodes should be obvious because they "saturate" their /24 IP address subnets.

<m​atijapiskorec:matrix.org> We don't yet have a plan to publish this data. It would be technically challenging (it's GBs of data). But we are open for suggestions and collaboration! :-)

<o​frnxmr:monero.social> Xmr used to use 8

<r​ucknium:monero.social> That suggests that a malicious party is renting whole /24 subnets to run proxy nodes

<r​ucknium:monero.social> ofrnxmr: Do you know when that changed?

<r​ucknium:monero.social> Matija Piskorec, Yu Gao : Do you plan to present this paper anywhere at a conference soon?

<m​atijapiskorec:matrix.org> Thank you for the suggestion! In the future we might decide to exclude them.

<a​ntilt:we2.ee> Can you expand on this scenario ?

<m​atijapiskorec:matrix.org> Yu Gao: is presenting in on IEEE ICBC conference in Pisa, 2-6 June. icbc2025.ieee-icbc.org

<r​ucknium:monero.social> Matija Piskorec: Well, maybe still include them and write a narrative about them or something. You could elaborate a lot about the facts you found, if you want to speculate a little. On a related topic, you found "supernodes" with very high number of connections (different from the spy nodes that boog900 discovered. As you know, this paper also found that supernodes existed: [Gao<clipped message

<r​ucknium:monero.social> , Y., Piškorec, M., Zhang, Y., Vallarano, N., & Tessone, C. J. (2025). "Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network".](moneroresearch.info/267)

<r​ucknium:monero.social> Great!

<y​ugao:ifi.uzh.ch> This is another research idea I am going to simulate, but it is very early stage, maybe I will share it in the future?

<r​ucknium:monero.social> I wonder if the supernodes are nodes of mining pools that want to propagate their blocks as quickly as possible. Or other honest services. Or they could be trying to spy, but Dandelion++ is designed to defend against supernodes since the stem phase propagates txs to outbound connections.

<s​pirobel:kernal.eu> is there the possibility to implement a reputation system to prevent these kinds of eclipse attacks? It seems like using ips to make it expensive to run fake peers is duct tape. would be a great research topic

<y​ugao:ifi.uzh.ch> Rucknium: I am also going to your MorKon5 workshop.

<o​frnxmr:monero.social> 2020 monero-project/monero c67fa32

<r​ucknium:monero.social> Fantastic. I will be presenting there, too, but remotely.

<a​ntilt:we2.ee> i have some ideas regarding WoT -- last agenda item.

<s​yntheticbird:monero.social> WebOfTrust?

<0​xfffc:monero.social> Videos will be available immediately?

<a​rticmine:monero.social> Thanks. I actually thought the number of connections change was earlier

<r​ucknium:monero.social> 0xfffc: My videos will be available immediately since they will be pre-recorded and available on Vimeo (or possibly another public site). I think MoneroKon organizers need some time to post edited versions of most in-person presentations. You can ask in #monerokon:matrix.org for more info.

<r​ucknium:monero.social> boog900 has suggested that the default number of outbound connections could go even higher if and when a more bandwidth-efficient tx relay protocol is implemented. 0xfffc said at the beginning of the meeting that he was working on it.

<a​ck-j:matrix.org> Yu Gao: maybe I missed it but did you publish the list of super node IP addresses?

<y​ugao:ifi.uzh.ch> no

<y​ugao:ifi.uzh.ch> We totally understand the responsibility of analysing DLT networks.

<r​ucknium:monero.social> Here is the new tx relay proposal: monero-project/monero #9334

<o​frnxmr:monero.social> A higher number would probably improve a majority pruned-node environment, but w/o tx-relay improvements, it adds a lot of latency

<0​xfffc:monero.social> Yes. Boog is implementing for cuprate. I have started monerod tx relay

<0​xfffc:monero.social> Let me find the links

<o​frnxmr:monero.social> Theres also in-progress code for this

<o​frnxmr:monero.social> The main problem with increasing outbound is putting a bottleneck on the minority nodes who accept incoming connections

<a​ck-j:matrix.org> Yu Gao: would you consider disclosure of the super node IP addresses to the Monero VRP via hackerone?

<o​frnxmr:monero.social> In a network where only 1/10 nodes have incoming connections, the singke node has to handle all of the traffic. We set incoming to unlimited by default, bur in practice most node will bottleneck-out at 100-1000 connections, depending on network haedware, operating system, and uplink speed

<0​xfffc:monero.social> [Rucknium](matrix.to/#/@rucknium:monero.social)

<0​xfffc:monero.social> Cuprate:

<0​xfffc:monero.social> Cuprate/cuprate #407

<0​xfffc:monero.social> Monerod:

<0​xfffc:monero.social> 0xFFFC0000/monero #60

<a​ntilt:we2.ee> for the record, in a stress situation, less cx will be more resilient (in all likelyhood)

<o​frnxmr:monero.social> So increasing outbound is, imo, abbad idea at a certain point. Cant use up "all" of the incoming slots by abusing our outbound connections

<m​atijapiskorec:matrix.org> In principle we are open to disclosing any information (data, code) related to our paper to the Monero team.

<r​ucknium:monero.social> The paper says, "Our results show that the network is highly centralized around several super nodes with significant betweenness centrality and high degrees. While this centralization strengthens security and robustness, it also introduces potential vulnerabilities."

<r​ucknium:monero.social> Technically, yes the graph metrics would show more centrality when a few nodes decide to set a high non-default number of outbound connections. However, is it centralized in a meaningful way? If the supernodes didn't exist, would the network be in a better or worse state?

<o​frnxmr:monero.social> i assume the supernodes are what i am referring to. Most non-supernodes are exhausted much more easily

<o​frnxmr:monero.social> Increasing outbound connections exacerbates this problem

<0​xfffc:monero.social> Skimmed the paper, my questions too 👆🏻

<o​frnxmr:monero.social> (Even with improved tx-relay)

<o​frnxmr:monero.social> If the supernodes didnt exist, the question is: do the remaining nodes have enough inbound slots to service the nerwork

<b​oog900:monero.social> I'm not saying we should wack the number of connections stupid high, but with the new protocol reducing bandwidth usage by 75%+ we could double the number connections and still be using less bandwidth overall (assuming linear growth which isn't the case with the new protocol, it should be less).

<o​frnxmr:monero.social> Bandwidth isnt the bottleneck here, its the number of inbound connections available to the network

<r​ucknium:monero.social> IIRC, there have been a couple of papers that worry that BTC's default 8 outbound connections is too low.

<a​ntilt:we2.ee> The view needs to be dynamic and individualistic. nodes may decide for themselves (UI?)

<o​frnxmr:monero.social> In would assume that less than 50% kf nodes on the network are reachable via incoming due to nat, shared ip, etc

I uploaded 41 GB over 11 hours today on an unrestricted node. So not sure about " Bandwidth isnt the bottleneck here" ...

<r​ucknium:monero.social> rbrunner: found the supernode operator :P

Lol

<o​frnxmr:monero.social> what is an "unrestricted node"?

<y​ugao:ifi.uzh.ch> It depends on how we define centralisation. If the nodes have a lot of connections, for instance is the mining pool nodes, then it has super computing power and an advantage to get more rewards, something like this, and also if the super nodes shut down, the network is easily disconnected

No limits on number of incoming, no speed limit

<o​frnxmr:monero.social> and is your rpc public?

No

<o​frnxmr:monero.social> 41gb isnt a lot. Its like 1/4 of a node syced from you

<o​frnxmr:monero.social> i highly doubt the 42gb is due to txrelay

<0​xfffc:monero.social> > and also if the super nodes shut down, the network is easily disconnected

<0​xfffc:monero.social> I have problem with this part. I can’t imagine what kind of network / graph is that.

<a​ntilt:we2.ee> thats hard to predict.

<o​frnxmr:monero.social> Its because most nodes dont have incoming connections, so those nkdes _must_ make their connections to those who do, leading to centralization around the ones that do

<b​oog900:monero.social> how many connections rbrunner? on average doesn't have to be exact

100 or so

<o​frnxmr:monero.social> If 80% of the connections on the network are directed at supernodes, that implies that the rest of the network's incoming is likely exhausted

<r​ucknium:monero.social> Yu Gao: Matija Piskorec : By the way, MRL has powerful scientific computing hardware if you ever did want to share data with MRL so that MRL researchers could look at it, too. Or if something needed a lot of RAM and threads.

<y​ugao:ifi.uzh.ch> I believe a general node would not intentionally modify its config file to get a lot of connections.

<r​ucknium:monero.social> One machine with 256GB of RAM and another with 1TB of RAM.

<j​effro256:monero.social> Current impl of the node node picks more-recently-succeeded outgoings with high probability, so perhaps the network strongly coalesces around nodes which have high uptime

<r​ucknium:monero.social> About 100 inbound connections on nodes with open ports is very common, AFAIK.

<r​ucknium:monero.social> Yu Gao: By default, Monero nodes accept an unlimited number of inbound connections.

<m​atijapiskorec:matrix.org> My opinion is that centralization is a bit ambiguous word - we can measure centrality in many different ways. And of course, more or less centralization is not necessarily a good or a bad thing, because it affects the network in different ways. So it's hard to say whether removing the supernodes would make the network better or worse.

<0​xfffc:monero.social> [ofrnxmr](matrix.to/#/@ofrnxmr:monero.social)

<a​ntilt:we2.ee> it would slow down the network, but consensus may be robust. The spam attack hints at that. Future will tell.

<a​ntilt:we2.ee> it would slow down the network, but consensus may be robust. The spam attack hints at that. Future will tell.

<a​ntilt:we2.ee> Unless a bad actor takes advantage of the situation... i think i get your idea.

<a​rticmine:monero.social> This is under 10Mbps. It does indicate that upstream bandwidth can be a limitation

<y​ugao:ifi.uzh.ch> But inbound connections can be a burden for a general node?

<b​oog900:monero.social> from my data in 9334 I would expect about 10GB of that to be tx-relay FWIW

<b​oog900:monero.social> the rest is probably a node syncing

<r​ucknium:monero.social> Yu Gao: Yes. In the suspected tx spam attack last year, many nodes had big problems because too many txs and too many conenctions.

<r​ucknium:monero.social> That is a reason why a Monero "stressnet" was organized last year. A large number of txs were spammed to test problems and correct them.

<o​frnxmr:monero.social> Not if they are behind a nat etc, and in practice that is limited by uplink speed and network hardware or os (anywhere from 10-1000 connections)

<a​rticmine:monero.social> It can be if they are in a cable as opposed to fibre Internet connection. This is because of the mindset of the cable tv companies

<m​atijapiskorec:matrix.org> I have to go now, but thank you everyone for your questions and interest in our paper! You can always reach us via email (they are in the paper) if you have any additional questions or you want to discuss potential collaboration

<o​frnxmr:monero.social> Upnp rarely works in my experience, meaning that unless a user manually enables port forwarding, their node does not have incoming.

<b​oog900:monero.social> IMO we can double the number of outbound connections with the new relay protocol and still be fine, if individual nodes need to limit connections they should be doing that already.

<o​frnxmr:monero.social> Imo we should definitely not

<r​ucknium:monero.social> Here is info on what happened on the stressnet: reddit.com/r/Monero/comments/1eoana8/the_stressnet_so_far

<b​oog900:monero.social> if that is enough to kill the network then the network is more at risk now with the current protocol and connection count

<o​frnxmr:monero.social> Not without knowing how many non-superpeer nodes have incoming connections

<j​effro256:monero.social> Thank you!

<y​ugao:ifi.uzh.ch> sorry Rucknium, I also need to go now. Thanks for reaching out; it's a pleasure to join here, and the great discussions. Feel free to connect with us by email.

<r​ucknium:monero.social> Matija Piskorec: Yu Gao Thank you very much for discussing here! I think we will be in touch.

<o​frnxmr:monero.social> Its a very simple problem. If there are 150 network participants, but only 10 of them have incoming connections, and limited to 100 connections each = max 1000 incoming connections can be served. If the other 140 nodes have 12 outgoing connections, that is 1680 outgoing slots to fill.

<0​xfffc:monero.social> Why are you saying that? With new tx relay protocol, what’s the problem? Once new tx relay kicks in, the bandwidth usage almost halves

<a​rticmine:monero.social> For example here in British Columbia Canada, the Telco offers up to 3 Gbps symmetrical and in some cases 5Gbps symmetrical. The Cable co maxes out at 200 Mbps upstream and in most cases much lower

<o​frnxmr:monero.social> This isnt about bandwidth, its about slots

<0​xfffc:monero.social> No, my point was, I don’t see issues doubling slots when we reduced bandwidth usage

<o​frnxmr:monero.social> You're not doubling incomibg slots

<o​frnxmr:monero.social> Youre doubling the amount of incoming slots that are used up

<a​ntilt:we2.ee> move on ?

<o​frnxmr:monero.social> Instead of 1680, now those 140 nodes are trying to hold 3360 outgoing connections against 1000 available incoming slots

<r​ucknium:monero.social> Nodes with open ports have a strangely high number of inbound connections. If there are no supernodes with non-default outbound conenctions, then about 90% of nodes are unreachable. But probably there are supernodes.

<r​ucknium:monero.social> There are a couple more agenda items.

<s​pirobel:kernal.eu> web of trust, web of trust (if you chant it, it sounds a bit like one of us, one of us) hyped for this topic as it seems to be at the bottom of all of this

<a​rticmine:monero.social> We have to distinguish here between initial node synchronization and ongoing node relay. Nodes with closed ports still have to deal with ongoing node relay

<r​ucknium:monero.social> 4) FCMP++ transaction weight formula. seraphis-migration/monero #26

<r​ucknium:monero.social> jberman and jeffro256 are working on the requirements for this. They have been discussing in #no-wallet-left-behind:monero.social

<r​ucknium:monero.social> Transaction weight is used for the dynamic block weight algorithm and tx fees.

<j​berman:monero.social> my latest analysis on FCMP++ tx weight formula is here: seraphis-migration/monero #26#discussion_r2057203539

<0​xfffc:monero.social> Honestly, if we would’ve opened a separate repo for FCMP++ migration would been much more clear. I still have problem understanding what is going on. We do FCMP++ under seraphis migration, we used to have seraphis as protocol. Now we are doing FCMP++

<a​rticmine:monero.social> The clawback was implemented to account for verification time with l6 outputs. It is overkill when we are limiting the number of outputs to 8. So I would recommend against it

<0​xfffc:monero.social> ( anyway, not wanna hijack the topic )

<o​frnxmr:monero.social> Outputs, and not inputs, right 😏

<j​berman:monero.social> Wonder how verification time on an 8-input FCMP++ membership proof compares to a 16-output BP/BP+, guessing it's higher by a solid amount/and the scaling properties much more pronounced for FCMP++ than for BP/BP+?

<j​effro256:monero.social> Verification is still >5x slower for an 8-input tx, whereas the size is only <2x

<o​frnxmr:monero.social> i'm 100% against limiting inputs to 8

<o​frnxmr:monero.social> [@tobtoht:monero.social](https://matrix.to/#/@tobtoht:monero.social)

<j​effro256:monero.social> Or are you referring to the BP+ clawback?

<b​oog900:monero.social> but what about the load on nodes 😏

<a​rticmine:monero.social> Yes

<o​frnxmr:monero.social> what about load on nodes when i need to chain 10 tx together.

<j​effro256:monero.social> We can re-use the BP+ clawback code for FCMP++ weight, it's like less than 10 extra lines, so it's not too much of a hassle if it brings us a more accurate pricing IMO

<o​frnxmr:monero.social> Its not like we magically limit the number of inputs used per day by limiting the number usable per tx to some unrealistically low number

<j​berman:monero.social> reusing BP+ clawback code exaclty had the problem of incentivizing fewer input combinations into more txs versus 1 tx for all inputs, which is why I made that algo similar to bp+ clawback with those tweaks

<a​rticmine:monero.social> It does not improve pricing especially if we can improve on parallel processing for verification. Unbound bandwidth is the biggest limitation

<b​oog900:monero.social> they scale up the next power of 2 right? 1 17 input tx is more expensive to verify than a 16 + 1 input txs or whatever.

<o​frnxmr:monero.social> Not from my understanding (or lackthereof)

<a​rticmine:monero.social> This comes down to the cost and availability of bandwidth vs parallel processing compute time

<a​rticmine:monero.social> More correctly unbound bandwidth

<j​berman:monero.social> you wouldn't need to chain fwiw if you want to have comparable ux to today, you could construct multiple txs at one time. the idea behind the 8-input limit was to be able to verify a single tx in reasonable time for tx pool processing

<o​frnxmr:monero.social> thats what i mean by chaining

<j​effro256:monero.social> Yes this is sort of true. It's not exactly powers of two like Bulletproofs, but this is more or less correct

<o​frnxmr:monero.social> Making me send 5 separate tx for 1 payment

<a​rticmine:monero.social> The limit makes sense but it makes additional weights redundant

<j​effro256:monero.social> Sorry, not like Bulletproofs *as we use them for range proofs*

<j​effro256:monero.social> B/c FCMPs also use Bulletproofs underneath

<j​effro256:monero.social> Rather, a variation named GBPs

<r​ucknium:monero.social> I think that last time MAX_INPUTS/MAX_OUTPUTS was discussed, it was decided to take up the question again once the optimized code is settled and there are benchmarks for everything.

<o​frnxmr:monero.social> from a purely UX standpoint, i'm against a limit below... the tx size limit 🙃

<a​rticmine:monero.social> I recall that discussion

<r​ucknium:monero.social> So maybe stay on the topic of just tx weight formula.

<r​ucknium:monero.social> Unless the questions cannot be separated at all.

<a​rticmine:monero.social> I am saying we don't need weights just for verification time

<b​oog900:monero.social> we must we only have 1 FCMP per tx?

<b​oog900:monero.social> why must we only have 1 FCMP per tx?

<b​oog900:monero.social> can't we have 1 for each block of 8 or something

<j​berman:monero.social> that's a good point^

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

<j​effro256:monero.social> AFAIK, there isn't anything stopping us cryptographically

<a​rticmine:monero.social> Also FCMP has to use a fixed weight for a given number of outputs to address changes in the number of layers

<j​effro256:monero.social> I remember that there was code written just like this for Bulletproofs, where it broke down the number of outputs into its bit-wise decomposition, and put as many BPs as there were 1 bits in the output count. I can't remember why it wasn't used in production

<j​berman:monero.social> interesting, I didn't know that

<b​oog900:monero.social> yeah the number of BPs in a tx is dynamic per serialization it is enforced to 1 though by consensus.

<j​berman:monero.social> jeffro256 proposed an idea to use a constant number of layers in the weight calculation and I support the idea, reasoning is here: github.com/jeffro256/monero/blob/fc…yptonote_format_utils.cpp#L510-L531

<r​ucknium:monero.social> I guess I am wrong, but I thought more inputs added to the same FCMP does not increase the verification time per input. So breaking them up does not improve verification time. And the storage size per input of a FCMP actually _decreases_ as input number increases. These were my interpretation of kayabaNerve's numbers, which were theoretical, but not direct code benchmarks.

<a​rticmine:monero.social> Yes I agree. If the number of layers changes the weight does not change. I support this

<j​effro256:monero.social> jberman: I removed the multiple-BP construction code in this PR: monero-project/monero #9717. This is what it used to look like:https://github.com/jeffro256/monero/blob/2e8a128c752a3cee2a0bee43b3c15ae7ec344792/src/ringct/rctSigs.cpp#L1202-L1240

<a​rticmine:monero.social> Keeping the weight constant over a layer change is very important for scaling

<j​effro256:monero.social> It does increase time-per-input once you hop over a power-of-2 boundary, which I think is what happens for a 5-input under jberman's benchmarks, I would have to check again. Much like how going from proving 8 range proofs to 9 means you pay for 16

<r​ucknium:monero.social> I think this will be an ongoing discussion. Let's try to get a few words in about the Web of Trust for peer selection idea.

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

<r​ucknium:monero.social> I forgot to put this on the posted agenda 😬

<j​berman:monero.social> tbc, we're at ~150mn or so outputs today, we bump to 7 layers at ~320mn, 8 layers at 12bn, 9 at 200bn+

<r​ucknium:monero.social> flip flop: Do you want to discuss Web-of-Trust?

<a​ntilt:we2.ee> i'll shoot a text but we can discuss next time

<a​ntilt:we2.ee> A naive rating system as in pgp key signing may backfire - bad actors (20% spynodes) may be faster to sign each other than the rest of us. Local F2F nets are a different application compared to global consensus.

<a​ntilt:we2.ee> I'd rather expand on /anchor nodes/ by proofing good behaviour such as availability, contribution to consensus, etc. The idea is that an adversary may have trouble faking such a track record (which may give more weight to old entries). Ideally a big database could be avoided. Thats just a theoretical idea atm.

<r​ucknium:monero.social> flip flop: Sounds good.

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

<a​ntilt:we2.ee> bye!

<s​yntheticbird:monero.social> thanks

<s​yntheticbird:monero.social> delicious meeting

<a​rticmine:monero.social> Thanks

<o​frnxmr:monero.social> Ty

<r​ucknium:monero.social> jeffro256: Maybe what I was seeing was the total verification time cost, given current user behavior. In other words, the txs that used to have many inputs would have to follow a consolidation sequence. The consolidation sequence would use the max power of two to do the consolidations, so it would be efficient.

<0​xfffc:monero.social> Thanks everyone for great meeting

<r​ucknium:monero.social> In here: "Monero FCMP MAX_INPUTS/MAX_OUTPUTS empirical analysis" gist.github.com/Rucknium/784b243d75184333144a92b3258788f6

<j​berman:monero.social> fwiw kayabanerve did also discuss including multiple proofs in 1 tx here: gist.github.com/kayabaNerve/dbbadf1f2b0f4e04732fc5ac559745b7

<j​berman:monero.social> reasoned against it for bandwidth reasons and to avoid having a single tx take seconds to verify. I think the latter is still a reasonable point of contention when allowing multiple proofs in 1 tx (imagine including many valid proofs and then 1 invalid at the back)

<j​effro256:monero.social> I don't think including very many almost-correct proofs in 1 transaction is any different from including very many txs in an almost-correct set of txs, as long as you verify each FCMP individually

<j​effro256:monero.social> We would want to put a max size on each FCMP obviously

<j​berman:monero.social> Presumably the RPC would limit to 1 tx per submission, and I guess blocks other RPC submissions

<b​oog900:monero.social> yeah we are going to be paying the bandwidth cost anyway just over many txs

<b​oog900:monero.social> for UX I think having a single tx is better and the verification/bandwidth cost is the same as if it was split into multiple txs

<j​effro256:monero.social> It's also better for services which depend on certain on-chain actions being atomic

<j​effro256:monero.social> True, which isn't much different than blocking to verify each FCMP individually

<j​berman:monero.social> Fair counter-points imo

<j​berman:monero.social> There's also the argument that requiring more txs = more outputs = more FCMP++ proofs to verify longer term too

<b​oog900:monero.social> kayabanerve: also said here that 5 4 input FCMP would verify quicker than 1 16: monero-project/meta #1102

<b​oog900:monero.social> > <k​ayabanerve:matrix.org > If the block only has a single 16-input transaction, that single proof will cost us thousands of scalar multiplications alone. If we had 5 4-input transactions (which is how they'd be aggregated under MAX_INPUTS=4), the computational complexity would be a fraction.

<b​oog900:monero.social> > < k​ayabanerve:matrix.org > (as the 4-input TXs would reasonably share their base cost with other TXs, making their cost an amortized percentage of the base cost and only the per-proof costs)

<b​oog900:monero.social> If I understand correctly.

<j​effro256:monero.social> Maybe I'm misunderstanding, but I think the point Kayaba is trying to make is that you can verify four 4-input TXs at a time, whereas you can only use 1 core for a 16-input, so your real-time difference between starting to verify and stopping is 4x, even though total CPU time is the same

<j​effro256:monero.social> Which is especially important for tx propagation time

<j​effro256:monero.social> That's also assuming that the 16-input tx is using 1 FCMP, not multiple

<a​rticmine:monero.social> Yes of course. One can parallel process the 4 4input txs

<a​rticmine:monero.social> Independently of each other

<j​berman:monero.social> Steel-manning kayaba's argument using mine and kayaba's figures:

<j​berman:monero.social> To DoS a node, an attacker would hammer it perpetually, hogging bandwidth/CPU time

<j​berman:monero.social> Allowing uncapped input limits, each malicious IP gets an estimated/untested 2s of a CPU thread for a bad tx (and more bandwidth expended over a shorter period)

<j​berman:monero.social> Capping input limits to 8: each malicious IP gets ~200ms of a CPU thread for a bad tx

<j​berman:monero.social> So the same attack when capping limits would require 10x more IP's to perpetually pull off the same attack

<j​berman:monero.social> If you spread out more txs with input limits, it still requires more IP's to submit the bad txs that maliciously hog the node get your IP blocked

<j​effro256:monero.social> > Allowing uncapped input limits, each malicious IP gets an estimated/untested 2s of a CPU thread for a bad tx (and more bandwidth expended over a shorter period)

<j​effro256:monero.social> This is assuming 1 FCMP per transaction though, yeah?

<b​oog900:monero.social> I mean txs are sent in batch + we could verify each FCMP in a tx one by one

<b​oog900:monero.social> If the batching is seen as a potential issue

<b​oog900:monero.social> Which should work out the same if we have multiple fcmp per tx or multiple txs

<j​berman:monero.social> I don't think batching is the primary issue. Even if you do allow batching and then process serially, each good tx is fine. The problem is that a bad tx would take (hypothetically) 2s to verify which is then hogging the CPU

<j​berman:monero.social> That's on verification time alone. If we also factor in bandwidth and the RPC limits to 1 per submission, then the same underlying issue kayaba is pointing out is there (each bad tx per IP hogs significantly more bandwidth)

<a​rticmine:monero.social> A large number of input TX because of it's size would attract a very large penalty if it is added at the penalty threshold. This type of TX should require a much larger node relay fee to ensure it is mined.

<a​rticmine:monero.social> This leads to a spam attack where nodes are flooded with large input TXs the majority of which would not get mined.

<a​rticmine:monero.social> If large input TXs are allowed the best way I see to deal with them is to have a significantly higher minimum node relay fee that would pay the penalty at the threshold. Increasing the weight for these TXs is not a solution and can actually make the problem worse

<j​berman:monero.social> Ya, we could require node relay fees for large input txs and moneromoo did already set that sort of thing up

<a​rticmine:monero.social> I am not in favor of large input TXs by the way

<j​berman:monero.social> to be clear, I'm referring to a node relay fee not included in the tx, but would need to be paid to a node directly in order for the node to accept processing a large input tx

<a​rticmine:monero.social> Keep it simple and pop at the fee to the miner. Why would the miner mine these TXs at a loss?

<b​oog900:monero.social> I'm not even sure fees really help here, someone could create double spends of the same inputs and then got a lot of txs for "free" as they wont ever be mined

<a​rticmine:monero.social> Pay the fee to the miner

<j​berman:monero.social> (and then it becomes a problem on the p2p relay side though)

<b​oog900:monero.social> the maximum you could go is 1 double spend per node

<a​rticmine:monero.social> Why should nodes relay a mass of doubly spends?

<b​oog900:monero.social> if a tx take a while to verify a lot of double spends will cause a DoS with little cost + no banning

<j​berman:monero.social> maybe we layer on pow hashing for submitting/relaying txs lol, pow hash paid for by tx creator

<j​effro256:monero.social> I was thinking the same thing

<a​rticmine:monero.social> No . This discriminates against rho who live in the tropics

<b​oog900:monero.social> I do think that is the only valid solution

<b​oog900:monero.social> fees only count for txs in blocks

<b​oog900:monero.social> even paying fees to transfer only counts if the tx is included in a block

<a​rticmine:monero.social> It is not a solution. Just launch the attack from Canada during the winter A good -40 temperature should do the trick

<a​rticmine:monero.social> POW hashing to send transactions is a terrible idea

<j​effro256:monero.social> The computational cost wouldn't be anywhere close to block difficulty, just enough that it's some multiple >1 of cost to verify an FCMP , and the hash wouldn't be re-usable for mining

<a​rticmine:monero.social> Russia would also work

<b​oog900:monero.social> p2pool has PoW for connections ....

<b​oog900:monero.social> i guess that is mining so it doesn't matter as much

<j​berman:monero.social> tor introduced it ya?

<a​rticmine:monero.social> The computational cost is very dependent on the outside temperature. This kind of thing does not belong in Monero

<j​effro256:monero.social> Doing a PoW-based attack, even in Russia or Canada, where the heating is "free", still costs something because of opportunity cost. If you're expending all this effort, that's CPU time that isn't being used for mining XMR

<a​rticmine:monero.social> One is using CPUs

<b​oog900:monero.social> For non-attackers this cost should be minimal

<a​rticmine:monero.social> Not if you are in the Australian outback during the summer or in India during a heat wave

<j​berman:monero.social> It should be fine even for them

<a​rticmine:monero.social> Your device is already overheating and one forces POW?

<a​rticmine:monero.social> Charge a fee in XMR intead

<a​rticmine:monero.social> Instead

<j​effro256:monero.social> Single-digit seconds of CPU time won't be enough to even warm your hand. By that logic, Monero requiring stealth addresses, and thus 1 ECDH per enote to scan is discriminatory. That takes way more CPU time for honest users

<j​berman:monero.social> 1) I'm betting it's almost certainly going to be less CPU power than scanning the chain, 2) it could only be required for higher input txs

<b​oog900:monero.social> I would bet creating the tx would cost more than the PoW

<s​yntheticbird:monero.social> 2) is an interesting twist

<b​oog900:monero.social> the PoW only has to be more than verification

<j​berman:monero.social> ^

<j​berman:monero.social> ^ in reponse to "I would bet creating the tx would cost more than the PoW"

<a​rticmine:monero.social> Why not simply require a higher fee?

<b​oog900:monero.social> you can't - this only effects txs in blocks

<b​oog900:monero.social> tx-pool txs can be double spent

<j​berman:monero.social> we're discussing nodes processing the txs before they enter their pool

<j​effro256:monero.social> The point is that you can't validate a transaction until after you do. You could require a higher fee, but you can't actually check it w/o expending CPU time for verification

<a​rticmine:monero.social> A node relay fee

<b​oog900:monero.social> ay yes the tx before the tx

<b​oog900:monero.social> which also needs a tx ...

<b​oog900:monero.social> or we paying with fiat?

<j​berman:monero.social> also this

<j​berman:monero.social> would have to pay fees for every relay to every node too

<j​effro256:monero.social> How do you check the node relay fee without verifying a transaction?

<a​rticmine:monero.social> One just increases the node relay fee paid to the miner. This would provide deterrence

<s​yntheticbird:monero.social> no

<a​rticmine:monero.social> One cannot stop invalid transactions with source POW

<s​yntheticbird:monero.social> at least if i wanted to dos the network I wouldn't be deter

<s​yntheticbird:monero.social> (I want to dos the network and this is a confession that im a bad actor acting against monero's interest)

<b​oog900:monero.social> currently ~5k nodes on the network I can double spend an input ~5k times and send a different tx to each node cutting my cost by 5000

<b​oog900:monero.social> no but it adds cost

<b​oog900:monero.social> to make my node do work, you must have to do work

<a​rticmine:monero.social> I can do the work when it is -40 C and make you work at 40 C

<s​yntheticbird:monero.social> *Equal rights for monero p2p agents!*

<j​berman:monero.social> there is a question of if it's enough PoW to even stop the DoS. If this holds, which I believe it does thanks to ec divisors, then the PoW really only max 2x's the cost to the attacker. It would really have to be a more significant PoW to work

<j​effro256:monero.social> The nature of PoW is that it is much easier to verify work than to create work. It wouldn't necessarily be a 1-to-1 cost

<j​berman:monero.social> the PoW could only be required for large input counts though and scale up as input counts increase

<b​oog900:monero.social> If we are talking about getting rewarded for work then yes that would be bad. You have to solve 1 puzzle to send a tx, the puzzle will cost less than creating the tx (probably).

<b​oog900:monero.social> If we are talking about discriminating against attackers then yes you are right.

<j​effro256:monero.social> That doesn't really matter to the verifier. A valid transaction could take 24 hours to create, but the verifier only cares about verification time. It takes 0ms to make a bad elliptic curve divisor

<a​rticmine:monero.social> One of the biggest misconceptions of POW is that people ignore the value or cost or the heat producedi

<j​berman:monero.social> that's true, but point being, it would probably have to be a solidly costing PoW

<b​oog900:monero.social> the goal isn't for someone to be pumping PoW all day to send txs

<b​oog900:monero.social> the tx generation/scanning process will generate more heat

<s​yntheticbird:monero.social> Are there really no distinguishable characteristics that could permit a node to "predict" a margin of computation time it would take ?

<r​ucknium:monero.social> Won't a RandomX PoW requirement (even for high-input txs) entrench RandomX in wallet code? IIRC, there was a suggestion to eventually eliminate all PoW-related code from wallets to reduce malware false positives.

<s​yntheticbird:monero.social> Monero CEO will have to buy the 999k$ Micro(talent)soft approved certificate

<j​berman:monero.social> curious if equix gets flagged too spec.torproject.org/hspow-spec/v1-equix.html

<a​rticmine:monero.social> This is a very valid point. One more reason to keep POW away from wallets

<j​berman:monero.social> we could see how long it would take a reference CPU to construct the PoW and enforce that difficulty

<j​effro256:monero.social> Yes and no. No if, like in the current situation today, all wallets submit transactions to daemons's RPC. Daemons inherently already have RandomX code. It would prevent a hypothetical wallet from existing which submits transactions to the p2p interface of another daemon, *and* doesn't need RandomX code.

<s​yntheticbird:monero.social> lr

<j​berman:monero.social> fwiw I also don't think windows hostile and easily reversible decisions should affect Monero protocol decisions in this regard

<j​effro256:monero.social> But submitting transactions to another's daemon p2p interface directly as a non-daemon is obviously horrible for privacy if not done correctly.

<s​yntheticbird:monero.social> Sorry, I meant for FCMP tx verification

<s​yntheticbird:monero.social> not PoW

<j​berman:monero.social> oh I see, ya! by looking at how many inputs are the proof, the node can predict a margin of computation time it would take

<j​berman:monero.social> to verify

<j​berman:monero.social> sort of

<a​rticmine:monero.social> ... and not relay, or at least delay relay

<j​berman:monero.social> I mean ya for sure. the node could theoretically even verify all input combos on boot and measure timings. I'm sure there's a better way to do it though

<s​yntheticbird:monero.social> There could be a formula for forcing source PoW or other mechanism on (predicted) time consuming txs

<a​rticmine:monero.social> Realistically if large input TXs are an attack vector, which I agree with, can't we just limit this at the protocol level?

<j​effro256:monero.social> Yeah FCMP verification time is more-or-less a constant function of (number of inputs, number of tree layers), both of which are provided explicitly in the transaction.

<j​effro256:monero.social> Yes, but at the cost of not having large input TXs: UX degradation, the time delay that input consolidation brings, and worse liveness / atomicity guarantees for services

<j​effro256:monero.social> If we allow high-input TXs at a consensus level, we can always tack on relay rules or PoW or miner relay fees or whatever else afterwards. But if we reject it at a consensus level, then we would need a hard fork to bring them back

<b​oog900:monero.social> wont txs with multiple FCMPs naturally have PoW built in. The worry is if the last proof is invalid the whole thing has the be thrown away but the person still has to construct multiple valid proofs then they had to put in work

<a​rticmine:monero.social> This is a very valid point. We can restrict or penalize them at node relay

<a​rticmine:monero.social> I am fine with that

<j​berman:monero.social> boog900: this why I'm arguing the PoW should probably be significantly greater than cost to construct the tx for txs with higher n inputs, and should scale by n inputs in the tx

<j​effro256:monero.social> Not if it's an invalid FCMP, then it's basically free to make

<j​effro256:monero.social> The cost should scale, not because of honest construction time, but because of verification time

<j​berman:monero.social> boog is saying the earlier FCMPs packed in would be valid, and then a later one would be invalid

<b​oog900:monero.social> yeah but the argument was that multiple FCMPs was equivalent to a single FCMP if the last is invalid, as they both waste significant work if invalid

<b​oog900:monero.social> but they aren't as you need to put work in for multiple valid FCMPs

<a​rticmine:monero.social> I have a serious concern with POW at the wallet level. Requiring POW to access P2P pool is completely different since the users in that are contributing hash power

<j​effro256:monero.social> Ah yes true, sorry my misunderstanding

<b​oog900:monero.social> here^

<j​effro256:monero.social> Tbf, it wouldn't be at the wallet level, it would be at the daemon level in the p2p protocol

<b​oog900:monero.social> this makes multiple FCMPs per tx equivalent to multiple txs with 1 FCMP, right?

<j​berman:monero.social> I would think it would be at the wallet level too to protect public RPC's

<r​ucknium:monero.social> Why would nodes be the entities creating the PoW? If I am a node, why would I bother creating PoW to relay a tx?

<r​ucknium:monero.social> Relaying anything is actually a favor.

<s​yntheticbird:monero.social> *You will thanks me for relaying your transaction and you will be happy*

<j​effro256:monero.social> Because either A) it's your node and your wallet and you want the tx relayed, B) your node, and users you care about, or C) you're running a public RPC node

<j​effro256:monero.social> The point of public RPC is that it's a public service

<s​yntheticbird:monero.social> or better

<j​berman:monero.social> "this makes multiple FCMPs per tx equivalent to multiple txs with 1 FCMP, right?" -> sorry I'm not following fully following the thread of your argument here. can you rephrase?

<s​yntheticbird:monero.social> We allow both mode. If node allows it you can request it to generate the PoW. Otherwise the node can say "nah sorry not to day, please do it yourself"

<a​rticmine:monero.social> Very good point

<j​berman:monero.social> We probably expect public RPC's to reasonably exist and don't want public RPC's to be exposed to a dos vector, so I think it would make sense that wallets would construct the PoW in the first place

<b​oog900:monero.social> The problem was multiple FCMPs in a tx allows for someone to use up a lot of CPU if all the FCMPs are valid except the last. Which is the same as 1 big FCMP in cost to the node.

<b​oog900:monero.social> This is different than splitting the tx into multiple different ones with 1 FCMP each as the valid ones will still be added to the pool, therefor are not a waste.

<b​oog900:monero.social> However the multiple FCMPs per tx still have a significant cost adding a pseudo-PoW meaning it isn't the same as 1 big FCMP. Also individual txs can be double spent still wasting work.

<b​oog900:monero.social> My argument is that we should allow multiple FCMPs per tx as there is no difference.

<s​yntheticbird:monero.social> if PoW for relay is introduced I would like it the update to be called FCMP++/Carrot/POWER. because PoW Enabled Relaying.

<s​yntheticbird:monero.social> do i welcome any more creative naming

<s​yntheticbird:monero.social> tho*

<j​effro256:monero.social> I'm not against public RPC operators choosing to block/allow any traffic that they see fit since it's by definition a public service and they're paying for their own server / own internet hookup. But you're inherently opening yourself up to DoS vectors that don't exist if you don't turn on public RPC, so I don't see why it wouldn't be an option

<j​berman:monero.social> "My argument is that we should allow multiple FCMPs per tx as there is no difference." -> Not in place of PoW, ya? But as a separate (but related) point?

<b​oog900:monero.social> yeah I am saying PoW or not having multiple FCMPs per tx is no worse than multiple txs

<j​berman:monero.social> Ya I think that is a reasonable point

<j​effro256:monero.social> They only difference I can think of rn is that in between each "checkpoint", or smallest meaningful indivisible unit of computation, if the transaction with 1 FCMP succeeds, someone somewhere is paying a transaction fee. Whereas with a transaction with N FCMPs succeeds and N-1 verify, but the last fails, then no-one pays a tx fee

<j​berman:monero.social> Well wait no, I understand. Let's just assume no PoW for now

<j​berman:monero.social> The node gets stuck processing a large bad tx that the node would not use. Yes, the client has done work to construct this bad tx, but that work is wasted work compared to having constructed a complete valid tx.

<j​berman:monero.social> That would be categorically worse than node getting stuck for 10x less time processing a bad tx

<j​berman:monero.social> "Also individual txs can be double spent still wasting work" -> w/current policy, nodes can just quickly reject a key image it has already seen, no? Not following how that is consequential here

<j​berman:monero.social> I can (I think) see the argument that with PoW, it still makes sense to have multiple FCMPs per tx

<j​berman:monero.social> (Going to have to step away in a sec and come back unfortunately)

<b​oog900:monero.social> > w/current policy, nodes can just quickly reject a key image it has already seen, no? Not following how that is consequential here

<b​oog900:monero.social> Yeah I thought double spending was checked after the input checks but looking at the code it is checked first, non-input checks like bulletproofs are still checked before the double spend check tho my bad.

<b​oog900:monero.social> and yeah it could've just been changed if it was

<j​berman:monero.social> np, I actually didn't remember if it is or not, but was just making a point that it could be

<b​oog900:monero.social> I do remember bringing that up now as a way to find out if a node has a stem tx or not ...

<b​oog900:monero.social> literally unfixable though without introducing this DoS

<j​berman:monero.social> tevador explains relevant rationale here for why equix over randomx in tor: github.com/tevador/equix/blob/master/devlog.md

<j​berman:monero.social> TL;DR faster verification to prevent flooding attacks, and high memory requirement

<j​berman:monero.social> Worth thinking it through in our case. Probably don't want to impose too strict of memory requirements on clients, though our allowed verification time could potentially be significantly higher if we don't impose PoW relay reqs on lower input txs

<j​berman:monero.social> So maybe the low memory RandomX variant could make sense in our use case

<r​ucknium:monero.social> jberman: This is the issue I referred to previosuly: monero-project/monero #8827

<r​ucknium:monero.social> > Better security for wallets using untrusted remote nodes. Malicious remote nodes can feed wallets fake blockchain data. With this proposal, wallets could partially verify the integrity of the blocks received from untrusted remote nodes with the cost of a few hashes.

<j​berman:monero.social> gotcha thank you

<j​berman:monero.social> this seems relatively simple to include in next fork

<j​berman:monero.social> and to answer your q "Is this related to the issue that tevador found in the current PoW?" -> checking PoW on block headers is related to including the tree root yep. That idea by tevador would speed up the PoW verification / benefit the approach

<j​berman:monero.social> @sech1 @selsta do you know if anyone has started working on bringing that change into monero for next fork? we can add it to the list of TODO's if not

sech1 knows best the current status

tevador was working on it but he's not active anymore

He actually did submit it tevador/RandomX #265

It's just RandomX V2 which is not finished yet (RISC-V code is missing for it)

<j​berman:monero.social> got it ya, so looks like it's just a matter of implementing that specific change in the monero repo

<j​berman:monero.social> / integrating that PR

<j​berman:monero.social> *thumbs up* good bump rucknium

<j​berman:monero.social> I hope tevador is alright

<r​ucknium:monero.social> That's one reason we have regular meetings. To discuss current work plans to make sure possible synergies aren't missed :)

<k​ayabanerve:matrix.org> Rucknium: bytes can decrease upon an increase in inputs. It still trends upwards.

<k​ayabanerve:matrix.org> jeffro256: Batch verification of four small FCMPs is faster than verification of one large FCMP, even on a single core.

<j​berman:monero.social> One thing worth mentioning: if the PoW puzzle also hashes a ref to the latest block in addition to the tx, it removes the attacker's ability to slowly accumulate many bad txs + PoW solutions over a long period of time

<j​berman:monero.social> (could also expand the window to be n blocks in case the chain advances after constructing)