Great news to hear!  I hope you have time to also enjoy the trip; I'll bet Moscow is very beautiful place.

Thank you for taking the time to write out these detailed updates.

This is both incredibly fascinating, and a beautiful show of the kinds of innovation the Bitcoin system supports!

Stockholm syndrome or something similar to it, I would suppose.  Miners 'round these parts have suffered many abuses from many mining equipment companies.

On topic, I have no stake in this particular complaint, but to-date I held friedcat and ASICMiner in high regard.  It is disconcerting to see them ignoring some of their most important customers.  It was these early auction customers that established the market price for ASICMiner's hardware, and consequently fueled the continued rise of their dividends and stock price.  It seems unwise to ignore them now.  Again, I don't own any of their auctioned blades, but regardless share your concern and would like to see friedcat make their customers whole.

In a related event, friedcat recently offered heavily discounted coupons for early USB stick customers (like myself).  It was, of course, not strictly necessary and seemed to be a rather gracious gesture on their part, for which many of us were excited and grateful.  However, ASICMiner initially only shipped a fraction of the discounted quantities, leaving us waiting a few weeks before the rest were shipped.  By the time I received all of my discounted sticks (through a group buy), friedcat had already dropped the wholesale price to match the "discount."  While not dishonest, it was completely disappointing and really, in my opinion, destroyed the goodwill I assume it was intended to generate.  Especially so, given ASICMiner's golden track record previously.

I want to hope that ASICMiner simply got caught off-guard by the emergence of so many competitors, causing them to scrap their 2nd gen chips and move directly to 28nm.  This would explain friedcat's lack of attention of communication lately, as such a rapid shift would leave everyone at ASICMiner exceedingly busy and stressed.  One can only hope...

Good catch!  Looks like a typo to me.  I'd edit it, but I'm not sure about the rules on editing BIPs on the wiki.

I don't think that'll work.  Here's why:

Suppose we simplify BIP32, to make my explaination easier, but without loss of generality:


The weakness here, that you're trying to solve, is that if any derived private keys are leaked, an attacker can find the parent private key, and thus all derived keys:


Now, from what I understand of your proposal, you'd modify that like so:


Where x is a secret not given to an auditor, and X is the associated public key (given to the auditor).  If a derived private key leaks...


Therefore, if one private key in a branch leaks, all derived private keys leak.

256-bit ECDSA has a security strength of 128-bits under classical computing.  Under Lamport, that would require signatures of length 128 * 128 bits, which is 2 KB.  The public keys would be 4 KB. (Source)

To have an estimated security strength of 128-bits under quantum computing, Lamport signatures would be 256 * 256, which is 8KB. (Source)

I would say the size of the signatures would be one reason.  The inability to re-use them being another.  What if you received bitcoins to a Lamport derived address after you already spent from it?  Now you can't spend the extra bitcoins.

Also, are Lamport signatures going to offer significantly more protection than one-time ECDSA with pay-to-hash?  Using ECDSA that way, even if ECDSA is broken, would only be weak for the 10 minutes or so before a transaction gets into a block.  Can we reasonably foresee a break in ECDSA so profound that it can be performed in under 10 minutes?

Seems like the real issue is that broken ECDSA will break BIP32, our means of allowing convenient one-time-addresses.  And BIP32 can't be applied to Lamport, so Lamport doesn't help here either.

Keep them updates comin'!  It helps distract me from watching the Oculus shipping thread(s)...

No problems here.  Heck, you can round up my order if you're lazy

It's been going up 30% each readjustment lately.

Round of applause.  Very awesome to see!  Thank you for sharing, and pushing to warner's repo.

Personally, I'd like to see it use a separate HMAC-DRBG module, to help code separation, unit testing, and code reuse (https://github.com/fpgaminer/python-hmac-drbg is public domain).  Also, the possibility to swap out HMAC-DRBG for a different function, so it can be used as a test-bed for using plain HMAC.

I reached out to Colin Percival (who wrote scrypt, for example) for his thoughts/comments on RFC 6979.  Here's what he had to say (with his permission):


This seems to be in agreement with pretty much everyone else's opinion on RFC 6979, which is good to see.  Many thanks to Colin Percival for taking the time to respond to my inquiry!

