Avatar
Super Testnet
2183e94758481d0f124fbd93c56ccaa45e7e545ceeb8d52848f98253f497b975
Open source dev w/ bitcoin focus | supertestnet.org bc1qefhunyf8rsq77f38k07hn2e5njp0acxhlheksn

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

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.

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/

Hey nostr:nprofile1qqszm52qe2qdkc4u7dma0klx3532jka2g8geck6fwxncyp90wktq2xssynh8t or anyone else, is there a nice looking service that helps people check out or try a variety of NWC-compatible wallets? I'm making a website where people connect an NWC string and I want to link people to something helpful in case they don't know what NWC is yet

Replying to Avatar Super Testnet

1. In terms of sender privacy, monero leaks the following data:

- at least one of the sender's inputs -- useful for tracing monero via the common input ownership heuristic

- at least one of the sender's ring signatures, including the sender's pubkey -- useful for tracing monero via the decoy elimination attack, the Eve-Alice-Eve attack, and the poisoned output attack

- Lightning does not reveal either of those things

2. In terms of receiver privacy, monero leaks the following data:

- the recipient's monero address -- useful for tracing monero by asking exchanges if any of their users has that address

- the recipient's stealth pubkey -- useful for tracing monero via the decoy elimination attack, the Eve-Alice-Eve attack, and the poisoned output attack

- the amount received by the recipient -- useful for tracing monero via the Eve-Alice-Eve attack, the poisoned output attack, and the timing analysis attack

- Lightning does not reveal any of those things, except sometimes a pubkey used for communication -- though that can also be avoided, either by using a proxy or via blinded routes

3. In terms of amount privacy, monero leaks the following data:

- the fee paid by the sender -- useful for fingerprinting wallets (e.g. custodial wallets tend to set higher fees than do users of self-custodial wallets)

- I already mentioned the following leak under "receiver privacy" but it's also an amount privacy leak so I'll just repeat it: monero leaks the amount received by the recipient -- useful for tracing monero via the Eve-Alice-Eve attack, the poisoned output attack, and the timing analysis attack

- Lightning does not reveal either of those things

For more info on monero leaks, see https://moneroleaks.xyz

1. In terms of sender privacy, monero leaks the following data:

- at least one of the sender's inputs -- useful for tracing monero via the common input ownership heuristic

- at least one of the sender's ring signatures, including the sender's pubkey -- useful for tracing monero via the decoy elimination attack, the Eve-Alice-Eve attack, and the poisoned output attack

- Lightning does not reveal either of those things

2. In terms of receiver privacy, monero leaks the following data:

- the recipient's monero address -- useful for tracing monero by asking exchanges if any of their users has that address

- the recipient's stealth pubkey -- useful for tracing monero via the decoy elimination attack, the Eve-Alice-Eve attack, and the poisoned output attack

- the amount received by the recipient -- useful for tracing monero via the Eve-Alice-Eve attack, the poisoned output attack, and the timing analysis attack

- Lightning does not reveal any of those things, except sometimes a pubkey used for communication -- though that can also be avoided, either by using a proxy or via blinded routes

3. In terms of amount privacy, monero leaks the following data:

- the fee paid by the sender -- useful for fingerprinting wallets (e.g. custodial wallets tend to set higher fees than do users of self-custodial wallets)

- I already mentioned the following leak under "receiver privacy" but it's also an amount privacy leak so I'll just repeat it: monero leaks the amount received by the recipient -- useful for tracing monero via the Eve-Alice-Eve attack, the poisoned output attack, and the timing analysis attack

- Lightning does not reveal either of those things

> how do you proof that you send someone funds (in LN)?

Typically, the recipient gives the sender a receipt, and cannot sweep the funds from the LN htlc without doing so. Notably, there is an exception: it's possible (and common) to set up a payment that does not require a receipt from the recipient. If you do that then you simply do not get a proof of payment.

> [In monero] you can't proof who owns [an] address [or] if that money actually gets used/moved

There are four techniques outlined on moneroleaks.xyz for finding out who owns an address and/or if the money sent to that address actually got used/moved. These techniques have all been used to trace and convict monero users. I won't let monero bros pretend to have any intellectual honesty while they continually ignore widely known and documented circumstances while insisting they are impossible.

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

> I think [it] does you a disservice

I think it helps a lot. It illustrates a critical privacy flaw that monero has and lightning doesn't

Some monero bros don't yet seem to "get" that letting the sender trace their funds to its destination (the recipient's pubkey) is a huge problem that tracers use to find and convict monero users

By pointing it out over and over again, I think I am helping them learn the huge problems with their preferred privacy solution and showing them a viable alternative

> why [do] you feel the need to make better arguments?

Because I like to improve over time, including at arguing

If anyone wants to join me in a group chat, download the android app and reply to this note -- I will try to add your pubkey to a group chat

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.

> other 14 fake pubkeys won't do that hop obviously

Other *15* fake pubkeys -- the total ring size is 15 decoys + 1 true sender

> isn't your real pubkey...exposed...?

It depends. Some of the other 15 pubkeys might have, by chance, sent money around the same time you did; but even if they didn't, some other transaction within the same time frame might have selected them as a decoy too, so that it *looks like* that decoy might have sent money in the same time frame you did.

If neither of those happens, then your pubkey is the only one that shows up in a future ring signature, which might be logged as evidence that there's something special about it. Namely, the attacker knows two things: the "special pubkey" received money in one transaction, and then in a future transaction, it *might* have sent money.

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

No, they gave me an XMR address, I sent money to it, and then traced the transaction that I created

I often do this in order to demonstrate that monero has worse receiver privacy than lightning

Receiver privacy means not leaking info that should be known only to the receiver, including what address he received money into and how much money he received.

Monero leaks this data to the sender but lightning doesn't. And this data is very valuable to chain analysts, who commonly use it to trace monero in Eve-Alice-Eve attacks. That is where Eve, the attacker, sends money to Alice (the victim), and then watches the blockchain to see what happens to the money next.

If Alice ends up sending the money to someone who knows Alice's identity, Eve can sometimes collude with them to deanonymize two transactions: Eve -> Alice and Alice -> Eve. This attack has been used to successfully trace the monero of three criminals and convict them of crimes, as seen in thr first three case studies on moneroleaks.xyz.

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!”