-
Notifications
You must be signed in to change notification settings - Fork 83
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
No vesting during cron #1594
Comments
Since everyone appears to be fine with this issue and we've heard no complaints for the last year I think once we understand and confirm that there is nothing going wrong here that this should be a wont fix. We should go back and remove the if-guarded vesting unlock entirely to avoid any future confusion. |
filecoin-project/lotus#12828 to inspect the scale of the problem |
Noting this while I stumble upon it: I think it comes from #1424 This: builtin-actors/actors/miner/src/lib.rs Lines 4469 to 4481 in 8a75734
Which is only called on
The question is - why do some miners seem to get properly vested funds if this is universally wrong? Using my little tool to have a look (filecoin-project/lotus#12828 - although I have a modified version locally that just runs through the power actor for miners with claims) my current stats say:
So a lot of them appear to be vesting properly. There's another way that you can get your vesting unlocked, |
I agree with your assessment and that
Alternatively we could just remove vesting entirely from cron since SPs have worked around this for the last year and now know how to handle this. This would save subsidized cron compute which is nice. I don't have very strong feelings either way. |
Failing test: #1635 case.
Assuming FIP-0100 passes, we'll be charging a fee from vesting funds every epoch so we should probably just vest in cron anyways (I'm currently working on making this not have to load/store the entire vesting queue every time...). |
This lets us efficiently take fees from vesting funds without loading/storing this object each time. It also lets us check if there are funds to vest without having to load any additional state, because the "next" batch of vesting funds are always stored in the root state object. If FIP-0100 passes, we'll likely want this change as we'll otherwise read/write the vesting funds queue on every deadline for every miner. fixes #1594
This lets us efficiently take fees from vesting funds without loading/storing this object each time. It also lets us check if there are funds to vest without having to load any additional state, because the "next" batch of vesting funds are always stored in the root state object. If FIP-0100 passes, we'll likely want this change as we'll otherwise read/write the vesting funds queue on every deadline for every miner. fixes #1594
This lets us efficiently take fees from vesting funds without loading/storing this object each time. It also lets us check if there are funds to vest without having to load any additional state, because the "next" batch of vesting funds are always stored in the root state object. If FIP-0100 passes, we'll likely want this change as we'll otherwise read/write the vesting funds queue on every deadline for every miner. fixes #1594
This lets us efficiently take fees from vesting funds without loading/storing this object each time. It also lets us check if there are funds to vest without having to load any additional state, because the "next" batch of vesting funds are always stored in the root state object. If FIP-0100 passes, we'll likely want this change as we'll otherwise read/write the vesting funds queue on every deadline for every miner. fixes #1594
This lets us efficiently take fees from vesting funds without loading/storing this object each time. It also lets us check if there are funds to vest without having to load any additional state, because the "next" batch of vesting funds are always stored in the root state object. If FIP-0100 passes, we'll likely want this change as we'll otherwise read/write the vesting funds queue on every deadline for every miner. fixes #1594
This lets us efficiently take fees from vesting funds without loading/storing this object each time. It also lets us check if there are funds to vest without having to load any additional state, because the "next" batch of vesting funds are always stored in the root state object. If FIP-0100 passes, we'll likely want this change as we'll otherwise read/write the vesting funds queue on every deadline for every miner. fixes #1594
This lets us efficiently take fees from vesting funds without loading/storing this object each time. It also lets us check if there are funds to vest without having to load any additional state, because the "next" batch of vesting funds are always stored in the root state object. If FIP-0100 passes, we'll likely want this change as we'll otherwise read/write the vesting funds queue on every deadline for every miner. fixes #1594
Funds should be vesting during cron. However there are instances where an active deadline cron does not vest any funds such that there are unclaimed vesting table entries in the past.
The culprit is likely related to faulty assumptions about the vesting table structure and deadline cron epoch alignment. It was probably introduced in #1424.
The text was updated successfully, but these errors were encountered: