* [Bitcoin-development] Peer Discovery and Overlay
@ 2013-12-24 8:52 Jeremy Spilman
2013-12-24 10:47 ` Tier Nolan
2013-12-24 14:02 ` Peter Todd
0 siblings, 2 replies; 5+ messages in thread
From: Jeremy Spilman @ 2013-12-24 8:52 UTC (permalink / raw)
To: bitcoin-development
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Peer Discovery and Overlay
2013-12-24 8:52 [Bitcoin-development] Peer Discovery and Overlay Jeremy Spilman
@ 2013-12-24 10:47 ` Tier Nolan
2013-12-24 14:02 ` Peter Todd
1 sibling, 0 replies; 5+ messages in thread
From: Tier Nolan @ 2013-12-24 10:47 UTC (permalink / raw)
To: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Peer Discovery and Overlay
2013-12-24 8:52 [Bitcoin-development] Peer Discovery and Overlay Jeremy Spilman
2013-12-24 10:47 ` Tier Nolan
@ 2013-12-24 14:02 ` Peter Todd
2013-12-24 17:11 ` Warren Togami Jr.
1 sibling, 1 reply; 5+ messages in thread
From: Peter Todd @ 2013-12-24 14:02 UTC (permalink / raw)
To: Jeremy Spilman; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Peer Discovery and Overlay
2013-12-24 14:02 ` Peter Todd
@ 2013-12-24 17:11 ` Warren Togami Jr.
2013-12-24 17:15 ` Mike Hearn
0 siblings, 1 reply; 5+ messages in thread
From: Warren Togami Jr. @ 2013-12-24 17:11 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Peer Discovery and Overlay
2013-12-24 17:11 ` Warren Togami Jr.
@ 2013-12-24 17:15 ` Mike Hearn
0 siblings, 0 replies; 5+ messages in thread
From: Mike Hearn @ 2013-12-24 17:15 UTC (permalink / raw)
To: Warren Togami Jr.; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-12-24 17:15 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-24 8:52 [Bitcoin-development] Peer Discovery and Overlay Jeremy Spilman
2013-12-24 10:47 ` Tier Nolan
2013-12-24 14:02 ` Peter Todd
2013-12-24 17:11 ` Warren Togami Jr.
2013-12-24 17:15 ` Mike Hearn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox