<j​berman:monero.social> Commented my rationale supporting both FCMP++ research proposals in advance of tomorrow's MRL meeting: monero-project/meta #1119#issuecomment-2516057549

Brandon Goodell's GBP security review cc jberman kayabanerve repo.getmonero.org/monero-project/c…als/-/merge_requests/449#note_27508

<r​ucknium:monero.social> MRL meeting in this room in one and half hours.

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

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

<j​effro256:monero.social> Howdy

<a​rticmine:monero.social> Hi

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

Hello

<v​tnerd:monero.social> hi

<c​haser:monero.social> hello

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

<v​tnerd:monero.social> I’ve got to fix a functional test in my monerod patches, its a pain tracking it down for some reason

<r​ucknium:monero.social> me: Suggested spy node ban list community communication plan: gist.github.com/Rucknium/76edd249c363b9ecf2517db4fab42e88 boog900 . HackerOne report.

<j​effro256:monero.social> Me: testing and improving the Carrot code

<j​berman:monero.social> me: wrapping up FCMP++ wallet sync starting from arbitrary restore height (it's working as expected), then planning to move over to FCMP++ proof construction over the FFI

<o​frnxmr:monero.social> Not me, but i hope that those MAX_INPUT tests check 64+ inputs

<j​berman:monero.social> I also commented my +1 on Gooddell's GPB review linked above by @plowsof, and provided more detailed rationale in support of moving forward with Cypher Stack to review Veridise's work on logarithmic derivatives in divisors, and to move forward with Veridise on R1CS proving

Thanks jberman

<r​ucknium:monero.social> 3) Carrot audit/review: github.com/cypherstack/carrot-audit…ses/download/final/Carrot-final.pdf

<r​ucknium:monero.social> jeffro256: Could you give a summary and maybe TODO list that came out of this audit/review?

<j​effro256:monero.social> The review went well with no real crypto issues , I just need to clarify some portions of the spec

<j​effro256:monero.social> Also there were a couple typos

<j​effro256:monero.social> But overall I'm happy with how it went

<j​effro256:monero.social> One change that Kayaba brought up that would actually change the crypto is doing switch commitments

<r​ucknium:monero.social> Doesn't that require a lot of post-quantum R&D?

<j​effro256:monero.social> Not really if we're scoping it to just commitments they're pretty well understood

<j​effro256:monero.social> The hard part is getting some PQ security out of the onetime outputs and key images

<j​effro256:monero.social> But that part can be done later

What would that type of commitments improve?

<j​effro256:monero.social> Amount commitment blinding factors are transmitted as part of the sender-receiver protocol and thus need to be decided beforehand

<j​effro256:monero.social> Rbrunner: A switch commitment allows for a commitment to be perfectly blinding and computationally binding until it "switches" to perfectly binding

<j​effro256:monero.social> Well not really "perfectly", but still computationally binding against a quantum computer

So they would be a step towards future PQ security?

<j​effro256:monero.social> In higher level terms, it let's us set up a PQ-secure turnstile in the future

And using those would not invalidate the audit results just obtained?

<c​haser:monero.social> we'd basically get post-quantum monetary soundness in exchange for losing confidentiality

<r​ucknium:monero.social> Would it be a true turnstile or just a future prohibition on spending outputs that do not have the switch commitments, i.e. outputs produced before switch commitments were available?

<j​effro256:monero.social> I think they would basically be a very small-scoped swap of one part of the derivation, so we would need to revalidate just that small bit of the derivation , but nothing else

<j​effro256:monero.social> Well it wouldn't lose confidentially unless actively "switched". We wouldn't retroactively lose confidentially for enotes spent before the turnstile

<c​haser:monero.social> yes, this is to mean what comes after the hypothetical fork that flips the switch

<j​effro256:monero.social> It depends on the implementation, but old outputs do not use switch commitments so there wouldn't be any way to prove a quantum computer didn't open its commitment to an arbitrary value so those probably wouldn't be allowed

<j​effro256:monero.social> Proving ownership PQ-securely will be a lot harder , but that is specific to how the wallet derives its addresses , but doesn't need to be a part of the addressing protocol

<j​effro256:monero.social> (At the moment)

<j​effro256:monero.social> Switch commitments *do* though, unless we were to transmit the entire blinding factor encrypted to the receiver (which RingCT did do at one point)

<j​effro256:monero.social> However, this costs an extra 32 bytes per enote

