Hi, worry it took me 3 days to get back to you, I am preparing for a workshop in Europe. Did you try testing your implementation on the NWC tester? https://supertestnet.github.io/nwc_tester/ I recommend doing it with a backend that definitely works first, like this one: https://supertestnet.github.io/bankify/ One you have seen it work with a known-working backend, try it with your backend. Inspect the code bases to see what you are doing differently from the known-working one.

because downloading the blockchain makes less sense with more garbage in it, regardless of the blocksize limit

The filter I'm gathering data on is called minRelayTxFee -- minimum relay transaction fee. Almost every bitcoin transaction pays fees to miners, and most nodes have a standard filter that checks every transaction sent to its mempool to see if it pays a minimum fee. If not, it refuses to relay that transaction. Thanks to most nodes doing this, there is a mitigation for what would otherwise be a significant DoS vector on bitcoin: without this filter, spammers could cheaply DoS the network by sending out millions of 0-fee transactions. In the op_return wars, people who oppose spam filters have been arguing for a while now that spam filters "don't work" because some large op_returns bypass the spam filters and get into the blockchain via private mempools, or libre-relay. One of the pro-filter side's responses is that these are exceptional cases; only a small percentage of transactions in the blockchain show any evidence of bypassing the op_return filters, and that helps prove that the filters work. Recently, the anti-filter crowd has a new argument: spam filters "don't work" because some transactions pay less than the standard minimum feerate; they bypass the minRelayTxFee filter. So I created this website to gather statistics about that, and show that the same counterargument applies: only a small percentage of transactions in the blockchain show any evidence of bypassing the minRelayTxFee filter, and that helps prove that the filters work.

Is anyone still denying that mempool filters work? If so, wow... they are down so bad https://supertestnet.github.io/filter-stats/

The lightning network has superior privacy tech to the main privacy coin (monero) while simultaneously scaling better Want a real cryptocurrency? It's bitcoin on LN

Why don't you invite one of your moneronfriends to debate me? You can record it on a zoom chat or similar and we can publish it on nostr

I do have new arguments now...maybe it is time for a new version

It's probably just luck, but Ocean entered the top 10 mining pools today. They even surpassed the measured hashrate of the principal spam-friendly mining pool, which is Mara. Let's see if they manage to keep this spot over the next few days.

They are neat technology, but it is bad if they make people think it is generally safe to reuse them. It is not. If you use them, you should make a new silent payment address for every service you use, and if it an anonymous service (like a swap service) you should make a new one for each *payment.* Otherwise you are subject to two attacks: 1. Profiling A supposedly anonymous service, like a swap service, can create a hidden profile of a user based on the address they send money to. E.g. if I use it twice with the same silent payment address, they can keep a record of that and know that at time A I received $20 and at time B I received $35, because I reused the same silent payment address. Thus they create a hidden profile on me and learn *when* I use their service and *how much* I swap there day to day, which is info they should not know. Mitigating this attack requires creating a new silent payment address for each payment whenever you use an anonymous service like that. 2. The colluding sender attack This attack also relies on address reuse. In it, two people -- Alice and Bob -- observe that Alice sent $10 to the same silent payment address that Bob sent $5 to. So together they know the same person received at least $15, which they should not know. Ideally, Alice should only know about *her* payment and Bob should only know about *his.* But if I reuse the same address, they can compare notes and learn that both of their payments went to the same person. That's a privacy leak, and to mitigate it, you must not give the same silent payment address to two different people. Make a different one for each such payment.

There is a new section on http://moneroleaks.xyz It's called "List of attacks" Learn the names and inner workings of 6 common techniques used to trace monero, as well as information about real-world cases where each technique was used to trace and convict a monero user

