Steven Allen

We either need to implement this or @anorth's suggestion for M2.1 for _full_ compatibility with the EVM. The question is really: does that actually matter for the Ethereum ecosystem? I'll...

It looks like implementation progress is being made, but it still doesn't look ready: https://github.com/bytecodealliance/witx-bindgen.

IMO, this should simply be implemented as runtime-provided function. Actors can call the "replace code" function to upgrade themselves. 1. I'm not convinced an external interface is what we're looking...

We'll also likely need an "upgrade" method on deployed actor code. I.e., when some actor calls `replace_code(new code cid)`, we'll want to: 1. Run the _upgrade_ (not constructor) function on...

So, one interesting issue will be re-entrancy. E.g.: ``` A -> B -> A (upgrade) A -> B A (upgraded state-tree but old code?) ``` We're going to need to...

No, assuming we can reach consensus on the current actor addressing proposals.

This also applies to the constructor: - The EAM's Create/Create2 methods will take (and validate) the caller's "EVM" address as a parameter. - The EAM will pass this address to...

Ok, we have an alternative. If we get rid of `Bind4` (which I'm planning on doing), we'll have at most _one_ `f4` address (unfortunately, along with an `f2` address). Given...

Resolved in https://github.com/filecoin-project/FIPs/discussions/477 (merged into the f4 work).

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...