-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
self_destruct should auto-create beneficiary #736
Comments
I concur |
See also #726 |
Proposal: Just treat this as a method-0 send with no parameters. I.e.:
|
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. |
In other words, the user should now:
|
Er, maybe better to just reject the call to |
I'd moderately prefer to burn just the refund but still reject
|
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. |
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
We can handle these cases, but it's simpler to just ask the user to drain their actor before calling |
In the EVM: 1. Self destruct continues even if it sends funds into oblivion. 2. Self destruct will auto-create a beneficiary. This lets us punt filecoin-project/ref-fvm#736 to M2.2.
In the EVM: 1. Self destruct continues even if it sends funds into oblivion. 2. Self destruct will auto-create a beneficiary. This lets us punt filecoin-project/ref-fvm#736 to M2.2.
In the EVM: 1. Self destruct continues even if it sends funds into oblivion. 2. Self destruct will auto-create a beneficiary. This lets us punt filecoin-project/ref-fvm#736 to M2.2.
In the EVM: 1. Self destruct continues even if it sends funds into oblivion. 2. Self destruct will auto-create a beneficiary. This lets us punt filecoin-project/ref-fvm#736 to M2.2.
In the EVM: 1. Self destruct continues even if it sends funds into oblivion. 2. Self destruct will auto-create a beneficiary. This lets us punt filecoin-project/ref-fvm#736 to M2.2.
In the EVM: 1. Self destruct continues even if it sends funds into oblivion. 2. Self destruct will auto-create a beneficiary. This lets us punt filecoin-project/ref-fvm#736 to M2.2.
In the EVM: 1. Self destruct continues even if it sends funds into oblivion. 2. Self destruct will auto-create a beneficiary. This lets us punt filecoin-project/ref-fvm#736 to M2.2.
We've worked around this in the EVM by sending, then self destructing. Punted to M2.2 to avoid yet another FIP. |
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.The text was updated successfully, but these errors were encountered: