-
Notifications
You must be signed in to change notification settings - Fork 992
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
Investigate whether we can create a second MASP epoch tracker #2833
Comments
@grarco any idea of how difficult this is? |
We are still waiting for a confirmation on whether this is actually needed |
A confirmation from whom? |
i'm ambivalent about prioritizing an epoch time decrease: it doesn't have to be a priority, but i'm concerned that it could be stuck like this forever, once it's the default (politically and/or dev priority). is there some in-between option that wouldn't require creating a second MASP epoch? |
I don't think there's an in-between option. I also don't think this change is particularly complicated in principle, but it might be annoying in practice - @grarco do you have a rough idea (hours? days? weeks?) |
I agree there's no other option. I'd say it takes a few days (but hard to say for certain until I start to work on this) |
Let's revaluate this again next week after other definitely necessary work is completed. |
@grarco to evaluate this in more detail today. |
h/t @gavinly
Investigate whether we can create a second MASP epoch, where
masp_epoch = regular_epoch % n
(mod n
), wheren
could be, for example,4
- the objective being to allow faster epochs without letting the conversion table grow too much.The text was updated successfully, but these errors were encountered: