Path: csiph.com!news.mixmin.net!aioe.org!nv6aqDUptC4hH84sVxnTkg.user.gioia.aioe.org.POSTED!not-for-mail
From: Boris Dorestand <bdorestand@example.com>
Newsgroups: comp.programming
Subject: Re: an ethereum ECDSA-difficulty
Date: Fri, 29 Jan 2021 13:06:34 -0300
Organization: Aioe.org NNTP Server
Lines: 57
Message-ID: <864kiz3eyd.fsf@example.com>
References: <868s8c4zyu.fsf@example.com> <87im7fooo6.fsf@LkoBDZeT.terraraq.uk>
NNTP-Posting-Host: nv6aqDUptC4hH84sVxnTkg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.9.2
Cancel-Lock: sha1:b+wpXVwM6e64ndFpgKyJQ0ue8t0=
Xref: csiph.com comp.programming:12000

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.