bug fix for transaction receipts with multiple transactions in one block

[davidbancor]

When calling web3.eth.getTransactionReceipt() for a transaction which was mined with at least one other transaction in the same block, the logs returned include the logs of every other transaction in that block. As you can imagine reproducing the bug isn't trivial, but if you'd like i'll provide a detailed way to reproduce this issue. The fix I added in receiptserializer.js filters the logs in the block the transaction was included in to only return logs that match the original transaction hash.

[mikeseese]

@balexander4 verified this issue: #273 (comment)

[davidmurdoch]

Thanks, @davidbancor and @seesemichaelj! We'll need to write some tests for this before merging, but the fix itself LGTM!

[davidbancor]

Could it perhaps be an issue that the fix isn't normalizing the transaction hash to be lowercase, and then when calling web3.eth.getTransactionReceipt you can get different results for passing in a non lowercase transaction hash?

[davidmurdoch]

@davidbancor It could be. We'll need to add a test for that.

[davidmurdoch]

@davidbancor Opened an issue for handling mixed-case or uppercase transaction hashes, as Ganache doesn't currently support it (at least not for getting transaction receipts): #308

I don't think it is currently possible to generate a log or transaction that records an upper-mixed-case transaction hash in the context of the filter logging code this PR addresses, however I do think adding the toLowerCase check could prevent possible issues down the line so I'll go ahead and make the change. Thanks again!

[nicholasjpaterno]

Overall LGTM, I think we should discuss more how this effects forking.