Avatar
andrewtoth
10dc30b77d65c2884d0226d8ead2d52d50d766703ffdcefbf4a071b3e732fa67
Replying to Avatar L0la L33tz

I wrote a very basic overview of watermarking, fingerprinting, timing analysis and supernodes for Bitcoin Magazine's last print issue, which is pretty much an unsolicited advertisement for why I think we need a second mempool (and also mixnets, but thats a longer story). Since no one cares about stuff like this on Twitter anyway, I'll explain here.

Bitcoin has a privacy issue on baselayer. I know this. You know this. Everybody knows this. The problem is that there's a lot of stuff we can't do to solve this issue without completely fucking up how Bitcoin works, like, say, anonymous amounts. But there is some stuff we *can* do to increase privacy on the Bitcoin baselayer. One of those things is incorporating a second mempool to integrate Dandelion++, the routing protocol used in Monero. Hear me out.

One of the ways blockchain surveillance firms identify who what transactions belong to on the Bitcoin blockchain is by operating so-called supernodes. A supernode sets up as many connections to other nodes as it can, and by doing so can establish where a transaction was first seen in the peer-to-peer network, ergo ascribe whom a transaction belongs to.

Here's where Dandelion++ comes in. Instead of propagating transactions to *all* connected peers, Dandelion++ propagates transactions like, well, a Dandelion.

In Dandelion++ propagation, Bitcoin nodes send transactions to *one* peer, instead of to all of them. This peer sends it to another peer, they send it to another peer, and so on and so forth. This is called the "stem phase".

When we've established enough plausible deniability, Dandelion++ reaches the "fluff phase". At this point, a node that did not *create* the transaction, but is simply relaying it, propagates it to all nodes in the network it is connected to, including supernodes, and the next node does the same, and so on and so forth – business as usual.

Incorporating Dandelion++ (or any other anonymizing propagation protocol, like Dandelion, Dandelion Lite, or Clover) would arguably seriously fuck up the blockchain surveillance stick as we are taking away the most obvious attack vector for blockchain surveillance firms. It's also not a trivial task, see ajtowns' overview of stempools (and no one wants to maintain another mempool on bitcoin, if we're honest). But it's a really interesting proposal to think about to increase privacy on Bitcoin that, yes, would be a lot of work to implement and maintain, but also does not get talked about enough imo for everyone yapping about Bitcoin baselayer privacy.

AJ Towns' Stempool overview: https://gist.github.com/ajtowns/f3a19c33b80750a47c5b83ecf6a09aaf

BM Article:

https://bitcoinmagazine.com/print/whistleblowing-in-the-surveillance-age

This is a much simpler alternative that achieves the same thing, and has a PR ready to be merged today. IMO you should promote review of this to get merged asap instead of dandelion which has been around as an idea for a decade.

https://github.com/bitcoin/bitcoin/pull/29415

Replying to Avatar ck

Hmmm

It takes a long time for them to validate a new block, because they have to fetch all txs that were filtered from peers.

https://github.com/bitcoin/bitcoin/pull/28233 should help mitigate this.

Good example!

Anything in the last hundred years though?

Hmm that's not how a soft fork works. Soft forks are invisible to non-consenting nodes. The UASF forced all hash rate onto the soft fork. There's no way to force majority hash rate to *not* enforce a soft fork by running a node without new hard fork rules.

Not sure, haven't been following closely. I'm just countering the assertion "Soft forks require economic majority of nodes to run." It only requires hash rate majority, which can be forced by economic majority without hard fork. It can't be stopped by economic majority without hard fork.

2017 was an economic majority enforced soft fork with a minority of hash rate. Today the threat is hash rate majority soft fork. The only way for economic majority to stop it is with a hard fork.

Soft forks only require a majority of hash power to run. Enforcing a soft fork with a minority of hash power required an economic majority.

The only way an economic majority can reject a majority of hash power enforced softfork is with a hard fork.

Oh, if the user is not compiling this will not work. You will have to generate the function and compile it for each L value you want your users to be able to configure. A declarative macro would work for that.

The reason these are PWAs in the first place is to circumvent app stores though. If an app store allowed them they wouldn't be PWAs but native apps.