<r​ucknium:monero.social> Ok. This is a big decision, so maybe we can think about it and come back next meeting to discuss more.

<r​ucknium:monero.social> 4) Security Review - Generalized Bulletproofs. Brandon Goodell's comments. repo.getmonero.org/-/project/54/upl…ef138126850/GBP_Security_Review.pdf repo.getmonero.org/monero-project/c…als/-/merge_requests/449#note_27508

<r​ucknium:monero.social> jberman: What is the "tightness gaps" you mentioned?

<r​ucknium:monero.social> As far as I can tell, everything came out fine in the GBP review.

<j​berman:monero.social> From section 4.1: "security proofs do not merely establish

<j​berman:monero.social> security. The proof itself contains a description of a reduction from one problem to

<j​berman:monero.social> another, and the details of that reduction lead to a tightness gap in security. Both

<j​berman:monero.social> [3] and [7] neglect analysis of tightness. This is a usual practice and up to

<j​berman:monero.social> industry standards."

<r​ucknium:monero.social> Does "reduction from one problem to another" mean that it has been proven that P ⇔ Q? That statements P and Q are equivalent?

<r​ucknium:monero.social> The "tightness gap" makes me think that they are not proven exactly equivalent.

<r​ucknium:monero.social> Anyway, maybe this is something I need to educate myself on. Goodell says that GBP is proven OK up to industry standards.

<r​ucknium:monero.social> Any more comments on this?

Are they already implemented for Monero, those GBPs?

<j​berman:monero.social> I don't know if that question is directly relevant/exactly how it relates. From the conclusion which migh help provide more color: "The tightness gaps implied by the security proofs of [7] imply a lower bound on

<j​berman:monero.social> scheme security, and this bound weakens with each transcript rewinding. Ensuring

<j​berman:monero.social> this lower bound exceeds cryptographic security is a conservative way to select

<j​berman:monero.social> system parameters for future system designers. It would be nice that [7] be modified

<j​berman:monero.social> to mention and compute tightness gaps. Due to this, security theorem statements

<j​berman:monero.social> are most useful when stated like this: If there exists an algorithm A which runs in

<j​berman:monero.social> time at most tA and breaks one of the security properties of scheme S with success

<j​berman:monero.social> probability at least ϵA, then there exists an algorithm B which runs in time at most

<j​berman:monero.social> tB and solves a famously hard problem P with success probability at least ϵB"

<r​ucknium:monero.social> This is sort of about the total bits of security of Monero txs, maybe

<j​berman:monero.social> GBPs are "generalized bulletproofs" and are a core component of FCMP++. Kayaba implemented GBPs in his work on FCMP++

Nice

<r​ucknium:monero.social> 5) Proposed Cypher Stack review of "On the Use of Logarithmic Derivatives in Eagen’s Proof of Sums of Points". gist.github.com/kayabaNerve/6173fa623ac0f6a9cd4269c16f3ffd48

<r​ucknium:monero.social> The review sounds good to me. Thanks for the write-up, kayabanerve

<j​berman:monero.social> It does seem relevant in that the choice of bit-security may be affected by the tigtness gap (i.e. a "tighter" gap seems to imply a wider window for certain classes of attacks, rendering a higher bit security unnecessary? I'm may be reading that portion incorrectly)

Yes, those gists are valuable to keep the (at least for me) much welcome overview

<j​berman:monero.social> sorry, rending a higher bit security more necessary*

That proposed review seems good to me also

<j​berman:monero.social> Nice :)

<j​berman:monero.social> Reiterating +1 from me too

<r​ucknium:monero.social> Anyone else have comments on Proposed Cypher Stack review of "On the Use of Logarithmic Derivatives in Eagen’s Proof of Sums of Points"?

Does Monero help here to push forward the state of the art of crypocurrencies in general?

<j​berman:monero.social> AFAIK Monero seems to be the most widely used application of BPs, so it would certainly make sense for Monero to push forward research into attacks / security hardening for BPs

Interesting.

<r​ucknium:monero.social> I see loose consensus here in favor of Cypher Stack review of "On the Use of Logarithmic Derivatives in Eagen’s Proof of Sums of Points". gist.github.com/kayabaNerve/6173fa623ac0f6a9cd4269c16f3ffd48

<r​ucknium:monero.social> Or maybe jeffro wants to say something

<r​ucknium:monero.social> Maybe not. Let's move on.

<r​ucknium:monero.social> 6) Veridise proposed work: Formal definition of an interactive protocol and verifying the R1CS defined in the FCMP++ paper aligns. gist.github.com/kayabaNerve/175a00de6edd3a64458dacb4f5e481e0

<r​ucknium:monero.social> Seems good to me

<j​berman:monero.social> +1

Yes, thankfully looks good, because we need those R1CSs - whatever they are :)

<c​haser:monero.social> rbrunner: this is a good primer: learn.0xparc.org/materials/circom/a…what-is-r1cs-and-how-does-it-fit-in

Thanks, looks pretty wild :)

<c​haser:monero.social> it is :)

<j​effro256:monero.social> Sorry, reviewing other people's review on zk proofs is a bit over my head ;)

<j​effro256:monero.social> Hopefully someday it won't be

<r​ucknium:monero.social> Do we have loose consensus here in favor of this proposed work by Veridise?

+1

<c​haser:monero.social> I find the forest of proofs and reviews a bit hard to navigate, that flow chart discussed last week would definitely help :) but I have no objection either.

<j​effro256:monero.social> With limited information , I say +1

<j​berman:monero.social> I've been working on this spread sheet: cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed

<c​haser:monero.social> jberman this is awesome. thank you. additional respect for using CryptPad.

Quite a number of lines towards the end, but those are mostly or even all code audits, right?

<j​berman:monero.social> :)

<j​berman:monero.social> Almost all code audits except "Gadgets formal verification"

Thus quite straightforward

<r​ucknium:monero.social> I see loose consensus in favor of Veridise proposed work: Formal definition of an interactive protocol and verifying the R1CS defined in the FCMP++ paper aligns. gist.github.com/kayabaNerve/175a00de6edd3a64458dacb4f5e481e0

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

So with those "gadgets" the "crypto" will be complete.

<r​ucknium:monero.social> I wrote a draft post to urge node operators to enable boog900 's ban list: gist.github.com/Rucknium/76edd249c363b9ecf2517db4fab42e88

<r​ucknium:monero.social> Note that the draft says "The Monero Research Lab (MRL) has decided to recommend that all Monero node operators enable a ban list of suspected spy node IP addresses."

<j​berman:monero.social> @rbrunner yep, we're approaching the finish line for theoretical vetting of FCMP++

<r​ucknium:monero.social> Is that accurate? Does MRL make that recommendation? Discuss.

Seems to me evidence is good enough, and potential harm big enough, to indeed speak out such a recommendation. We don't go overboard here, if you ask me.

<r​ucknium:monero.social> I hope this can be released in a week or so. It would also need some Monero devs and researchers to PGP-sign the ban list and to ask SethForPrivacy to add the ban list to his monerod Docker template.

<r​ucknium:monero.social> Anyone should feel free to suggest edits by making a comment on the gist

"MRL has decided to ask node operators to block these IP addresses voluntarily instead of by default." For what it's worth, that seems important to me.

<c​haser:monero.social> IMHO looks sane, and the best that can be done to mitigate the problem at present.

<j​effro256:monero.social> Do you have a deterministic method / piece of code that can re-find these proxies, and would you be willing to do a semi-closed source release to those who you want to the sign the banlist ?

<r​ucknium:monero.social> rbrunner: Should I put that higher in the post?

<r​ucknium:monero.social> jeffro256: That is a question for boog900

Seems like a good finishing sentence to me. That's a good spot IMHO

<b​oog900:monero.social> Yes I'll PM you

<j​effro256:monero.social> I understand that the methodology should remain semi-private since we don't want the adversary to adapt their methods, but I personally would like to know why I would be signing a banlist, even if I don't release the details to the public

Makes sense.

<j​berman:monero.social> Speaking just for myself I don't personally want to take an explicit role in advocating for banning specific IP's. The approach seems reasonable generally to me though

<j​berman:monero.social> I also haven't gotten the chance to dig deeper into @boog900 's findings, but it passes my initial smell test. Would encourage anyone who wants to dig deeper / sign off to PM @boog900 as well

<s​yntheticbird:monero.social> now is the time to give each people a different method so that if one is patched we know who is the maul

<j​effro256:monero.social> One legit use case for a proxy node tho that jberman brought up was running a node at home but not revealing to the world where your home is

<b​oog900:monero.social> These nodes do not proxy all messages they handle handshakes themselves

Well, we don't have something against the occassional single proxy node, right?

Just to whole packs of them ...

