[bisq-network/bitcoinj] Bisq's bitcoinj peer discovery changes audit (#28)

[Oscar Guindzberg]

- Commits to audit
  -  https://github.com/bisq-network/bitcoinj/commit/659f3c167df39bad2977947ba3def29044a63cc3  
- How it works now
  - PeerGroup: When "addr" msg is received, add a new peer to the "inactives" collection.
  - PeerGroup property addPeersFromAddressMessage to disable the feature
  - bisq/bitcoinj node never sends “getaddr” msgs
  - bisq/bitcoinj node receives from time to time unsolicited “addr” msgs from peers.
  - bisq sets addPeersFromAddressMessage to false (disables the feature) if preferences.getBitcoinNodes() is not empty.
- upstream bitcoinj support for addr/getaddr messages
  - upstream bitcoinj does not implement this feature
    - Peer class can send "getaddr" msg and process incoming "addr" msg, but the feature is not used.
    - This is a missing feature on bitcoinj.
  - Related work on upstream bitcoinj
    - https://groups.google.com/d/msg/bitcoinj/3Y93LIDfJaM/SOYnpM9hlkYJ 
    - https://github.com/bitcoinj/bitcoinj/pull/2   
  - New conversation I started: https://groups.google.com/forum/#!topic/bitcoinj/W3gkXT7Hk2M 
- Bitcoin core support: https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery 
- Comments by commit author
  - I modified bitcoinj to listen to the addr p2p messages and add nodes dynamically. I was rather surprised mainline bitcoinj didn't already do that since it is standard bitcoind functionality.
  - This was in context of enabling bitcoinj p2p traffic to work over Tor, including DNS lookups which was a particularly tricky aspect.
  - There were several considerations:
  - 1. btc nodes come and go, so hard-coded seeds become unavailable over time. thus unreliable (Oscar comment: it's true, but same non critical issue is present on every app that uses bitcoinj).
  - 2. DNS provided nodes are a tiny subset of total bitcoin p2p network, and using only them is a point of centralization. dns maintainers become gatekeepers. (Oscar comment: but same non critical issue is present on every app that uses bitcoinj)
  - 3. DNS over Tor is slow and some record-sets from bitcoin DNS servers are too large, which result in empty result set. (if memory serves, sipa's dns node was one such.) In prior testing, we would sometimes have issues with few connections being made to p2p network, and then it never corrects itself back up to the target 8 or 10. Using the addr message fixed that issue as I recall. (Oscar comment: Dan has a point here. Since Bisq uses by default the curated btc nodes harcoded in the bisq code instead of dns discovery, this is not as critical as it could be)
  - 4. Bitcoin DNS servers do not provide .onion addresses. So addr messages are best way to become informed of nodes running behind Tor (Oscar comment: Why is important to connect to btc nodes running behind tor?).
  - 5. It is a way to bootstrap p2p connections from a local peer, eg bitcoind on same machine or subnet, even if DNS is being flaky/slow over Tor (Oscar comment: If a user is connected to a local bitcoind, she probably does not want to connect to any other bitcoin node for privacy/trust issues).
  - 6. It's a part of the bitcoin p2p protocol. Not implementing it in bitcoinj seems incomplete at best. (Oscar comment: agree)
  - 7. It was not hard to do. low hanging fruit (Oscar comment: Probably there are many weak points in the implementation).
- Implementation problems/limitations.
  - If a user wants to connect just to localhost node or to the Bisq curated node list in BtcNodes.java for privacy issues, this mechanism might have her connected to other nodes. This could probably solved by improving when PeerGroup.setAddPeersFromAddressMessage() is set to true.
  - getaddr messages are never sent, so bitcoinj depends on the unsolicited "addr" msgs peers send from time to time.
  - An attacker could send a million "addr" msgs with fake peers causing a DoS on the bitcoinj node.
  - Received addresses are not persisted.
  - Full support of peer discovery using getaddr/addr msgs might be difficult to implement.


-- 
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/bitcoinj/issues/28
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190326/cb51b26f/attachment.html>