To those who are getting "Idled 1 miners"-style messages in cgminer, it might be worth checking if you're hitting the cgminer overtemperature cutoff. I don't know how it is where you live, but where I am, it has been getting warmer. As a result, sometimes my Bitburners would hit the default cutoff of 60 degrees and then stop. The overtemperature cutoff is especially suspect if your miners stop once a day (since ambient temperature has a strong daily fluctuation).

The relevant cgminer option is "--avalon-cutoff" eg. "--avalon-cutoff 65" to raise it to 65 degrees. If ambient temperatures are increasing, I would also overclock a bit less, since higher temperatures seem to correlate with higher HW errors.

I'm not sure if this is the optimisation you're after, but section 2.2.6 of http://www.springeronline.com/sgw/cda/pageitems/document/cda_downloaddocument/0,11996,0-0-45-110359-0,00.pdf (from here: http://cacr.uwaterloo.ca/ecc/) describes the property as: the prime must be a sum or difference of powers of 2^32. secp256k1 doesn't have this property exactly, which is why your code has all that shifting in it.

Well, it looks like it's finally over. This morning, Avalon did a bunch of refunds. This group buy was one of them: https://blockchain.info/tx/730e45ef0d59847973bb9e80e6e05c014787e5c91b01094647a39d7a5ab76199.

