Peer Discovery and Overlay

Some really nice efforts out there to map and analyze the bitcoin P2P network.

The current protocol apparently recommends returning up to 2500 addresses from 'getaddr'. I'm not sure how much clients are expected to probe the address space in order to select 'far-apart' peers, or how much such an process would even attempt to achieve.

How much does it matter if the ability to discover the entire network of peers is fast or slow? There are probably pros and cons to both.

Is there any thought to how existing bitcoin node relations, and the ease at which peers can be discovered, becomes a service in itself, or even possibly a vulnerability?

Are there any past instances of applications hijacking or interfacing with the exiting p2p messages, or abusing 'getaddr' functionality? Are there any guidelines on this, or should there be?

On Tue, Dec 24, 2013 at 8:52 AM, Jeremy Spilman <jeremy@taplink•co> wrote:

> Are there any past instances of applications hijacking or interfacing with
> the exiting p2p messages, or abusing 'getaddr' functionality? Are there
> any guidelines on this, or should there be?
>
>

There was a BIP by Stefan Thomas for adding custom services to the protocol. Discovery would be helpful here too. If this was added, it wouldn't be intended for use in a hostile way though.

This one was the custom services BIP. It defines a change to the version message and also custom sub-commands. https://github.com/bitcoin/bips/blob/master/bip-0036.mediawiki

This one discusses how network discovery should be handles. https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Service_Discovery

On Tue, Dec 24, 2013 at 12:52:46AM -0800, Jeremy Spilman wrote:

> Some really nice efforts out there to map and analyze the bitcoin P2P
> network.
>
> The current protocol apparently recommends returning up to 2500 addresses
>  from 'getaddr'. I'm not sure how much clients are expected to probe the
> address space in order to select 'far-apart' peers, or how much such an
> process would even attempt to achieve.

The logic is that by simply connecting to peers at random you keep the network structure as a whole randomized. You don't need to make any specific attempt at connecting to "far-apart" peers.

> How much does it matter if the ability to discover the entire network of
> peers is fast or slow? There are probably pros and cons to both.
>
> Is there any thought to how existing bitcoin node relations, and the ease
> at which peers can be discovered, becomes a service in itself, or even
> possibly a vulnerability?

Keep in mind it's easy for better knowledge of the network to be a vulnerability; the number of full nodes is small enough that DoS attacking all of them is quite feasible.

The other big vulnerability is that getaddr data is best effort; we currently have no mechanism to ensure that nodes are in fact operated by separate individuals. It'd be quite easy for someone to set up a relatively small number of nodes that only advertise themselves in the getaddr information. Over time they would get proportionally more incoming connections than is "fair"

As for node addresses being a service, that's what the DNS seeds are! bitcoinj clients, for instance, depend very heavily on those seeds and can be easily compromised in a variety of ways by them.

I was concerned about this issue so we sponsored BlueMatt to implement an address database for bitcoinj. In the future it won't be entirely reliant on what DNS tells it.

Warren

On Tue, Dec 24, 2013 at 6:02 AM, Peter Todd <pete@petertodd•org> wrote:

> As for node addresses being a service, that's what the DNS seeds are!
> bitcoinj clients, for instance, depend very heavily on those seeds and
> can be easily compromised in a variety of ways by them.
>

Thanks Warren! That's great. It's also a prerequisite for chain pruning, so it's not only about decentralisation but also scalability.

Looking forward to reviewing and merging that.

On Tue, Dec 24, 2013 at 6:11 PM, Warren Togami Jr. <wtogami@gmail•com>wrote:

> I was concerned about this issue so we sponsored BlueMatt to implement an
> address database for bitcoinj.  In the future it won't be entirely reliant
> on what DNS tells it.
>
> Warren
>
>
> On Tue, Dec 24, 2013 at 6:02 AM, Peter Todd <pete@petertodd•org> wrote:
>
>> As for node addresses being a service, that's what the DNS seeds are!
>>  bitcoinj clients, for instance, depend very heavily on those seeds and
>> can be easily compromised in a variety of ways by them.
>>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>