FIP-0077: Add Cost Opportunity For New Miner Creation

[tediou5]

Fip: FIP-0077
Fip update: FIP-0077 update
Discussions: discussions

Also, should we allow users to use the deposit as an initial pledge? I think i can do this.

[anorth]

I'm reviewing this as a high level implementation proposal rather than in detail yet.

There are two decisions here that cause a much larger impact on code and complexity that I think necessary.

• New state for the deposit. We already have a vesting table capable of representing the idea of funds locked until some epoch. Adding new state representing a new type of locked funds means all the calculations about balances need to take that into account. The chance of introducing an error now or later is very high. It requires a state migration. I can't see any advantage of the separate representation.
• A new method for the deposit. The deposit is required at miner creation. It would be simpler to just pass the funds in the call to the miner constructor (which already happens) and compute the lock in that constructor. The duplication of miner logic code in the power actor will not be acceptable (though we could extract it somewhere to share). The power actor is already calling the miner actor once, there's no point calling a second time. The only parameter is the lock amount, which can be computed at the miner, so we don't need to adjust the miner constructor parameters. The constructor can fail if the balance is insufficient for the lock.

[anorth]

should we allow users to use the deposit as an initial pledge

I don't think this is worth the complexity it will involve to implement it. I suggest not doing that for now.

[tediou5]

@anorth

A new method for the deposit. The deposit is required at miner creation. It would be simpler to just pass the funds in the call to the miner constructor (which already happens) and compute the lock in that constructor. The duplication of miner logic code in the power actor will not be acceptable (though we could extract it somewhere to share). The power actor is already calling the miner actor once, there's no point calling a second time. The only parameter is the lock amount, which can be computed at the miner, so we don't need to adjust the miner constructor parameters. The constructor can fail if the balance is insufficient for the lock.

Yeah, I'm just want an early exit here. I will fix this.

---

New state for the deposit. We already have a vesting table capable of representing the idea of funds locked until some epoch. Adding new state representing a new type of locked funds means all the calculations about balances need to take that into account. The chance of introducing an error now or later is very high. It requires a state migration. I can't see any advantage of the separate representation.

Yes, adding a state makes it a lot more complicated. But its very easy and necessary to use the deposit as an initial pledge, if we have an deposit state.

Maybe we could give it a try ? Or if you're very adamant here, I can remove the code.

[anorth]

Yes, adding a state makes it a lot more complicated. But its very easy and necessary to use the deposit as an initial pledge, if we have an deposit state.

My opinion is that it is not worthwhile to have that feature. I'm open to other opinions, more information etc though. My default stance is that any additional complexity has to bring a lot of benefit.

[rjan90]

Hey! 👋

As part of our cleanup to kick off the year, I'm reviewing all open non-draft pull requests. Could you please do one of the following for your PR?

1. Close it: If it's no longer needed.
2. Mark as Draft: If it needs more work, and add the next steps.
3. Ready for Review: If it's good to go, let me know, and I'll assign a reviewer.

If there's no response in a week, I'll assume it's option 1 and close the PR. If you have any questions, just let me know.

Thanks for your help in keeping things organized, and I appreciate your contributions!

[tediou5]

Hey! 👋

As part of our cleanup to kick off the year, I'm reviewing all open non-draft pull requests. Could you please do one of the following for your PR?

1. Close it: If it's no longer needed. 2. Mark as Draft: If it needs more work, and add the next steps. 3. Ready for Review: If it's good to go, let me know, and I'll assign a reviewer.

If there's no response in a week, I'll assume it's option 1 and close the PR. If you have any questions, just let me know.

Thanks for your help in keeping things organized, and I appreciate your contributions!

@rjan90 Thank you for your work. This PR has been cleaned up and re-implemented according to our previous discussions. It is now ready for review.

[BigLep]

@tediou5 : I see this slipped through the maintainer cracks. I'm actually not sure how. Regardless, can you resolve conflicts and we'll get a reviewer assigned?

@rvagg : do you have a reviewer suggestion for this one?

[rvagg]

Are we in a chicken/egg situation with this and filecoin-project/FIPs#963? @tediou5 are you still keen to pursue attempting to get FIP-0077 accepted? If so, how are you proposing to proceed here? Do you want to get some clarity on the implementation here and then go reopen filecoin-project/FIPs#963, or do you think that you've got enough feedback from the existing work with Alex so far to go back and do that?
I'm not yet up to speed on this FIP, other than remembering the CreateMiner spam incident, but can get up to speed if you need help getting the implementation further if that's what's needed to get the FIP update reopened so core-devs can consider it.

[tediou5]

Are we in a chicken/egg situation with this and filecoin-project/FIPs#963? @tediou5 are you still keen to pursue attempting to get FIP-0077 accepted?

Yes, I’ll communicate with @ipfsforcezuofu and reopen filecoin-project/FIPs#963.

[tediou5]

@BigLep Conflicts and test cases have been fixed.

[tediou5]

Rebase for fix conflicts and test cases.

[BigLep]

@rvagg : for next steps here, should we enage when FIP-0077 passes last call? Is this also a good candidate for Forest to look at?

[tediou5]

Replace magic numbers in unit and integration tests with fn minimum_initial_pledge and fn get_minimum_initial_pledge, and remove unnecessary variables and parameters as suggested.

The latest discussion on FIP-0077 reduced the deposit to the original 10%. I will submit this change after the FIP is merged.

[BigLep]

@ZenGround0 : I added you as a reviewer given your priority this week of supporting actor changes to land.

[ZenGround0]

Overall this looks good. I'll come back to it for another look tomorrow.

[ZenGround0]

Apart from nitpicks it LGTM

[BigLep]

Thanks for reviewing @ZenGround0 .

@tediou5 : will you be able to incorporate comments by end of day 2025-08-29?

[tediou5]

@BigLep @ZenGround0 68e18aa, Done.

[BigLep]

I'm going to merge this given it got approval and nits were handled. Nice work @tediou5 !

[BigLep]

Followup Lotus work is being tracked in filecoin-project/lotus#13287