Bitcoin Forum

If someone is interested, a made a visualization [1] of the Bitcoin P2P network using Protocoin [2]. I'll release the source code together with the next release of Protocoin.

[1] http://pyevolve.sourceforge.net/wordpress/?p=2654
[2] http://protocoin.readthedocs.org

Very cool, I've been interested for a while, in various aspects of the Bitcoin network's node topology.

Thanks for spending your time on this and sharing with the community.

If I recall from skimming over the code (at least the latest reference client version) the GetAddr function only returns a sub-set of connected peers - is that correct? I assume this is for both performance and might have a security benefit of making it some attacks more difficult than if the GetAddr function returned ALL peers.

I'd be interested to know if there's any tuning that's possible for the Bitcoin network to improve transaction and block propagation speeds... that could be done with code to measure latency, bandwidth detection, and "other" between peers and optimize the GetAddr function to encourage certain nodes to peer where it would be an improve to the overall topology. At the same time any such optimization would need to be designed in such a way that didn't make it prone for misuse.

/end ramble

Sorry if my thoughts ended up seeming like a bit of an attempt at thread hijacking... semi related though!

It doesn't return connected peers at all, it returns some peers that it knows about. Connected is orthogonal.

Maintaining the expander graph property and protecting the network against accidental partitioning and the randomness property which makes adaptive attacks not have big sibyl advantages are far more important that propagation speed. Generally proving any particular optimization can't be misused— or even won't just naturally partition on its own is quite tricky.

Nice visualization!

Only about 230 Vertices? Probably I'm just ignorant, but looks fragile.

Thanks for the clarification! I should have taken a moment to refresh myself with addrman, the comments and the code make it obvious that getaddr is returning a list of known nodes, without RPC access to call getpeerinfo - there's no easy way to learn the connected peers.


Agreed, it would very tricky without implying some trust between certain peers, e.g. some kind of hierarchy of nodes and "super" nodes. This would be incongruent with the core idea of a trustless p2p network.