SPV: DCR vs BTC

[jholdstock]

Here are some extra notes I came up with whilst writing #676. A comparison of SPV in DCR vs BTC, and some of the reasons the DCR implementation is superior.

I want to discuss whether this detail is worth including in some form - to be honest this kind of content might be better suited to "unofficial" comms (reddit/medium/etc).

Decred implementation
    - Client-side compact filters proposed by lightning labs developers and contributed to by several bitcoin core devs. Also updates to bips 157 158 - changes we are hoping to pull in later.
    - The wallet client downloads the full set of filters, and locally matches which blocks contain owned transactions without uploading any private data. 
    - Removes need to trust the remote node
    - Not revealing your filter makes it harder for observers to identify your addresses/tx/coins

Bitcoin implementation
    - Server-side matching with bloom filters. The filter contains hashes for all of your addresses and scripts. Uploaded to a bitcoin node which has a full copy of the blockchain, it selects all transactions which match the filter and sends them back. 
    - Makes it possible for a passive observer to infer which addresses you are watching, and therefore which transactions and which coins are yours.
    - Requests for filters have to be updated and handled differently for different clients, which can be expensive for the node serving the requests. Opens a DoS attack window

Bloom filters vs GCS filters
    - bloom filters use more network traffic.

[jrick]

It's silly to compare this "vs BTC" when we literally ripped out a better alternative SPV implementation for Bitcoin (the SPV implementation in the wallet is different, but the concept and filter creation is largely the same). Comparing pros and cons between gcs committed filters and server-side bloom filtering is ok, but let's not make this an "us vs them" comparison.

[jholdstock]

Yeah totally agreed - I was just using "vs" as shorthand, intending to convey a comparison, not a competition.

[s-ben]

Seems like it would make a good medium piece or Decred blog post.

[xaur]

Totally agreed with jrick.

To my knowledge this SPV was proposed for Bitcoin and there may be existing deployments somewhere on the Bitcoin network that predate Decred's implementation. Since it's not part of consensus, it's really about the implementation. If Bitcoin Core does not support this new tech (I sincerely don't know, I don't follow it) it's a problem of this implementation, even if it is dominant.

If we compare "DCR vs BTC" we may repeat the silly case of the compare page. It should be at least "Decred Core vs Bitcoin Core", but better to abstract from that and talk just about the tech. I suggest to rename this issue to something like "SPV: client-side vs server-side filtering" to stop the confusion early

+1 for the blog post if anyone can produce that. If some adoption numbers are available it's fine to include them, e.g. "75% of Decred nodes support client filters, while only 15% for Bitcoin".

edit: it may be worth to note that Decred's filters will be even stronger when/if the consensus change to add block header commitments is implemented and voted in. Then there will be a fundamental advantage on the consensus level. But don't hype it too much until it's done.