Today I decided to analyze a paper discussing attacks against the privacy of the lightning network. The paper is here: https://arxiv.org/pdf/2003.12470 and it is called “An Empirical Analysis of Privacy in the Lightning Network.” It analyzes a number of attacks on LN privacy, including one I found particularly interesting, the discussion of which contains this sentence: “We thus developed a tracing heuristic, which follows the “peeling chain” initiated at the opening and closing of public channels to identify any associated private channels.” (page 6) The Peeling Attack (page 6) The peeling attack is designed to identify unannounced channels on the lightning network. As part of the attack (the name for which I made up), they identified all outputs on the blockchain that could feasibly be channel opening transactions on the lightning network, and then checked how those outputs were spent. Some of them were “channel closure” transactions, confirmed by this method: they observed that the transaction sent money to a lightning node who had public channels, and they confirmed *that* by observing that the recipient *spent* the money to open a “public” channel, which showed up in the public channel graph. Since they identified channel closure transactions of a channel that was not announced on the public graph, they knew it must be an unannounced channel. A particularly poignant sentence is this one: “Out of the 27,183 transactions we identified as representing the opening of private channels, we were able to identify both participants in 2,035 (7.5%), one participant in 21,557 (79.3%), and no participants in 3,591 (13.2%).” By identifying many unannounced channels via their opening and closing transactions, they could get the total capacity of those channels, as well as the “final” balance of both parties when the channel closed. What are the weaknesses of this attack? Some are: it only finds unannounced channels if they are in a peel chain, that is, a series of transactions that keep opening and closing channels using a particular utxo and its change; it does not identify unannounced channels that are not part of a peel chain; it does not get anyone’s channel balance while the channel is open, only its total channel capacity; when it identified a channel closure, it only learned the “final” balance of the two nodes, not their transaction history. The Targeted Probing Attack (page 8) Regarding balances, they also have an attack for guessing the internal balances of an individual announced channel, though the attack has weaknesses. The attack is discussed in section 4, page 8 of the paper. It’s similar to Rene Pickhardt’s channel probing attack, but I will dub the new method the “targeted probing attack,” as opposed to Rene’s attack, which I dub the “dragnet probing attack.” The targeted probing attack requires identifying a channel, which they call B -> C, where B and C are lightning nodes and the arrow is the channel between them. Then the attacker must open two “attacker” channels (the dragnet method requires only one channel), one with B and another with C. Then the attacker sends a series of payment probes, such that their channel with B is always the “from” channel and their channel with C is always the “to” channel. By only having those two channels, they know the payment probe must pass through B and C. If the payment makes it to the destination node, then they infer that the capacity of B -> C is split up in such a way that B has at least that much money on his side of the channel; then they cancel the payment and try again with a higher amount, and keep doing they reach the channel’s capacity or the payment fails. (That’s a bit simplified; they optimize the number of transactions they must try by doing a binary search, but whatever.) At that point, they infer that the internal balance of node B in the channel B -> C is just below whatever amount failed (if there was a failure), or is just the entire capacity of the channel (if there never was a failure), and the balance of C is whatever’s leftover of the capacity of the channel. They admit that the targeted probing attack has a weakness: “[In] the case in which there is more than one intermediate channel between the two attacker nodes…the above method identifies the bottleneck balance in the entire path, rather than the balance of an individual channel.” (page 9) Consequently, B and C may have channels between them that the attackers don’t know about (e.g. unannounced channels that weren’t in a peel chain), and thus this attack does not for-sure discern the internal balance of B for a particular channel, it only finds that he has *at most* whatever amount they got through. E.g. if they got a payment of $500 through, maybe B only had $200 on his side of the B -> C channel they were probing, but he had $300 or more in another channel with C that they didn’t know about, and routed the remainder through that channel. The AOH Attack (Assume One Hop - page 10) The paper discusses an attack for guessing the senders and recipients in a lightning payment, in section 5, “Path Discovery,” on page 10. They describe their attack thusly: “The strategy of our…adversary is simple: they always guess that their immediate predecessor is the sender. … Similarly, they always guess that their immediate successor is the recipient.” Their attack relies on the assumption that most nodes will try to pass their payment through the shortest possible route to the destination, and that this means most payments will actually only have one hop: “the route to the destination in LN is constructed solely by the payment sender. All clients generally aim to find the shortest path in the network, meaning the path with the lowest amount of fees.” (page 11) They simulate this attack in section 5.1 (page 11), where they say they took “snapshots” of the lightning network’s public nodes and channels (specifically, they say their methodology for getting the snapshot is outlined in section 3.1 on page 5, and that section only mentioned public nodes and channels – unannounced ones are only discussed later, in section 3.2). Then they assigned a routing algorithm semi-randomly to each node on this network, where the algorithms were re-written versions of the routing algorithms used by LND, CLN, and Eclair. Then they pretended these nodes sent simulated payments to one another at random, and checked how often a routing node was right if a payment passed through it and it guessed that the node before it was the sender and the node after it was the recipient. They were correct 56.65% of the time. What are the weaknesses of this attack? Well, they were *wrong* about a single hop 43.35% of the time, so that’s already pretty damaging to their case. But also, they were working on a constrained network: they completely excluded private nodes as possible senders, and it is a lot easier to guess the sender/recipient when your simulator excludes, right at the start, a huge number of nodes that could otherwise be the sender/recipient.

In my latest challenge, I identify the sender pubkey, recipient pubkey, and amount of a monero tx: https://x.com/SuperTestnet/status/1942082587192602801 I also identify the change pubkey and the amount it received: https://x.com/SuperTestnet/status/1942083538406223907 Monero bros: “That’s not a real trace!”

No But it has one thing going for it: it leverages a harder money

People wonder why I dislike monero Well, I learned how it works https://x.com/LayerTwoLabs/status/1946267387952533968

an opinion

When spammers pay large miners directly, it does hurt decentralization of miners. And I think that is bad, but I compare that downside with this other downside: when spam is "welcomed" by removing the spam filters, that increases the total amount of spam on the blockchain, and that hurts decentralization of *nodes.* Specifically, it makes nodes harder to sync, and incentivizes more people to avoid doing so. So either way you get a harm: if spammers pay large miners directly, that hurts decentralization of miners. If, instead, they are welcomed into the public mempool, that amount of spam on the blockchain rises, and that hurts decentralization of nodes. Which harm is worse? I think the latter is worse, particularly because the *amount* of money actually going to large miners from spammers paying them directly is currently very small. The filters seem to be effective enough that most spammers aren't *trying* to bypass them by paying large miners directly. Instead, they seem to prefer just using other blockchains where spam is more welcome.