Depending on what your use case is, this might be useful: https://bitcointalk.org/index.php?topic=916441.0
The scheme described by Gus Gutoski will protect a parent private key from the release of a specific number of its child private keys.

Thank you for helping me find a better value for the bandwidth multiplication factor. My initial guesstimate of 10 was really handwavy and I agree with your methodology. But I do like to use real-world data, so:

• Number of peers: 20 seems like a good minimum value for a healthy Bitcoin network - 8 for outbound connections, 8 for inbound connections, and a few for crawlers/leechers.
• tx size: the average tx size of the last 20160 blocks, beginning from block 363900, was 560 bytes.
  
• inv messages: My sniffer logged 13743 packets with 18374 inv messages. Including the various protocol overheads, the result was 98 bytes per inv.
• tx messages: Overhead (as determined from sniffer) was about 90 bytes per tx message - so an average of 650 bytes per tx.
• block messages: I'll assume overhead is negligible here, since blocks are bulk data. Thus block messages contribute an average of 560 bytes per tx.

The result is (20 * 98 + 2 * 650 + 2 * 560) / (560) = 7.8
I shall update my original post/graphs with this factor.

I'm including overhead because ISPs do count overhead towards caps.

Interesting that nearly half of bandwidth attributable to a single tx is due to inv messages. Looks like there's room for optimisation there.

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).

I decided to analyse the situation in the case of mining pools. As a start, I used Meni's parameters as described in https://bitcointalk.org/index.php?topic=1078521.msg11557115#msg11557115.

Assume I have 1% of the total hash rate. I am currently in a 90% mining pool. There are also 10 1% miners. Using the results in Meni's post, my expected income per block is 0.04685 BTC.

Will I earn more by leaving the 90% mining pool and solo-mining?

If I solo-mine, the 90% mining pool is now an 89% mining pool and there are 11 1% miners. Solving for these parameters:
n0 = 7217 (slightly smaller)
n1 = 5945 (almost the same)
p = 0.6906 mBTC (slightly larger)
Penalty paid by 1% miners: f(5945) = 0.4602 BTC
Penalty paid by 89% miner: f(7217) = 3.3043 BTC
Average penalty: 0.89*3.3043 + 0.11*0.4602 = 2.9914 BTC
Reward per block for 1% miner: 5945 * 0.0006906 + 2.9914 - 0.4602 = 6.6368 BTC
Reward per block for 89% miner: 7217 * 0.0006906 + 2.9914 - 3.3043 = 4.6712 BTC

My expected income per block is now 0.06637 BTC, 42% higher than when I was in a mining pool. There is a very strong incentive to betray the large mining pool. I have not done any additional calculations, but I suspect it is also profitable for every individual miner in the larger mining pool to leave and solo-mine, or at least join a smaller pool.

Thus a sensible large mining pool operator should not mine supersized blocks. Meni, I realise you've come to this conclusion another way (higher income means higher difficulty), but this is yet another reason why rollover penalties discourage large mining pools from mining large blocks.

Why not have both an elastic block cap and floating block limits? A common argument against floating block limits is "big miners will create super-sized blocks full of crap to artifically inflate the block limit". This attack is conveniently addressed by your rollover penalties, as the penalty is a function of block size (not of transaction fees), so miners cannot game the system by including self-mined transactions.

Consider the following floating block limit function:
evaluated every N blocks.
With k = 1.0 and N = something large like 8064, we have an equilibrium situation consisting of the status quo, where everyone stays under the soft cap of T. If a large mining cartel wishes to inflate block sizes against the will of smaller miners, they must begin creating larger blocks and paying penalties towards the smaller miners, for each block. With sufficiently large N, this is not sustainable.

Let's say Bitcoin experiences sustained, long-term growth and the fee pool/demand increases. Now everyone, including smaller miners, is creating blocks larger than T. Everyone pays penalties, but in doing so, the "penalty" isn't really a penalty; everyone receives about as much from the rollover pool as they pay. After 8064 blocks, T increases to account for this genuine, long-term increase in demand.

There are lots of parameters here, and they can be adjusted to disincentivize a mining cartel from artificially inflating block sizes. For example, increasing N and making the limit function f(x) "harder" will both increase the cost to artificially inflate block size limits. Another possibility is setting k < 1.0 (e.g. k = 0.98), which means that maintaining the status quo has a cost. If miners unanimously decide to maintain the status quo, then no-one is actually penalised because everyone receives as much from the penalty pool as they pay. However, if smaller miners feel that the status quo is unreasonable (because of past bloat from a large mining cartel), they can choose to make smaller blocks and "bleed" penalties from the larger miners. However, I am concerned that setting k < 1.0 might implicitly set an absolute minimum transaction fee.

tl;dr version:
With floating block limits + rollover penalties:
mining cartel tries to artificially inflate blocks => they must subsidize smaller miners with penalties
Bitcoin experiences genuine, long-term growth => miners unanimously include more transactions => block sizes will increase

Anyone who wants to clone your code can just upload (unsigned) firmware that dumps the bootloader. The STM32F2xx's level 2 code protection does not prevent flash from being read by code that is running within the microcontroller. No, this won't get you the source, but if you're going to be making a 1:1 copy, you don't need source.

For those who are getting "usb_write" errors and are unable to power cycle the boards, here is some firmware:
https://www.dropbox.com/s/x9zhnm86uuzcn05/bitburner-fury-firmware_1.2.6.hex (BTB identifier, for cgminer < 3.6.0)
https://www.dropbox.com/s/l87xnp5mdfg6f8y/bitburner-fury-firmware_1.2.6_BBF.hex (BBF identifier, for cgminer >= 3.6.0)

This adds a soft watchdog which will auto-reset the microcontroller if the main thread blocks. This doesn't fix the cause of the usb_write errors (I'm still working on that), but it means that if they do occur, your boards won't sit there doing nothing.

For those with both Avalon and BitFury-based BitBurners, here is some firmware which will cause the BitBurner Fury boards to be recognised as "BBF" in cgminer >= 3.6.0:
https://www.dropbox.com/s/ae86stw2amyntna/bitburner-fury-firmware_1.2.5_BBF.hex.
This update does not fix any bugs or improve the hashrate in any way (over any previously released firmware). All it mainly does is change the USB product string so that cgminer uses a different identifier. Also, if you run "./cgminer -n", the Avalon and BitFury BitBurners should be easily distinguishable due to the new product string.

If using this firmware, note that voltage is now set in cgminer using "--bitburner-fury-voltage" instead of "--bitburner-voltage". "--bitburner-fury-voltage" will set the actual voltage, so there's no need for any 300 mV offset. Also, "--bitburner-fury-voltage" only affects boards which identify as "BBF", and "--bitburner-voltage" will only affect boards which identify as "BTB". This makes it more difficult to accidentally swap voltage settings.

The maximum core voltage for the BitBurner Fury boards is 1100 mV. This is a hard limit; if you really want to increase it, you will need to replace R35 (normally 12 k ohm) with something smaller.

To update firmware from Linux, you can try using pic32prog. Some modifications are required: see https://bitcointalk.org/index.php?topic=179769.msg2897971#msg2897971. I have made those changes in https://www.dropbox.com/s/7g7nygo7jbazd7z/pic32prog-an1388.tar.gz. After compiling it, power-on the boards and run "./pic32prog <hex file>" within the 12 second bootloader window.

About the "multiplied by 2" thing, that's a relic from when an input queue was introduced (you needed to multiply the actual number of miners by 2 to compensate for the input queue). cgminer versions >= 3.4.0 do not need the multiplication by 2. I think that instruction is there to account for people using older cgminer versions.

Are you using the latest firmware (https://www.dropbox.com/s/zn94oofozdn0eqb/BitBurnerFury_08.10.13.hex)? This firmware deals specifically with a "CAN-BUS causes usb_write error" issue. It only needs to be written onto the USB-connected boards, so it's okay if the CAN-connected ones aren't updated.

The baud rate, number of chips and timeout are all ignored (they're vestigial from the Avalon-based BitBurners). The number of miners should be 16 * number of boards in the largest stack. Since you've divided your stack up, it should be 64. But if you had all 8 boards in a single stack it should be 128. It's okay if the number of miners is larger than necessary, though you might get a slightly higher stale rate due to cgminer queueing up more work than necessary.

The cable should be a straight-through (pin 1 to pin 1, pin 2 to pin 2, ..., pin 10 to pin 10) flat ribbon cable with 0.05 inch pitch. If you have one with >10 wires, you can just tear off all but 10. The connectors should be female sockets, 2 rows of 5 pins, 0.1 inch between each pin (you probably already knew that from looking at the board), IDC termination. Something like this: http://www.digikey.com/product-detail/en/CWR-210-10-0203/CSR10S-ND/1122565 should do.

What voltage/frequency settings are you using? Setting too high a frequency can cause close to 100% HW errors. Also, it is normal to see a huge rush of HW errors just after the board is power-cycled. Eventually (after ~1000), the rush should stop. To make accurate HW error measurements, you should restart cgminer, or zero statistics ('d', 'z') after the rush.

The BitSafe hardware wallet is an open-source project. It did not originate from BFL (see https://bitcointalk.org/index.php?topic=152517.0 for the hardware side and https://bitcointalk.org/index.php?topic=78614.0 for the firmware side), though BFL are the ones commercialising it. Like many open-source projects, work was done in our (allten and I) spare time, on a purely voluntary basis. Since we have other things going on in our lives, sometimes that means that development stalls. Currently, development has stalled. I expect things to pick up in the coming months as I have more free time.

You may not find a hardware wallet useful. You are probably competent at computer security. A hardware wallet will not offer you much additional security. But what about "ordinary people", who may not be as well-versed in keeping their computers secure? How are they supposed to store and use their BTC? Hardware wallets like the BitSafe and Trezor aim to improve wallet security while remaining useable by ordinary people.

The --bitburner-fury-voltage option will only take effect if a board identifies as BBF (as opposed to BTB) in cgminer. The current firmware will always identify as BTB, although getting it to identify as BBF is as simple as changing the USB product string from "BitBurner" to "BitBurner Fury".

I'm going to hold off on changing the USB product string until pull #499 makes it into an official release. This is because changing the USB product string will stop the boards from being recognised by older cgminer versions.

Yes, this is a bit of a mess. But hopefully in a few weeks time, everyone will be using new firmware and new cgminer which will render all this "add 300 mV to the desired core voltage" business obsolete.

You could try overclocking and overvolting. I believe the maximum is 1100 mV (i.e. --bitburner-voltage 1400). You would need to do some testing to see what the optimal frequency is, but I think something around 300 MHz is achievable (based on the prototype that I have).

I should expand on what I said before. Theoretical hashrate is 11.63 * frequency, per chip. So for example, at 256 MHz, that's 2.98 GH/s per chip or about 47.7 GH/s per board. A frequency of 300 MHz corresponds to 56 GH/s per board.

I don't know what version of firmware you're using, but try using this one:
https://www.dropbox.com/s/fvc970hel90qwgd/bitburner-fury-firmware_1.2.4.hex

For instructions on updating firmware, see:
http://www.burninmining.com/assembly-instructions-part-2/

Try this:

Here's an explanation of the avalon-options parameter:

• 115200: baud rate. Ignored by firmware.
• 16: number of miners. Set this to 16 * number of boards.
• 10: chips per miner. Ignored by firmware.
• d: timeout. Ignored by firmware.
• 256: frequency. This sets the frequency of the external clock. The theoretical hashrate is 11.63 * frequency.

Like with the BitBurner XX boards, --bitburner-voltage controls the core voltage. However, since BitFury is 55 nm instead of Avalon gen1's 110 nm, the actual core voltage will be 300 mV less than what you set here. So "--bitburner-voltage 1230" will set core voltage to 930 mV. (Future versions of the firmware/cgminer will probably use a different identifier to avoid confusion.)

It is normal to get hundreds of HW errors/duplicate work on the first run after power up. This is a firmware bug. It should resolve itself in 30 seconds. If you do want to get accurate measurements of HW errors, run cgminer for 30 seconds, then restart cgminer.

In principle, yes, since the CAN-bus protocol is also the same. But in practice, you will get HW errors because of how cgminer's Avalon driver is implemented*. Also, frequency settings are broadcast across the CAN-bus and it's unlikely that you would want Avalon and BitFury to run at exactly the same frequency.

Maybe in the future, when a well-designed cgminer driver and corresponding firmware is written, you will be able to mix Avalon/BitFury/Cointerra/whatever BitBurner boards.

Voltage control for BitBurner boards from within cgminer was added in August (see https://github.com/ckolivas/cgminer/commit/b0f4d55be77adfacc3fd3e1bf0540a0252610455).

See https://github.com/ckolivas/cgminer/pull/499.

*cgminer's Avalon driver rotates through an array of work units. Mixing Avalon and BitFury will cause the array rotation to happen too fast for the Avalon boards, causing cgminer to forget about work units and resulting in "no matching work" errors.

About the software situation, I can clear this up a bit.

Though I am not burnin or cryptx, I am the person primarily responsible for the boards' firmware. The firmware for the BitBurner Fury boards emulates the Avalon protocol, just like the Avalon-based BitBurner XX boards. So there won't be any need for a customised version of cgminer. All the details of BitFury chip communication are abstracted away by the firmware. If you already have BitBurner XX boards, whatever setup you have will be fine for the BitBurner Fury boards.

Some minor changes to cgminer might be required since voltage settings are different (since Avalon = 110 nm, BitFury = 55 nm). Also, since the BitFury boards are much more powerful, some delays need to be adjusted to ensure that the cgminer driver doesn't become a bottleneck.

For HW wallets, there are faster (in raw bits/s) ways to collect entropy for < 1 USD in parts and with no user interaction required. I describe some of them here: https://bitcointalk.org/index.php?topic=127587.msg1434009#msg1434009, but I am sure there are many more ways. These also have the benefit of being internal, so it is more difficult for an observer to guess the state of your entropy pool.