Alex North

@Stebalien thanks for reviewing this. I may have been a bit premature. There are some other cases of lost information, but I was trying not to do that. I will...

I would expect we don't need a FIP for the change here unless they change some behaviour to be other than what might be expected had we had user-programmed actors...

Another item: the payment channel requires that addresses are of account actors specifically. If we implement either account abstraction or a standard signature verification method, we should instead delegate signature...

The miner actor only supports built-in accounts and multisigs as control addresses

Almost anything that uses the built-in actor `Type` enum is suspect. We probably want to remove these syscalls entirely, so we need to remove the users of them. Most urgent...

From @Kubuxu (#493) Here is a list of slowest tests: ``` "extend_sector_with_deals",408.601976852 "sector_assignment::assign_sectors_to_deadlines",107.120695873 "deal_starts_on_day_boundary",85.341671754 "overdue_precommit",54.788396499 "aggregate_one_precommit_expires",54.227713798 "deal_is_correctly_processed_if_first_cron_after_expiry",39.801908073999996 "all_payments_are_made_for_a_deal_client_withdraws_collateral_and_client_account_is_removed",39.76637831 "regular_payments_till_deal_expires_and_then_locked_funds_are_unlocked",31.483729491 "expired_deal_should_unlock_the_remaining_client_and_provider_locked_balance_after_payment_and_deal_should_be_deleted",31.43561346 "payment_for_a_deal_if_deal_is_already_expired_before_a_cron_tick",30.252185392 "locked_fund_tracking_states",29.044090355 "regular_payments_till_deal_expires_and_then_we_attempt_to_slash_it_but_it_will_not_be_slashed",27.649656669 "sector_number_allocation::compaction_with_mask",27.548936622 "deal_is_slashed_at_the_end_epoch_should_not_be_slashed_and_should_be_considered_expired",27.483643367 "cron_enrolls_on_precommit_prove_commits_and_continues_enrolling",15.796063935 "deals_are_scheduled_for_expiry_later_than_the_end_epoch",15.711722069 "deal_is_processed_after_its_end_epoch_should_expire_correctly",15.59722642 "terminate_valid_deals_along_with_expired_and_cleaned_up_deal",15.436974767 "prove_replica_update_multi_dline",14.614798868...

> Don't we implement cron catchup? Some of the code may rely on the every-epoch behaviour. I know I advocated for simplifying to do so once that behaviour was reliable.

Thanks for raising this, I'm sorry it has languished. I'm a bit torn here. On the one hand there is some real value here, exploding the bundle size could cause...

I don't see the problem with this changing on every PR. We mandate squashed commits anyway (❤️) so there'll be no noise in the commit history. Note if we didn't...

Hmm, I might have misunderstood the configuration then, and yes I can see how pushing commits to branches would actually be annoying in common workflows of not getting your PR...