(1JrwWrt3TYUzMYFEBLX5hTo1zFsEY6tWZN is an Avalon-controlled address. 1GxGpQrAS345PvYJaW4YANFiJQuRurLVjL is John (John K.)'s refund address for this group buy, as indicated in https://bitcointalk.org/index.php?topic=141672.msg3111564#msg3111564.)

Those results look very close the theoretical values for the relevant Poisson distribution (lambda = 1). The first 11 theoretical values are: {367.88, 367.88, 183.94, 61.313, 15.328, 3.0657, 0.51094, 0.072992, 0.009124, 0.001014, 0.000101}. This makes sense, since mining is a Poisson process.

Something I learned: multiple nonces within one work unit occurs about 2/3 as often as a single nonce. So you should be prepared to handle multiple nonces.

Here is something which might work. It is based on Pratt certificates (see http://en.wikipedia.org/wiki/Pratt_certificate).

Mining process
The miner attempts to find a large prime n which has the following properties:

• The most significant 256 bits are equal to the merkle root
• The prime is large enough to meet the difficulty target

The miner can do this by trying random large integers (the least significant bits are the "nonce") and running many iterations of the Miller-Rabin test. With enough Miller-Rabin iterations, the miner can be quite confident that they actually have a prime.

Proof of work
To generate the proof of work, the miner generates a Pratt certificate for their large prime n. Generation of a Pratt certificate is very hard; it requires the factorisation of n - 1, which is requires exponential time in the size of n. Yet it is easy to verify a Pratt certificate; verification is polynomial time in the size of n. For example, factorisation of a 1024 bit integer is about 7 million times as difficult as a 512 bit integer (according to http://en.wikipedia.org/wiki/General_number_field_sieve), yet it is only 16 times as difficult to verify.

This meets the criteria for a useful proof-of-work: hard to generate, easy to verify, adjustable difficulty and incorporates the merkle root.

Mining pools are more complicated to implement, since integer factorisation is not as trivially parallellisable as hashcash. This might explain why the initial client is solo-mine only.

It also has the property of being sensitive to improvements in factorisation algorithms. This makes it somewhat resistant to ASICs, since algorithm improvements may invalidate ASIC designs, so ASIC developers may not wish to take on the risk.

(Edit: linear -> polynomial)

Here's my identification of the parts. The layout seems to match this identification. I've also included a per-unit price estimation, based on 10,000 unit quantities at digikey.

Top left: NXP Semiconductor 74HC574 (octal D-type flip-flop), about 0.12 USD
Top middle: Atmel ATTiny2313 (8 bit microcontroller), about 0.72 USD
Top right: Silicon Laboratories CP2102 (USB to UART interface), about 2.30 USD
Bottom right: Alpha & Omega Semiconductor AOZ1021 (3A synchronous buck regulator), about 0.50 USD

Use these at your own risk!

For 325 MHz: buf[6] = 0x2b and buf[7] = 0x0a
For 350 MHz: buf[6] = 0xf3 and buf[7] = 0x0a
For 375 MHz: buf[6] = 0xbb and buf[7] = 0x0b
The meaning of these values is documented on page 6 of the Avalon ASIC (A3256-Q48) datasheet.

I personally don't think anything will be added to the block header within 5 years, since that would have the effect of making lots of existing ASICs useless. Also, if anyone wants to "add" some extra data to a block, they can already do this (in a way that's compatible with all existing miners) by using the coinbase.

What I mean by less-than-optimal is that since the SHA-256 constants are not hardcoded, some logic can't be optimised out at compile time. Within an ASIC, this would manifest as increased die area or power consumption. But I have no experience with ASIC design, so for all my ignorance it could be an insignificant 0.0001% increase or an embarassing 10% increase.

From reading the firmware source and looking at the released datasheet, the BFL chips interestingly do not have certain SHA-256 constants hardwired. The firmware is responsible for setting the SHA-256 initial hash value for the first hash, as well as the padding and length of both the first and second hashes.

What this means is that (for example) if an extra field were to be appended to the block header, the BFL chips could handle this change (via. a firmware upgrade), but the Avalon chips couldn't. This also means that the BFL chips are slightly less-than-optimal (I have no idea how much less than optimal), since some extra gates will be required to handle the possibility that those "constants" can change.

allten and I have been working on the Bitsafe, another hardware wallet. Its development history actually extends goes back further than Trezor's. There are assembled open-source development boards available (see https://bitcointalk.org/index.php?topic=152517.0;all), as well as prototype open-source firmware (see https://bitcointalk.org/index.php?topic=78614.0).

The Bitsafe project was picked up by Butterfly Labs, who are helping us bring it to market later this year. They have (understandably) decided to not do the preorder thing.

I spoke to etotheipi at Bitcoin 2013 and he was very enthusiastic about hardware wallets. He felt that they complemented Armory well. Anyway, I think Armory is well-positioned to support hardware wallets, after all, a hardware wallet is basically an offline signing wallet.

Thankyou for this. My experience has been exclusively with low-frequency stuff.

According to the IR3895 datasheet, if Vref is grounded, then the output voltage can be adjusted by changing the voltage on the Vp pin. So you can easily add the capability to adjust the ASICs' core voltage.

70% of those parts are decoupling caps for the ASICs. Is it really necessary to have 14 per ASIC? As a back-of-the-envelope calculation, I get about 5 nC of charge per clock cycle (based on 1.5 A @ 282 MHz). With 0.8 uF of lumped capacitance, neglecting ESR/ESL, that's about a 7 mV drop, which is small. Maybe you can get away with less? Maybe you can use larger capacitance values but fewer caps overall?

I suppose the only way to know is to do some in-circuit testing on actual ASICs.

Those 2" high heatsinks are quite beefy. The site claims a thermal resistance of 1.4 degrees C/watt for a 3"x4" section (presumably with natural convection). With such a thermal resistance, it looks like you can dissippate the heat of 16 chips with a slow/quiet fan, or perhaps no fan at all.

I'll join others here in saying that it's going to be much more cost effective to use a switching regulator with integrated MOSFETs. The NCP3170 looks appropriate.

As for C6, C7 and L2, these appear to form a low-pass LC filter. The corner frequency of such a filter is 1 / (2 * pi * sqrt(L * C)), and the filter is second-order. So for example, if L = 100 nH and C = 44 uF, the corner frequency is 75 kHz. This means the 642 kHz input ripple current is reduced by a factor of (642 / 75)^2 which is about 70. How low do you want the input ripple current to be?

Shipping info sent.

I'm in for 500 chips. I paid 40.01 BTC (TX ID: d5ac6ffd20f4ad6ecc4ae1975dafdd8e31fe4179ecf264a502509379171ecb5a).

I may throw in another 20 BTC if I can get the funds in time.

This is not quite what you're looking for, but: the USB 2.0 specification, section 7.2.4.1, states that the capacitive load presented by the device must not exceed 10 uF. I interpret this to mean that the current slew rate can be as high as you want (limited only by the inductance of the USB cable), as long as your current surges are in 10 uF gulps.

Here's another interpretation: each of those 2 byte register values can be interpreted as a little-endian integer, with bits 4 - 11 giving the core clock rate in 2 MHz increments. I would hypothesise that the 32 MHz clock is being pre-divided by 16, then multiplied by the factor given in this register. If that's true, it should be possible to tweak the clock rate in 2 MHz increments. If any of these DIY boards have a programmable power supply, then it could be just like the GPU days, with people tweaking their boards to get that extra few percent.

(As for why the clock isn't just 2 MHz to begin with, perhaps the 32 MHz is also used as a serial clock.)


The probability of two (or more) ASICs in a set of 10 hitting a valid nonce at the same time is about 2e-18. You could OR together all 10 outputs, ignore collisions, and get away with it (you'll lose a negligible portion of valid results).

Here's an update:

In October 2012, allten contacted me. He had designed some hardware but needed some firmware, while I had some firmware but only a hardware prototype. So we combined our efforts. He sent me a special development version of the BitSafe:




I spent some time porting the firmware to the BitSafe. I think the BitSafe will be the "home" of the hardware-bitcoin-wallet firmware, though much of that codebase is and will remain platform-independent. If you want to get your hands on some actual hardware, see https://bitcointalk.org/index.php?topic=152517.0.

The images above make the BitSafe look misleadingly large. This one gives a better sense of scale:


My immediate goals for the firmware have concentrated on integration with other parts of the Bitcoin infrastructure.

• The deterministic wallet implementation now uses the (proposed) BIP 0032 specification. This should allow wallets to be imported/exported across other BIP 0032-compatible Bitcoin clients.
• The wire protocol is being changed to make it more similar to that of slush/stick's Trezor. This should make it easier for Bitcoin clients to support hardware wallets in general.
• I began working on a P2SH (multisignature) address generator, to facilitate secure multisignature reception of funds. However, I've put that on hold to focus on more basic use cases.

Finally, since the last update, a difficult but significant goal has appeared. Gavin Andresen proposed a secure payment protocol (see https://gist.github.com/gavinandresen/4120476) which makes address rewrite attacks much more difficult. The problem with asking "Send 0.0461 BTC to 1QLbz7JHiBTspS962RLKV8GndWFwi5j6Qr?" is that an attacker could covertly rewrite this address and it is difficult for a user to determine whether a given address is genuine or not. With the proposed payment protocol, the prompt would be something like "Send 0.0461 BTC to mtgox.com?", where the name is validated using some sort of certificate chain.

Such a solution has been alluded to in this thread (see https://bitcointalk.org/index.php?topic=78614.msg880376#msg880376) and elsewhere, but Gavin Andresen's proposal looks likely to become "the standard". So I would like to implement it.

The device doesn't store blocks, block headers, or any transaction data. This makes it somewhat difficult to use in a POS situation. It's still possible: there is a "get master public key" command which allows the POS terminal to derive every address in a wallet. From there, the POS terminal can scan the blockchain and build a transaction. This is a lot of legwork for the POS terminal. Another disadvantage is that the user sacrifices privacy, since the POS terminal knows every address in the wallet.

A description of the wire protocol can be found at https://github.com/someone42/hardware-bitcoin-wallet/blob/master/PROTOCOL. I'm trying to make it like the one described here: https://bitcointalk.org/index.php?topic=125383.0.

You would need to have the correct encryption key in order to initiate a backup, but once you do, the paper backup can be encrypted or unencrypted. Encrypted paper backups can buy you time if the paper is compromised, whereas unencrypted paper backups protect you against you forgetting the wallet passphrase .