Previous Page

CheckBlock

651.

As for the CheckBlock function, the Developers submitted this was one of the key functions in the Bitcoin Source Code, being the first stage in the processing of blocks under the ProcessBlock function in the main.cpp file, followed by AcceptBlock. I agree.

652.

In the original source code, CheckBlock is comprised of six steps, each preceded with a single line comment as follows:

652.1.

// Size limits

652.2.

// Check timestamp

652.3.

// First transaction must be coinbase, the rest must not be

652.4.

// Check transactions

652.5.

// Check proof of work matches claimed amount

652.6.

// Check merkleroot

653.

Each of those single line comments, save the fourth, provides a summary description of the checks that the relevant function undertakes that anybody with a basic understanding of Bitcoin could surmise. The fourth “Check transactions” is more ambiguous. Dr Wright was invited to explain what it comprised. He answered as follows:

“123: 6 Q. And then, fourthly, we can see that it checked

7 transactions?

8 A. Yes.

9 Q. What was that?

10 A. That it checks transactions?

11 Q. Yes, what was the check of the transactions?

12 A. Basically making sure that they are valid, that

13 the transactions that have been received follow

14 the rules, etc.

15 Q. So what sort of thing?

16 A. What sort of thing. So, basically, Bitcoin uses script.

17 The way that you'd have to then check would be does

18 the key work, does other policies work, are the output

19 and script valid. It's a predicate. So, what we're

20 functionally doing in here is ensuring that all of

21 the input and output is structured correctly, that if

22 there's a message with an ECDSA key that the correct

23 previous block had been signed.

24 Q. So I remember you talking the other day -- I can't

25 remember which day it was -- about how, when you were

124: 1 first running the Bitcoin Software, it hadn't been --

2 the mining that had been absorbing all of your

3 electricity, as it were, it was doing ECDSA checks in

4 relation to the underlying transactions; is that right?

5 A. And much more.

6 Q. Okay, but when you're talking about ECDSA checking, is

7 that what you're talking about in relation to --

8 A. That particular part, yes.”

654.

The Developers submitted that this description by Dr Wright of the “Check transactions” stage of the CheckBlock function (namely that the signature of transactions was checked) was hopelessly wrong, on the basis that the checks in “Check transactions” are set out in the main.h file at {L4/98.1/8}. Dr Wright was taken to them {Day8/124:18-p125:9}: they comprise just three basic checks of each transaction, namely checking that (a) there was at least one input and one output to a transaction, (b) the value of created UTXOs was not negative, and (c) if it was a coinbase transaction that the scriptSig was of the right size and, if it was not a coinbase transaction, that its input is not null.

655.

However, Dr Wright persisted in suggesting that the CheckBlock function still checked the signatures of transactions in some mysterious, unexplained manner:

“125:10 Q. It did not involve checking ECDSA signatures, did it?

11 A. Again, that then calls these other functions.

12 Q. Dr Wright, you're wrong about that?

13 A. I am not wrong about that. If you note this,

14 the diagram that you had is hierarchical. So, that

15 particular function calls the next function, and when

16 you're talking about checking CheckSig in that

17 particular one, then that's ECDSA, but it's not in that

18 core.

19 Q. You see, Dr Wright, this is a pretty central core point

20 in relation to the operation of the Bitcoin Software and

21 you don't know about it, do you?

22 A. Actually, I do, and you're not letting me explain it

23 properly.

24 Q. I'm going to explain it to you. Can we go, please, to

25 {L4/97.1/23}. Sorry, 98.1, I think, it is, page 23

126: 1 {L4/98.1/23}. No, 97.1, page 23 {L4/97.1/23}.

2 So, do you see here that we can see a function which

3 is described as "ProcessBlock"?

4 A. I do.

5 Q. And do you see underneath that, the preliminary check

6 that it does is called "CheckBlock"?

7 A. I do.

8 Q. And do you see that a secondary check, after CheckBlock

9 has been completed, is called "AcceptBlock"?

10 A. I do.

11 Q. Now, it is within AcceptBlock that the signatures are

12 checked, isn't it?

13 A. Basically what we have is a series of functions that

14 each of these call other functions. So, where you're

15 trying to say that each of these don't do all of that,

16 the diagram that these guys don't like is a functional

17 call mapping each of these areas down.

18 Q. I'm not asking you about any diagrams, I'm asking you

19 about what is in the CheckBlock function, and you told

20 me that within the CheckBlock function were checks of

21 ECDSA signatures.

22 A. If it's a header and everything else is underneath it,

23 then that is part of the entire function and you are

24 checking everything. So when you have one function

25 follow another to be correct, then all of those

127: 1 sub functions are part of the same function.

2 Q. I'm afraid you're wrong, Dr Wright. If we want to

3 explore how you get to signatures from the AcceptBlock

4 function, I can take you there. Do you want me to do

5 that?

6 A. Like I said, the block includes both the full check and

7 each of these. So when you have a transaction that you

8 have checked, it then goes into the block and it's put

9 into a binary tree structure. All of that is checked as

10 part of the entire function. What you're doing is

11 pulling out each individual call and saying that it's

12 separate. It isn't.

13 Q. We have looked at what the CheckBlock function contains

14 and you have said it contains an ECDSA signature check.

15 It doesn't, does it?

16 A. That's not what I said.

17 Q. Well, we can see what you said.

18 A. What I said was, the function includes all of

19 the processes in that. CheckBlock doesn't work unless

20 each of the called functions are there.”

656.

In summary, the check of signatures of transactions was not part of the CheckBlock stage of the ProcessBlock function. It was carried out in the AcceptBlock stage as was demonstrated to Dr Wright at {Day8/127-129}. I agree with the Developers that Satoshi would not have got these points wrong and so this is another indication that Dr Wright did not write the Bitcoin Source Code.

Next page