Is there a problem with mining?

1

  1. The speed of the exposure is slow to explorer, too.
    Why does the block keep changing?
    At first, it was a different hash address and then it changed to 65d address.

  2. If the hash power rises and mining becomes difficult, the difficulty level should also increase, but what is the monopoly phenomenon of one address?

2

I agree with you.
IMO most of miners can not receive the latest block from peers.
They are tring to mining already minted block at LATE.
So an abnomal block interval could be found.
( [954739]~ [954740], about 20 mins)
They will go away by fork.

Untitled
Untitled1572×375 30.6 KB

I saw validator log like
“New fork head xxxxx is ahead of time”
from https://github.com/gluwa/Creditcoin/blob/c1576ad7e7259c7765c13b5f4489034704adab37/PoW/PoW/init.py#L677

now = time.time()
    new_time = float(new_consensus[IDX_TIME].decode())
    if (new_time > now + 30):
        LOGGER.warning("New fork head {} is ahead of time {}".format(new_fork_head.identifier[:8], new_time))
        return False

What will happen
if a miner who has the most hash power
set system clock ahead of current time by 1 min while mining?
And modified the compare_forks(self, cur_fork_head, new_fork_head) function to return false always.

Other peer’s fork resoultion rejects the block
because the timestamp of block is ahead more than 30sec
(regarded as invalid timestamp block)

But after more than 30 seconds goes by,
the rejected block will become main chain.
Because the block is more longer and old.
So other’s minted block will be disappear.
Is it right?

3

The node(65d76) mined about 40-50% of the daily mining volume before this fork. It would have been impossible to change the chain validation logic.
Also, more and more addresses are starting to appear in that node’s chain now. I think this is a temporary phenomenon. It often happens when there are many bad nodes in the network.

4

Propositions:

  • Miner X has the most hashing power (within miners not the aggregated hashing power of all miners).
  • Miner X has wall time one minute ahead.
  • Rejects all incoming forks by compare_forks(…) always returning False.

Thus:

  • Miner X blocks won’t be accepted by the network due to block time being ahead of time. By the time miner X’s blocks are valid by clock time, the network has had time to build its own collective chain. Miner X is handicapping itself by not letting its broadcasted blocks be valid for the next 30 seconds. I don’t find incentives under these premises for miners to adopt this behavior.
5

Is that why mining is not possible only when you wait?