[decentralisation-utility = potential number of full nodes * potential number of users]

Finding an optimal block size is about tradeoffs - too big, and you have centralisation, too small, and Bitcoin cannot support as many users. How can this be quantified? Here is a simple and general figure-of-merit, "decentralisation-utility":

decentralisation-utility = potential number of full nodes * potential number of users

Decentralisation is represented by the potential number of full nodes. Utility is represented by the potential number of users. The question of finding an optimal block size is then: how can decentralisation-utility be maximised? For example, it's better to reduce potential number of users by 20%, if that would mean 30% more potential full nodes.

Potential number of full nodes

For most residential full node operators, the limiting factors will probably be data caps and upload speed. It's difficult to get combined statistics on this, but I did find one excellent data set. The FCC's Measuring Broadband America Report (see https://www.fcc.gov/reports/measuring-broadband-america-2014) contains a wealth of data about broadband Internet connections in the US. Commendably, they have also made the raw data available from https://www.fcc.gov/measuring-broadband-america/2014/raw-data-fixed-2013. The data is supposedly representative of the general consumer population.

The raw data contains cross-referenced upload speeds and total usage (downloaded and uploaded bytes). I will use total usage to represent "proven" capacity - if a user is able to transfer 20 GB/month of any data, this demonstrates that they are capable of transferring 20 GB/month of Bitcoin block data, and that 20 GB/month fits within their data cap. Furthermore, I calculated the maximum amount that could be transferred at their upload speed, and if this was lower than their total usage, then that becomes their proven capacity.

Here are the results:

This graph represents the proportion of users who are capable of transferring the amount on the x-axis. For example, if we set block size limits so that Bitcoin needs 10 GB/month, then 98% of users can run full nodes. But if we set block size limits so that Bitcoin needs 100 GB/month, then only 67% of users can run full nodes.

I'll assume that there are 10,000^# people out there wishing to run full nodes. As block size is increased, an increasing proportion of those people will be unable to run full nodes due to lack of data capacity.

Potential number of users

I'll assume that each "user" of Bitcoin requires 1000^# bytes of on-chain space each day. This corresponds to 2 - 4 transactions per day, per user. Each MB of block size then supports 144,000 Bitcoin users. Layer-2 networks like Lightning will increase the number of potential users, as users will (on average) require less on-chain space

Combining these

There is still one more question: how does block size (in MB) influence data usage (in MB/month)? I'll assume completely full blocks every 10 minutes, and that block data needs to be transferred a total of 10 times. This is reasonable, as Bitcoin is a P2P gossip network and transactions/blocks may need to be retransmitted to peers. Transferring transactions/blocks a total of 10 times means that a full node can relay to at least 9 peers¹ and that results in fast enough propagation (< 5 hops for 10,000 nodes). So for example, 1 MB blocks would require 44.6 GB/month of data capacity (1 MB * 4464 blocks/month * 10). Edit: see https://bitcointalk.org/index.php?topic=1108530.msg11793460#msg11793460, the bandwidth multiplication factor is probably closer to 7.8.

Combining all that, here is what decentralisation-utility looks like:


The optimal block size is about 3.8 MB.

Some issues with this analysis:

• The dataset is for the US. I was unable to find a good enough dataset for anywhere else.
• The dataset is from September 2013. Bandwidth capacity and usage has grown since then, and will continue to grow.
• Proven capacity (i.e. usage) will underestimate actual maximum capacity. This figure of 3 MB is quite conservative.
• The optimal block size is inversely proportional to the bandwidth multiplication factor. For example, assuming that the factor is 2 instead of 7.8 leads to the conclusion that the optimal block size is 15 MB. A bandwidth multiplication factor of 2 is the theoretical minimum that could be obtained via. improvements to the Bitcoin P2P protocol.

tl;dr: Trading off decentralisation and number of users in the US broadband environment results in an optimal block size of 3.8 MB. With P2P protocol improvements this could be up to 15 MB.

¹I'm assuming a future where IBLT is part of the Bitcoin P2P protocol, so that transaction data doesn't need to be sent "twice". I'm also assuming that most non-relaying SPV nodes use bloom filtering, so that not every transaction needs to be relayed to them.
^#All parameters marked with "#" are irrelevant to the optimisation. It turns out that tweaking these parameters ends up rescaling the y-axis of the decentralisation-utility graph (which we don't care about), but will leave the x-axis untouched (we do care about that as it has block size in it).

[Edit: Please see https://bitcointalk.org/index.php?topic=78614.msg1327630#msg1327630 for an updated prototype.]

Edit: Please see https://bitcointalk.org/index.php?topic=78614.msg1327630#msg1327630 for an updated prototype.

Hardware Bitcoin wallet is a project which aims to implement a minimal dedicated Bitcoin wallet. Its main difference with every other Bitcoin client/wallet out there is its low resource requirements: the binary is currently 25 kilobytes large, it uses less than 2 kilobytes of RAM and requires only 160 bytes of non-volatile storage per wallet. With such low requirements, I reckon a production device would be smaller, more robust and cheaper than any other Bitcoin wallet.

The wallet stores private keys (actually, it only stores a seed for the deterministic key generator), parses transactions and signs transactions. It essentially doesn't do anything else. This is by design - simpler means a smaller attack surface. Private keys are generated on the device and never leave the device, except when doing a wallet backup. Even then, the seed is only displayed - it is never sent over the serial port. My intention is that physical access to a device is required in order to obtain private keys or to spend anything. As an additional layer of security, wallets can be encrypted. An encrypted wallet offers pseudo-two-factor authentication: in order to spend BTC, you need to know the wallet passphrase and you need to have the hardware Bitcoin wallet.

Here's a somewhat messy prototype:

The thing on the left is an Arduino clone (though I'm not actually using the Arduino IDE or libraries). The bunch of discretes on the lower part of the breadboard comprise a noise source, which is used to generate random numbers. The input user interface consists of two pushbuttons (bottom-left and bottom-right corners), where the user can approve or disapprove of actions. This gives you an idea of the necessary hardware peripherals required. Of course, a production device would be much more compact than this .


Here's the prototype signing a transaction:

Here's an actual transaction that it signed: http://blockexplorer.com/t/AEhoN6bzjd.

The code is hosted at: https://github.com/someone42/hardware-bitcoin-wallet. Currently, there's only a port for the ATmega328 microcontroller. However, most of the code is platform-independent; porting to another microcontroller "only" involves writing drivers for the microcontroller's peripherals.

I shall commit to being open and transparent, releasing source code and hardware specifications as I produce them. If people are interested, I might even design a production hardware Bitcoin wallet. From simple BOM and assembly cost estimates, such a device would cost 6 to 7 USD per unit to manufacture (for a quantity of 1000). If anyone has questions/suggestions, feel free to ask in this thread.