Appeal to authority: A failure of trust

Abstract. In December 2015, a Motherboard article suggested that cryptographic

keys claimed by Wired and Gizmodo to be linked to Satoshi Nakamoto were created
using technology that was not available on the dates they were supposedly made.
This idea has gained widespread acceptance. However, in this paper we present
evidence that disproves this claim by showing precisely how the keys in question
could indeed have been generated on the specified dates. In addition, a warning is
rung regarding the onset of centralised authority in the control of bitcoin that has
been achieved through Blocksize restrictions. These restrictions have led to
centralisation of Bitcoin via the dogma of the core development team. This paper
highlights why it is always essential to investigate allegations and critically evaluate
the evidence presented.

1.

Introduction

This paper aims to disprove the assertion made by bitcoin core developer Greg Maxwell as reported
in Motherboard [2] (and elsewhere) that cryptographic keys associated with Satoshi Nakamoto could
not have been generated at the time they were supposedly made. This paper neither confirms nor
denies those keys; the aim is to show that their creation on the disputed dates is possible. We do
this by laying out, step by step, a repeatable procedure that any interested individual can follow to
confirm that the required cryptographic features were available at the time. Furthermore, in doing
this, we hope to edify those like Maxwell who aspire to acquire the proper skills and knowledge in
this area, so that misconceptions can be reduced and further misinformation avoided.
The logical fallacy of an appeal to authority is made whenever we try to justify an idea through
the citing of expertise as the reason to hold that idea. However, even experts are subject to
validation. The nature of science is of a system derived through empirical proof and evidence.
Generally, an appeal to authority is fallacious when we cite those who have no special expertise.
This is of greater concern when we have an individual believed or purporting to be an expert who
abuses trust. Even experts have agendas and the only means to ensure that trust is valid is to hold
those experts to a greater level of scrutiny. It remains the expert's reasons and methods that are
valuable and not the fact that a statement is made by an expert. Experts can be wrong and may not
be aware of invalid statements they have themselves made.
The importance of critical thinking cannot be overstated. Bitcoin on the Blockchain have been
designed with the aim of limiting the amount of trust needed to deal with unknown parties. It is a
system that allows us to create systems that open dialogue and communication between parties. Of
particular note, it is a system that allows us to record interactions and validate them seamlessly
across time and distance.
We remain a long way from understanding the value of the system. Before we get to a point
where we can trade and interact we need to understand the nature of trust. Even with Bitcoin, we
can never create a society that does not rely on trust. It is a part of human nature that looks to others
for leadership. Those who assume the mantle of leadership also need to understand the burdens and
the responsibilities. All too often, the limitations of those who have had leadership and
responsibility handed to them show forth in a damaging manner. The media do not sell news but
1

sell sensation. For this, the fallacies of suppressed evidence and selective attention should be first
to mind. It is in this spirit that the current paper is presented; the claims made herein are supported
by evidence with the intention that it be critically and independently evaluated.

2.

PGP key analysis and review.

In a response that has been taken up by Motherboard [2], a great deal of weight has been placed on
an assertion made by bitcoin core developer Gregory Maxwell [3] that has cast doubt on the validity
of a number of PGP keys. This paper neither confirms nor denies those keys, but it does address
the questions posed by Maxwell as reported by Wired magazine.
The misinformation questioned in this paper has been variously reported but can be summarised
as follows:
The 8,2,9,10,11 list was added to the GNUPG code tree in commit
e50cac1d848d332c4dbf49d5f705d3cbbf074ba1 on July 9th, 2009, and not
released until version 2.0.13 later. This is well after the 2008 date on the key.
The 2,8,3 list was the prior list the would have been used in 2008. That they
were different at all was surprising, considering that they claim to be
generated less than a day apart.
The list mentioned above refers to the cipher-suites, or encryption algorithms, used in the
creation of the keys. It is known that the Satoshi Nakamoto key was created using GnuPG 1.4.7. In
the following sections we provide in detail the procedure required to disprove the claim reported in
Motherboard and to highlight the dangers of reporting without sufficient fact checking. Due to the
lack of response and analysis along with the willingness to accept the word of an expert on faith
alone and without independent verification, it has become necessary to demonstrate that this position
is incorrect.

3.

GnuPG 1.4.7

As we have quoted above, it was stated that This is well after the 2008 date on the key. What was
not clarified was that the 2008 version of the software is available and has been saved.

https://web.archive.org/web/20070606214025/http://www.gnupg.org/download/
ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.7.exe1

