Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #12000
| From | Boris Dorestand <bdorestand@example.com> |
|---|---|
| Newsgroups | comp.programming |
| Subject | Re: an ethereum ECDSA-difficulty |
| Date | 2021-01-29 13:06 -0300 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <864kiz3eyd.fsf@example.com> (permalink) |
| References | <868s8c4zyu.fsf@example.com> <87im7fooo6.fsf@LkoBDZeT.terraraq.uk> |
Richard Kettlewell <invalid@invalid.invalid> writes: > Boris Dorestand <bdorestand@example.com> writes: >> The nonce is 1, the gas price is 20 gwei, the maximum gas units is >> 21000, the to-address is correct, the amount is 1 ether = 10^18 wei, the >> data payload is empty, the v value of the signature is 46, as I intended >> and the r, s values of the signature are precisely those I intended to >> encode. Everything looks perfectly as it should. >> >> --8<---------------cut here---------------start------------->8--- >> out.rkt> r >> 30190652438768558380735263684943397541547868147655542157485309011183437025247 >> out.rkt> s >> 93620689063899170013813414230496747665687050654128603934107115817203536307811 >> --8<---------------cut here---------------end--------------->8--- > > That does not meet Ethereum’s signature canonicalization requirements. > > $ python3 > Python 3.7.3 (default, Jul 25 2020, 13:03:44) > [GCC 8.3.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> n=115792089237316195423570985008687907852837564279074904382605163141518161494337 > >>> r=30190652438768558380735263684943397541547868147655542157485309011183437025247 > >>> s=93620689063899170013813414230496747665687050654128603934107115817203536307811 > >>> s<(n//2)+1 > False > >>> > > See https://files.gitter.im/ethereum/yellowpaper/VIyt/Paper.pdf (212), p21. Thank you, Richard. That was part of the problem. I also went through another problem which is the fact that I don't have the full point r, only its x-coordinate, shown above. I don't think the package crypto-lib (https://pkgs.racket-lang.org/package/crypto-lib) exposes the full point r, so I was left with calculating the y-coordinate of r. However, there are at least two possibilities for such y-coordinate: sqrt(r^3 + 7) -sqrt(r^3 + 7) == -sqrt(r^3 + 7) + p, where p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F. So I essentially need to try both and see which ones match the signer when I recover the public key from the signature. I know the signer (it's myself) and so I look at both public keys and see which one is really mine, that is, I brute-force the v value. I must still learn to recover public keys from signatures. There are some details I might still not quite understand. Perhaps there are 4 possible public keys, instead of 2. Perhaps 2 of these 4 are very unlikely to come up. I'm studying these bits still. Thanks very much for your attention.
Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
an ethereum ECDSA-difficulty Boris Dorestand <bdorestand@example.com> - 2021-01-28 16:35 -0300
Re: an ethereum ECDSA-difficulty Richard Kettlewell <invalid@invalid.invalid> - 2021-01-29 13:31 +0000
Re: an ethereum ECDSA-difficulty Boris Dorestand <bdorestand@example.com> - 2021-01-29 13:06 -0300
Re: an ethereum ECDSA-difficulty "Dirk T. Verbeek" <dverbeek@xs4all.nl> - 2021-01-30 18:10 +0100
csiph-web