@gmaxwell Want to review?

@sipa maybe its taken care by secp256k1_rfc6979_hmac_sha256_initialize, but RFC6979 specifies:

If that value of k is within the [1,q-1] range, and is suitable for DSA or ECDSA (i.e., it results in an r value that is not 0; see Section 3.4), then the generation of k is finished. The obtained value of k is used in DSA or ECDSA.

Is this handled externally [to that function] as part of the libraries signing process?
In which case, I assume you feed T back in somehow?
If you don't feed it back, and just restart, then technically this isn't RFC6979 compliant.

@dcousens Right, secp256k1_rfc6979_hmac_sha256 only implements the PRNG side of the construction. The specific use as defined by RFC6979 is done inside the signing code.

With benchmarks on

src/bench_internal.c: In function ‘bench_rfc6979_hmac_sha256’:
src/bench_internal.c:268:9: error: too many arguments to function ‘secp256k1_rfc6979_hmac_sha256_initialize’
         secp256k1_rfc6979_hmac_sha256_initialize(&rng, data->data, 32, data->data, 32, NULL, 0);
         ^
In file included from src/bench_internal.c:11:0:
src/hash_impl.h:205:13: note: declared here
 static void secp256k1_rfc6979_hmac_sha256_initialize(secp256k1_rfc6979_hmac_sha256_t *rng, const unsigned char *key, size_t keylen) {
             ^
make: *** [src/bench_internal-bench_internal.o] Error 1

Rebased and fixed bug found by @apoelstra.

ACK. (but see nit)

tested ACK

Addressed nit.