Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bisq's bitcoinj "addr" message support audit #28

Open
oscarguindzberg opened this issue Mar 26, 2019 · 0 comments
Open

Bisq's bitcoinj "addr" message support audit #28

oscarguindzberg opened this issue Mar 26, 2019 · 0 comments

Comments

@oscarguindzberg
Copy link

oscarguindzberg commented Mar 26, 2019

  • Commits to audit
  • How it works now
    • PeerGroup: When "addr" msg is received, add a new peer to the "inactives" collection.
    • PeerGroup property addPeersFromAddressMessage can be used 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
  • Bitcoin core support: https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery
  • Comments by Dan (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.
    • 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.
    • 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.
    • 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.
    • 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?.
    • 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.
    • It's a part of the bitcoin p2p protocol. Not implementing it in bitcoinj seems incomplete at best.
      • Oscar comment: agree.
    • It was not hard to do. low hanging fruit.
      • Oscar comment: See "Implementation problems/limitations" section.
  • Implementation problems/limitations.
    • If a user wants to connect just to the Bisq curated node list in BtcNodes.java for privacy issues, this mechanism might have her connected to other nodes. This could probably be 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. See upstream bitcoinj attempts to do it detailed above.
  • Actions:
@oscarguindzberg oscarguindzberg changed the title Bisq's bitcoinj peer discovery changes audit Bisq's bitcoinj "addr" message support audit Mar 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant