1
I have created a raw transaction, added the hash code, and Double-sha256 this result. Now I should sign this hash with the private key, which would give me the DER encoded signature, but I'm not clear on what exactly I should be doing. How do I SIGN this hash with the private key? What exactly would I be doing? I am not using any crypto library, except for SHA256, and I have implemented secp256k1 my self, so I guess in relation to that, what should I be doing with the private key and the hash? I am specifically aimed at step 15. If I were to guess, this and this are essentially my answer, unless I am mistaken, and if I am, I would like to know why. Otherwise, the caveat with those answers is the introduction of a random nonce. Why could I not just have the private key = "k" (since you shouldn't reuse addresses anyway, right?), calculate "s", and concatenate "r" and "s"? Or is this how it IS done?
This seems relatively close to what I am looking for, however, in this example, wouldn't "k" simply be the private key, and "p1" simply be the public key generated from this private key (code I already have), leaving "s" as the only added calculation I would need to implement in order to sign the hash? – doffing81 – 2017-01-11T18:54:14.093
use k=priv would comprimize your private key if you try to use it more than once – amaclin – 2017-01-11T19:23:27.667
Indeed, that is why I assume address reuse is not recommended in Bitcoin. Still, k=priv is essentially what is done, no? – doffing81 – 2017-01-11T19:25:13.933
I mean, what good is the private key if you introduce a random nonce? I believe the answer is related to my first comment here. If all I have to do is calculate "s", and concatenate it with a public key derived from the private key (without a random nonce)... game on. If this is not the case, I would like to know how, or why? – doffing81 – 2017-01-11T21:26:10.103
you must keep the 'k' value secret. – amaclin – 2017-01-11T22:06:14.780
My question would be how the private key is not secret, but I'm assuming you'll go down the path of address reuse, which is fine. I guess I have to assume that a random nonce is necessary, even though I question it when you don't reuse an address. Looks like I'll have to read up on this
– doffing81 – 2017-01-11T23:19:08.517Do not use k=privkey. Doing so will instantly reveal the private key to everyone. The standard algorithm for choosing k is RFC6979. – Pieter Wuille – 2017-01-12T22:07:52.183
Thank you Mr. Sir Pieter Wuille :). I haven't actually worked past this point yet in the transaction signing process, which is where my ignorance comes into play, but have indeed discovered that RFC6979 is the standard, as per the link in my answer, and am currently looking into that standard. – doffing81 – 2017-01-12T22:14:31.583