Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

getTransactionreceipt returns null for some transaction on ETC blockchain #5779

Closed
miningpoolhub opened this issue Jun 7, 2017 · 4 comments
Labels
F1-security 🛡 The client fails to follow expected, security-sensitive, behaviour. M4-core ⛓ Core client code / Rust.

Comments

@miningpoolhub
Copy link

Hi
I'm currently running ETC with Parity/v1.4.10-stable-4e6329a-20170118/x86_64-linux-gnu/rustc1.15.0

At block 3862300,
Calling eth_getTransactionReceipt to 0x0e914f05f01f3aa28c092bd1140094dffc32917a06352517ff0e96aa396ce901
returns null which should give some valid value.

gastracker also outputs error on viewing 3862300 block.
http://gastracker.io/block/3862300
( http://gastracker.io/block/3862301 works well. Seems like gastracker is using parity behind )

I can explore that block from etcchain block explorer.
https://etcchain.com/block/number/3862300

0x0e914f05f01f3aa28c092bd1140094dffc32917a06352517ff0e96aa396ce901
transaction has 0 amount transfer.
I think this caused some bug retrieving eth_getTransactionReceipt.

@splix
Copy link
Contributor

splix commented Jun 7, 2017

I can confirm this issue. It seems that Parity calculates tx hash incorrectly for some of the transactions.

For example block 0x5a27889310c457b3c3bf7739ffa7d6c5a463b104255fe39390f564b704319249 (at 3855567). For Parity eth_getBlockByHash RPC returns following transactions:

"transactions": [
	"0xe608e8c84c5a6ff3338a0b240e6ef500e54fcf75ce38a54790388c4ddbf5435c",
	"0xa9a1571663a7f2682d753a71180985b69c9283294bae009cc237136e6c254919"
],
"transactionsRoot": "0x3b4823d87c253eb22261b4fed467b32df7a8cd91079d4bf753e6e9f86184e8a1"

But Geth gives:

"transactions": [
	"0xe608e8c84c5a6ff3338a0b240e6ef500e54fcf75ce38a54790388c4ddbf5435c",
	"0x241901a9a7d64f1b8e157afc6659f97a2f40b5146d27b5f820d018773ab506b7"
],
"transactionsRoot": "0x3b4823d87c253eb22261b4fed467b32df7a8cd91079d4bf753e6e9f86184e8a1"

If you try to fetch tx data for tx 0xa9a1571663a7f2682d753a71180985b69c9283294bae009cc237136e6c254919 by using eth_getTransactionByHash RPC it returns null. But both works for 0x241901a9a7d64f1b8e157afc6659f97a2f40b5146d27b5f820d018773ab506b7

{"jsonrpc":"2.0",
 "method":"eth_getTransactionByHash",
"params":["0x241901a9a7d64f1b8e157afc6659f97a2f40b5146d27b5f820d018773ab506b7"],"id":1}

Parity returns:

{
	"jsonrpc": "2.0",
	"result": {
		"blockHash": "0x5a27889310c457b3c3bf7739ffa7d6c5a463b104255fe39390f564b704319249",
		"blockNumber": "0x3ad4cf",
		"hash": "0xa9a1571663a7f2682d753a71180985b69c9283294bae009cc237136e6c254919",

Notice that JSON output has invalid value for hash field.

Can reproduce with Parity 1.5.2 and 1.5.12. Chain resync didn't fix the issue

@5chdn 5chdn added F1-security 🛡 The client fails to follow expected, security-sensitive, behaviour. Z0-unconfirmed 🤔 Issue might be valid, but it’s not yet known. M4-core ⛓ Core client code / Rust. and removed Z0-unconfirmed 🤔 Issue might be valid, but it’s not yet known. labels Jun 7, 2017
@arkpar
Copy link
Collaborator

arkpar commented Jun 8, 2017

Fixed in 1.6.8. A re-sync is required.

@splix
Copy link
Contributor

splix commented Jun 9, 2017

@arkpar is there any plans to release a stable release with that fix?

@arkpar
Copy link
Collaborator

arkpar commented Jun 14, 2017

@splix The fix is in the stable branch, but we'll probably release 1.7 and stabilize 1.6 sooner instead.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F1-security 🛡 The client fails to follow expected, security-sensitive, behaviour. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

No branches or pull requests

4 participants