ok, i looked at some of the code. i see that you have basically written the elliptic curve calculates on your own. are you sure they are correct? is it tested?
i didn't understand two things:
1. why are you doing
this check? r + s doesn't have to be dividable by 2. and i can't find it anywhere that says this check is needed. do you know any reason i am missing? see 4.1.3 of SEC1
also i believe this
mod is completely unnecessary as the numbers you are giving it are 256-bit and mod with that larger number will return the same thing. not to mention that where it is being called the numbers (r and s for instance) must be 32 byte otherwise the implementation would be broken.
2. the other thing i didn't get is why are you using the private key itself for
generating a random number for signing. isn't there any better RNG provider to use?
might i also suggest
Separation of concerns. some files are too large (as in 1000+ lines) and it seems like they don't all need to be in one place.
nitpicking but
DER Format comment should really move to line 252 because that is where you are DER formatting

We are very pleased that someone from outside looks through our code.
This unit, secp256k1.pas was written by me, so I will tell you about your remarks.
This mod is required due to a flaw in BigInteger class which allows to generate n-bit integer number where n is all free bits in RAM. Sometimes it create an 257 bit number even with 256bit constraits in upper lines. So this module is security check to not allow damaged r,s pair appear in signature.
About d number (priv) in k generating you got right, there should be a trngBuffer instead of d. It will be changed in next release.
This comment about DER formatting has been missed out when code was moved down.
Our signatures are correct and they have been tested few thousand times.
Thank you for your contribution
