callTracer is missing data for SELFDESTRUCT opcode

[errb]

System information

Geth version: 1.9.2
OS & Version: Windows

Expected behaviour

If a transaction trace results in the contract being self-destruct, callTracer should return the value that was transferred with SELFDESTRUCT opcode.

For example in this transaction you can see that 101.5 Ether was transferred when the contract was executed:
https://etherscan.io/tx/0x8006a2927a31404cf381e7a440a41d47e7a8e0c85a496f70bc6cac235987898f

Actual behaviour

Right now the trace only contains the opcode type but no other fields (like value, from and to that would show how Ether was moved).

Steps to reproduce the behaviour

1. Trace any transaction that executes SELFDESTRUCT opcode on a contract that still has Ether (for example: 0x8006a2927a31404cf381e7a440a41d47e7a8e0c85a496f70bc6cac235987898f):

> debug.traceTransaction("0x8006a2927a31404cf381e7a440a41d47e7a8e0c85a496f70bc6cac235987898f", {tracer: "callTracer"})
{
  calls: [{
      type: "SELFDESTRUCT"
  }],
  from: "0x005221f8f111036a49617178eb2e815a1ab74140",
  gas: "0x2c9e",
  gasUsed: "0x1755",
  input: "0xbe8360c5",
  output: "0x",
  time: "6.0095ms",
  to: "0x50bb21befa6c04f0c81a44edaea5f11d069791f8",
  type: "CALL",
  value: "0x0"
}

[holiman]

SELFDESTRUCT is a bit special, in that it isn't a proper CALL with a value. The op itself is not aware if the value (if any) that's being moved -- it is not like the other CALL-variants that way. The transfer of ether happens more as a side-effect of the termination. @karalabe any thoughts about if we can do anything about this?

[karalabe]

I'm a bit torn on this one. Currently if I make a plain transaction, that fails, the tracer just tells me that value V was attempted to be transferred, fail/succeeded. It doesn't explicitly tell me the amount actually moved (as in V or 0). If we were to add the value movements to suicide, shouldn't we add it elsewhere?

[holiman]

I think the value should be the value provided as argument in the CALL. There can be only two cases: either the call was successfull and value was transferred, or teh call was unsuccessfull and 0 was tranferred.

I don't know how to consider selfdestruct. There is no value in the suicide op, the suicide op only has a beneficiary. So semantically it shouldn't be there, but I understand that it would be practical...

[errb]

I didn't know that suicide op is not aware of the value moved. In that case it does make sense to not include it as a value in trace results.

The approach used in Parity traces seems interesting. They include balance for suicide op which I assume is equal to the value moved:

{
    "action": {
      "address": "0x50bb21befa6c04f0c81a44edaea5f11d069791f8",
      "balance": "0x58098703ade260000",
      "refundAddress": "0x005221f8f111036a49617178eb2e815a1ab74140"
    },
    "blockHash": "0x3866dbe8e02a6926b2b0b6593f30b4510490b80bd0405ed970fe10f25181878c",
    "blockNumber": 2707845,
    "result": null,
    "subtraces": 0,
    "traceAddress": [
      0
    ],
    "transactionHash": "0x8006a2927a31404cf381e7a440a41d47e7a8e0c85a496f70bc6cac235987898f",
    "transactionPosition": 3,
    "type": "suicide"
  }

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.