[bisq-network/bisq] chore: add btc node (#3506)

[Kilian Rausch ⚡️]

Not taking this personally, since what you are saying makes sense as of bisq status quo.

Thinking a bit more about this, I want to object to the concept of `btc node operator` or a `federation of Bitcon Core Nodes` in general. According to [the docs](https://docs.bisq.network/btcnode.html), this role was introduced to
> (1) avoid relying on bloom filters to protect user privacy when connecting to arbitrary public nodes
> (2) ensure Bisq connects to nodes with consistent Bitcoin Core implementations.
> (3) in the case of a hard fork, it would be impossible for Bisq to tell which fork a connected node was running

IMHO all 3 reasons have failed/serious problems:
(1) I believe it's worse to give my tx info to a handful of bisq operators copmared to spreading it across arbitrary public nodes. This is creating a highly centralized `federation` (that's even the word that is used in the docs). A honeypot to be ddosed or regulated for any adversary, especially a regulator. Also - are we sure that these hard-coded node operators where real world identities are *very* easily attached - never become liable for failed/fraudulent btc transactions? Additionally: now that it's ready to be used with enough btcd's on the network to support it, shouldn't bisq consider switching to [neutrino](https://github.com/lightninglabs/neutrino/)?
(2) This clearly failed so far, quite some nodes are on satoshi 16 or lower, missing security patches etc.
(3) I agree this is a huge issue, but it's a problem the entire bitcoin network and all SPV wallets are facing. I as a bisq user do object a bisq node operator deciding for a particular fork on my behalf. Since it's not an if, but a when there will be another contentious hard fork in the future, bisq should do the following IMHO:
* warn user in the UI that the fork is happening (explain in plain english they why, how, what)
* give user a choice ("a) I want to deal with it on my own" vs. "b) I want some trusted bisq operators to decide for me").

If the user decides for a), disable trading from the scheduled blockheight of the fork and only re-enable by the user actively agreeing to a disclaimer.
Only if the user decided for b) and only then the bisq client should connect to the btc node operator's full nodes and only for the limited time of uncertainty while the hard fork battle is happening. The SPV wallet should connect to all nodes again once the hardfork is clearly resolved via a bisq client software update.

Taking all of the above into account I think there should be a path towards `bisq without permanent btc node federation`. Request for comments ;)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/3506#issuecomment-549302910
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191104/8ed53d9a/attachment.html>