From 86034b6ecdecf3fd2ab9240897d54eb099d6474a Mon Sep 17 00:00:00 2001 From: Omar Boukli-Hacene Date: Thu, 26 Apr 2018 04:03:12 +0400 Subject: [PATCH] Fix inconsistent date format --- ch10.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 47028166..025df820 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -402,7 +402,7 @@ By selecting the specific _parent_ block, indicated by the Previous Block Hash f c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e ---- -Jing's mining node will then add a 4-byte timestamp, encoded as a Unix "epoch" timestamp, which is based on the number of seconds elapsed from January 1, 1970, midnight UTC/GMT. The time +1388185914+ is equal to Friday, 27 Dec 2013, 23:11:54 UTC/GMT. +Jing's mining node will then add a 4-byte timestamp, encoded as a Unix "epoch" timestamp, which is based on the number of seconds elapsed since midnight UTC, Thursday, January 1, 1970. The time +1388185914+ is equal to Friday, December 27, 2013, 23:11:54 UTC. Jing's node then fills in the target, which defines the required Proof-of-Work to make this a valid block. The target is stored in the block as a "target bits" metric, which is a mantissa-exponent encoding of the target. The encoding has a 1-byte exponent, followed by a 3-byte mantissa (coefficient). In block 277,316, for example, the target bits value is +0x1903a30c+. The first part +0x19+ is a hexadecimal exponent, while the next part, +0x03a30c+, is the coefficient. The concept of a target is explained in <> and the "target bits" representation is explained in <>.