<b​oog900:monero.social> Or intercept and insert their own data

<a​rticmine:monero.social> This may be related to the video I reviewed on MoneroTopia

<r​ucknium:monero.social> The Chainalysis one? It might

<a​rticmine:monero.social> Yes that one

<a​rticmine:monero.social> The idea there was to trick unsuspecting wallets to connect to the spy none in order to collect the wallet IPs

<a​rticmine:monero.social> Node

<r​ucknium:monero.social> Boog900's findings are more about the P2P network privacy. IIRC the Chainalysis representative complained that Dandelion++ made their job harder. Maybe they are trying to have a strategy to weaken D++

<a​rticmine:monero.social> Yes I understand, weaken D++ by collecting wallet IPs

<a​rticmine:monero.social> My concern here is that a BS company does not change to use proxy IPs to do this

<c​haser:monero.social> they can definitely weaken the effects of D++ by running loads of spy nodes, can't they?

<a​rticmine:monero.social> Have to use

<j​berman:monero.social> IIRC Chainanal was running malicious nodes hosted at community trusted domains that had prior expired and Chainanl picked up the domains. So it wasn't that they were running proxies on tons of IP's, rather that they controlled community trusted domains

<r​ucknium:monero.social> chaser: Yes

<j​berman:monero.social> Whereas the discussion here is relevant to running tons of spy proxy nodes across many different IP's, which Chainanal may also be doing, but it's not known who's doing that AFAIK

<a​rticmine:monero.social> Yes they can., but detecting proxy nodes does not address this

<r​ucknium:monero.social> chaser: The effect of the suspected spy nodes on the privacy provided by D++ is estimated here under "Empirical privacy impact": monero-project/research-lab #126#issuecomment-2460261864

<p​reland:monero.social> Making sure I remember this correctly: if you use your own node for transactions, this makes the Chainalysis attack not an issue for you, correct?

<r​ucknium:monero.social> preland: The _remote node_ attack would not affect you, but your own node could still be connecting to peer spy nodes, which weakens D++. To avoid connecting to them, run the ban list.

<j​berman:monero.social> ^+1

<o​frnxmr:monero.social> tx-proxy

<b​oog900:monero.social> I think Chainalysis were black-holing txs, if you look at the video by the IP addresses in observations there are small symbols, sadly he never hovered over any long enough for the help text to pop up with a description of what they mean, at least I didn't see it.

<b​oog900:monero.social> The 4 symbols I have seen are: a speaker, cross, 3 lines, question mark.

<b​oog900:monero.social> The only one I have a little bit of confidence on is the 3 lines, I think it means stem, like the tx was sent in a stem message. At 32:00 if you look at all outputs with IPs with that symbol the time till it was seen a second time is extremely high, it makes me think these txs were blackholed.

<a​rticmine:monero.social> I believe the real issue is the behavior of the proxy node as opposed to the node being a peproxy

<o​frnxmr:monero.social> anonymous-inbound

<j​berman:monero.social> +1 to @ofrnxmr 's point also. Using tor/i2p via tx-proxy is another way to avoid a spy proxy node from correlating your node's IP to your txs

<o​frnxmr:monero.social> NAT nodes are easier to blackhole, because you cant connect to them 🙃. Using anonymous-inbound and tx-proxy throw in variables that make it a guessing game

<r​ucknium:monero.social> Yes, but there is an unresolved issue with the real IP address of a Monero node onion service being discovered. I can't link to it right now since moneroresaerch.info is giving an error 😬

<a​rticmine:monero.social> So we have nodes that accept wallets. Connections but do not open outbound connections

<o​frnxmr:monero.social> When you relay via tx-proxy, it doesnt share your onion address

<o​frnxmr:monero.social> So even if you associate me ip to onion (my onion starts with ofrnxmr btw), you dont know my tx-proxy's txes

<b​oog900:monero.social> your node will insert it at the end of a peer list message IIRC

<o​frnxmr:monero.social> At the end ? 💀

<r​ucknium:monero.social> Here it is: Shi et al. (2024) "Deanonymizing Transactions Originating from Monero Tor Hidden Service Nodes" dl.acm.org/doi/abs/10.1145/3589335.3651487

<a​rticmine:monero.social> Can we focus on the node behaviour itself as opposed to whether it is behind a proxy?

<o​frnxmr:monero.social> Sounds like unintended behaviors. Whats the point of hiding the addr$ss via "unknown tor host", if the host is known via being the last onion on the peerlist 🥲

<o​frnxmr:monero.social> Artic, are you asking about the spy node behavior?

<a​rticmine:monero.social> Yea

<v​tnerd:monero.social> yikes, I really botched that then.

<a​rticmine:monero.social> Yea

<a​rticmine:monero.social> Yes

<v​tnerd:monero.social> knowing the hidden service doesn’t automatically get you the IP address, at least, but some Tor node knows the correlation

<r​ucknium:monero.social> ArticMine: Ideally, a Monero node should be able to determine if its peer is a single node or if it is part of a network of proxied nodes. The network of proxied nodes means that the spy node operator pays a lower cost in storage, RAM, and CPU.

<v​tnerd:monero.social> this should’ve been an a GI Issue; I don’t recall seeing it before

<v​tnerd:monero.social> another point - if you use —tx-proxy without —anonmous-inbound you get the privacy back, but aren’t helping the network of relays

<r​ucknium:monero.social> There's a paper about how to check if something is a real single node or not, but requires a lot of protocol changes, found by boog900 : JHeo, Ramachandran, and Jurdak (2023) "PPoS : Practical Proof of Storage for Blockchain Full Nodes" ieeexplore.ieee.org/document/10174897

<v​tnerd:monero.social> we can randomize the list, but there’s a timestamp too that could be problematic

<r​ucknium:monero.social> Do we want to discuss `MAX_INPUTS`/`MAX_OUTPUTS` again or do we want to end the meeting here and postpone that discussion until we get more CPU benchmarks?

<j​effro256:monero.social> The latter IMO

<a​rticmine:monero.social> Yes but the real issue here is the spying. I just don't see the deterrence in just detecting proxies

<a​rticmine:monero.social> I mean the BS company will just pass the additional cost to government

<j​effro256:monero.social> if you can detect proxies, then you can ban them from D++ stems

<r​ucknium:monero.social> AFAIK, the only deterrence that D++ has is to make it economically costly for an adversary to spy. It's a permissionless network after all.

<r​ucknium:monero.social> This is the end of the meeting. We can continue discussing P2P network privacy, of course :)

<c​haser:monero.social> mitigating that would probably require a different network-layer mixing method

<c​haser:monero.social> and potentially non-trivial PoW for participation

<j​berman:monero.social> @vtnerd here's the relevant code for sending a node's IP to outgoing connections at the end of the peerlist: github.com/monero-project/monero/bl…2a/src/p2p/net_node.inl#L2475-L2501

<r​ucknium:monero.social> chaser: I would agree. The Dandelion++ protocol limits the spying effectiveness to roughly the theoretical minimum. The theoretical minimum is a function of the share of spy nodes on the network.

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

<j​berman:monero.social> @moneromoo brought up this exact issue on my PR and I completely forgot to look into it more :/ monero-project/monero #8324#issuecomment-1125108872

<r​ucknium:monero.social> I summarize the D++ protocol's resistance to spy nodes in the GitHub issue I linked above.

<r​ucknium:monero.social> monero-project/research-lab #126#issuecomment-2460261864

<r​ucknium:monero.social> If an adversary has enough malicious nodes, he/she can also try to launch eclipse and network partitioning attacks, which are distinct from spying.

<v​tnerd:monero.social> @jberman yes, I know what needs to be fixed, just a little disappointed I missed this first time

<s​yntheticbird:monero.social> he/she? Artificial intelligence don't have gender

<v​tnerd:monero.social> oh wow, just read that moo comment. a shame this wasn’t fixed earlier

<o​frnxmr:monero.social> For any spy's that kept logs: i was joking. my onion doesnt start with "ofrnxmr" 🫠

<a​rticmine:monero.social> From issue 126 the outbound connection behavior combined with accepting wallet connections are characteristic of the malicious nodes

<a​rticmine:monero.social> I mean the proxy approach is reasonable as long as it does not inadvertently target legitimate proxy use for privacy purposes

<a​rticmine:monero.social> In any case a back and forth between the community and the adversary on this could easily set up the adversary for a significant legal failure here in Canada over privacy law violations

<r​ucknium:monero.social> moneroresearch.info is back up. It was the runaway mysql log issue again.

<0​xfffc:monero.social> Apologies everyone. I totally forgot/missed this meeting.

<0​xfffc:monero.social> Anyway, my update was mostly working on general wallet-rpc issues. #9601 and other small fixes. ( although small, but should introduce good speed up in many cases )

