chifra export - unreconciled txs II

[tjayrush]

This transaction: https://etherscan.io/tx/0x506e7978ba52886681b75797e4403579ba703b5f9df576a34602ada1709085fb

Does not reconcile. Reproduce with:

chifra export 0x054993ab0f2b1acc0fdc65405ee203b4271bebe6 --accounting --statements --ether --fmt json --first_block 15549161 --last_block 15549163 --asset 0xf5b2c59f6db42ffcdfc1625999c81fdf17953384

The reason this happens can be called a 'misleading airdrop.'

The smart contract generates events, but there is no change in any of the ERC20 balances.

We've been told this is method that people fish for private keys. "Hey, you got an airdrop, visit this website..."

This is a less expensive way to do this (they would have to pay for state changes otherwise).

We can delete these automatically by doing this:

1) Does the reconciliation not balance?
2) Is the transfer a token transfer?
3) Does the transaction contain more than some number (100?) of Transfer events?
4) Does the account balance at the previous block == account balance at end of the block? (no state change)

If yes -- ignore the event.

Covered by test case acctExport_failed_statement_2572_1.txt

[tjayrush]

This transaction https://etherscan.io/tx/0x634799410165000edaf1b1e8e5e8055b39cdd534d3c3dc9738865d39adb5d888 does not reconcile.

Reproduce with:

chifra export 0x65b0d5e1dc0dee0704f53f660aa865c72e986fc7 --accounting --statements --ether --fmt json --first_block 11670418 --last_block 11670420 --asset 0xc713e5e149d5d0715dcd1c156a020976e7e56b88

This happens because the smart contract does not generate events for the interest income.

Of course, this is an error by the smart contract.

Because we do not want to do "per-smart-contract" accounting (as this would be completely unsuportable), we will solve this in the following way.

Solution: We will create two new fields in our reconciliation data called impliedMint and impliedBurn. This will account for intra-appearance mis-balances. That is, reconciliation errors that occur internal to a transaction. If the actual ending balance of a transaction is below the expected value, create an impliedMint. If the calculated value is above the actual value, create an impliedBurn. In this case it would be an impliedMint because the interest is missing.

Solution for inter-appearance reconciliation errors: In this case, there is a missing transaction between the previous appearance and the current appearance. Here we will create a correctingMint and/or correctingBurn.

Covered by test case acctExport_failed_statement_2572_2.txt

[tjayrush]

This is the one Lefteris showed me: https://etherscan.io/tx/0xd1c7e3ac48006c0b15b73e854f2380e2fd2972f273884326a0f76f7158cc0401

[tjayrush]

Search for "DOES NOT BALANCE" in test cases.

Search also for "not balanced".

[tjayrush]

This PR (#2716) fixed the first of the mentioned issues (false airdrops) but maybe not the exact transaction mentioned above. A test case was added.

Keeping it open since not the whole issue is fixed.

[tjayrush]

This is just one:

chifra export 0xab5801a7d398351b8be11c439e05c5b3259aec9b --accounting --statements --ether --fmt json --chain mainnet --first_block 13505597 --last_block 13505599 --asset 0xadaa92cba08434c22d036c4115a6b3d7e2b5569b

but if one runs

chifra export chifra export 0xab5801a7d398351b8be11c439e05c5b3259aec9b --accounting --statements

one will see many more. This is Vb's address.

[tjayrush]

This command:

chifra traces  0x343ba476313771d4431018d7d2e935eba2bfe26d5be3e6cb84af6817fd0e4309 --fmt txt

used to produce three traces (one of which was fake). The fake one was added in the old C++ code so that reconciliations of what we call SuicideSends (a self-destruct that spends money and kills itself sending the ending balance of the transaction somewhere else.

When we ported to GoLang, we chose not to include this "fake" trace, but we did it during the port of chifra trace not chifra export. Therefore, there may be a lurking bug in the reconciliation that will be easy to forget (without this issue).