This has nothing to do with RFC6979, however with ECDSA signing and public key restoration.
The (r, s) is the conventional output of an ECDSA signature, the place r is computed because the X coordinate of a degree R, modulo the curve order n.
In Bitcoin, for message signatures, we use a trick known as public key restoration. The very fact is that you probably have the total R level (not simply its X coordinate) and s, and a message, you may compute for which public key this might be a legitimate signature. What this permits is to ‘confirm’ a message with an deal with, while not having to know the total key (we simply do public key restoration on the signature, after which hash the recovered key and examine it with the deal with).
Nevertheless, this implies we want the total R coordinates. There might be as much as 4 totally different factors with a given “X coordinate modulo n”. (2 as a result of every X coordinate has two attainable Y coordinates, and a couple of as a result of r+n should be a legitimate X coordinate). That quantity between 0 and three we name the restoration id, or recid. Subsequently, we return an additional byte, which additionally features as a header byte, by utilizing 27+recid (for uncompressed recovered pubkeys) or 31+recid (for compressed recovered pubkeys).
Strictly talking the recid shouldn’t be vital, as we will simply cycle by all of the attainable coordinate pairs and examine if any of them match the signature. The recid simply quickens this verification.
Basically, if h is the cofactor, the utmost variety of totally different factors with given “X coordinate modulo n” will likely be 2(h+1). Within the case of secp256k1, which has cofactor 1, we get 2(1+1) = 4.
