1

Here are two RLP-encodings of two signings of the same transaction --- for Goerli. Notice how the "Signed by" address is different. This must be implying something is wrong with my signing procedure? The private key with which I'm signing is 6e08[...]28d8. The address relative to this private key is 3e21c651dfc21ee198bc2f735502eb82a2e8c4f0, so I was expecting to see "Signed by: 0x3e21c651dfc21ee198bc2f735502eb82a2e8c4f0".

%helpeth parseTx 0xf86d018612309ce5400082a4109479e4e5c6309eab8df0299973ef29ce2b001704a5880de0b6b3a7640000802ea02db2dc28cf1c6d049d773bd78c5fad9cca19e4e4e191e9ec80f5765c1a5739b8a0747602789e0b20eeca045e49260fc7382d937125178ea2e4a712326b7c0b8eb8
Signed by: 0xd07b876c0b06b6fea8de3df326518abc5a862c45
Nonce: 0x01
To: 0x79e4e5c6309eab8df0299973ef29ce2b001704a5
Value: 1000000000000000000 (1 ETH)
Data: 0x
Gas limit: 42000
Gas price: 20000000000000 (20000 Gwei)
Potential total transaction cost: 0.84 ETH
Minimum required account balance: 1.84 ETH

%helpeth parseTx 0xf86d018612309ce5400082a4109479e4e5c6309eab8df0299973ef29ce2b001704a5880de0b6b3a7640000802ea033f0f6603ce617e2bc67048c63ac7ee407b82517fb490e694030d43893c26b12a0725bb38fc835acc70290164eba994bfc144ef9151a7de5ea57880576f7895a65
Signed by: 0xe31621a692881e27467be5b22e3b15720fe1aa55
Nonce: 0x01
To: 0x79e4e5c6309eab8df0299973ef29ce2b001704a5
Value: 1000000000000000000 (1 ETH)
Data: 0x
Gas limit: 42000
Gas price: 20000000000000 (20000 Gwei)
Potential total transaction cost: 0.84 ETH
Minimum required account balance: 1.84 ETH
%
user66567
  • 21
  • 4
  • Hi there. I know this only relates to Georli, but please don't reveal private keys to the public. It's a bad habit to fall into... And even if a human doesn't see it, there are bots about. – Richard Horrocks Jan 28 '21 at 11:02
  • 1
    I surely wouldn't fall into the habit, but it doesn't cost me much to remove it from here right now. (Of course, it remains in the history forever now.) Thanks! – user66567 Jan 28 '21 at 11:29
  • That's fine, but I didn't remove it myself because anyone can just look at the edit logs :-) I would move the testnet ETH to a new address. (I don't know how reliable the Georli faucet is - if it's quick to get your hands on testnet ETH then it might not matter anyway.) – Richard Horrocks Jan 28 '21 at 11:30
  • 1
    It's quick, yes. But, no worries, I'll follow the local culture. Thanks for the tip. – user66567 Jan 28 '21 at 11:33
  • Signatures should be deterministic, so if the transaction is the same, the signature should be the same as well. There's likely something wrong with your signing method, as all the other transaction parameters in your RLP encoded data seem correct. – Morten Jan 28 '21 at 11:58
  • What do you mean signatures should be deterministic? This is an ECC-signature and my understanding is that ECC-signatures are not deterministic. Each two signatures of the same data should produce different signatures. – user66567 Jan 28 '21 at 12:01
  • @user66567 he is saying that same Private key on same message will produce same signature, i.e. deterministic – Nulik Jan 28 '21 at 15:19
  • nothing wrong with procedure, you just have a bug somewhere. do a debug output of your signing process and dump address of the signer before it enters the signing routine – Nulik Jan 28 '21 at 15:20
  • most likely you are using wrong private key – Nulik Jan 28 '21 at 15:21
  • I don't think so --- the same private key on the same message will produce different signatures because each signing process generates an ephemeral private key for the signature. So maybe you mean to dump this ephemeral private key during the signing process? – user66567 Jan 28 '21 at 17:34
  • I discovered that part of the problem is that the s value cannot live in the upper half interval of the curve order. Having fixed that, helpeth never thinks the signature is invalid anymore. However, it still recovers public keys incorrectly sometimes, very likely because I'm calculating v incorrectly. This question here, therefore, becomes how to calculate v properly. I hope I can calculate v from r and s without knowing the ephemeral private key --- because I don't think OpenSSL exposes such key me and I'm using OpenSSL for signatures. – user66567 Jan 29 '21 at 11:38

1 Answers1

1

The problem is in v. I don't have access to the ephemeral private key used in the signing process, so I can't easily get the y-coordinate of this private key, which I need for computing v. However, since I know the public key of the signer (which is myself), I can verify which v produces the correct public key, this way inferring which v I must encode the transaction with.

So, essentially, in such situation I need to brute-force v. I don't have another solution. For a better solution I'd need to modify the primitive libraries I'm using to calculate v for me during the signing process because the signing process is the one which has the information for calculating v precisely.

Assuming you have the correct y-coordinate, this answer shows you how to compute v.

user66567
  • 21
  • 4