getBlockByNumber response object does not include nonce property

[sammy007]

Same for getBlockByHash via RPC and via console. Same for web3.eth.getUncle.

[sammy007]

Well I see nonce is not even defined in a Block struct https://github.com/ethcore/parity/blob/master/rpc/src/v1/types/block.rs#L38

[debris]

It's intended. Please see ethereum/EIPs#95 . For ethash engine, first element of seal_fields is a nonce.

[sammy007]

So there is sealFields: [nonce, mixDigest]. And the response might be sealFields: [mixDigest] if block is not PoW block. Correct? I am asking because I use nonce to find block found by pool since there is no way to get hash before job submission. With both nonce and mixDigest it's even better.

PoA is a new name for upcoming PoS?

[sammy007]

I see that param order is different, [mixHash, nonce] vs [nonce, mixHash] in proposal. Please fix in EIP or in parity otherwise there very likely will be another inconsistence between geth and parity.

[sammy007]

Also while mining I found that parity returns broken nonce and mixHash for uncle blocks via RPC:

submitWork:

nonce: 0xc9a86158ff0cea0e
powHash: 0x50a4472e4949d7e3f1bea31a8fd223823820f2f0f38db6d3bb67979ac563015e
mixDigest: 0xed5b0ca9b4a8f00aaf9b4b3b9ede7d20b0cab7f085e1e5a51553af9a7886c252

curl -X POST http://localhost:8545 -d '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0xe9a1d", "0x0"],"id":0}'

Parity:

{"sealFields":[
  "0xa0ed5b0ca9b4a8f00aaf9b4b3b9ede7d20b0cab7f085e1e5a51553af9a7886c252",
  "0x88c9a86158ff0cea0e"
]}

mixHash: 0xa0ed5b0ca9b4a8f00aaf9b4b3b9ede7d20b0cab7f085e1e5a51553af9a7886c252 <- extra a0

nonce: 0x88c9a86158ff0cea0e <- notice that extra 88

Geth:

{ "nonce":"0xc9a86158ff0cea0e" }

[debris]

you are absolutely right! These are remainings of rlp encoding. fix and tests on the way.

[sammy007]

@debris Thanks. I am highly concerned about the order of nonce and mixHash in sealFields. Please update either a EIP or parity. I wanna make pool usable with parity and such uncertainty should be resolved before it's too late :)

[debris]

I fixed decoding of seal_fields in #1094

also I updated the EIP and it now has the correct order of seal_fields - mixHash followed by nonce

"seal_fields": 
[
  "0x11bbe8db4e347b4e8c937c1c8370e4b5ed33adb3db69cbdb7a38e1e50b1b82fa",
  "0x0000000000000042"
]

[gavofyork]

@debris there are two ways to fix this:

• implement a generic RLP -> JSON transcoder and transcode each of the seal fields individually into the seal_fields JSON list. for now there are only data fields so you only have to handle one case.
• use Engine::extra_info along with the Engine instance to tell you about nonce and mixHash within the JSON RPC module. you'll need to implement Ethash::extra_info.

[oliverw]

@debris @sammy007 I'm a bit confused. The issue has been closed but I'm still seeing the the a0 and 88 prefixes mentioned by @sammy007 in the results returned by the latest parity release (Parity/v1.7.3-beta-d097956-20171009/x86_64-linux-gnu/rustc1.20.0). Could anyone clarify?

[sammy007]

Can confirm it on 1.7.4 as well.

[sammy007]

Also, this call #1090 (comment) returns {"jsonrpc":"2.0","result":null,"id":1}. Maybe because pruned, or for some other reason.

[sammy007]

This rpc issue breaks existing software which depends on parity rpc. Does it mean that a fix is delayed until 1.9?

[5chdn]

Yeah that needs a patch.

[atlanticcrypto]

Does this problem carry over to the 1.8.x beta release as well? Or is that a good fail-over choice during the patch of 1.7.x?

[atlanticcrypto]

Any update on the timing of this patch? Thanks.