Articles No Need to Ask: Creating Permissionless Blockchains of Metadata Records Dejah Rubel INFORMATION TECHNOLOGY AND LIBRARIES | JUNE 2019 1 Dejah Rubel (rubeld@ferris.edu) is Metadata and Electronic Resource Management Librarian, Ferris State University. ABSTRACT This article will describe how permissionless metadata blockchains could be created to overcome two significant limitations in current cataloging practices: centralization and a lack of traceability. The process would start by creating public and private keys, which could be managed using digital wallet software. After creating a genesis block, nodes would submit either a new record or modifications to a single record for validation. Validation would rely on a Federated Byzantine Agreement consensus algorithm because it offers the most flexibility for institutions to select authoritative peers. Only the top tier nodes would be required to store a copy of the entire blockchain thereby allowing other institutions to decide whether they prefer to use the abridged version or the full version. INTRODUCTION Several libraries and library vendors are investigating how blockchain could improve activities such as scholarly publishing, content dissemination, and copyright enforcement. A few organizations, such as Katalysis, are creating prototypes or alpha versions of blockchain platforms and products.1 Although there has been some discussion about using blockchains for metadata creation and management, only one company appears to be designing such a product. Therefore, this article will describe how permissionless blockchains of metadata records could be created, managed, and stored to overcome current challenges with metadata creation and management. LIMITATIONS OF CURRENT PRACTICES Metadata standards, processes, and systems are changing to meet twenty-first century information needs and expectations. There are two significant limitations, however, to our current metadata creation and modification practices that have not been addressed: centralization and traceability. Although there are other sources for metadata records, including the Open Library Project, the largest and most comprehensive database with over 423 million records is provided by the Online Computer Library Center (OCLC).2 OCLC has developed into a highly centralized operation that requires member fees to maintain its infrastructure. OCLC also restricts some members from editing records contributed by other members. One example of these restrictions is the Program for Cooperative Cataloging (PCC). Although there is no membership fee for PCC, catalogers from participating libraries must receive additional training to ensure that their institution contributes high quality records.3 Requiring such training, however, limits opportunities for participation and can create bottlenecks when non-PCC institutions identify errors in a PCC record. Decentralization NO NEED TO ASK | RUBEL 2 https://doi.org/10.6017/ital.v38i2.10822 would help smaller, less-well-funded institutions overcome such barriers to creating and contributing their records and modifications to a central database. The other significant limitation to our current cataloging practices is the lack of traceability for metadata changes. OCLC tracks record creation and changes by adding an institution’s OCLC symbol to the 040 MARC field.4 However, this symbol only indicates which institution created or edited the record, not what specific changes they made. OCLC also records a creation date and a replacement date in each record, but a record may acquire multiple edits between those two dates. Recording the details of each change within a record would help future metadata editors to understand who made certain changes and possibly why they were made. Capturing these details would also mitigate concerns about the potential for metadata deletion because every datum would still be recorded even if it is no longer part of the active record. INFORMATION SCIENCE BLOCKCHAIN RESEARCH Many researchers and institutions are exploring blockchain for information science applications. Most of these applications can be categorized as either scholarly publishing, content dissemination and management, or metadata creation and management. One of the most promising applications for blockchain is coordinating, endorsing, and incentivizing research and scholarly publishing activities. In “Blockchain for Research,” Rossum from Digital Science describes benefits such as data colocation, community self-correction, failure analysis, and fraud prevention.5 Research activity support and endorsement would use an Academic Endorsement Points (AEP) currency to support work at any level, such as blog posts, data sets, peer reviews, etc. The amount credited to each scientist is based on the AEP received for their previous work. Therefore, highly endorsed researchers will have a greater impact on the community. One benefit of this system is that such endorsements would accrue faster than traditional citation metrics.6 One detriment to this system is its reliance on the opinions of more experienced scientists. The current peer review process assumes these experts would be the best to evaluate new research because they have the most knowledge. Breakthroughs often overturn the status quo, however, and consequently may be overlooked in an echo chamber of approved theories and approaches. Micropayments using AEP could “also introduce a monetary reward scheme to researchers themselves,” bypassing traditional publishers.7 Unfortunately, such rewards could become incentives to propagate unscientific or immoral research on topics like eugenics. In addition, research rewards might increase the influence of private parties or corporations to science and society’s detriment. Blockchains might also reduce financial waste by “incentivizing research collaboration while discouraging solitary and siloed research.”8 Smart contracts could also be enabled that automatically publish any article, fund research, or distribute micropayments based on the amount of endorsement points.9 To support these goals, Digital Science is working with Katalysis on the Blockchain for Peer Review project. It is hard to tell exactly where they are in development, but as of this writing, it is probably between the pilot phase and the minimum viable product.10 The Decentralized Research Platform (DEIP) serves as another attempt “to create an ecosystem for research and scientific activities where the value of each research…will be assessed by an experts’ community.”11 The whitepaper authors note that the lack of negative findings and unmediated or open access to INFORMATION TECHNOLOGY AND LIBRARIES | JUNE 2019 3 research results and data often leads to scientists replicating the same research.12 They also state that 80 percent of publishers’ proceeds are from university libraries, which spend up to 65 percent of their entire budget on journal and database subscriptions.13 This financial waste is surprising because universities are the primary source of published research. Therefore, DEIP’s goals include research and resource distribution, expertise recognition, transparent grant processes, skill or knowledge tracking, preventing piracy, and ensuring publication regardless of the results.14 The second most propitious application of blockchain to information science is content dissemination and management.15 Blockchain is an excellent way to track copyright. Several blockchains have already been developed for photographers, artists, and musicians. Examples include photochain, copytrack, binded, and dotBC.16 Micropayments for content supports the implementation of different access models, which can provide an alternative to subscription- based models.17 Micropayments can also provide an affordable infrastructure for many content types and royalty payment structures. Blockchain could also authenticate primary sources and trace their provenance over time. This authentication would not only support archives, museums, and special collections, but it would also ensure law libraries can identify the most recent version of a law.18 Finally, Blockchain could protect digital first sale rights, which are key to libraries being able to share such content.19 “While DRM of any sort is not desirable, if by using blockchain-driven DRM we trade for the ability to have recognized digital first sale rights, it may be a worthy bargain for libraries.”20 To support such restrictions, another use for blockchain developed by companies such as LibChain is open, verifiable, and anonymous access management to library content.21 Another suitable application for blockchain is metadata creation and management.22 An open metadata archive, information ledger, or knowledgebase is very appealing because access to high quality records often requires a subscription to OCLC.23 Some libraries cannot afford such subscriptions. Therefore, they must rely on records supplied by either a vendor or a government agency, like the Library of Congress. Unfortunately, as of this writing, there is little research on how these blockchains could be constructed at the scale of large databases like those of OCLC and the Library of Congress. In fact, the only such project is DEMCO’s private, invitation-only beta.24 DEMCO does not provide any information regarding their new product, but to make its development profitable, it is most likely a private, permissioned blockchain. CREATING PERMISSIONLESS BLOCKCHAINS FOR METADATA RECORDS This section will describe how to create permissionless blockchains for metadata records including grouping transactions, an appropriate consensus algorithm, and storage options. Please note that these blockchains are intended to augment current metadata record creation and modification practices and standards, not supersede them. The author assumes that record creation and modification will still require content (RDA) and encoding (MARC) validation prior to blockchain submission. Validation in this section will refer solely to blockchain validation. Generating and Managing Public and Private Keys All distributed ledger participants will need a public key or address for blocks of transactions to be sent to them and a private key for digital signatures. One way to create these key pairs is to generate a seed, which can be a group of random words or passphrases. The SHA-256 algorithm can then be applied to this seed to create a private key.25 Next, a public key can be generated from that private key using an elliptic curve digital signature algorithm.26 For additional security, the NO NEED TO ASK | RUBEL 4 https://doi.org/10.6017/ital.v38i2.10822 public key can be hashed again using a different cryptographic hash function, such as RIPEMD160, or multiple hash functions, like Bitcoin does to create its addresses.27 These key pairs could be managed with digital wallet software. “A Bitcoin wallet is an organized collection of addresses and their corresponding private keys.”28 Larger institutions, such as the Library of Congress, could have multiple key pairs with each pair designated for the appropriate cataloging department based on genre, form, etc. Creating a Genesis Block Every blockchain must start with a “genesis block.”29 For example, a personal name authority blockchain might start with William Shakespeare’s record. A descriptive bibliographic blockchain might start with the King James Bible. This genesis block includes a block header, a recipient’s public key or address, a transaction count, and a transaction list.30 Being the first block, the block header will not contain a hash of the previous block header. It will contain, however, a hash of all of the transactions within that block to verify that the transactions list has not been altered. The block header will also include a timestamp and possibly a difficulty level and nonce.31 Then the block header is hashed using the SHA-256 algorithm and encrypted with the creator’s private key to produce a digital signature. This digital signature will be appended to the end of the block so validators can verify that the creator made the block by using their (the creator’s) public key.32 Finally, the recipient’s public key or address, the transaction count, and transaction list are appended to the block header.33 Block header • Hash of previous block header • Hash of all transactions in that block • Timestamp • Difficulty level (if applicable) • Nonce (if applicable) Block • Recipient public key or address • Transaction count • Transaction list • Digital signature In her master of information security and intelligence thesis at Ferris State University, Amber Snow investigated the feasibility of using blockchain to add, edit, and validate changes to Woodbridge N. Ferris’ authority record.34 As shown in figure 1, she began by creating a hash function using the SHA-256 algorithm to encrypt the previous hash, the timestamp, the block number, and the metadata record. “The returned encrypt value is significant because the returned data is the encrypted data that is being committed as [a] mined block transaction permanently to ledger.”35 The ledger block, however, “contains the editor’s name, the entire encrypted hash value, and the prior blocks [sic] hashed value.”36 INFORMATION TECHNOLOGY AND LIBRARIES | JUNE 2019 5 Figure 1. Creating a SHA-256 hash. Next, as shown in figures 2 and 3, she created a genesis block with a prior hashed value of zero by ingesting Ferris’ authority record as “a single line file that contains the indicator signposts for cataloging the record.”37 Figure 2. Ingesting Woodbridge N. Ferris' authority record.38 Figure 3. Woodbridge N. Ferris' authority record as a genesis block. Note the previousHash value is zero. Snow noted that “the understanding and interpretation of the MARC authority record’s signposts is not inherently relevant for the blockchain data processing.”39 To keep the scope narrow, she also avoided using public and private key pairs to exchange records between nodes. “The RI [Research Institution] blockchain does not necessarily require two users to agree…instead the RI blockchain is looking to commit and track single user edits to the record.”40 Creating and Submitting New Blocks for Validation Once a genesis block has been created and distributed, any node on the network can submit new blocks to the chain. For metadata records, new blocks should contain either new records or multiple modifications to the same record with each field being treated as a transaction. When a NO NEED TO ASK | RUBEL 6 https://doi.org/10.6017/ital.v38i2.10822 second block is appended, the new block header will include the hash of the previous block header, a hash of all of the new transactions, a new timestamp, and possibly a new difficulty level and/or nonce. The block header will then be hashed using SHA-256 and encrypted with the submitter’s private key to become a digital signature for that block. Finally, another recipient’s public key or address, a new transaction count, and a new transaction list will be appended to the block header. Additional blocks can then be securely appended to the chain ad infinitum without losing any of the transactional details. If two validators approve the same block at the same time, then the fork where the next block is appended first becomes the valid chain while the other chain becomes orphaned.41 Although Snow’s method does not include exchanging records using public keys or addresses, she was able to change a record, add it to the blockchain, and successfully commit those edits using the Proof of Work consensus algorithm.42 As shown in figure 4, after creating and submitting a genesis block as “tester 1,” she added a modified version of Woodbridge N. Ferris’ record as “tester 2.” This version appended the string “testerchanged123” to Woodbridge N. Ferris’ authority record. Then she validated or “mined” the second block to commit the changes. Figure 4. Submitting and validating an edited record. Figure 5 shows that the second block is chained to the genesis block because the “previousHash” value of the second block matches the “hash” of the genesis block. This link is what commits the block to the ledger. The appended string in the second block is at the end of the “metadata” variable. INFORMATION TECHNOLOGY AND LIBRARIES | JUNE 2019 7 Figure 5. The new authority record blockchain. A more sophisticated method to append a second block would require key pairs. As described previously, a block would include a recipient’s public key or address, which would route the new and modified records to large, known institutions like the Library of Congress. Although every node on the network can see the records and all of the changes, large institutions with well- trained and authoritative catalogers may be the best repository for metadata records and could store a preservation or backup copy of the entire chain. They are also the most reliable for validating records for content accuracy and correct encoding. Achieving Algorithmic Consensus Once a block has been submitted for validation, the other nodes use a consensus algorithm to verify the validity of the block and its transactions. “Consensus mechanisms are ways to guarantee a mutual agreement on a data point and the state…of all data.”43 The most well-known consensus algorithm is Bitcoin’s Proof of Work, but the most suitable algorithm for permissionless metadata blockchains is a Federated Byzantine Agreement. Proof of Work Proof of Work (PoW) relies on a one-way cryptographic hash function to create a hash of the block header. This hash is easy to calculate, but it is very difficult to determine its components.44 To solve a block, nodes must compete to calculate the hash of the block header. To calculate the hash of a block header, a node must first separate it into its constituent components. The hash of the previous block header, the hash of all of the transactions in that block, the timestamp, and the difficulty target will always have the same inputs. The validator, however, changes the nonce or random value appended to the block header until the hash has been solved.45 In Bitcoin this process is called “mining” because every new block creates new Bitcoins as a reward for the node that solved the block.46 NO NEED TO ASK | RUBEL 8 https://doi.org/10.6017/ital.v38i2.10822 Bitcoin also includes a mechanism to ensure the average number of blocks solved per hour remains constant. This mechanism is the difficulty target. “To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they’re generated too fast, the difficulty increases.”47 Adjusting the difficulty target within the block header keeps Bitcoin stable because its block rate is not determined by its popularity.48 In sum, validators are trying to find a nonce that generates a hash of the block header that is less than the predetermined difficulty target. Unfortunately, Proof of Work requires immense and ever-increasing computational power to solve blocks, which poses a sustainability and environmental challenge. Bitcoin and other financial services may need to rely on Proof of Work because “the massive amounts of electricity required helps to secure the network. It disincentivizes hacking and tampering with transactions…”49 because an attacker would need to control over 51 percent of the entire network to convince the other nodes that a faulty ledger is correct.50 Metadata blockchains would rely on public information and therefore would not need the same level of security as private financial, medical, or personally identifiable information. Unlike Bitcoin, metadata blockchains also would not need a difficulty target because fluctuations in block production rates would not affect a metadata block’s value the same way cryptocurrency inflation would. Therefore, despite its incredible security, Proof of Work would be computationally excessive for metadata record blockchains. Federated Byzantine Agreement Byzantine Agreements are “the most traditional way to reach consensus. […] A Byzantine Agreement is reached when a certain minimum number of nodes (known as a quorum) agrees that the solution presented is correct, thereby validating a block and allowing its inclusion on the blockchain.”51 Byzantine fault-tolerant (BFT) state machine replication protocols support consensus “despite participation by malicious (Byzantine) nodes.”52 This support ensures consensus finality, which “mandates that a valid block…never be removed from the blockchain.”53 In contrast, Proof of Work does not satisfy consensus finality because there is still the potential for temporary forking even if there are no malicious nodes.54 The “absence of consensus finality directly impacts the consensus latency of PoW blockchains as transactions need to be followed by several blocks to increase the probability that a transaction will not end up being pruned and removed from the blockchain.”55 This latency increases as block size increases, which may also increase the number of forks and possibility of attack.56 “With this in mind, limited performance is seemingly inherent to PoW blockchains and not an artifact of a particular implementation.”57 BFT protocols, however, can sustain tens of thousands of transactions at nearly network latency levels.58 A BFT consensus algorithm is also superior to one based on Proof of Work because “users and smart contracts can have immediate confirmation of the final inclusion of a transaction into the blockchain.”59 BFT consensus algorithms also decouple trust from resource ownership, allowing small organizations to oversee larger ones.60 To use BFT, every node must know and agree on the exact list of participating peer nodes. Ripple, a BFT protocol, tries to ameliorate this problem by publishing an initial membership list and allowing members to edit that list after implementation. Unfortunately, users are often reluctant to edit the membership list thereby placing most of the network’s power in the person or organization that maintains the list.61 INFORMATION TECHNOLOGY AND LIBRARIES | JUNE 2019 9 Federated Byzantine Agreement (FBA), however, does not require each node to agree upon and maintain the same membership list. “In FBA, each participant knows of others it considers important. It waits for the vast majority of those others to agree on any transaction before considering the transaction settled.”62 Theoretically, an attacker could join the network enough times to outnumber legitimate nodes, which is why quorums by majority would not work. Instead, FBA creates quorums using a decentralized method that relies on each node selecting its own quorum slices.63 “A quorum slice is the subset of a quorum convincing one particular node of agreement.”64 A node may have many slices, “any one of which is sufficient to convince it of a statement.”65 The system constructs quorums based on individual node decisions thereby generating consensus without every node being required to know about every other node in the system.66 One example of quorum slices that might be good for metadata blockchains is a tiered system as shown in figure 6. The top tier would be structured like a BFT system where the nodes can tolerate a limited number of Byzantine nodes at the same level. This level would include the core metadata authorities, such as the Library of Congress or PCC members. Members of this tier would be able to validate any record. The second or middle tier nodes would depend on the top tier because, in this example, a middle tier node requires two top tier nodes to form a quorum slice. These middle tier nodes would be authoritative, known institutions, such as universities, that already rely on the core metadata authorities on the top tier to validate and distribute their records. Finally, a third tier, such as smaller institutions, would, in this example, rely on at least two middle tier nodes for their quorum slice. Figure 6. Tiered quorum example. NO NEED TO ASK | RUBEL 10 https://doi.org/10.6017/ital.v38i2.10822 Using an FBA protocol to validate a transaction requires each node to exchange two sets of messages. The first set of messages gathers validations and the second set of messages confirms those validations. “From each node’s perspective, the two rounds of messages divide agreement…into three phases: unknown, accepted, and confirmed.”67 The unknown status becomes an acceptance when the first validation succeeds. Acceptance is not sufficient for a node to act on that validation, however, because acceptance may be stuck in an indeterminate state or blocked for other nodes.68 The accepting node may also be corrupted and validate a transaction the network quorum rejects. Therefore, the confirmation validation “allows a node to vote for one statement and later accept a contradictory one.”69 Figure 7. Validation process of statement a for a single node v. FBA would lessen concerns about sharing a permissionless blockchain, but it can “only guarantee safety when nodes choose adequate quorum slices.”70 After discovery, Byzantine nodes should be excluded from quorum slices to prevent interference with validation. One example of such interference is tricking other nodes to validate a bad confirmation message. “In such a situation, nodes must disavow past votes, which they can only do by rejoining the system under new node names.”71 Theoretically, this recovery process could be automated to include “having other nodes recognize reincarnated nodes and automatically update their slices.”72 Therefore, the key limitation to using an FBA algorithm is continuity of participation. If too many nodes leave the network, reengineering consensus would require centralized coordination whereas Proof of Work algorithms could operate after losing many nodes without substantial human intervention.73 STORING THE BLOCKCHAIN Storing a large blockchain, such as Bitcoin, is a significant challenge. One method to facilitate that storage would be to rely on top tier nodes to retain a complete copy of the blockchain and allow smaller, lower tier nodes to retain an abridged version. In Bitcoin, these methods are known as full payment verification (FPV) and simplified payment verification (SPV). FPV requires a complete copy of the blockchain to “verify that bitcoins used in a transaction originated from a mined block by scanning backward, transaction by transaction, in the blockchain until their origin is found.”74 Unfortunately, as one might expect, FPV consumes many resources and can take a long time to initialize. For example, downloading Bitcoin’s blockchain can take several days. This long installation period is partly due to the size of blockchain, but if Proof of INFORMATION TECHNOLOGY AND LIBRARIES | JUNE 2019 11 Work is used as the consensus algorithm, then the new node must also connect to other full nodes “to determine whose blockchain has the greatest proof-of-work total (by definition, this is assumed to be the consensus blockchain).”75 Using FBA instead of Proof of Work would eliminate this time and resource consuming step. In contrast, SVP only allows a node “to check that a transaction has been verified by miners and included in some block in the blockchain.”76 A node does this by downloading the block headers of every block in the chain. In addition to retaining the hash of the previous block header, these headers also include root hashes derived from a Merkle Tree. A Merkle Tree is a method where “the spent transactions…can be discarded to save disk space.”77 As shown in figure 8, combining transaction hashes for the entire block into a single root hash in the block header saves a considerable amount of storage capacity because the interior hashes can be eliminated or “pruned” off the Merkle Tree. Figure 8. Using a Merkle Tree for storage. As shown in figure 9, to verify that a transaction was included a block, a node “obtains the Merkle branch linking the transaction to the block it’s timestamped in.”78 Although it cannot check the transaction directly, “by linking it to a place in the chain he can see that a network node has accepted it and blocks after it further confirm the network has accepted it.”79 NO NEED TO ASK | RUBEL 12 https://doi.org/10.6017/ital.v38i2.10822 Figure 9. Verifying a transaction using a Merkle root hash. Compared to FVP, SVP “requires only a fraction of the memory that’s needed for the entire blockchain.”80 This small amount of storage enables SVP ledgers to sync and become operational in less than an hour.81 SVP is limited, however, only allowing nodes to manage addresses or public keys that they maintain whereas FVP ledgers are able to query the entire network. Thus, an SVP ledger must rely “on its network peers to ensure its transactions are legit.”82 Theoretically, an attacker could overpower the entire network and convince nodes using SVP to accept fraudulent transactions, but such an attack is very unlikely for metadata blockchains. For additional security, an SVP node could also “accept alerts from network nodes when they detect an invalid block, prompting the user’s software to download the full block and alerted transactions to confirm the inconsistency.”83 Adding such a feature to metadata blockchain software would eliminate the slight risk of it being contaminated by malicious actors. Thus, SVP offers the ability for smaller institutions to participate in creating and maintaining a metadata blockchain without requiring them to have the storage capacity for the entire blockchain. CONCLUSION AND FUTURE DIRECTIONS This article described how permissionless metadata blockchains could be created to overcome two significant limitations in current cataloging practices: centralization and a lack of traceability. The process would start by creating public keys using a seed and the SHA-256 algorithm and private keys using an elliptic curve digital signal algorithm. After creating the genesis block, nodes would submit either a new record or modifications to a single record for validation. Validation would rely on a Federated Byzantine Agreement (FBA) consensus algorithm because it offers the most flexibility for institutions to select authoritative peers. Quorum slices would be chosen using a tiered system where the top tier institutions would be the core metadata authorities, such as the Library of Congress. Only the top tier nodes would be required to store a copy of the entire blockchain (FVP) thereby allowing other institutions to decide whether they prefer to use SVP or FVP. INFORMATION TECHNOLOGY AND LIBRARIES | JUNE 2019 13 Future directions for research could start with investigating whether this theoretical design will work. FBA has not been heavily promoted as an option for a consensus algorithm, but its quorum slices create trust between recognized authorities and smaller institutions. Another area of study could be whether there is a significant demand for metadata blockchains. Many institutions appear frustrated at the costs and limitations of working with a vendor, but they also view such relationships as necessary for metadata record creation and maintenance. A metadata blockchain would reduce such dependence, but some institutions may be leery of using open source software. Other institutions might be hesitant to adopt blockchain because they believe it is merely another “fad” or an unnecessary addition to metadata exchange systems. A third area for research could be a cost-benefit analysis for implementing metadata blockchains that weighs current vendor fees and labor costs against the potential storage and labor costs. Such an analysis may create a tipping point where long-term return on investment outweighs the short-term challenges. ENDNOTES 1 “About the Project,” Blockchain for Peer Review, Digital Science and Katalysis, accessed Nov. 29, 2018, https://www.blockchainpeerreview.org/about-the-project/. 2 “MARC Record Services,” MARC Standards, Library of Congress, accessed Nov. 29, 2018, https://www.loc.gov/marc/marcrecsvrs.html; “Open Library Data,” Open Library, Internet Archive, accessed Nov. 29, 2018, https://archive.org/details/ol_data ; OCLC, 2017-2018 Annual Report. 3 “Join the PCC,” Program for Cooperative Cataloging, Library of Congress, accessed Nov. 29, 2018, http://www.loc.gov/aba/pcc/join.html. 4 “040 Cataloging Source (NR),” OCLC Support & Training, OCLC, accessed Nov. 29, 2018, https://www.oclc.org/bibformats/en/0xx/040.html. 5 Dr. Joris Van Rossum, “Blockchain for Research,” accessed Nov. 29, 2018, https://www.digital- science.com/resources/digital-research-reports/blockchain-for-research/. 6 Van Rossum, 11. 7 Van Rossum, 12. 8 Van Rossum, 12. 9 Van Rossum, 16. 10 Digital Science and Katalysis, “About the Project.” 11 “Decentralized Research Platform,” DEIP, accessed Nov. 29, 2018, https://deip.world/wp- content/uploads/2018/10/Deip-Whitepaper.pdf. 12 DEIP, 13. 13 DEIP, 14. 14 DEIP, 16. NO NEED TO ASK | RUBEL 14 https://doi.org/10.6017/ital.v38i2.10822 15 Jason Griffey, “Blockchain for Libraries,” Feb. 26, 2016, https://speakerdeck.com/griffey/blockchain-for-libraries. 16 “E-Services,” Concensum, accessed Nov. 29, 2018, https://concensum.org/en/e-services; “About,” Binded, accessed Nov. 29, 2018, https://binded.com/about; “FAQ,” Dot Blockchain Media, accessed Nov. 29, 2018, http://dotblockchainmedia.com/. 17 Van Rossum, “Blockchain for Research,” 10. 18 Debbie Ginsberg, “Law and the Blockchain,” Blockchains for the Information Profession, Nov. 22, 2017, https://ischoolblogs.sjsu.edu/blockchains/law-and-the-blockchain-by-debbie- ginsberg/. 19 Griffey, “Blockchain for Libraries.” 20 “Ways to Use Blockchain in Libraries,” San José State University, accessed Nov. 29, 2018, https://ischoolblogs.sjsu.edu/blockchains/blockchains-applied/applications/. 21 “LibChain: Open, Verifiable, and Anonymous Access Management,” LibChain, accessed Nov. 29, 2018, https://libchain.github.io/. 22 Griffey, “Blockchain for Libraries.” 23 San José State University. “Ways to Use Blockchain in Libraries.” 24 “Demco Software Blockchain,” Demco, accessed Nov. 29, 2018, http://blockchain.demcosoftware.com/. 25 Jordan Baczuk, “How to Generate a Bitcoin Address—Step by Step,” Coinmonks, accessed Nov. 29, 2018, https://medium.com/coinmonks/how-to-generate-a-bitcoin-address-step-by-step- 9d7fcbf1ad0b. 26 “Elliptic Curve Digital Signature Algorithm,” Bitcoin Wiki, accessed Nov. 29, 2018, https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm. 27 Conrad Barski and Chris Wilmer, Bitcoin for the Befuddled (San Francisco: No Starch Pr., 2015), 139. 28 Barski and Wilmer, 12-13. 29 Barski and Wilmer, 11. 30 Barski and Wilmer, 172-73. 31 Barski and Wilmer, 172-73. 32 Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” accessed Nov. 29, 2018, https://bitcoin.org/bitcoin.pdf. 33 Barski and Wilmer, Bitcoin for the Befuddled, 170-72. INFORMATION TECHNOLOGY AND LIBRARIES | JUNE 2019 15 34 Amber Snow, “The Design and Implementation of Blockchain Technology in Academic Resource’s Authoritative Metadata Records: Enhancing Validation and Accountability” (Master’s thesis, Ferris State University, 2018), 34. 35 Snow, 40. 36 Snow, 40. 37 Snow, 37, 40. 38 Snow, 42. 39 Snow, 37. 40 Snow, 39. 41 Barski and Wilmer, Bitcoin for the Befuddled, 23. 42 Snow, “The Design and Implementation of Blockchain Technology,” 37. 43 “9 Types of Consensus Mechanisms You Didn’t Know About,” Daily Bit, accessed Nov. 29, 2018, https://medium.com/the-daily-bit/9-types-of-consensus-mechanisms-that-you-didnt-know- about-49ec365179da. 44 Barski and Wilmer, Bitcoin for the Befuddled, 138. 45 Barski and Wilmer, 171. 46 Barski and Wilmer, 138. 47 Nakamoto, “Bitcoin,” 3. 48 Barski and Wilmer, Bitcoin for the Befuddled, 171. 49 Helen Zhao, “Bitcoin and blockchain consume an exorbitant amount of energy. These engineers are trying to change that,” CNBC, Feb. 23, 2018, https://www.cnbc.com/2018/02/23/bitcoin- blockchain-consumes-a-lot-of-energy-engineers-changing-that.html. 50 Barski and Wilmer, Bitcoin for the Befuddled, 23. 51 Shaan Ray, “Federated Byzantine Agreement,” Towards Data Science, accessed Nov. 29, 2018, https://towardsdatascience.com/federated-byzantine-agreement-24ec57bf36e0. 52 Marko Vukolić, “The Quest for Scalable Blockchain Fabric: Proof-of-Work vs. BFT Replication,” IBM Research – Zurich, accessed Nov. 29, 2018, http://vukolic.com/iNetSec_2015.pdf 53 Vukolić, “The Quest for Scalable Blockchain Fabric,” [5]. 54 Vukolić, [6]. NO NEED TO ASK | RUBEL 16 https://doi.org/10.6017/ital.v38i2.10822 55 Vukolić, [6]. 56 Vukolić, [7]. 57 Vukolić, [7]. 58 Vukolić, [7]. 59 Vukolić, [6]. 60 David Mazières, “The Stellar Consensus Protocol: A Federated Model for Internet-level Consensus,” Stellar Development Foundation, accessed Nov. 29, 2018, https://www.stellar.org/papers/stellar-consensus-protocol.pdf. 61 Mazières, 3. 62 Mazières, 1. 63 Mazières, 4. 64 Mazières, 4. 65 Mazières, 4. 66 Mazières, 5. 67 Mazières, 11. 68 Mazières, 11. 69 Mazières, 13. 70 Mazières, 28. 71 Mazières, 29. 72 Mazières, 29. 73 Mazières, 29. 74 Barski and Wilmer, Bitcoin for the Befuddled, 191. 75 Barski and Wilmer, 191. 76 Barski and Wilmer, 192. 77 Nakamoto, “Bitcoin,” 4. 78 Nakamoto, 5. 79 Nakamoto, 5. INFORMATION TECHNOLOGY AND LIBRARIES | JUNE 2019 17 80 Barski and Wilmer, Bitcoin for the Befuddled, 192. 81 Barski and Wilmer, 193. 82 Barski and Wilmer, 193. 83 Nakamoto, “Bitcoin,” 5.