Shameless self-promotion: https://github.com/fpgaminer/strong-arm

Looks to me like the LUT implementation of EC scalar multiplication.  You have 256 pre-computed values, each of the form 2^i * G so you can just add them together depending on the bits of the scalar.  I can go into a more detailed explanation if you would like.

I chose not to implement that optimization in strong-arm, since it really wasn't much of a bottleneck, and I personally prefer transparent code over optimized code.  Easier to audit and avoid bugs.

You can do that in pseudo-RFC 6979 by just reseeding the DRBG with any extra entropy you'd like.  Though, as natb pointed out, gmaxwell and others believe it best to leave things fully deterministic.  I'm ... still on the fence, but leaning more towards deterministic after reading gmaxwell's arguments.

Two stages, depending on user paranoia:

1) Update the device before using it, with known good firmware (cryptographically signed + deterministic compilation). [Does not rule out rootkit]
2) Open the device, visually verify hardware, and use JTAG/SWD to manually wipe and flash. [Rules out rootkit, FPGA masquerade, etc]

This will mitigate all reasonable attacks.  The only one left would a malicious custom ASIC pretending to be the MCU.  But if your attacker is willing to spend millions of dollars ... hell, you must be doing something right in your life.

Yes, there are a million and one ways to attack a user when a malicious party can manipulate the hardware.  But, you make a great point regardless; better safer than sorry.

Rather than that, and assuming you have a trusted computer on which to do all this (since it will have access to your master key), just build the backup manually using your own entropy and restore it to the device.  Then query the device for a few public keys to verify it's using your backup.  I specifically left this option open on my platform, so that advanced users could choose their own means of creating the master key.  For example, choosing it like a brainwallet.

As usual, gmaxwell, your comments are wonderfully insightful and helpful.  Thank you for taking the time to bat around these ideas with me (and the rest of the community).

Well, if the Satoshi client had used uint32 ...

Except now nVersion == 0 or with the high bit set is non-standard

Anyway, thank you for the response!  I was just curious, and wanted to make sure there weren't going to be any other weird bugs cropping up because of it.

No need, just check the r value OpenSSL returns.

Until BIP 0032.5 is formalized and we feel more comfortable about it, this isn't a bad check to have in my opinion.  Combined with continuous random number generator tests (you should have those anyway, to protect private key generation).

gmaxwell, I'm curious about a discrepancy between the wiki's Protocol Specification page, and the Bitcoin-QT client's CTransaction class.  The wiki says nVersion is uint32.  CTransaction says int.  Which is correct?  Should the wiki be updated?  Seems to me like versions should never be negative, and uint32 is thus more appropriate.

gmaxwell proposed BIP 0032.5, calling for the usage of a deterministic version of ECDSA.  Deterministic ECDSA signature generation (like the one defined by RFC 6979) is compatible with existing ECDSA verification implementations, so any Bitcoin client could use it today.  Neat!  I have a thread open discussing RFC 6979.

It may be wise for applications to run continuous health checks on any RNG they're using.  FIPS 140-2 requires a simple one, for example.  Maybe even run a cut-down version of DIEHARD every so often?

Pffft, sissies.  I soldered 0402 with a big honking chisel tip on my Hakko.    Not that I'll ever want to hand solder 0402 again.

But for the love of electronics, please get good solder.  Good solder, good iron, and flux is all a man needs to be happy.

On a related note, if a solid ⁽¹⁾ hash function actually did exist, it would have some groundbreaking implications: Theoretical implications of one-way functions.

(1) "In computer science, a one-way function is a function that is easy to compute on every input, but hard to invert given the image of a random input. Here, "easy" and "hard" are to be understood in the sense of computational complexity theory, specifically the theory of polynomial time problems." ~ Wikipedia:One-way function

For both CKD functions, it is okay for IL to be 0.  You only need to check that IL < n.  (and that k_i != 0)

IL being 0 means the child's EC key pair is equal to the parent's EC key pair, which is a bit odd, but not explicitly forbidden by the current BIP 0032.  (NOTE: The extended key may still differ in these cases)

I just finished a more detailed look at the code.  There were only two bugs, both pedantic in nature.  The rest of the code looks fine to me.