Do not transfer ETH with selfDestruct about design

[ehildenb]

@axic and I had a similar discussion about this yesterday (adding a seperate EEI method transferFunds and using that for the various call/selfdestruct). I think the concern was that then the owner of the contract being transferred to has no say in how to execute when people transfer into it. I think it's a good idea though, to add such a primitive transfer. People could take advantage of the safer transfer on the ewasm shard instead of an empty call.

[chfast]

I'm aware of the cons of such transfer(). But you can emulate it in EVM1 by creating a temporary contract and selfdestructing it. Such ether transfer is unnoticed by the targeted contract.
If the evm2wasm is still a goal, i propose to have simpler EEI functions and have other EVM1 quirks implemented in evm2wasm so the eWASM is not polluted.

My questions is, can you implement fully compliant EVM1 SELFDESTRUCT having the EEI functions as described above?

[ehildenb]

I think so. I'm still working on the K spec for the EEI, and my focus is on conforming to the type signatures that eth_interface specifies, while using the EEI functionality directly with KEVM (so moving the logic out of KEVM that is needed into KEEI). If the KEVM tests pass with the KEEI, then we know it's possible.

[ehildenb]

Advantages of having an executable spec :P

[chfast]

Changes proposed in #113.