We can test the claim that Two of the keys attributed to Satoshi were likely created using
technology that wasnt available on the dates that they were supposedly made [2]. In a download
of this software, we can simply check and refute this statement. The first step is to start by installing
the version of the software that was used on the original Satoshi key in 2008 from the link listed
above. Once this has been downloaded, we can install the old version of the software. We configure
and run this by going to the command line and changing to the directory it was installed into (see
Fig. 1). The link provided above has a copy of the software as at June 2007. This is more than a
full year prior to the 2008 keys that have been disputed.

The Signature and SHA-1 checksum for gnupg-w32cli-1.4.7.exe is available from the NIST software catalogue:
b806e8789c93dc6d08b129170d6beb9e1a5ae68f
2

Figure 1: GPG 1.4.7 install on Windows

By executing the following command, we can list the details of all the keys stored in our keyring.
gpg -a --export "Satoshi Nakamoto" | gpg --list-packets -verbose | more
With the key associated with the Vistomail account, the known fingerprint is
18C09E865EC948A1. In analysing the results of the above command on this key we can validate
the following output from the image displayed in Fig. 2.

Figure 2: Details of the Satoshi PGP key

From Fig. 2 and the results that can be independently verified, one will see the cipher suites that
are associated with the PGP with a 32-bit fingerprint of 5EC948A1. We will simply note this for
future reference at this point.
In his assertions, Gregory Maxwell had stated that both keys use a list of cipher-suites that dont
match up to the Original Key, and werent added to GPG until 2009. This statement is important
and we need to note that it was followed with the reported statement from Motherboard:
3

Maxwell found that the Wired Key and the Gizmodo Key have preferred hash
algorithms 8,2,9,10,11. The Original Key has a preferred hash algorithm
list 2,8,3. This refers to the cipher-suites, or encryption algorithms, used.
The 8,2,9,10,11 list was added to the GnuPG code tree as a commit on July
9, 2009, and released inversion 2.0.13 on September 4, 2009.
The importance of this statement is that Maxwell has firmly asserted that the algorithms,
8,2,9,10,11 have only been added from a later period in 2009. It is stated that the code tree was
built on the 09th July 2009 and that this was released on the 04 th September of the same year. The
challenge to the reader is to engage in an independent scientific examination of the evidence
presented. Each stage of this paper can be repeated. The truth is not in who has stated it, but in the
formal validation of the results. As the Internet Archive and the NIST software archives hold the
cryptographic hashes of the released software, the truth comes from a mathematical analysis of the
binary and source code that has been retrieved.
This paper details how the reader can download and install GnuPG version 1.4.7. This is a
version of the software that was commonly available in 2008 and was in fact compiled and available
to download as a binary from 2007. The mirror repository sites are maintained by NIST and the US
Library of Congress and the software hashes are widely available making the validation of this
software a reasonably straightforward proposition [4]. We have engaged in this exercise in order to
demonstrate that the former statement made by Maxwell is incorrect. From what we will document
below, the reader will note the ease with which a knowledgeable individual could have built a PGP
key using the disputed cypher suites, 8,2,9,10,11. We demonstrate this using a version of the
GnuPG binaries that had been compiled in 2007.
We start by issuing the following command used to create a new key. We can complete this
using the former version of software:
gpg --gen-key
For this exercise, GnuPG is installed on Microsoft Windows. The first version of Bitcoin and
indeed the version of PGP keys that are attributed to the Satoshi email address were compiled on
Microsoft Windows. In executing these commands in the manner listed in this paper, the reader will
obtain the same results as have been displayed in the following figures.

Figure 3: Generating a new PGP key

The first step is to enter the values for the test key that we are using to create a PGP key that we
can evaluate. In running through this process step by step, the reader will obtain an understanding
of how GnuPG functions and also an insight into the inner workings and format of the created public
and private key pairs.

Figure 4: Selecting a passphrase

Next, key is created and saved in the keyring. The requirement to move the mouse is due to a
process of collecting entropy (see Fig. 5). This is to ensure that the code used in GnuPG, rndw32.c
does not repeat the same or extremely similar results as this could lead to a compromised key. The
Riemann zeta function for example is a commonly used method of creating a pseudo random series
of numbers. If an attacker can guess the input, they can attack the private keys. This is not what we
are concerned about in this paper but should be noted by the reader to ensure that a strong source of
entropy is available when key security matters.

Figure 5: The new key is created

In this first stage, we have created a PGP key pair that has been built using a 1024 Bit DSA key
for signing and a 2048 Bit key for encryption. The nature of this exercise is to familiarise the reader
with the process of creating a default key using the 2007/8 version of GnuPG in a manner that aligns
to the 1024 bit Satoshi key.
Next, we shall extend this exercise into the creation of a 4096 Bit RSA key pair. We will then
further extend this into adding protocol suites to our keys. This is important as it will prove
definitively to the reader through evidence and not authoritative statement that the following
statement by Gregory Maxwell cannot be correct:
Two of the keys attributed to Satoshi were likely created using technology that wasnt available
on the dates that they were supposedly made.
In the logical analysis of evidence, we cannot have contradictions. Where such a contradiction
exists, we need to check our premises. In this process that we are exploring together, either we can
recreate a similar key along the lines of the one Maxwell has stated could not have existed and must
have been backdated, or we cannot. If we can create a key using the GnuPG software from 2007
6

and add the attributes of the disputed keys to a newly created key pair, then Maxwell is wrong. If
we cannot complete this process, then he was correct and the keys could have been backdated. This
is a binary outcome and there cannot be any other result.
Either creating the keys was possible, or the evidence reported by Motherboard was unfounded.

Figure 6: Creating a 4096 Bit RSA key

One of the claims made in the Motherboard article was that the creation of a 3072 bit RSA key
was unusual for the time. We will show that this is incorrect and misleading. Not only is it simple
to create a key of this length but it was a process that was readily available to a novice, let alone an
experienced user of cryptographic software. When an RSA algorithm is selected, it is possible to
create a far more secure key than when a DSA key has been chosen. The reason for this comes from
the limitations on the key length for DSA. This length is always 1024 bits as is specified by FIPS
186-2. The result is that from the limits that are imposed on the DSA key length as compared to an
RSA key length that is not limited: it is obvious that one can generate much stronger RSA keys than
DSA keys. For this reason, RSA was preferable over DSA in 2008. (Note that this was before the
wide deployment of Elliptic Curve Cryptography.)
More importantly, it has been widely argued2 that the key length of DSA was deliberately limited
in the government standard in order to increase the chances that a government agency could decrypt
it. When a signed and/or encrypted message was to be valid for a short time, say in the order of
months to a year, a 1024 bit DSA key would have been adequate. When the key would have been
required to last for a decade or more, it would have been preferable to use either a 3072 bit or 4096
bit RSA key. It should be clear to the reader that this was not a difficult decision and that a
2

This debate has been detailed at https://www.guyrutenberg.com/2007/10/05/ssh-keygentutorial-generating-rsa-and-dsa-keys/ and later at

https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html
7

knowledgeable individual who desired a contract or other signed document would not have selected
a small key length that would not be expected to have lasted for a sufficiently long term.
For a deed, the term of the deed can be calculated to be the final date plus 12 years. NIST
recommended prior to 2010 that for a document that is to be protected up until to 2030 such as the
one in question, that a Factoring Modulus or RSA key length of 3072 bits should be selected.
Given this information, it is not a great leap in logic to see that the selection of a 3072 bit RSA key
was not an unusual choice. Rather, had a lower strength key been selected for the purpose it was
used for, we would be likely to suspect either the security and cryptographic knowledge or the
integrity of the creator of that key [5], [4].
The statement noting that the selection of algorithms in the disputed PGP keys was unusual also
seems out of place. In January 2011, Gregory Maxwell moderated a discussion [1] concerning the
reason for the selection of the specific Koblitz curves used in the Bitcoin code. The use of secp256k1
has been a source of debate within the community with some contention. This selection was a tradeoff between speed and power but is out of scope in this paper other than to note that this comment
could not in itself be validly supported by anyone who knows Satoshi.
Returning to our exercise, we can view the details of the key we have just by executing the
following commands:

gpg --fingerprint "Test Account"

gpg -a --export "Test Account" | gpg --list-packets -verbose

Figure 7: Validating extended data for the new key

We see here the default hash list of 2.8.3 as Maxwell asserts is the only available choice. This
is displayed in Fig. 7 on the line that lists the pref-hash-algos. Our next exercise is to change the
default algorithms used in our newly created key to implement a new selection based on the hash
list, 8,2,9,10,11. In doing this, we logically prove that the following statement is not correct:
The 8,2,9,10,11 list was added to the GnuPG code tree as a commit on July 9,
2009, and released inversion 2.0.13 on September 4, 2009.
In this exercise, we are using the 2007/8 version of GnuPG. The consequence of this is that we
are limited to being able to select only those algorithms that are listed in the original codebase. If
algorithms 9,10,11 are not included, then this step would fail. Use the following command to
9

