chifra export: Example of an unreconciled transaction

[tjayrush]

For address 0x5e7b645d5bf86750cb1913122ba8a8545e2a9fd1 and transactions 10045927.52 and 10045927.53 (which, it should be noted are in the same block) the second transaction does not reconcile, but the first one does.

Truth is, the first one is incorrect.

This happens because .52 spends 11.466 Eth which is then recouped by .53.

The value of .52 is 0.00 at the top level, but has a trace that has an 11.466 expenditure. Since we try to avoid looking at traces if we can (because of performance), we do not dig into traces of .52 since it appears to balance (given that we only have per-block balances and .53 offsets the expenditure.

Possible solutions:

1. dig into every trace for every transaction (BAD IDEA - PERFORMANCE KILLER)
2. keep track of 'block balances' which is true if all transactions in a block balance, and false otherwise. If a block has more than one transaction for the address of interest, and if any don't balance -- rerun entire block with full tracing enabled.

[tjayrush]

Note that .53 reports being out of balance, while in reality .52 is.

[tjayrush]

Another excellent example is for this address: 0xd2f5852eb4b0c12c23a97914b2a9d954cf621781.

The first 'found' transactions has a non-zero balance. This is because it is a smart contract that had ether sent to it before the smart contract existed -- that is it is a counterfactual send. The mobil app that creates this type of smart contract knows before instantiation the address of the smart contract. It sends ether to that address. Then, and only then, does it send the transaction that creates the contract.

Our code, finding a smart contract, only starts its search for appearances when that contract is instantiated. Therefore, the first transaction is out-of-balance.

Solution: If a smart contract has a non-zero balance on the block prior to its deployment -- start the search earlier.

This information may be of interest:

function isContract(address account) internal view returns (bool) {
// According to EIP-1052, 0x0 is the value returned for not-yet created accounts
// and 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 is returned
// for accounts without code, i.e. keccak256('')
bytes32 codehash;
bytes32 accountHash = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470;
// solhint-disable-next-line no-inline-assembly
assembly { codehash := extcodehash(account) }
return (codehash != accountHash && codehash != 0x0);
}

[tjayrush]

The initial example above no longer fails to reconcile. Closing.

I will open another issue for the second example, which is actually working as designed.