|
Title: CBlockHeader::nTime, is that a problem? Post by: bigphoenixman on December 29, 2017, 07:05:30 AM I find out that more than 2% block Timestamp(nTime) is wrong.
for example: Block#501251 Timestamp 2017-12-27 10:34:56 Block#501252 Timestamp 2017-12-27 10:34:39 I think more than 2% is too lot. Should we design some protocol let every miner use correct time? Title: Re: CBlockHeader::nTime, is that a problem? Post by: ranochigo on December 29, 2017, 07:18:56 AM There is no need for it. Timestamp for the blocks are not important for it to be absolutely accurate, it just has to be within a certain range.
The problem with such a protocol is that all of the nodes on the network has to connect to a central server which determines the exact time. This is inherently difficult to do, considering the difficulty for thousands of clients to connect to a server and be synchronized at the same time. If not every node in the world is at the exact same unix timestamp, some of the nodes would not see the blocks as valid and thus diverge from the others. The main argument is that the offset isn't an issue. Title: Re: CBlockHeader::nTime, is that a problem? Post by: bigphoenixman on December 30, 2017, 02:47:04 AM There is no need for it. Timestamp for the blocks are not important for it to be absolutely accurate, it just has to be within a certain range. The problem with such a protocol is that all of the nodes on the network has to connect to a central server which determines the exact time. This is inherently difficult to do, considering the difficulty for thousands of clients to connect to a server and be synchronized at the same time. If not every node in the world is at the exact same unix timestamp, some of the nodes would not see the blocks as valid and thus diverge from the others. The main argument is that the offset isn't an issue. yes, sure, it's not important. I find out this problem when i read every blockhead into memory and sort by nTime. I suppose it's a fast way to retrieve the chain. Yesterday, i find wrong time, just in few minutes. But today, I find out the block# 301596, the nTime is wrong more than 3 hours. I think we should resolve this later, how about some miner give a nTime = 2030year tomorrow. ofcouse , It's doesn't matter, but just look a little bit ugly. Title: Re: CBlockHeader::nTime, is that a problem? Post by: ranochigo on December 30, 2017, 02:58:50 AM yes, sure, it's not important. I find out this problem when i read every blockhead into memory and sort by nTime. They can't. The timestamp of a block is not offset more than 2 hours from the network adjusted time which is the median of the time that is retrieved from the nodes. You definitely cannot enforce blocks to be within a small timeframe for a few reasons I can think of:I suppose it's a fast way to retrieve the chain. Yesterday, i find wrong time, just in few minutes. But today, I find out the block# 301596, the nTime is wrong more than 3 hours. I think we should resolve this later, how about some miner give a nTime = 2030year tomorrow. ofcouse , It's doesn't matter, but just look a little bit ugly. 1. Miners include the timestamp in the block header and sometimes, they increase the nonce as a variable before they hit the target. 2. Propagation takes some time. No one should be using the timestamp to sort out the block, only the block height. Title: Re: CBlockHeader::nTime, is that a problem? Post by: nullius on December 30, 2017, 04:39:02 AM yes, sure, it's not important. I find out this problem when i read every blockhead into memory and sort by nTime. They can't. The timestamp of a block is not offset more than 2 hours from the network adjusted time which is the median of the time that is retrieved from the nodes. You definitely cannot enforce blocks to be within a small timeframe for a few reasons I can think of:I suppose it's a fast way to retrieve the chain. Yesterday, i find wrong time, just in few minutes. But today, I find out the block# 301596, the nTime is wrong more than 3 hours. I think we should resolve this later, how about some miner give a nTime = 2030year tomorrow. ofcouse , It's doesn't matter, but just look a little bit ugly. 1. Miners include the timestamp in the block header and sometimes, they increase the nonce as a variable before they hit the target. 2. Propagation takes some time. Add to this: 3. Secure, reliable agreement on a reasonably high-precision network time runs into the very same “General” (hah) problem which mining is intended to solve. Indeed, off-the-cuff, I can think of some constructions which may perhaps maybe could be used to replace mining—if we had secure, reliable high-precision network time agreement. (And if I had wings, and if all cows were identical and spherical...) No one should be using the timestamp to sort out the block, only the block height. No one should; but you know, somebody will (and just did). I think there’s a rule somewhere that if you provide a variable value, somebody will (ab)use it for purposes neither foreseen nor supported by the design. I will now wait for someone to use the nonce in some way which requires meaning it does not have. |