interactively edit the key using the algorithms that were available in the key (note that the key ID
will be the one you have created):
gpg --edit-key 85203B75B1D6C458
When running the edit-key sub-command, the reader would change the listed key value from
our example, 85203B75B1D6C458 to represent the PGP fingerprint of the key that they have just
created.

Figure 8: GPG 1.4.7 install on Windows

The list of hash algorithms that Maxwell has stated to be new 8,2,9,10,11 are defined at the
following site:
http://tools.ietf.org/html/rfc4880#section-9.4
We can validate that this site maintained this list in 2007 using the Web Archive:
https://web.archive.org/web/20071027063636/http://www.iana.org/assignments/pgp-parameters
To detail what we are discussing, the numbered hash algorithms are listed below:
8
2
9
10
11

SHA256
SHA1
SHA384
SHA512
SHA224

Returning to our example, we can issue the setpref sub-command at the command line. This
allows the owner of a PGP private key to change the set of hash algorithms used by the key. This
change is completed using the following command:
>setpref SHA256 SHA1 SHA384 SHA512 SHA224 AES256 AES192
AES CAST5 ZLIB BZIP2 ZIP Uncompressed
For this exercise, we have left the Symmetric and compression algorithms as the default. These
can be changed through variables in the same sub-command. Fig. 9 displays the output from the
execution of this command. Following this process, we have changed the default keys to include a
list of hash algorithms that are expected to remain cryptographically sound for longer. In particular,
the choice of using RSA 3072 bit signing keys such that a digital signature can last securely up to
2030 requires that we also incorporate a more secure set of hash algorithms.
10

Figure 9: GPG 1.4.7 install on Windows.

In completing the change to the private key for the exercise, it is important to remember to save
using the save interactive command. This is demonstrated in Fig. 10. This step is crucial as the
changes made to the keys are not permanent until the save command has been issued.

Figure 10: GPG 1.4.7 install on Windows

11

Having completed this exercise, the reader can now check that the newly created PGP key has
incorporated the changes and now includes the selected hash algorithms. This is completed using
the following command:
gpg -a --export "Test Account" | gpg --list-packets -verbose
This command is demonstrated in Fig. 11.

Figure 11: GPG 1.4.7 install on Windows

This exercise has allowed the reader to independently validate the inclusion of algorithms into a
PGP key. In particular, the exercise has taken the reader through the addition of algorithms into a
PGP key using the software available in 2007. Accordingly, it can be seen that the claim reported
on Motherboard stating the PGP keys are probably backdated is false.
This exercise proves that those algorithms that had been stated to not exist at the time within
GnuPG 1.4.7 had indeed been implemented. Maxwells assertion is false. To revisit this, let us
review the following quote from Motherboard:

12

We already noted that RSA-3072 is an odd form of encryption to use in 2008, but there is
other
metadata
in
these
keys
that
seem
to postdate
2008.
Keys are clearly selected for purpose. The security requirements are matched against the
economic requirements of creating and running a particular key length. For longer keys, the amount
of computational power required to both create and implement the level of desired encryption
increases. If a key is only used for limited purposes and a low cost function, the key length selected
is generally lower. When a key is required to remain secure for a long period of time, the key length
needs to be increased to accommodate this requirement.
The following page details the use of RSA 3072 in 2007:
http://www.linuxquestions.org/questions/linux-security-4/gpg-rsa-or-dsa-with-el-gamal-fornew-keys-565242/
It is important to note that at this time, due to vulnerabilities with SHA-1 and DH, RSA 3072
was a secure choice and was not uncommon. When the requirement was to maintain a signed
document for more than a decade or until at least 2020, the usual choice of keys was 3072 bit RSA.
The following exercise details the creation of an RSA-3072-bit key using the GnuPG 1.4.7
software:

Figure 12: GPG 1.4.7 install on Windows

We then issue the password in order to complete the creation of a new key. This is demonstrated
in Fig. 13.
13

Figure 13: GPG 1.4.7 install on Windows

Again using the gpg --edit-key command the reader can update the PGP key such that they
can create the required RSA encryption sub-key. In this case, the key ID is added to the command
and issued as follows:
gpg --edit-key E355680C

Figure 14: GPG 1.4.7 install on Windows

14

We create the encryption key using the addkey command. This is demonstrated in Fig. 15.

Figure 15: GPG 1.4.7 install on Windows

Finally, it is again important to save the key using the save command. This is documented in
Fig. 16. If the save command is not issued in the interactive session, the changes made to the key
will not be saved permanently.

15

Figure 16: GPG 1.4.7 install on Windows

This exercise has taken the reader through the creation of a 3072-bit RSA PGP key using GnuPG
1.4.7 as it was compiled into a Microsoft Windows binary in 2007, thereby disproving the claims
made in the Motherboard article. From this we can only conclude that the perpetrators of that
misinformation did not understand the workings of PGP sufficiently to implement a different hash
algorithm that was, as we have clearly demonstrated, readily deployed over a year before the release
of the version used in the creation of the disputed keys. We hope that the foregoing explanation will
go some way towards their education.
Maxwell states that his copy of the key log is definitive, however he has not supplied any
timestamped supporting evidence to validate this assertion. We may either conclude that Gregory
Maxwell understood what he was asserting and has intentionally misled the community in stating
that the PGP keys referenced had been backdated, or that a Bitcoin core developer did not understand
the workings of PGP sufficiently. Bitcoin was designed to allow for validation and proof in places
where trust was being abused. It was created to ensure that trust authority alone is not sufficient.

4.

On centralisation

There is an inherent warning in the foregoing discussion with regard to the growing power of
individuals who may not fully grasp the full potential of the Blockchain but who nevertheless have
a disproportionate level of influence. A case in point is the current dispute regarding the size of the
16

Blockchain. It is not the increase in size of the Blockchain that is leading towards centralisation, it
is the creation of an unintended scarcity. In limiting the size of the Block, the issue of control and
the use of the protocol is centralised to a limited number of developers. The Bitcoin protocol was
designed to be the primary protocol in the same manner that IPv4 and soon IPv6 are the primary
networking protocols. It may be that changes to Bitcoin lead to forks in the future just as IPv4 is
migrating towards IPv6, but the core of the Internet remains based on a single set of protocols. The
core of this system is an RFC or request for comment system and not a fixed standard.
The result is that we have multiple protocol stacks across the Internet that are interacting. This
is the plan for Bitcoin and the Blockchain. The bitcoin core protocol was never designed to be a
single implementation maintain by a small cabal acting to restrain the heretics. In restricting the
Blocksize, the end is the creation of a centralised management body. This can only result in a
centralised control function that was never intended for Bitcoin. Satoshi was removed from the
community to stop this from occurring. Too many people started to look to Satoshi as a figurehead
and controller. Rather than experimenting and creating new systems within Bitcoin, many people
started to expect to be led. In the absence, the experiment has not led to an ecosystem of
experimentation and research, of trial and failure, but one of dogma and rhetoric.
Several core developers, including Gregory Maxwell have assumed a mantle of control. This is
centralisation. It is not companies that we need to ensure do not violate our trust, but individuals.
All companies, all governments and all of society consists of individuals and the interactions they
create. In the past, these ideas were discussed extensively with Mike Hearn and others who saw the
need for the Blockchain to be unconstrained. Gregory Maxwell has been an avid supporter in
limiting Blocksize3. The arguments as to the technical validity of this change are political and act
against the core principles of Bitcoin. The retention of limits on Block size consolidates power into
the hands of a few individuals. This is the definition of centralisation.
The Internet was not a controlled system. Many applied for and received the equivalent of a
standard in implementing an RFC, but at the same time, the development of new Internet Protocols
occurred prior to the writing of an RFC. Many RFCs came to be written years after the protocol was
widely adopted. This is what Bitcoin was designed for. Not for cautious stagnation as the banks
have allowed themselves to enter, but for change and growth. Bitcoin was not created to have a
single core team developing. It was developed in a manner that would allow anyone to create their
own version. Each version would compete and could lead to forks, but this is a desired outcome.
Where a fork is created it will either lead to a new set of protocols, or it will be rejected. Only the
new forms of transactions are truly at risk and their introduction can be planned without the
requirements for a central governing body.

5.

Conclusion

We have demonstrated that the claims made in the Motherboard article [2] regarding the keys
associated with Satoshi are incorrect. Specifically, that the PGP key information we have analysed
demonstrates that the keys could have been created earlier rather than backdated as was alleged. In
so doing we have provided something of an instructional guide on key creation and also a warning
against the centralisation of bitcoin control especially by those who may lack sufficient technical
expertise.
Political bias should not exist within a technical solution based on the mathematical analysis of
a universal source of truth. The position that has been assumed by those seeking centralisation of
Bitcoin for many years is to create an artificial scarcity within Bitcoin associated with the limits on
the Blocksize. This is an issue that can be addressed through technology. The assertions that have
3

