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

Reduction of timestamp granularity mask to limit orphan bias #229

Open
creativecuriosity opened this issue Sep 30, 2015 · 1 comment
Open

Comments

@creativecuriosity
Copy link
Collaborator

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.

@tryphe
Copy link
Collaborator

tryphe commented Jun 7, 2016

I've seen a few solo miners complaining lately, so I've come up with a non-answer for you:

  1. 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.

  2. 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.

  3. 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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants