Reject unexpected transfers of value (was: Add an equivalent of "payable" to the runtime)

[Stebalien]

Specifically:

rt.payable() where a call gets reverted if:

1. The balance sent to the actor was non-zero.
2. rt.payable was not called at some point.

We could, alternatively, have a rt.not_payable(). That's the "less breaking" approach.

[vyzo]

The negated approach is saner, this is special functionality and should thus be optin.

[anorth]

I think there's reasonable justification for doing the breaking approach, if we can do it soon. Receiving funds unexpectedly would very likely lead to their loss. I would say that being able to receive funds is the special functionality.

[vyzo]

Thats a reasonable argument, but is there precedent for it?

More importantly for FEVM, isnt accepting funds the default mode?
Code often doesnt even get to run there with the gas limit convention, so a contract wouldnt have the chance to accept funds by default.

[anorth]

Just to confirm, @Stebalien, given the location of this issue, you're proposing this as a safety feature for the built-in actors runtime (which is essentially just a support library). It's not something that would be available or enforced for any user actors, though of course they could copy the pattern.

[anorth]

Related discussion about being able to refuse bare sends of value (which would require VM support): filecoin-project/ref-fvm#835

[Stebalien]

Just to confirm, @Stebalien, given the location of this issue, you're proposing this as a safety feature for the built-in actors runtime (which is essentially just a support library). It's not something that would be available or enforced for any user actors, though of course they could copy the pattern.

Yes.

More importantly for FEVM, isnt accepting funds the default mode?

Yes. However, the default in solidity is to reject funds.

[anorth]

I've renamed this "Reject unexpected transfers of value" to reflect the behavioural change. I concur that support in the Runtime would be a good way to get it. This will become valuable as user-programmed contracts/actors emerge, and we can do the development/user community a favour by preventing the built-in actors from accepting their funds.