You are viewing a single comment's thread from:

RE: Why does steem use this canonical thing instead of strict secp256k1?

in #beyondbitcoin8 years ago

In fact, these more strict requirements make the system more secure.
You can realize that when you think about it from the information theoretical point of view. The requirement for r and s each being of length 32 means that the signature has to have a length of 64 (+1 for the pubkey recovery parameter). This requirement makes it impossible to leak information of the private key into the signature, no matter what you do.

As for not being deterministic, there actually is no requirement for it whatsoever. All that RFC6979 results in is a random k which is needed to prevent an easy derivation of k from two signatures (if the same k is used twice). This can be done by using RFC6979, or just some random timestamp. Being able to deterministically derive k has no other impact than making sure that k isn't reused. And for that reason, graphene (as well as most clients) implement RFC6979 and then permute the k if necessary.