Bitcoin Forum

The Bitcoin network is a fruitful source of data concerning all sorts of problems in economics, computer science, and applied mathematics. In this post I am concerned with the the underlying dynamic complex network, about which we need to know in order to say anything meaningful about the network stability, efficiency, resilience to various forms of attack, behavior under parameter change (e.g. messing with the block frequency), and anything else you can think of.

Example: consider the "Internet" (whatever that means). We "know" that the nodes form a scale-free network where the number of nodes of degree  k  is proportional to  k^(-2.2)  or so (with a cut-off).

For the Bitcoin network, besides the degree distribution, distance and bandwidth between nodes, clustering coefficient, and so on, we need to know things like the processing power of each node (many people are not mining at all! the ones that are are not randomly distributed!) and rates at which different kinds of nodes join or leave the network. One thing we have working in our favor is that the the Bitcoin network is relatively small, therefore it should be possible to obtain some reasonable data.

Does anybody have access to such data? Does anybody want to support this sort of research?

I think this is a very important area of research. I, for one, do not mine, but I keep a 24x7 v0.8.1-beta client running (to strengthen the network). It usually has 50-60 connections. I limit my total upload bandwidth to 500kbps. I would be very interested in knowing many of the things you alluded to. Maybe the client could be enhanced to gather and display network data in the same way that it gathers and retains Bitcoin transaction data. That way everyone would know that they were running on the same network (no bifurcation had taken place) - among other many other things.

I agree, and here's a method I developed a decade ago to perform measurement operations in a totally decentralized fashion:

http://www.google.com/patents/US20050007964

Thanks for the links and comments. A client modified to gather info and statistics, and persuading enough people to run it, seems like the way to go. Schemes to compute accurate statistics for dynamically changing peer-to-peer networks, based on local measurements, have indeed been researched for at least a decade or so, but it seems no one has yet applied them to the Bitcoin network (even if someone had, such results should be independently reproducible).

For anyone interested in pursuing this, here is a preliminary exercise:

Devise a method to obtain a "random" sample of steadily-connected Bitcoin nodes (I suggest at the very very least 100) and for each one record the number of connections to the network (this information should be visible in the default client's Debug Window). What can you infer about the distribution of this quantity?

I strongly suspect that the distribution of processing power, memory, bandwidth, and up time for Bitcoin nodes will very closely resemble that of the Gnutella network back in the days, since the peer to peer overlay functions identically.

A problem with using local statistics is that it can be spoofed.

I wonder if it wouldn't be a good idea for several P2P networks to share the purely network-related parts of their protocols and networks. That should give us both strength in numbers and synergy. For instance, some have speculated that Satoshi's initial goal was to provide a currency that could be used to provide a financial incentive for running Tor nodes.

Nothing (except resource limits) stopping you from running multiple protocols over the same pipe...

As for Gnutella, you can fit a power law with cut-off to the degree distribution but I do not recall how statistically significant it is (p-value).

And the more protocols, the more users and therefore the bigger the pipes and the greater the outcry against attempts to block those pipes. And since some protocols are more controversial than others, it will be easier to work on the shared parts.

Getpeerinfo will do what it says.
Peers.dat file contains much more, but I don't know how to read it.