Support multiple HD accounts through a trusted local full node

[gary-rowe]

One suggestion made on Reddit gives an interesting angle to supporting multiple HD accounts:

For the 6000 people running their own node, it would be nice to have some benefit. Perhaps like the schildbach wallet one could set a trusted single node and disable bloom filtering ? At the very least this would increase speed, but perhaps could unlock multiple accounts ?

This could be a Labs feature in the first instance to try it out.

[jim618]

This would mean that the local instance of MBHD would have to process every single bitcoin transaction in every single block rather than filtered blocks. This is orders of magnitude more processing than the current configuration.

[aussiehash]

Schildbach wallet is still SPV but has 3 modes

• Normal mode - connects to random nodes
• Trusted peer mode with peer discovery - 1st connection is to the trusted node, but still connects to other nodes
• Trusted peer mode, skip peer discovery - only 1 connection

Providing a node you operate yourself and trust, means there is no privacy leak (no need for bloom filter) and no risk of being lied to or Sybil attacked.

[chriswheeler]

I'd be interested in this too, I run a node on a server on my local network, but run Multibit HD as my main wallet on my workstation, so being able to connect to a trusted local node would be a useful option for me.

[jim618]

This issue mixes two things - connectivity and bloom filtering.

MultiBit HD will automatically connect to a Bitcoin Core running on localhost. It also connects to other nodes mainly as we use transaction propagation to determine when a transaction has been sent properly and when the change of a transaction can be used.

You really don't want to switch off bloom filtering ! A filtered block (post bloom filtering) is a fraction the size of a whole block. MBHD will most likely choke processing full blocks, especially as they will no doubt get bigger (2MB, 8MB, 20MB ???)

If you were running a Bitcoin core 'somewhere else' you could probably port forward it from localhost to the 'other place'. I haven't done this.

Note that our brief for MBHD is to keep it simple. We don't want to add in configuration options for everything as it adds complexity to the end user. Hence we 'automagically' connect to localhost only and it's not configurable.

[rapodaca]

MultiBit HD will automatically connect to a Bitcoin Core running on localhost.

Interesting. Couple of questions:

1. How does the UI indicate that it's connected to the localhost node?
2. Does MultiBit HD only connect to localhost if running, or does it connect to others nodes at the same time as localhost?

[gary-rowe]

@rapodaca There is no UI indication of the connection. The overwhelming majority of MultiBit HD users will not use this feature so having a UI for it is more work than its worth.

MultiBit HD will connect to the localhost and others it discovers in addition to that. As Jim noted, we rely on transaction propagation to determine that the Bitcoin network has accepted and relayed it so this is unavoidable (and desirable).

[jim618]

It's not practical to have multiple account support with the architecture we use - see https://multibit.org/en/help/hd0.1/how-spv-works.html § Bloom filtering and single HD account support

Closing as not practical

[aussiehash]

You really don't want to switch off bloom filtering ! A filtered block (post bloom filtering) is a fraction the size of a whole block. MBHD will most likely choke processing full blocks

If exclusively connecting to an own trusted node, surely there is no need for bloom filtering. Just query the local node for UTXOs, and to broadcast transactions.

Core can watch addresses. https://www.reddit.com/r/Bitcoin/comments/3ewig4/really_like_the_watch_only_functionality_in/

[jim618]

I think you post illustrates the amount of work required to implement this. It's actually a different trust model than what we use at the moment (which is trusting a single peer as little as we can).

Just off the top of my head:

• 'Just query the local node for UTXOs' = we connect to Core/XT nodes using the Bitcoin network protocol, not RPC. Thus to get the UTXO set we would need to implement a Java RPC module.
• UTXOs don't give all the txes. Imagine another wallet with the same seed sent a tx and the outputs were spent. It's not in the UTXO set, we wouldn't get the tx back, wallet looks odd.
• We use transaction propagation (across multiple nodes) to work out:

++ Is change spendable ?

++ Confidence of tx - has it been spent successfully?

• What's the model with a single node - something different. More coding, testing
• How does the UTXO set change on a reorg ? Currently we (via bitcoinj) track all the forks and will automatically reorg when a chain 'takes the lead'. This is complicated code. How's it going to work with UTXO querying ?
• The PrunedBlockStore (which we'd probably need to use) in bitcoinj isn't production quality yet.
• We currently have a single set of backend code - having two will entail a more general connection architecture. More work. More testing.

Finally: there are roughly 6000 nodes. How many people would all this code help ? A few hundred at most. That's a few hours of MultiBit HD downloads.

tl;dr Yes, your suggestion could be done but it's lots of work for little gain.