User talk:Hkdtam: Difference between revisions
→Regarding "Elliptic Curve Digital Signature Algorithm": new section
SqrtNegInf (talk | contribs) |
Thundergnat (talk | contribs) (→Regarding "Elliptic Curve Digital Signature Algorithm": new section) |
||
Line 23:
:: There were no errors in your code! Your translation from 'Go' was faithful and accurate. No bugs were fixed in my revision, I was just fussing around with the style of the code, as described in my github notes. The reason I replaced the output section was it was the easiest way to show how it looked with fewer digits of precision. thundergnat++ looked at my changes and pointed out how to use an 'anonymous container' to avoid creating a useless temporary variable. RC is all about learning... --[[User:SqrtNegInf|SqrtNegInf]] ([[User talk:SqrtNegInf|talk]]) 20:42, 28 January 2020 (UTC)
== Regarding "Elliptic Curve Digital Signature Algorithm" ==
Have you looked at trying the [https://modules.raku.org/search/?q=Digest%3A%3ASHA256%3A%3ANative Digest::SHA256::Native] module? It is a high speed C based implementation and should be much faster than the pure Perl 6 Digest::SHA. It would let you replace the lines:
my \z = :16((sha256 msg).list>>.&{"%02s".sprintf(.base(16))}.join) % $.n;
with
my \z = :16(sha256-hex msg) % $.n;
getting the same results, and should be much faster besides.
Also, the constants block
our (\A,\B,\P,\O,\Gx,\Gy) = (0, 7, # https://en.bitcoin.it/wiki/Secp256k1
:10("0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F"),
:10("0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141"),
:10("0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798"),
:10("0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8"));
would be better written as:
our (\A,\B,\P,\O,\Gx,\Gy) = 0, 7, # https://en.bitcoin.it/wiki/Secp256k1
0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F,
0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141,
0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,
0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8;
They are already integers, albeit expressed in hexadecimal, no need to convert to strings and then re-interpret them.
Thanks for adding this! --[[User:Thundergnat|Thundergnat]] ([[User talk:Thundergnat|talk]]) 23:27, 24 February 2020 (UTC)
| |||