https://www.reddit.com/user/nullc

17

been made concerning PGP keys are a matter of fact. As the evidence is readily available, the
difficulty becomes the same of mitigating demagoguery. Rhetoric is frequently upheld over reason
whose voice is soft.
The response has not been one of reason, leading to the formation of a mob mentality. Just as
the main benefits of a digital currency are lost if a trusted party is still required to prevent doublespending, the benefits to society of a free and independent media are lost if we allow ourselves to
be bamboozled through the untested statements of an authority. Those with power need to be held
to a higher standard. When we read a statement, we should not assume its validity on face value
alone nor on the trust of an individual with an agenda. The technical analysis presented in this paper
can be validated. This is the process that should have occurred prior to Sarah Jeongs statement and
reporting of Gregory Maxwell in Motherboard. Trust placed in authority needs to be challenged [7].
Science and reason are based on the analysis of empirically derived evidence. When facts are
available, these, in the manner of the mathematical proof contained within Bitcoin need to be
analysed and validated.
The Motherboard article presented assertions as a matter of fact rather than as opinion. This has
led the community to believe that the notion of a signing subkey was created in 2014 as if it was a
fact and not a possibly uninformed opinion. It, and the encryption subkey, are only self-signed. We
have shown this assertion to be false. What has not been addressed is that there is an expiration
subpacket on the self signature of the disputed key which puts a time limit on the certification. This
follows from the definition in RFC-4880 at 5.2.3.6. Hal Finney helped write this document and
would have noted the error that has been distributed by the media. He would have further noted that
GPG will automatically use the most recent signing/encryption subkey when the master is
referenced. Where there are multiple keys in a keyring, it can be necessary to force a specific
key/subkey to be selected. To do this, it is essential that the user add an exclamation mark after the
Key ID.
The facts of this case are that the PGP key information we have analysed demonstrates that the
keys could have been created earlier and not later and backdated as was alleged. What we do not
know is whether this hasty assertion was an error from ignorance or one based on malicious intent.
It is always important to note that an absence of evidence is not evidence.
No evidence as to the existence of the PGP keys has been presented. The only evidence that
these keys have been uploaded after 2011 was a statement by Gregory Maxwell who said that he
had a 2011 chatlog where he and others discussed fake Satoshi keys (keys tied to Satoshis emails
that werent the Original Key) on the keyserver [2]. The interesting aspect to this statement was
that none of the participants to this thread thought to ask Satoshi if the keys were valid as would be
the practice in a web of trust.
Silence is not a confession. Before we decide to believe what we believe, it is necessary to verify
the information being asserted. We can clearly assert that the evidence Maxwell has presented to
justify his assertions to Motherboard that the PGP keys is false. His motives in this remain a
mystery. All we can state as to the intentions of Motherboard and Gregory is Whatevers going on
here, its pretty fishy.

18

References
[1] Development & Technical Discussion (Moderator: gmaxwell) > secp256k1

https://bitcointalk.org/?topic=2699.0
[2] Jeong, S. "Satoshi's Pgp Keys Are Probably Backdated and Point to a Hoax."

http://motherboard.vice.com/read/satoshis-pgp-keys-are-probably-backdated-and-point-to-ahoax.
[3] Maxwell, Gregory. "Blockchain Scale Tests by (Alleged) Satoshi! 340 Gb Blocks, 568k

Transactions! (Imgur.Com)." (2015)

[4] NIST Cryptographic toolset: Digital Signatures,

http://csrc.nist.gov/groups/ST/toolkit/digital_signatures.html (see also FIPS PUB 186-4

http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
[5] Orman H. & Hoffman P. (2004) "Determining Strengths for Public Keys Used for

Exchanging Symmetric Keys", RFC 3766, , 04/2004. https://www.rfceditor.org/info/rfc3766

[6]

Nakamoto, Satoshi (31 Oct 2008). "Bitcoin: A Peer-to-Peer Electronic Cash System"
(www.bitcoin.org).

[7] Thoreau, Henry David. 1849 "On the Duty of Civil Disobedience".

http://www.ibiblio.org/ebooks/Thoreau/Civil%20Disobedience.pdf
[8] Callas, J., Donnerhacke, L., Finney, H., Shaw, D. & Thayer, R. (November 2007) RFC

4880. OpenPGP Message Format. https://tools.ietf.org/html/rfc4880

19