self_destruct should auto-create beneficiary

[Stebalien]

Currently, if the beneficiary doesn't exist and is, e.g., a key address, we don't automatically create it. This differs from send where we do.

[anorth]

I concur

[anorth]

See also #726

[Stebalien]

Proposal: Just treat this as a method-0 send with no parameters. I.e.:

1. Lookup the current balance.
2. Call send (charging all the normal send gas).
3. Delete self (refunding nothing).

[Stebalien]

Ok, so, the issue with that approach is that it conflicts with the approach taken in #273 assuming we ever allow code on method 0 sends (#835). Basically, I'm concerned about re-entering a half-dead actor.

---

New proposal: remove the "beneficiary" from self-destruct, and burn any remaining balance. This puts the user in control of how the distribute funds and simplifies the implementation.

[Stebalien]

In other words, the user should now:

1. Call send (as many times as necessary) to drain the account.
2. Call self_destruct with no arguments.

[Stebalien]

Er, maybe better to just reject the call to self_destruct rather than burning money.

[Stebalien]

filecoin-project/FIPs#524

[Stebalien]

E.g. an entry point actor that needs to pay its own gas? It'll probably have some refund amount that needs to be burnt, at least.

I'd moderately prefer to burn just the refund but still reject self_destruct otherwise. It's a nice safe-guard to some otherwise nasty re-entrency bugs. I.e.:

1. Send away funds...
2. Send causes a chain reaction, granting us funds.
3. Self destruct burns them.

[anorth]

Ok so that would require a method inside the actor itself to (1) send its entire balance somewhere (the gas limit having already been reserved), and then (2) call self_destruct with no remaining balance.

But that is basically what self-destruct does! (When modified as you proposed to use a basic send). I don't really get the "re-entering a half-dead actor" concern if self_destruct works in this straightforward way.

However, I'll be convinced by an argument that there's some complexity here, and we should kick that complexity out of the VM and make the actors handle it.

[Stebalien]

Yep, the idea is to punt all the complexity to the user.

My primary concern is that, if we ever allow users to run code on method 0, the "send" from self_destruct could:

1. Fail for some reason. We have no good way to return the error to the user.
2. Re-enter the actor that's self-destructing, possibly sending it funds in the process.

We can handle these cases, but it's simpler to just ask the user to drain their actor before calling self_destruct.

[Stebalien]

We've worked around this in the EVM by sending, then self destructing. Punted to M2.2 to avoid yet another FIP.