Super Testnet on Nostr: ...

quoting nevent1q…u5ez

> you expose a profound misunderstanding of how stealth addresses and ring signatures actually work

I look forward to examining why you think that in the rest of this post

> Referencing a past output in a ring signature as a decoy is standard mixin behavior (it is not key reuse)

It is an unnecessary data leak that monero puts on a permanent, transparent ledger, and it gets people arrested, because chainalysis collects and analyzes that data. Moreover, it is key reuse: the key was used once when the recipient received money and a second time when he spent it. It sounds like you have a very narrow definition of what counts as "use" and are mad that I'm using a more reasonable definition. Let me ask you directly: is a key used when a person receives money? Is it used when they spend money? Are those two different times? I look forward to your answers.

> The Chainalysis examples you continually cite do not represent cryptographic vulnerabilities or blockchain leaks

They absolutely do. Chainalysis relies on the data they gather from the blockchain to help the police arrest their targets, and that data includes the ring signatures, the output keys, and the fee data. That data is leaked to a transparent, permanent ledger by protocol design, and some of it has already resulted in several arrests, as cited in the case studies pointed out here: https://supertestnet.github.io/monero-privacy-leaks/

Saying "the tracers *also* use *out-of-band* data when they can get it" does not change the fact that they rely on on-chain data too, and that data is needlessly leaked to a transparent, permanent ledger, which makes tracing much easier for them.

> Monero blockchain itself has never leaked spend histories

Lol, your dam has a thousand holes and you point to the one place that hasn't broken yet and say "but THAT part's still intact! Stop pointing out all the places where water is getting through and drowning people! Focus on the stones still in place!" It's a ridiculous, denialist approach.

> conflating out-of-band operational security blunders with cryptographic protocol failure is pure intellectual dishonesty

That's not what I'm doing. Users often do make opsec blunders. Often, that happens several txs down the trail, and the tracers only find the txs where the user made the blunder by tracing their monero txs several steps down until they find an opsec mistake.

This happened in the Columbian drug dealer case, and you can watch their video breakdown of the trace by clicking the link on my website. Here's a text breakdown for you.

At timestamp 34:03, they begin their trace with tx0: febcf2df049586a5b8c55e17f7627ce3751d19976f9f0c07dccd4836dbd7f3d1 -- where the target received money into monero in output 1.

Then, at timestamp 34:54, they analyze a follow-up tx, tx1: e4f525b214ef7310b53dd2e81be42801c7ee1a7c259ac0a093d813b493a788a8 -- where the target sent money received in tx0 into output 1.

Then, at timestamp 36:36, they analyze a follow-up tx, tx2: a5202cb022921d624d0e9a40a9d7e0cdc4d9cfeb0be11501414fe5a9c0cdd2a8 -- where the target sent money received in tx1 to output0.

Then, still at 36:36, they analyze a follow-up tx, tx3: bd39f43a8d5bee47feff2f22792977d0a4d3972ee0e4b2718b6208f1a6380d0d -- which is the step where the target leaked his ip address when he sent the money received in tx2 into another output without using a VPN. He broadcasted tx3 through a node that Chainalysis got data from. Chainalysis thus learned his ip address, and found him.

You may decide to focus blame entirely on the opsec mistake he made at tx3, where he leaked his ip address. But you ignore tx0, tx1, and tx2, where they collected and followed the data leaked by the monero blockchain itself, in order to trace the money *to* tx3 and associate it with their target. In reality, the blame lies in both places: monero shouldn't have leaked that data (it should work more like LN) *and* the target shouldn't have leaked his ip address while broadcasting tx3. But your denialism is ridiculous: it is not true that the only thing at fault here was the ip leak. They never would have found tx3 where he leaked that data if they couldn't trace the money through tx0, tx1, and tx2 first.

> your attempts to dismiss FCMP++ by comparing it to Lightning's Sphinx routing are equally nonsensical

I don't try to dismiss FCMP. I think it's a significant improvement. It's just not as good as what we're already doing in lightning. The person who claims they will win the silver prize in the future is not dismissed just because someone else already won the gold prize. Silver and gold are both good. But your future silver prize is currently theoretical, may never happen, and is not as good.

> FCMP...expand[s] the anonymity set from 16 to the entire cumulative history of outputs... Lightning's onion routing offers nowhere near this level of privacy

It does. Lightning's packets are encrypted blobs that could contain *any* information. One payment packet is indistinguishable from another, in such a way that *any* wallet could have created it, even one spun up ten minutes ago and which is never used again. That anonymity set is at least as large as the one FCMP extends to. LN's anonymity set is, in fact, an infinite set, because the set of wallets that could have made any given payment packet includes all wallets that might exist for only the space of a few minutes just to make that packet, and that number is infinite. Monero’s anonymity set is currently 16 by comparison, and after FCMP (if it ever comes) it will still be a finite number, though in the millions, and thus really good (like silver compared to gold).

