[Bitcoin-development] Peer Discovery and Overlay

[Bitcoin-development] Peer Discovery and Overlay

[Jeremy Spilman]

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?

Re: [Bitcoin-development] Peer Discovery and Overlay

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1401 bytes --]

Re: [Bitcoin-development] Peer Discovery and Overlay

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

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.

-- 
'peter'[:-1]@petertodd.org
000000000000000092a315c01cfc115d7f1b40dc44edbafd504b0d7498b0704a

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Peer Discovery and Overlay

[Warren Togami Jr.]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

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.
>

[-- Attachment #2: Type: text/html, Size: 898 bytes --]

Re: [Bitcoin-development] Peer Discovery and Overlay

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 2607 bytes --]