<0​xfffc:monero.social> I read the discussion. I have a question about blackhole nodes. What is the wallet response? I am a wallet. I send a transaction. My transaction gets blackholed on its way ( and never gets to fluff ). What do I do? wait and resend to same node?

<0​xfffc:monero.social> Because IIUC, blackholing is going to introduce another security issue. If I have 20% of nodes as spy node, I set the rule to blackhole any transaction unless you get it from the wallet. Then my surveillance capability is going to get a boost.

<0​xfffc:monero.social> Scenario 1:

<0​xfffc:monero.social> Wallet generates tx -> node 1 -(stem)- > node 2 (blackhole).

<0​xfffc:monero.social> Wallet waits x seconds.

<0​xfffc:monero.social> Wallet generates tx again, changes the node -> node 2 ( now this node has more information ), and passes the transaction.

<r​ucknium:monero.social> In scenario 1, the honest `node 1` will broadcast the tx in fluff mode after the embargo timeout fires, so it still gets spread through the network without the wallet user doing anything.

<0​xfffc:monero.social> oh thanks. now it made sense. I forgot that all the nodes (on stem path) do the fluff after few seconds. So not big of a deal.

<r​ucknium:monero.social> Still, IMHO, the black-holing node 2 gets some info from this. Because ordinarily node 2 doesn't know that the immediately preceding node in the stem was the actual origin.

<r​ucknium:monero.social> But if node 2 black-holes the tx, then they can run a statistical model about how many nodes may have participated in the stem phase (because with more nodes participating in the stem phase, the first timeout will be reached sooner).

<0​xfffc:monero.social> Yes. it basically breaks the very purpose of stem. But still not as bad as I thought for a moment.

<0​xfffc:monero.social> The interesting case is when you have X % of nodes on the network. ( Let's say 30% of the nodes on the network are spy node and doing blackholing. That is the interesting case to think about ).

<0​xfffc:monero.social> For example. Let's think my scenario 1. If node 2 is blackholing. and after embargo timeout node 1 will fluff. Then considering you are running 30% of the nodes on the network. There is chance you know which nodes that tx is originated from.

<b​oog900:monero.social> between all the stems that got the tx before it was blackholed the one to fluff should be random

<b​oog900:monero.social> so ideally you shouldn't know if the one to fluff was the initiator

<r​ucknium:monero.social> I'm not completely sure about this, but I think there's an impossibility proposition here. You can either:

<r​ucknium:monero.social> (1) Set embargo timers so that which node is first to broadcast does not give much information about the true origin node, but how many nodes participated in the stem phase can be estimated by maximum likelihood estimation of how many `n` i.i.d. random variables are in `y = min{x_1, x_2,...,x_n}` where `y` is the actual observed time of the fluff broadcast. This timer could be hig<clipped message

<r​ucknium:monero.social> h-variance/mean exponential, for example. Or

<r​ucknium:monero.social> (2) Set embargo timers so that which node is first to broadcast does give information about the true origin node, but how many nodes participated in the stem phase is hard to estimate. This timer would be a low-variance random variable or even a fixed constant.

<r​ucknium:monero.social> But you cannot get the best of both worlds of (1) and (2).

<r​ucknium:monero.social> Of course, in case (1) if you estimate that only a single node participated in the stem phase, then you would guess which node was the actual tx originator.

<a​rticmine:monero.social> The point of this BS attack is to get the IP address of the wallet and correllate it to the public TX information. This effectively bypasses D++. entirely.

<a​rticmine:monero.social> I am thinking in another direction entirely. Instead of blacklisting the malicious nodes to other nodes, blacklist the malicious nodes to the wallets.

<a​rticmine:monero.social> We create a blacklist of "suspicious" nodes and wallets following the blacklist will not connect to the "suspicions" nodes.

<a​rticmine:monero.social> We will have to be careful here in that those signing the blacklist should be in jurisdictions with strong anti SLAPP laws.

<b​oog900:monero.social> these are P2P nodes, they are (presumably) trying to find the IP of the first node in the stem route, the origin node. D++ is only used for P2P, not by wallets, currently at least. They don't announce RPC ports for wallets to use, although some do have active RPC servers.

<a​rticmine:monero.social> What we are doing here is giving the BS companies their own medicine back

<a​rticmine:monero.social> ... and Chainalysis has used any SLAPP in New York in their defense

<a​rticmine:monero.social> anti SLAPP