Difference in return value for 'r' parameter in getTransactionBy...

[tjayrush]

This curl command:

curl --location --request POST 'http://archive02.archivenode.io:8545' --header 'Content-Type: application/json' --data-raw '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x785b221ec95c66579d5ae14eebe16284a769e948359615d580f02e646e93f1d5", "0x25"],"id":1 }'

returns different values in the r key from both TurboGeth and Parity.

Nethermind returns:

    ....
   "r": "0x0acdf839bdcb6653da60900f739076a00ecbe0059fa046933348e9b68a62a222",
    ....

(64 characters and a leading zero)

Both TurboGeth and Parity return

    ....
   "r": "0xacdf839bdcb6653da60900f739076a00ecbe0059fa046933348e9b68a62a222",
    ....

(63 characters, no leading zero)

As bytes, these two values are identical. As strings, when returned from RPC, they differ.

Note, My guess is this happens with any transaction whose r has a leading zero, so not just this example.

[tkstanczak]

thanks @tjayrush

[tjayrush]

I actually think you guys have it right. You produce a 64 character (32 byte) response. Makes more sense to me than a 63 character response even though it's the same value.

[tkstanczak]

It depends on whether the number is treated as a byte array or number. If other clients treat r and s like numbers then it should be without leading zeros. pon., 12 paź 2020 o 16:00 Thomas Jay Rush <notifications@github.com> napisał(a):

…

I actually think you guys have it right. You produce a 64 character (32 byte) response. Makes more sense to me than a 63 character response even though it's the same value. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#2372 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADZZYJIWBM6YOXSFHQZ3XTSKMKZRANCNFSM4SLZKZMQ> .

[tjayrush]

To be honest, I don’t even know what ‘r’ and ’s’ (or even ‘v’) are or how they’re used.

According to the Parity docs (which may or may not be gospel) it's a QUANTITY: https://openethereum.github.io/wiki/JSONRPC-eth-module#eth_gettransactionbyhash.

But, according to these from Nethermind, they're DATA https://docs.nethermind.io/nethermind/ethereum-client/json-rpc/json-rpc-modules/eth#eth_gettransactionbyhash

[tjayrush]

I found this document which indicates that the r and s values are DATA, so I think you'all have it right. https://github.com/ethereum/EIPs/blob/794830d53ac68fc510637268eb37e37749fdb0b1/EIPS/eip-1474.md#eth_gettransactionbyblockhashandindex

[fjl]

I just found this issue using the new hive JSON-RPC test suite. All other clients treat r, s as QUANTITY and do not return leading zero. I know it's annoying, but for the sake of consistency among clients, we should change it to QUANTITY in Nethermind.

This issue originally came up in November 2018 for geth: ethereum/go-ethereum#18152
We discussed it on the ACD call a couple months later and decided to use QUANTITY because it matches the encoding of r, s in RLP for consensus.

[tkstanczak]

will look at it