> While Sphinx encrypts routing hops, intermediate nodes along a payment path must know the exact HTLC amount and CLTV expiry passing through their channel in order to update local channel commitment transactions. Claiming intermediate routing nodes don't know the routed amount is factually false.

They do not know the "total" amount because of multipath payments

> Even with Multi-Path Payments, large routing hubs holding massive network liquidity can trivially perform timing, flow, and volume correlation analysis

You neglected several important "ifs": if the money doesn't flow through them, they don't get to analyze it; if only part of it flows through them, they don't learn the full amount; even if the full amount *does* flow through them, they cannot know that; they also don't know if the next node or nodes on the route are the recipient or not; and the person trying to trace the payment may not know who all to ask, and the ones he does ask may have a variety of privacy policies and refuse to answer. In lightning, not even the sender knows the ultimate destination node, let alone the routing nodes. This is much better than monero. Monero needlessly gives the sender a proof of which key belongs to the recipient as well as a proof of the amount received by that key in that tx, and it leaks fee data, input data, and output data to a permanent ledger along the way.

> framing the fact that a sender knows how much they sent to a recipient as a "privacy leak" is perhaps your most absurd mental gymnastic yet

You guys keep on restating a falsehood and can't seem to keep it straight. Let me ask you directly. Do you acknowledge that the following things are different on lightning? The "amount the sender sent" on lightning is different from the "amount the recipient(s) received." Do you acknowledge that? And do you acknowledge that the sender *knows the former* (which you two keep falsely criticizing me for denying) but -- in lightning -- he *does not know the latter* whereas in monero he does. That is a leak on monero that lightning fixes. The sender should not know how much the recipient(s) received or even if there are multiple recipients that he doesn't know about. It's none of his business. It's like the album store example: the buyer should know he paid, and get his receipt atomically, but if the money got split up between the clerk, the album's producer, and the artist, the buyer should not know that, nor the amounts they each received. That business is internal to the album store and is none of the buyer's business. Monero leaks that data and LN does not.

> A sender knowing the precise amount they transferred to a recipient is how basic arithmetic works, not a protocol flaw

The flaw is that he knows how much the recipient received as well as the number of recipients. That is an unnecessary data leak and a protocol flaw. Lightning fixes it.

> you completely ignore Lightning's glaring structural vulnerability: Active channel probing!

I do not ignore it. Channel probing is a flaw and deserves further work, I often talk about it and highlight progress being made in that department, like multiparty channels, which further dilute the potential information gleanable from channel probing, and prepaid htlcs, which increase the monetary cost of channel probing, and forwarding delays, which do two things: they increase the time cost of channel probing while simultaneously making it more likely that the capacities of other channels on the network (plus the one being probed) change mid-payment, thus fuzzing the data.

> any low-cost probe node can send fake payment probes across the network to continuously map balance changes across public channels

I question your claim that continuous probing is cheap, easy, or likely to yield a continuous set of accurate data. An attempt to learn the state of the whole network by probing was tried in 2020: https://arxiv.org/abs/2004.00333

It took 9 hours to get data about only 65% of the network, due to natural network delays and the prober’s method of probing a set of nodes, waiting for the htlcs to succeed or fail, and then probing the next set. Some of these delays are not things the prober can fix. In the test, these delays meant the state of the network was changing continuously during the probing, and once they had the full data, it was no longer an accurate picture. A prober could try connecting to more nodes simultaneously, but the costs rise if they try that, and even then, the probers may find the same thing the testers found: lots of nodes don't respond, lots of nodes aren't even announced, and there are lots of delays that harm the data.

> This allows malicious actors or government surveillance hubs to monitor payment flows in real time and deanonymize transacting parties with extreme statistical confidence without ever needing access to private keys

Your conclusion does not follow since so many of your premises are flawed. Also, the ongoing Blink case demonstrates a non-malicious party trying to trace a payment, and all the gaps in their knowledge are telling. We'll see if they are able to catch the criminal or not. I think we’re already learning a lot even now, and how long it takes them to nab him, if they do at all, will tell even more.

> Lightning's threat model inherently exposes users to traffic analysis, Sybil attacks, and active network surveillance by intermediate routing partners.

Sure, it has problems, and good devs are working on them, and more work is needed before anyone could make a claim like “tracing lightning is impossible.” But it's already better than monero in many respects: it leaks less data permanently, it leaks less data to the public, and it gives less data to senders. It gives too much data to routers, which is undoubtedly a problem, but even now it's better than monero if both are used carefully.

> Monero secures privacy at Layer 1 by default, I mean, concealing sender, receiver, and transaction amount simultaneously

Nah, it exposes data about all of those, as demonstrated on the site I linked. That data is often collected from the permanent, transparent monero ledger, analyzed, and used to charge criminals with crimes. You’re better off not leaking it to the public. You're better off with lightning.