Bitcoin Forum

Other => MultiBit => Topic started by: spin on March 22, 2015, 09:55:06 PM



Title: HD - Specify peers
Post by: spin on March 22, 2015, 09:55:06 PM
How do I specify a specific set of peer(s) to connect to for HD? 



Title: Re: HD - Specify peers
Post by: jim618 on March 23, 2015, 03:05:12 PM
There isn't a way to specify specific peer(s) to connect to with MultiBit HD.

The number and quality of the network connections affects the usability of the app in various ways that doesn't make this practical:

+ When you send a tx it broadcasts on half the peers and listens on the rest. When it hears the tx on half of the remaining peers MBHD then "believes" the tx is broadcast.
+ You cannot spend change until it a tx that been sent has been seen by two peers.
+ Connection slots in the Bitcoin network are valuable - you don't want SPV peers connecting to "too many" Core nodes as it is greedy (see calc below).

The bitcoinj library does a good job of tracking peers and peer quality, replacing peers that stop responding.

The factors above create a sweet spot of peers to connect to of 8. (Transmit on 4 peers, listen on 4, happy when you hear from 2 - same number as change being spendable).  This number of peers will appear in the next beta - it is set to 6 at the moment which does not work as well.

Thus there is little point in doing the extra work to config the peers when it's better to letter bitcoinj do the job.

RE: being greedy.
Each Bitcoin Core node has a default number of connection slots - 117 AFAIK. Thus the 6000 or so Core nodes can make:
6000 * 117 connections to other nodes.

That is to other Core nodes, Electrum (which is SPV), MultiBit, the Schildbach Wallet.

It's not actually *that* many connections.


Title: Re: HD - Specify peers
Post by: btchris on March 23, 2015, 03:59:04 PM
I think it would be nice if MultiBit HD allowed you to specify a single full node (out of the 8) as a hint. Specifically I'm thinking of circumstances where someone is running a full node on the same host or local LAN, and would like to make use of it.

To a small extent, it could encourage people who are already somewhat interested in running a full node towards doing so (and conversely, not having such an option may encourage people to stop running a full node after upgrading to MultiBit HD from Classic). I think (gentle) encouragement such as this would be a good thing.

Alternatively, an option that calls peerGroup.setUseLocalhostPeerWhenPossible(true) would be almost as good IMO.


connections to other nodes.

That is to other Core nodes, Electrum (which is SPV), MultiBit, the Schildbach Wallet.

I'm off-topic here... but Electrum connects only to somewhat-centralized servers; it doesn't participate in the P2P network (it does do SPV on what it downloads, though).


Title: Re: HD - Specify peers
Post by: spin on March 23, 2015, 08:18:49 PM
I think it would be nice if MultiBit HD allowed you to specify a single full node (out of the 8) as a hint. Specifically I'm thinking of circumstances where someone is running a full node on the same host or local LAN, and would like to make use of it.

To a small extent, it could encourage people who are already somewhat interested in running a full node towards doing so (and conversely, not having such an option may encourage people to stop running a full node after upgrading to MultiBit HD from Classic). I think (gentle) encouragement such as this would be a good thing.

Alternatively, an option that calls peerGroup.setUseLocalhostPeerWhenPossible(true) would be almost as good IMO.


connections to other nodes.

That is to other Core nodes, Electrum (which is SPV), MultiBit, the Schildbach Wallet.

I'm off-topic here... but Electrum connects only to somewhat-centralized servers; it doesn't participate in the P2P network (it does do SPV on what it downloads, though).
That's exactly what I want :)

I am running a full node.  I'm using multibit hd because it works well with the trezor.  It's slow to catch up when it could be catching up using my local node.  Happy to have more connections than that, but it's useful to have it use the local node when catching up.


Title: Re: HD - Specify peers
Post by: R2D221 on March 24, 2015, 06:57:40 PM
I think it would be nice if MultiBit HD allowed you to specify a single full node (out of the 8) as a hint. Specifically I'm thinking of circumstances where someone is running a full node on the same host or local LAN, and would like to make use of it.

Doesn't bitcoinj automatically connect to your full node if it's detected in localhost? I think I saw something like that in the source code.


Title: Re: HD - Specify peers
Post by: btchris on March 24, 2015, 08:06:30 PM
I think it would be nice if MultiBit HD allowed you to specify a single full node (out of the 8) as a hint. Specifically I'm thinking of circumstances where someone is running a full node on the same host or local LAN, and would like to make use of it.

Doesn't bitcoinj automatically connect to your full node if it's detected in localhost? I think I saw something like that in the source code.

It does by default, however MultiBit HD calls peerGroup.setUseLocalhostPeerWhenPossible(false) to disable this.


Title: Re: HD - Specify peers
Post by: spin on March 24, 2015, 09:21:19 PM
I think it would be nice if MultiBit HD allowed you to specify a single full node (out of the 8) as a hint. Specifically I'm thinking of circumstances where someone is running a full node on the same host or local LAN, and would like to make use of it.

Doesn't bitcoinj automatically connect to your full node if it's detected in localhost? I think I saw something like that in the source code.

It does by default, however MultiBit HD calls peerGroup.setUseLocalhostPeerWhenPossible(false) to disable this.
Mine is not on the same host.


Title: Re: HD - Specify peers
Post by: jim618 on March 26, 2015, 11:14:31 AM
Allowing bitcoinj to find and use a localhost Bitcoin Core seems like a good idea so I have raised it here:
https://github.com/bitcoin-solutions/multibit-hd/issues/484

I think I switched it off as it was noisy in the log / took some time but I'll look at it again.