You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assuming we will have forking changes during one of the upcoming updates, might it make sense to reduce the 16s timestamp granularity mask. Would this lessen the likelihood of a race condition and possibly alleviate some of the concerns of JD orphaning solo stakers?
EDIT: By "reduce" I am suggesting a mask such as 8s, 4s, etc.
The text was updated successfully, but these errors were encountered:
I've seen a few solo miners complaining lately, so I've come up with a non-answer for you:
It makes sense to me that you'd want to bias the time in your block with mean time of all peers on the network by preference of gaining the widest acceptance possible. In the event that there is a huge majority, you'd want to bias it with their time. That's not to say people still shouldn't update their clocks every day, though.
A majority miner gains an inherent mining advantage due to the start time of scanning work. That advantage is compounded when the same miner solves the subsequent block quickly. Other peers can start the work second(s) later due to wallet size, latency, and hardware. This advantage seems fickle, but makes a majority miner the only hashrate for this stairstep-like period of the whole network stopping/starting work.
There's also the issue of chain trust. The majority always has the most chain trust and cannot be beaten by any other block within the granularity window(I think? Can someone clarify this?)
Assuming we will have forking changes during one of the upcoming updates, might it make sense to reduce the 16s timestamp granularity mask. Would this lessen the likelihood of a race condition and possibly alleviate some of the concerns of JD orphaning solo stakers?
EDIT: By "reduce" I am suggesting a mask such as 8s, 4s, etc.
The text was updated successfully, but these errors were encountered: