CheckBlockHeader
The CheckBlockHeader function was introduced by Dr Wuille in March 2014 as part of a series of header synchronisation changes {Wuille1 [24-25] {C1/1/6}}.
CheckBlockHeader resulted from a split in the functionality present in the CheckBlock function described at [651] to [652] above, so that two of the six checks there described (the timestamp and proof-of-work checks) were prioritised ahead of the remaining four checks {Wuille1 [25] {C1/1/6}}.
By modularising CheckBlock into two stages, CheckBlockHeader and CheckBlock, nodes could quickly reject invalid blocks based on just their header, removing the need to download all of their transaction data.
When he was first taken to the CheckBlockHeader function in cross-examination, Dr Wright accepted that these changes were made by Dr Wuille (who had the username Sipa on GitHub) in 2013 and were not in Satoshi Nakamoto’s original code {Day8/132:23}-{Day8/133:6}.
However, one of Dr Wright’s reliance documents was a document entitled “BitCoin: SEIR-C propagation models of block and transaction dissemination” {L3/237} (“the SEIR-C document”). At Wright11 AppendixB [14.2] {CSW/2/52}, Dr Wright had stated that this document had been created between about Oct-Dec 2008 “before I released the system in January 2009”. In section 32 of the Appendix, I have found this document to be a forgery.
At {L3/237/13} the SEIR-C document purported to provide a description of the Bitcoin system’s block validation process. It stated as follows (and note the use of the present tense):
“Each node verifies a block before it propagates it to the connected peer nodes. In this way only valid blocks are propagated, and any invalid blocks are quickly isolated. The BitCoin Core client lists all of the validation requirements in the following functions:
• CheckBlock
• CheckBlockHeader”
When this anachronism (i.e. the inclusion of a reference to a function from 2014 in a document purportedly from 2008) was put to him in cross-examination, the exchanges proceeded as follows:
“135: 9 Q. Do you want to carry on and we'll see that it then
10 refers to two functions, the first is CheckBlock and
11 the second is CheckBlockHeader, isn't it?
12 A. Again, CheckBlock and CheckBlockHeader were meant to be
13 implemented. CheckBlockHeader was a simple function for
14 SPV. So in the client patches discussed with Gavin in
15 2010, CheckBlockHeader was an implementation of
16 a version of Bitcoin that does not have all of
17 the checking. So that's different to the version Sipa
18 put in, but that doesn't mean that there weren't
19 functions. Again, CheckBlockHeader was about having an
20 SPV, as defined in the White Paper, version of checking
21 just the block headers.
22 Q. There's no reference in the White Paper to
23 CheckBlockHeader, is there?
24 A. It has reference to SPV, which only checks Block Header.
25 There is no reference to any of the coding terms in
136: 1 the Bitcoin White Paper.
2 Q. When you say SPV checks -- "only checks Block Header",
3 what do you mean by "SPV" there?
4 A. Simplified Payment Verification.
5 Q. Right.
6 A. What that basically means is, like --
7 Q. To assist in the payment of individual transactions?
8 A. No, it's a -- basically what we're talking about is
9 a light node. So a node where an individual doesn't
10 need to download the entire blockchain. For instance,
11 I can just have the block headers and then I can have
12 a localised(?) path of where I'm checking an individual
13 transaction. I can keep each of those.
14 Q. Dr Wright, nobody referred to CheckBlockHeader until
15 the change that I took you to, did they?
16 A. No, that's wrong. That was actually part of building
17 SPV systems, that was basically the function I was
18 looking at at that time.
19 Q. There isn't a single document in which anybody refers to
20 CheckBlockHeader as a single function until Dr W[uille]
21 introduced it through GitHub, right?
22 A. I've no idea when he put it in that, but when I was
23 discussing the introduction of SPV, these concepts were
24 back there as well.
25 Q. Mr Andresen did not introduce CheckBlockHeader, did he?
137: 1 A. No, Mr Andresen got a patch from me initially. So
2 the patches for SPV were actually from Satoshi, me.
3 Q. Dr Wright, we've got the patches that Satoshi Nakamoto
4 sent to Mr Andresen; they do not include
5 CheckBlockHeader.
6 A. No, because I went off to develop things myself. So
7 where I was talking about work that I did in my other
8 companies, I didn't do everything publicly. The work on
9 Teranode now that was iDaemon that I've put in here, all
10 of those documents were based on our work, not his.
11 Q. Dr Wright, I know you want to talk about all of your
12 latest things. I'm actually trying to ask you about
13 things that Satoshi Nakamoto would know about, and that
14 is the original --
15 A. No, you're --
16 Q. -- Bitcoin code, right, and there was no reference in
17 the original Bitcoin code to CheckBlockHeader,
18 was there?
19 A. Again, difference between core, as in main nodes, and
20 those that are doing less, SPV, and there is a reference
21 to SPV. SPV nodes are those that only have to check
22 the headers across the network. If you read
23 the section, you will see that.
24 Q. Dr Wright, I am very confident that I can read any
25 section of anything and I will not see a single
138: 1 reference to CheckBlockHeader.
2 A. Because the code's not referenced in the White Paper at
3 all.
4 Q. And you're saying that -- when did you say then you
5 invented this? Was it in 2010, you said, when you were
6 talking to Mr Andresen?
7 A. No, I started working on SPV before I even released
8 Bitcoin. So, what I was doing is a combination of
9 Timecoin, which was a separate product, and Bitcoin.
10 Bitcoin was the main free product; Timecoin extended
11 everything.”
The Developers submitted that that set of responses bears many of the common tell-tale signs of Dr Wright’s dishonesty. I agree. They include:
An attempt to suggest that an optimisation introduced following Satoshi Nakamoto’s departure was something that Dr Wright had thought of all along. Suffice it to say, that was not something that it had occurred to Dr Wright to mention when he was initially taken to the CheckBlockHeader function: see [743] above.
An attempt to suggest that the future optimisation was preordained in the Bitcoin White Paper. The Bitcoin White Paper simply does not engage in this sort of technical detail.
An attempt to suggest that the feature emerged in discussions for which there would be a reliable document trail, but of which no documentary record exists. Gavin Andresen disclosed all of his communications with Satoshi Nakamoto, including patches. None includes a function called CheckBlockHeader.
A vacuous reference to iDaemon and/or Terranode and/or Timecoin or other “Star Trek-style technobabble” (to quote Mr Hearn at Hearn1 [28] {C/22/7}).