Bitcoin Forum
September 23, 2018, 07:26:42 AM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: CBlockHeader::nTime, is that a problem?  (Read 40 times)
bigphoenixman
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
December 29, 2017, 07:05:30 AM
 #1

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?
1537687602
Hero Member
*
Offline Offline

Posts: 1537687602

View Profile Personal Message (Offline)

Ignore
1537687602
Reply with quote  #2

1537687602
Report to moderator
1537687602
Hero Member
*
Offline Offline

Posts: 1537687602

View Profile Personal Message (Offline)

Ignore
1537687602
Reply with quote  #2

1537687602
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
ranochigo
Legendary
*
Offline Offline

Activity: 1554
Merit: 1090


View Profile WWW
December 29, 2017, 07:18:56 AM
 #2

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.

bigphoenixman
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
December 30, 2017, 02:47:04 AM
 #3

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.
ranochigo
Legendary
*
Offline Offline

Activity: 1554
Merit: 1090


View Profile WWW
December 30, 2017, 02:58:50 AM
 #4

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

nullius
Copper Member
Full Member
***
Offline Offline

Activity: 168
Merit: 757


Help! I’ve got the Pleurodelinaemia! @nym.zone


View Profile WWW
December 30, 2017, 04:39:02 AM
 #5

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

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!