xeth, core, event/filter, rpc: new block and transaction filters

[obscuren]

No description provided.

[frozeman]

eth_newBlockFilter works, but for eth_newPendingTransactionFilter seems not to be implemented

[frozeman]

This should probably be NewPendingTransactionFilter

[obscuren]

That's not the line you're looking for. But indeed, I implemented it as eth_newTransactionFilter. I'll change it to eth_newPendingTransactionFilter

[frozeman]

I tried both. Are sure that its also exposed to the RPC?

[frozeman]

I currently can't run the RPC test as the blocktest is not loading.

[obscuren]

I think this is now properly implemented:

Create filter

curl --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":1}' http://127.0.0.1:8545
{
    "id": 5,
    "jsonrpc": "2.0",
    "result": "0x0"
}

Send transaction

> eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[1], value: "10", gasPrice: "10"})
'0x3e477f3c0b66864a2d3775e8889f0f75a35dcb8f3d40c63a309a77375bccde56'

Get filter changes

curl --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x0"],"id":5}' http://127.0.0.1:8545
{
    "id": 5,
    "jsonrpc": "2.0",
    "result": [
        "0x3e477f3c0b66864a2d3775e8889f0f75a35dcb8f3d40c63a309a77375bccde56"
    ]
}

Get the transactions (including the pending)

> eth.getTransaction("0x3e477f3c0b66864a2d3775e8889f0f75a35dcb8f3d40c63a309a77375bccde56")
{
  transactionIndex: 0,
  value: '10',
  input: '0x',
  nonce: 329,
  blockHash: '0x0000000000000000000000000000000000000000000000000000000000000000',
  from: '0x1da8b4c338fcf6d64e64383f5a8d4da86eea9a6d',
  to: '0x30867b568b4cf518d4c432e8b140e1010e9f021c',
  gas: 90000,
  gasPrice: '10',
  hash: '0x3e477f3c0b66864a2d3775e8889f0f75a35dcb8f3d40c63a309a77375bccde56',
  blockNumber: 0
}

[frozeman]

will test in an h, thanks!!

[frozeman]

All seems to work fine!

But i have two things:

1. When i use eth_getTransactionByHash the console shows the following error I0508 09:42:10.729635 84136 xeth.go:257] EOF
2. I would strongly advise that we return null for the blockNumber and blockHash in the pending transaction. We agreed to that when we been here all together and i think its very necessary to allow for reliable checks.
   if you get a transaction using web3.eth.getTransaction('0x1235...') its hard to tell if its pending or not. Except you compare the blockNumber === 0, which imho is kind of wrong, as block number 0 is the genisis block. (This means we would have to explain that in the docs, that 0 means pending, whereas null is self explanatory)

I would do the same with pending logs (which rely on #852 to be fixed).

[obscuren]

No. null is not a valid hash neither a number.

null isn't right because it indicates a pointer type. The block number nor the hash is or should be a pointer (even if the internal type is). The right thing to do is to remove the field entirely (and therefor undefined)

[obscuren]

This PR will be merged because the change has been addressed. We can open a new issue for any pending (other) issues.