enforce low S values on key signing, read BIP62 for details

Check bip62 for more information: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#Low_S_values_in_signatures

Format of the Signature: 
See https://bitcointalk.org/index.php?topic=8392.msg127623#msg127623

A canonical signature exists of: 

<30> <total len> <02> <len R> <R> <02> <len S> <S> <hashtype>


Where R and S are not negative (their first byte has its highest bit not set), and not
excessively padded (do not start with a 0 byte, unless an otherwise negative number follows,
in which case a single 0 byte is necessary and even required).

Below are the dumped scriptpubkeys from my test; the real signature starts with the 30 column, the S value is after the second 02 then comes the length and then the s value, then hash type etc.

examples of scriptpubkeys that work because the s value is low:

0047 30 44 02 21 00dec4407c7777e49d2e42cc4710a50176f3d4063a49a8658c13ab3d04a314c2f0 02 1f 26aebe7ec8474cbfef91ecab7246f797d43dbe2bf9fec9dd46dc05696adbb7     01 25 512102d0a664057b9242c7173a3f8842ab2032e5c195db366bbe920104728d8bf6aaff51ae 

0047 30 44 02 20 386a9f2fbc218219faf7a9e5261b8512a76923f9db5d50016b2158d144207c50   02 20 1bd063d2173fe1ee3cf661349b969bb61744c3adc9c64699a7e4b9596ce0115a   01 25 512103b951358030c5a41c358fd6d3870d7212dbfa12e66e9b636694dd6e4d18e109b451ae 

Non-working examples, see the length of them (21), those have been created using bitcore from within copay - bitcoin daemon rejects them with tx rejected (error: -22), non canonical signature:

0048 30 45 02 20 246ad12c521d2d0692495bf0d1552e41ee5391c9c68f07022a996915ebf18777   02 21 00cc2450cfb494dd8a0fbaee5e6bf63fff326dcb2df851aae79c2ce25cdd2aac02 01 25 5121034fe02d728e97ebcef8771016ca100cac74a02c33fdd79a4fa2726c866a4c48c651ae

0048 30 45 02 20 3336d46f4cf0cbc5a804f32639a5f47736ce4ec9d247388f5e2eb00b6a018812   02 21 00cc9f9b2c93371be7bd87beac84ccc3a4ac71f542cffb052f8fab99cdf04a825b 01 25 512102b8c7e29ecc5a01803aacc6b2778d0c971bfd80d04f4aef15bfbfdc12340ec2e451ae

0049 30 46 02 21 008b28eb0be6b6ab552856bf1c3193ccc0da93bc0c045e6070614e1356f972b4f3 02 21 00fb91dc51591ec0871b42a81d169817c15f14b3ea162ba5084e2d1366c0947e54 01 25 51210266e27df5628c50b8cffa4b8e2f0789fe928099e04437f34f64633f7c786d4ef651ae

0048 30 45 02 20 4bca238d85bc5f1791b1ea3209bf586063607190d2f5f7de6224c7c68d36e270   02 21 00d33a3abfbd0bc3787d9626cf2d205f4f23bf720a5e4c9eebae1ae44d5914f8a2 01 25 51210216311e5472371bc8be25eb30aa74f2f7c41d880f0f2d9d1fe896d856cd2c50c651ae


This was pretty annoying to find ;)


Yes, 0x7FFF.... is half of the curve (n).

For more performance we can either hardcode it to 0x7FFF... or use bitshift right for faster calculation.

I´ve chosen to keep it simple to make the code more readable and easier to understand.

Maybe we should put it into https://github.com/bitpay/bitcore/blob/master/lib/common/Point.js#L9

theres already n defined anyway so it doesnt get calculated on every signing.