Skip to content
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

Allow PreCommit collateral to be moved from miner available balance #6603

Closed
jennijuju opened this issue Jun 25, 2021 · 6 comments · Fixed by #6629
Closed

Allow PreCommit collateral to be moved from miner available balance #6603

jennijuju opened this issue Jun 25, 2021 · 6 comments · Fixed by #6629
Assignees
Labels
area/sealing area/ux Area: UX good first issue Good for newcomers kind/discussion Kind: Discussion P2 P2: Should be resolved
Milestone

Comments

@jennijuju
Copy link
Member

Precommit collateral is moved from miner available balance in miner actor. Currently, in lotus, we are "forcing" the collateral to be paid from the worker/control address of the miner with the precommitsector message which leads miners to need to monitor the address balance closely so to maintain their miner operations = even they have enough funds in available balance to cover the collateral.

Two proposals we have:
A: Add a check to see if miner's enough available balance to cover collateral + buffer, if it does, don't send any more funds with the message, if not, send the collateral with the message.
B: make it configuration for miner to chose if they want to pay off using available balance or worker/control address.

@jennijuju jennijuju added P2 P2: Should be resolved area/ux Area: UX area/sealing kind/discussion Kind: Discussion labels Jun 25, 2021
@f8-ptrk
Copy link
Contributor

f8-ptrk commented Jun 28, 2021

people are doing this already, maybe ask how they implemented it and if they would pr it if the plan is ti implemented the advantage of keeping the code closed source will vanish and they can get at least "monetize" the PR

@jennijuju
Copy link
Member Author

jennijuju commented Jun 28, 2021

people are doing this already, maybe ask how they implemented it and if they would pr it if the plan is ti implemented the advantage of keeping the code closed source will vanish and they can get at least "monetize" the PR

Pr is def welcomed, however, I don’t know what you meant by monetized?

@f8-ptrk
Copy link
Contributor

f8-ptrk commented Jun 28, 2021

having this is an advantage. not PR'ing it is keeping this advantage. if they PR it the advantage is gone and the prestige of having it PR'ed is the only thing they get out of it (--> monetized)

not PR'ing it and getting it implemented leaves them naked vs. the prestige of having it PR'ed

@jennijuju jennijuju added the good first issue Good for newcomers label Jun 28, 2021
@jennijuju
Copy link
Member Author

Option A is a better candidate, if we add the configuration, it should be "true" to move from miner balance by default.

@f8-ptrk
Copy link
Contributor

f8-ptrk commented Jun 28, 2021

B, option B!

we for example have mostly no access to the available balance as an operator - we do not have access to the owner key. if we now allow the worker key to, basically, withdraw and use block rewards we have a problem.

but since it is possible already we might have to revisit our thinking about the owner key anyways.

@jennijuju
Copy link
Member Author

B, option B!

we for example have mostly no access to the available balance as an operator - we do not have access to the owner key. if we now allow the worker key to, basically, withdraw and use block rewards we have a problem.

but since it is possible already we might have to revisit our thinking about the owner key anyways.

Good point - a combination of both sounds like a good idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/sealing area/ux Area: UX good first issue Good for newcomers kind/discussion Kind: Discussion P2 P2: Should be resolved
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants