Appeal to Authority: a Failure of Trust

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 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 Gr eg Maxwell as reported in Motherboard [2] (and elsewhere) that cryptographic keys associated with Satoshi Nakamoto could not have been generated generated at the time they were supposedly supposedly made. This paper neither confirms nor denies those keys; the aim is to show that their 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 features were available at the time. 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 science is of a system derived through empirical proof and evidence. 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 the only means to ensure that trust is valid is to hold those experts to a greater level of scrutiny. scrutiny. It remains the expert's reasons and methods 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 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 systems that open dialogue and communication 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 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 those who have 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 suppressed evidence and selective 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 criticall y and independently evaluated.

2.

PGP – key 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 number of PGP keys. This paper neither confirms nor denies those keys, keys, but it does address the questions posed by Maxwell as reported by Wired magazine. The misinformation questioned in this paper has been variously report ed 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. 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 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 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 i t was stated that “This “This is well after the 2008 date on the key”. 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.exe 1

We can test the claim that “Two of the keys attributed to Satoshi were likely created using technology that wasn’t available on the dates that they were supposedly made ” [2]. In a download of this software, we can simply check 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 the software as at June 2007. This is more than a full year prior to the 2008 keys that have been disputed.

1

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

Figure 1: GPG 1.4.7 install on Windows

By executing the following command, we can list the details of all t he keys stored in our keyring. !"! $% $$&'"()* +,%*(-./ 0%1%2(*(+ 3 !"! $$4/-*$"%51&*- $$ 6&)7(-& 3 2()&

With the key associated with the Vistomail account, the known fingerprint is 18C09E865EC948A1. In analysing the results of the above above command on this key we can 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 suite s 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 “both keys use a list of cipher- suites that don’t match up to the Original Key, and weren’t 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, -suites, or encryption algorithms, used. The “8,2,9,10,11” list was added to t he 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” 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 09 th 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 reader can download and install 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 exercise in order to demonstrate that the former statement statement made by Maxwell is incorrect. From what we will document document below, the reader will note the ease wit h 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 used to create a new key. We can complete this using the former version of software: !"! $$!&8$1&9

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 commands in the manner listed in this paper, the reader will obtain the same results as have been displayed in the following figures.

4

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 step by step, the reader will obtain an understanding of how GnuPG functions and also an insight into t he inner workings and format of the created p ublic and private key pairs.

Figure 4: Selecting a passphrase

5

Next, key is created and saved i n the keyri ng. The requirement to move the mouse i s due to a process of collecting entropy (see Fig. 5). This is to ensure that the code used used in GnuPG, “rndw32.c” does not repeat the same or extremely similar results as this could lead to a compromised key. 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 b y 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 Gn uPG in a manner that ali gns to the 1024 bit Satoshi key. Next, we shall extend this exercise into the creation of a 4096 40 96 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 wasn’t available on the dates that they were supposedly made”. made ”. In the logical analysis of evidence, we cannot have have contradictions. Where such a contradiction contradiction exists, we need to check our our premises. In this process that we are exploring together, 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, backdated, or we cannot. If we can create a key using 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. 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 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. software. When an RSA algorithm is selected, it is possible 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 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 was preferable over DSA in 2008. (Note that this was 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 encrypted message was to be valid for a short 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 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 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 algori thms 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 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: ●

!"! $$:/8!&)")/8* +;&-* <55(=8*+

●

!"! $% $$&'"()* +;&-* <55(=8*+ 3 !"! $$4/-*$"%51&*- $$ 6&)7(-&

8

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”. -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 we logically prove that the following statement is not correct: The “8,2,9,10,11” list list was added to the GnuPG code tree as a commit on July 9, 2009, and released in i nversion 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 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): !"! $$&>/*$1&9 ?@ABCDE@DFGHIJ@?

When running the “edit“edit -key” sub-command, 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.


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: ? A L FB FF

,K
Returning to our example, we can issue the “ setpref “ setpref ” sub-command sub-command at the command line. This allows the owner of a PGP private key to change the set set of hash algorithms used by the key. This change is completed using the following command: M-&*")&: ,K

For this exercise, we have left the Symmetric and compression algorithms as the default. These can be changed 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 changed the default keys to include 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” save” interactive command. This 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.


11

Having completed this exercise, the reader can now check that the newly created PGP key has incorporated the changes and now includes the the selected hash algorithms. This is completed using the following command: !"! $% $$&'"()* +;&-* <55(=8*+ 3 !"! $$4/-*$"%51&*- $$ 6&)7(-&

This command is demonstrated in Fig. 11.


This exercise has allowed the reader to independently validate the i nclusion 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 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 been implemented. Maxwell’s assertion is false. To revisit this, let us review the following quote from Motherboard:

12

Wee already noted that RSA-3072 is an odd form of encryption to use in 2008, but there is W other metadata in these keys that seem to postdate to postdate 2008.”

“

Keys are clearly selected for purpose. The security requirements are matched against against the economic requirements of creating and 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 limited purposes and a low cost function, function, the key length selected is generally lower. When a key is required to remain remain secure for a long period of time, the key 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 secure choice and was was not uncommon. When the requirement was to maintain 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:


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


Again using the “gpg --edit-key” --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: !"! $$&>/*$1&9 NC@@H?BI


14

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


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

15


This exercise has taken the reader through the creation of a 3072-bi t 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 r elease of the version used in the 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 validate this assertion. We may either conclude that 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 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 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 single set of protocols. The core of this system is an RFC or “request for comment” system sys tem 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 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 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 were discussed extensively with Mike Hearn and others who saw the need for the Blockchain to be unconstrained. unconstrained. Gregory Maxwell has been an avid avid supporter in 3 limiting Blocksize . 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. system. Many applied for and received the equivalent 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 what Bitcoin was designed for. Not for cautious cautious stagnation as as the banks banks have allowed themselves to enter, but for change change and growth. Bitcoin was not created to have 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 and could lead to forks, but this is a desired 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 – control – especially 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 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 through technology. The assertions that 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 mitigating demagoguery. Rhetoric is frequently upheld over reason whose voice is soft. The response has not not been one of reason, leading 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 authorit y. Those with power need to be held to a higher standard. When we read a statement, we should not assume 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 Jeong’s statement and statement and reporting of Gregory Maxwell in Motherboard. Trust placed in authority needs 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, subkey, are only self-signed. We have shown this assertion assertion to be false. What has not been addressed addressed is that there is an 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 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 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 P GP keys has been p resented. The only onl y 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” “ fake” Satoshi keys (keys tied to Satoshi’s emails emails that weren’t the Original Key ) on the keyserver ” [2]. The interesting aspect 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. confession. Before we decide to believe what we believe, it is necessary to verify the information being asserted. We can clearly assert that 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 “Whatever’s “Whatever’s going on here, it’s pretty fishy.” 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, 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 )) 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 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

Appeal to Authority: a Failure of Trust

Recommend Documents