[Bitcoin-development] 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? -- 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=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Peer Discovery and Overlay
On Tue, Dec 24, 2013 at 8:52 AM, Jeremy Spilman jer...@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 -- 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=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Peer Discovery and Overlay
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 92a315c01cfc115d7f1b40dc44edbafd504b0d7498b0704a signature.asc Description: Digital signature -- 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=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Peer Discovery and Overlay
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 p...@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=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Peer Discovery and Overlay
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. wtog...@gmail.comwrote: 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 p...@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=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
