From f2426173390e4cddd9eaebfb6622a931cd8a0123 Mon Sep 17 00:00:00 2001 From: al_morris__ Date: Wed, 25 Nov 2020 13:01:11 -0400 Subject: [PATCH 01/11] replacing magic keys with test and fixing user account loader issues --- _includes/loader.html | 3 ++- assets/js/accountHandler.js | 6 ++++-- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/_includes/loader.html b/_includes/loader.html index a09656673..84a5f1859 100644 --- a/_includes/loader.html +++ b/_includes/loader.html @@ -30,7 +30,8 @@ var loader = document.getElementById('loader') if ( loader.className.includes('d-none') ) { - loader.className = loader.className.replace('d-none', '') + // loader.className = loader.className.replace('d-none', '') + console.log('tried to clear loader and loader was already hidden') } else { loader.className += ' d-none' } diff --git a/assets/js/accountHandler.js b/assets/js/accountHandler.js index 160d04be9..b7a49b70b 100644 --- a/assets/js/accountHandler.js +++ b/assets/js/accountHandler.js @@ -7,7 +7,9 @@ // } // }, i*500) // } -window.serverUrl = "http://localhost:8888/user" +const MAGIC_PUBLIC_KEY = "pk_test_4429B9D857E9A6B7"; + +window.serverUrl = "http://localhost:8888/user"; // window.serverUrl = "https://app.weteachblockchain.org/user" /* 3️⃣ Implement Render Function */ @@ -368,7 +370,7 @@ function loadAndSetupMagic() { if (!window.magicLoaded) { window.magicLoaded = true console.log('window.magicloaded is !true ', window.magicLoaded) - magic = new Magic("pk_live_EA466C1563BC5CFF"); + magic = new Magic(MAGIC_PUBLIC_KEY); console.log('about to render magic') renderMagic(); const checkUserData = async () => { From c7cc628dc0e3a393de54707e0d2825f9c1327bd2 Mon Sep 17 00:00:00 2001 From: al_morris__ Date: Wed, 25 Nov 2020 17:45:40 -0400 Subject: [PATCH 02/11] ff --- .../_lessons/bitcoin-for-devs_lesson01 2.md | 29 -- .../_lessons/bitcoin-for-devs_lesson02 2.md | 68 ---- .../_lessons/bitcoin-for-devs_lesson03 2.md | 137 -------- .../_lessons/bitcoin-for-devs_lesson04 2.md | 64 ---- .../_lessons/bitcoin-for-devs_lesson05 2.md | 54 ---- .../_lessons/bitcoin-for-devs_lesson06 2.md | 126 -------- .../_lessons/bitcoin-for-devs_lesson07 2.md | 82 ----- .../_lessons/bitcoin-for-devs_lesson08 2.md | 135 -------- .../_lessons/bitcoin-for-devs_lesson09 2.md | 183 ----------- .../_lessons/bitcoin-for-devs_lesson10 2.md | 38 --- .../_lessons/bitcoin-for-devs_lesson11 2.md | 101 ------ .../_lessons/bitcoin-for-devs_lesson12 2.md | 114 ------- .../_lessons/bitcoin-for-devs_lesson13 2.md | 115 ------- .../_lessons/bitcoin-for-devs_lesson14 2.md | 21 -- .../_lessons/blockchain-101_lesson_01 2.md | 20 -- .../_lessons/blockchain-101_lesson_02 2.md | 32 -- .../_lessons/blockchain-101_lesson_03 2.md | 50 --- .../_lessons/blockchain-101_lesson_04 2.md | 34 -- .../_lessons/blockchain-101_lesson_05 2.md | 40 --- .../_lessons/blockchain-101_lesson_06 2.md | 43 --- .../_lessons/blockchain-101_lesson_07 2.md | 40 --- .../_lessons/blockchain-101_lesson_08 2.md | 25 -- .../_lessons/blockchain-101_lesson_09 2.md | 30 -- .../_lessons/blockchain-101_lesson_10 2.md | 50 --- .../_lessons/blockchain-101_lesson_11 2.md | 39 --- .../_lessons/blockchain-101_lesson_12 2.md | 47 --- .../_lessons/blockchain-101_lesson_13 2.md | 25 -- .../_lessons/blockchain-101_lesson_14 2.md | 39 --- .../_lessons/blockchain-101_lesson_15 2.md | 46 --- .../_lessons/blockchain-101_lesson_16 2.md | 36 --- .../_lessons/blockchain-101_lesson_17 2.md | 17 - .../_lessons/blockchain-101_lesson_18 2.md | 17 - .../blockchain_security_lesson01 2.md | 34 -- .../blockchain_security_lesson02 2.md | 30 -- .../blockchain_security_lesson03 2.md | 35 --- .../blockchain_security_lesson04 2.md | 29 -- .../blockchain_security_lesson05 2.md | 45 --- .../blockchain_security_lesson06 2.md | 69 ----- .../blockchain_security_lesson07 2.md | 36 --- .../blockchain_security_lesson08 2.md | 22 -- .../blockchain_security_lesson09 2.md | 26 -- .../blockchain_security_lesson10 2.md | 31 -- .../blockchain_security_lesson11 2.md | 15 - .../_lessons/business_lesson01 2.md | 47 --- .../_lessons/business_lesson02 2.md | 59 ---- .../_lessons/business_lesson03 2.md | 37 --- .../_lessons/business_lesson04 2.md | 48 --- .../_lessons/business_lesson05 2.md | 37 --- .../_lessons/business_lesson06 2.md | 67 ---- .../_lessons/business_lesson07 2.md | 67 ---- .../_lessons/business_lesson08 2.md | 44 --- .../_lessons/business_lesson09 2.md | 42 --- .../_lessons/business_lesson10 2.md | 38 --- .../_lessons/business_lesson11 2.md | 35 --- .../_lessons/business_lesson12 2.md | 17 - .../decentralized-storage_lesson01 2.md | 41 --- .../decentralized-storage_lesson02 2.md | 24 -- .../decentralized-storage_lesson03 2.md | 28 -- .../decentralized-storage_lesson04 2.md | 40 --- .../decentralized-storage_lesson05 2.md | 29 -- .../decentralized-storage_lesson06 2.md | 30 -- .../decentralized-storage_lesson07 2.md | 18 -- .../decentralized-storage_lesson08 2.md | 37 --- .../decentralized-storage_lesson09 2.md | 58 ---- .../decentralized-storage_lesson10 2.md | 26 -- .../decentralized-storage_lesson11 2.md | 15 - ...1-blockchain-beyond-bitcoin_lesson_01 2.md | 42 --- ...1-blockchain-beyond-bitcoin_lesson_02 2.md | 33 -- ...1-blockchain-beyond-bitcoin_lesson_03 2.md | 68 ---- ...1-blockchain-beyond-bitcoin_lesson_04 2.md | 37 --- ...1-blockchain-beyond-bitcoin_lesson_05 2.md | 40 --- ...1-blockchain-beyond-bitcoin_lesson_06 2.md | 22 -- ...1-blockchain-beyond-bitcoin_lesson_07 2.md | 34 -- ...1-blockchain-beyond-bitcoin_lesson_08 2.md | 38 --- ...1-blockchain-beyond-bitcoin_lesson_09 2.md | 48 --- ...1-blockchain-beyond-bitcoin_lesson_10 2.md | 28 -- ...1-blockchain-beyond-bitcoin_lesson_11 2.md | 31 -- ...1-blockchain-beyond-bitcoin_lesson_12 2.md | 37 --- ...1-blockchain-beyond-bitcoin_lesson_13 2.md | 20 -- .../_lessons/hyperledger_lesson01 2.md | 66 ---- .../_lessons/hyperledger_lesson02 2.md | 35 --- .../_lessons/hyperledger_lesson03 2.md | 82 ----- .../_lessons/hyperledger_lesson04 2.md | 27 -- .../_lessons/hyperledger_lesson05 2.md | 20 -- .../_lessons/hyperledger_lesson06 2.md | 62 ---- .../_lessons/hyperledger_lesson07 2.md | 61 ---- .../_lessons/hyperledger_lesson08 2.md | 38 --- .../_lessons/hyperledger_lesson09 2.md | 69 ----- .../_lessons/hyperledger_lesson10 2.md | 37 --- .../_lessons/hyperledger_lesson11 2.md | 49 --- .../_lessons/hyperledger_lesson12 2.md | 25 -- .../_lessons/hyperledger_lesson13 2.md | 23 -- .../_lessons/hyperledger_lesson14 2.md | 29 -- .../_lessons/hyperledger_lesson15 2.md | 16 - all_collections/_lessons/ipfs_lesson_01 2.md | 33 -- all_collections/_lessons/ipfs_lesson_02 2.md | 31 -- all_collections/_lessons/ipfs_lesson_03 2.md | 38 --- all_collections/_lessons/ipfs_lesson_04 2.md | 29 -- all_collections/_lessons/ipfs_lesson_05 2.md | 17 - all_collections/_lessons/ipfs_lesson_06 2.md | 26 -- all_collections/_lessons/ipfs_lesson_07 2.md | 21 -- all_collections/_lessons/ipfs_lesson_08 2.md | 37 --- all_collections/_lessons/ipfs_lesson_09 2.md | 29 -- all_collections/_lessons/ipfs_lesson_10 2.md | 29 -- all_collections/_lessons/ipfs_lesson_11 2.md | 38 --- all_collections/_lessons/ipfs_lesson_12 2.md | 33 -- all_collections/_lessons/ipfs_lesson_13 2.md | 26 -- all_collections/_lessons/ipfs_lesson_14 2.md | 19 -- all_collections/_lessons/ipfs_lesson_15 2.md | 22 -- all_collections/_lessons/ipfs_lesson_16 2.md | 57 ---- all_collections/_lessons/ipfs_lesson_17 2.md | 18 -- assets/img/badges/blockchain101.png | Bin 0 -> 315525 bytes assets/img/badges/blockchainsecurity.png | Bin 0 -> 315525 bytes assets/js/swiped.min 2.js | 9 - aws_config 2.md | 31 -- checkKeywords 2.sh | 1 - jobs 2.html | 108 ------- socialFooterIframe 2.html | 23 -- support-us 2.html | 130 -------- use-bitcoin 2.html | 293 ------------------ userProfile 2.html | 265 ---------------- userProfile.html | 70 +++++ 122 files changed, 70 insertions(+), 5633 deletions(-) delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson01 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson02 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson03 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson04 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson05 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson06 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson07 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson08 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson09 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson10 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson11 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson12 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson13 2.md delete mode 100644 all_collections/_lessons/bitcoin-for-devs_lesson14 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_01 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_02 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_03 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_04 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_05 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_06 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_07 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_08 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_09 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_10 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_11 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_12 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_13 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_14 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_15 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_16 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_17 2.md delete mode 100644 all_collections/_lessons/blockchain-101_lesson_18 2.md delete mode 100644 all_collections/_lessons/blockchain_security_lesson01 2.md delete mode 100644 all_collections/_lessons/blockchain_security_lesson02 2.md delete mode 100644 all_collections/_lessons/blockchain_security_lesson03 2.md delete mode 100644 all_collections/_lessons/blockchain_security_lesson04 2.md delete mode 100644 all_collections/_lessons/blockchain_security_lesson05 2.md delete mode 100644 all_collections/_lessons/blockchain_security_lesson06 2.md delete mode 100644 all_collections/_lessons/blockchain_security_lesson07 2.md delete mode 100644 all_collections/_lessons/blockchain_security_lesson08 2.md delete mode 100644 all_collections/_lessons/blockchain_security_lesson09 2.md delete mode 100644 all_collections/_lessons/blockchain_security_lesson10 2.md delete mode 100644 all_collections/_lessons/blockchain_security_lesson11 2.md delete mode 100644 all_collections/_lessons/business_lesson01 2.md delete mode 100644 all_collections/_lessons/business_lesson02 2.md delete mode 100644 all_collections/_lessons/business_lesson03 2.md delete mode 100644 all_collections/_lessons/business_lesson04 2.md delete mode 100644 all_collections/_lessons/business_lesson05 2.md delete mode 100644 all_collections/_lessons/business_lesson06 2.md delete mode 100644 all_collections/_lessons/business_lesson07 2.md delete mode 100644 all_collections/_lessons/business_lesson08 2.md delete mode 100644 all_collections/_lessons/business_lesson09 2.md delete mode 100644 all_collections/_lessons/business_lesson10 2.md delete mode 100644 all_collections/_lessons/business_lesson11 2.md delete mode 100644 all_collections/_lessons/business_lesson12 2.md delete mode 100644 all_collections/_lessons/decentralized-storage_lesson01 2.md delete mode 100644 all_collections/_lessons/decentralized-storage_lesson02 2.md delete mode 100644 all_collections/_lessons/decentralized-storage_lesson03 2.md delete mode 100644 all_collections/_lessons/decentralized-storage_lesson04 2.md delete mode 100644 all_collections/_lessons/decentralized-storage_lesson05 2.md delete mode 100644 all_collections/_lessons/decentralized-storage_lesson06 2.md delete mode 100644 all_collections/_lessons/decentralized-storage_lesson07 2.md delete mode 100644 all_collections/_lessons/decentralized-storage_lesson08 2.md delete mode 100644 all_collections/_lessons/decentralized-storage_lesson09 2.md delete mode 100644 all_collections/_lessons/decentralized-storage_lesson10 2.md delete mode 100644 all_collections/_lessons/decentralized-storage_lesson11 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_01 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_02 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_03 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_04 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_05 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_06 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_07 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_08 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_09 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_10 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_11 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_12 2.md delete mode 100644 all_collections/_lessons/ethereum-101-blockchain-beyond-bitcoin_lesson_13 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson01 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson02 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson03 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson04 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson05 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson06 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson07 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson08 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson09 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson10 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson11 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson12 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson13 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson14 2.md delete mode 100644 all_collections/_lessons/hyperledger_lesson15 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_01 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_02 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_03 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_04 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_05 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_06 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_07 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_08 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_09 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_10 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_11 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_12 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_13 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_14 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_15 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_16 2.md delete mode 100644 all_collections/_lessons/ipfs_lesson_17 2.md create mode 100644 assets/img/badges/blockchain101.png create mode 100644 assets/img/badges/blockchainsecurity.png delete mode 100644 assets/js/swiped.min 2.js delete mode 100644 aws_config 2.md delete mode 100644 checkKeywords 2.sh delete mode 100644 jobs 2.html delete mode 100644 socialFooterIframe 2.html delete mode 100644 support-us 2.html delete mode 100644 use-bitcoin 2.html delete mode 100644 userProfile 2.html diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson01 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson01 2.md deleted file mode 100644 index cd63e07ca..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson01 2.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 1 -title: Prelude -permalink: /courses/bitcoin-for-developers/1/prelude ---- -
-
-Bitcoin for Developers - -Welcome to Blockchain Institute’s Bitcoin for Developers series of courses. This series was created for experienced developers who are comfortable in a UNIX based command line and want to learn how to work with blockchain technology, specifically the Bitcoin Blockchain Network. If you are new to Bitcoin, or haven't already browsed through Blockchain 101 and Blockchain Security, now would be a great time! - -In the Bitcoin for Developers Part I course we’ll be covering the following topics: -
- -
-Part II will cover Bitcoin transactions, scripting, and integrating payments. Blockchain Institute will also be offering courses covering Scaling and the Lightning Network! - -Let’s get started! - diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson02 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson02 2.md deleted file mode 100644 index baed56c27..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson02 2.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 1 -title: A Bitcoin History Lesson -permalink: /courses/bitcoin-for-developers/1/bitcoin-history-lesson ---- -
-
- -This course was designed for developers with no prior blockchain experience, so we’ll start right at the beginning by answering the question, what problem was the first blockchain, Bitcoin, built to solve? - -The quick answer here is the Double-Spend Problem or the Byzantine Generals Problem, which we’ll discuss more below. - -We think of Bitcoin and cryptocurrency as a rather new technology, and it is, but the vision of cash for the Internet is nearly as old as the Internet. - -When HTTP error codes were being created, code 402 Payment Required, was held for future use. - - - -Subsequently, there were many digital currency experiments prior to Bitcoin. Here’s a list of some fairly successful ones: - -DigiCash was founded by cryptographer David Chaum in 1989. The company developed a number of privacy protecting cryptographic protocols and saw some success with the companies product eCash which was trialed by two Australian banks in the ’90s. - -Other notable projects include E-Gold, Liberty Reserve , and Gold Money. Most of these systems sought to instill confidence by owning gold to back their currency and give it value. These currencies were essentially online tokens representing gold owned by the company. - -{% include callouts/note.html - bodyText="Some understanding of monetary theory is helpful here to properly grasp the functioning of these currencies and modern cryptocurrencies. When a currency is not “backed” by a commodity, such a gold, and controlled by a nation state there needs to be another means of giving it value. Generally, this is done through scarcity either by limiting the supply, via cryptography and a blockchain network or by tying it to a limited physical commodity such as gold." -%} - -While these systems worked, they had a serious drawback that was lamented by many in the digital currency community, they were centralized services. This centralization ran counter to the peer-to-peer dream of many digital pioneers, like the renowned “cypherpunks,” introducing security and privacy risks. However, this centralization existed for one very good reason, the Double-Spend Problem. - -Digital goods are very easy to copy. As in copy/paste easy to copy. - - - -When you have a string of data that represents a digital coin, you can use cryptography to prove origin, but you can’t prevent duplication. - -For example, let’s imagine that Alice has only one coin and yet she owes both Bob and Charlie one coin each. Alice can attempt to pay both of them using the same coin. She can take her coin, cryptographically sign it to prove that it is hers and then send it along to Bob. However, she can them take that same string of data that represents her coin, sign it again and send it along to Charlie. She is spending the same coin twice (double spending), and it’s not hard to see how this leads very quickly to massive inflation and destroys the currency. - -A central server can be used to prevent double spends--but is there another way? - - - -In the server-client model, payments can’t go directly from Alice to Bob, instead they first need to go through the central server which does the work of debiting Alice’s account and crediting Bob’s account. - -Many digital currency pioneers worked hard on solutions to this technological centralization issue and created federated systems, etc. But the peer-to-peer dream wasn’t realized until the development of Bitcoin, which solved the pesky problem of digital uniqueness. - -The Bitcoin Whitepaper was published by Satoshi Nakamoto in October 2008. Although not directly called so in the paper, this was the invention of what we now call the Blockchain. - -The whitepaper should certainly be read by anyone looking to understand this technology and its origins. But to summarized, Satoshi wanted to replace the centralized server with a peer-to-peer network which would then do the work of keeping track of who has what and when. - -{% include callouts/imageWithCaption.html - image="courses/bitcoin-for-developers/ByzantineGenerals2-01.jpg" - title="The Byzantine Generals Problem" - bodyText="General; B: Traitor. Byzantine Generals problem is an old fashioned analogy for a modern computing problem. The analogy is an army of generals encircling an enemy city. To defeat the enemy the generals must attack at the same time. However, there may be traitors amongst them. How do they coordinate this data and agree upon an attack time in hostile territory with the possibility of traitors?" -%} - -In the computer science world, this phrase refers to the possibility of having to cope with the failure of some of the components in the system. - -This term is used frequently in the blockchain world as it refers to the problem of reaching consensus in an open system where not all parties can be assumed to be trustworthy. - -The dream for this network is that is would be open to anyone. This brings us to the question of how do you coordinate data with people, around the world, who you don’t know or trust? - -{% include callouts/note.html - bodyText="Satoshi Nakamoto is a pseudonym. It is still not clear who the creators of Bitcoin are or were." -%} - diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson03 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson03 2.md deleted file mode 100644 index 0e64ecb14..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson03 2.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 1 -title: Enter the Blockchain - Part I -permalink: /courses/bitcoin-for-developers/1/enter-the-blockchain-part-i ---- -
-
-The Bitcoin blockchain was created to allow a network to coordinate and reach “consensus,” or agreement on shared data. Blockchains were created to solve the problem of how do users coordinate data with people, around the world, who they don’t know or trust? - -In this lesson and the next, we’ll walk through how the Bitcoin network comes to agreement on transaction data. - -But first, lets cover hashing as it is an integral part of the Bitcoin “Proof-of-Work consensus mechanism.” - -A hash function takes an input value and creates an output value deterministic of the input value. For any input value X, you will always receive the same output value Y whenever the hash function is run. In this way, every input has a determined output. - - -

Properties of hashes:

-
- -This is very useful in a number of ways. It allows you to use a hash as a nearly unforgeable identifier of data which can then be used to validate that data. The hash of data can also be used in a table to facilitate the quick lookup of that data. - -Bitcoin uses hash in many ways. For example, they are used to create transaction ID’s and to summarize and secure the data in a “block” of transaction data via Merkle trees. -{% include callouts/definition.html - title="MERKLE TREE" - bodyText="A tree constructed by hashing paired data (the leaves), then pairing and hashing the results until a single hash remains, the Merkle root." -%} - -{% include callouts/note.html - bodyText='The SHA-256 hash algorithm is used extensively in bitcoin.' -%} - -And now that hashes are out of the way, let's get back to understanding how the Bitcoin network makes decisions on which data is correct, and which is not. - -The first thing to keep in mind here is that this is a truly peer-to-peer network. There is no Bitcoin corporation, nor is there any one entity in control. - -When trying to visualize this process, it is helpful to keep the picture of nodes (computers) on a distributed network in your head. Remember, bitcoin is not a business or corporation, there is no CEO, no one entity is in control of it. Bitcoin is simply a network of computers all running the same, or compatible, software. - - - - -Let’s walk through the Bitcoin blockchain proof-of-work consensus process with an example: - -You have one bitcoin that you are trying to double spend. You create a perfectly valid bitcoin transaction sending your 1 BTC (the abbreviation for the currency unit of Bitcoin) to Alice. You sign that transaction and broadcast it to the Bitcoin peer-to-peer (P2P) network. However, at the same time, you create an also perfectly valid transaction sending that 1 BTC to Bob, sign and broadcast it. How will the network decide which transaction is valid and which transaction is to be rejected as a double spend? - - - -Every node on the Bitcoin network contributes to “consensus,” the process by which the data is agreed upon and becomes the ‘truth’ on the network. However, certain nodes, called miners, play a very important role in this process. - -The Bitcoin software creates a competition between mining nodes who do the work of gathering transaction data into “blocks.” In this competition, the winning miner receives a reward for their work and their block of data becomes a part of the blockchain. - -The mining reward plays a very important role in providing economic incentives to do the work of maintaining the network. Miners, who are simply people running computers with a lot of processing power, are competing with each other to create a valid block of Bitcoin transaction data that will be accepted by the network. When a miners block of data is accepted by the network, they are given some bitcoin as a “mining reward” or “block reward” This happens in a special transaction called a coinbase transaction (not to be confused with Coinbase the company). - - - -When the Bitcoin network was launched in 2009, the reward was 50 BTC per block. This reward halves (called halving) every 4 years (or 210,000 mined blocks) until it reaches an amount too small to transfer on the Bitcoin network. This was originally scheduled for the year 2140, but due to variations in difficulty adjustments, will likely occur before then. - -To create a valid block and win the competition, a miner needs to validate all the transactions in the block and then find a hash for the block that meets with the current network requirements. - -The Bitcoin software is designed to self adjust it’s settings so that a block is found roughly every ten minutes. This is done via a network difficulty setting. Roughly every two weeks, every 2016 blocks, all the nodes on the network calculate how quickly valid blocks were “found” or “mined” on the network. If valid blocks of transaction data were mined more frequently than every 10 min, the difficulty requirement will go up. If blocks were minded less often than every 10 min, the difficulty requirement will do down. - -The difficulty requirement is simply the format of the hash of the block data. - -When the difficulty requirement goes up, then the network will only accept hashes that start with a greater number of zeros. - -For example, the first hash below might not be ‘difficult’ enough to meet current network standards, while the second hash might be satisfactory. - -{% include callouts/codeSnippet.html - title="A low-difficulty hash" - bodyText="00000000000008a3a41b85b8b29ad444def299fee21793cd8b9e567eab02cd81" -%} - -{% include callouts/codeSnippet.html - title="A higher difficulty hash" - bodyText="0000000000000000000085b8b29ad444def299fee21793cd8b9e567eab02cd81" -%} - -This involves some luck as a miner will not be able to determine what the hash will look like prior to running the data through the hashing function. However, we call it difficulty rather than luckiness as the more computing power miners put into the process(relative to the rest of the network) the more likely they are to be lucky enough to find an acceptable hash. - -A miner attempts to find an acceptable hash simply by hashing the block data together with a random number called a “nonce.” - -{% include callouts/definition.html - title="NONCE" - bodyText="An arbitrary number that can be used just once in cryptographic communication. In the case of bitcoin mining, a nonce is added to the block data to produce variation in hashing output." -%} - -A miner will hash the block data, again and again, each time trying a different nonce until they are successful in finding a valid block hash, or until another miner has done so. - -Because of the way hash functions work, finding a compatible hash is a matter of trial and error that can take a considerable amount of computing power. Yet, verifying that a hash is valid is very quick and easy. - -This hashing is intentional busy work called “proof-of-work,” a concept first developed as a method to combat spam emails in 1993. - -This competition plays out with a miner winning the competition and receiving a reward roughly every 10min. - -In the next lesson, we’ll see how this competition determines which transaction in a double spend is valid and which is rejected. But first, here are some Mining Terms to get familiar with: - -{% include callouts/definition.html - title="DIFFICULTY" - bodyText="The number of leading zeros that a block hash should have." -%} - -{% include callouts/definition.html - title="BLOCK REWARD" - bodyText="The amount of BTC given to a miner when their block is accepted by the network." -%} - -{% include callouts/definition.html - title="BLOCK TIME" - bodyText="A measure of how long it will take the hashing power of the network to find a solution to the block hash, on average." -%} - -{% include callouts/definition.html - title="HASH RATE" - bodyText="The estimated number of terahash per second the Bitcoin network is performing." -%} - -{% include callouts/definition.html - title="HASHING POWER" - bodyText="The hash rate of a particular mining computer." -%} - -{% include callouts/definition.html - title="APPLICATION SPECIFIC INTEGRATED CIRCUIT (ASIC)" - bodyText="A computer chip built to be heavily optimized for a particular computational process, such as hashing SHA256." -%} - -{% include callouts/definition.html - title="HALVING" - bodyText="The date, roughly every four years, when the block reward is reduced by half." -%} diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson04 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson04 2.md deleted file mode 100644 index f764f0123..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson04 2.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 1 -title: Enter the Blockchain - Part II -permalink: /courses/bitcoin-for-developers/1/enter-the-blockchain-part-ii/ ---- -
-
- -So let’s head back to our example where you are attempting a double spend on the Bitcoin network. You have broadcast two valid transactions for 1 BTC each, one to Alice and one to Bob in an attempt to spend the same bitcoin twice. - - - -Which transaction “wins” and becomes valid depends upon which miner wins the mining race! If miner Ayat received the transaction to Alice first, her mining software will then reject the transaction to Bob as an invalid double spend. She will create a block that includes the transaction to Alice, not Bob. If the miner Han receives the transaction to Bob first, his software will reject the transaction to Alice as an invalid double spend. He will create a block that includes the transaction to Bob, not Alice. Though both valid, one of these will lose as an “orphaned block.” - -{% include callouts/definition.html - title="ORPHANED BLOCKS" - bodyText="These are blocks which are entirely valid but did not become part of the main chain. They can occur naturally when two miners produce blocks at similar times." -%} - -If Ayat, or any miner who received Alice’s transaction first, wins this round of the mining race, then Alice receives the transaction. If Han, or any miner who received Bob’s transaction first, wins this round of the mining race, then Bob receives the transaction. - - - -Let’s assume that Han “wins” this round of the mining race by being the first to find a hash for his block of transaction data that meets with the current network standards. His block of data contains the transaction sending the funds to Bob. He quickly transmits his winning block to the rest of the network. The funds in question are transferred to Bob and the duplicate transaction going to Alice is rejected as an invalid. -

While it was quite difficult for Han’s computer to find the winning hash, it is trivial for other computers on the network to verify that he has indeed won. Once other nodes have verified that Han did indeed win, they will accept Han’s block, approving of the coinbase transaction that rewards him for his work, and then carry on trying to find a valid hash for the next block.

- -{% include callouts/note.html - bodyText='There will only ever be 21 Million bitcoins. Bitcoins are created in the coinbase transaction and given to the winning miner as the block or mining reward. When the network launched in 2009 the mining reward was 50BTC. This reward halves roughly every 4 years, specifically every 210,000 blocks. "Halvings” have taken place in 2012 and 2016, leaving the current block reward at 12.5BTC. The next halving is estimated to take place in 2020. This will continue until the block reward is too small of an amount to be tracked on the Bitcoin network which is estimated to happen ~2140 leaving a total of 21 million BTC.' -%} - -This is how Blockchain gets it's name. Each new block of data is cryptographically linked to the last block by including the hash of the previous block in the new block. In this way, blocks are linked together in a sort of cryptographic chain, hence the name blockchain. - -{% include callouts/definition.html - title="BLOCK TIME AND DIFFICULTY ADJUSTMENTS" - bodyText="When new mining computers join the network there is an increase to the total hashing power of the network, which means that blocks are likely to be found sooner. This situation likely means that the difficulty will be adjusted upwards. And the reverse is true as well. When miners leave the network, the difficulty will be adjusted downwards." -%} - -{% include callouts/definition.html - title="CONFIRMATIONS" - bodyText="When a transaction has been included in a block it is said to have one 'confirmation'. When a second block is mined ‘on top’ of that block, we say that the transaction now has 2 confirmations, etc, etc. The more confirmations, or blocks added to that chain, the greater the certainty for that transaction. This is important as in a decentralized network like Bitcoin, confirming a transaction is not as simple as a database entry." -%} - -The above is the way in which the Bitcoin network agrees upon data and achieves “consensus.” While this whole process is managed by the Bitcoin software, it would be incorrect to think of this system as only computer science. Open, public blockchains like Bitcoin, are entire economic systems that rely heavily on monetary theory, economics, incentive structures, and game theory to function and thrive. - -{% include callouts/definition.html - title="CONSENSUS ALGORITHM" - bodyText="This is the method by which a network achieves agreement on data. Bitcoin’s consensus algorithm is often referred to as a proof-of-work algorithm due to its heavy reliance on proof-of-work hashing done by miners. Bitcoin’s consensus essentially creates a proof-of-work race between miner nodes in order to determine who gets to add data to the blockchain." -%} - -{% include callouts/note.html - bodyText="There are many other consensus algorithms that have been developed since Bitcoin, such as proof-of-stake." -%} - - -{% include callouts/callout.html - title="INCENTIVES AND GAME THEORY" - bodyText='Bitcoin and other open blockchain systems cannot function without economic incentives. Understanding the system and trying to predict how an open blockchain will behave cannot be done without considering the game theory.' -%} - -What are the Implications? While outside the scope of this course, it is very interesting to consider the implications of this technology. What might be the impact of money that exists outside the nation-state? What might be the impact of a technology that changes who and how we trust? - -Now that was a lot of information to absorb! While that information settles in your head, let’s cover some cryptography basics. diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson05 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson05 2.md deleted file mode 100644 index 89b1b96f9..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson05 2.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 2 -title: Asymmetric Cryptography -permalink: /courses/bitcoin-for-developers/2/asymmetric-cryptography ---- -
-
- -Cryptocurrencies are called so because cryptography is the material they are built with. Having a basic understanding of asymmetric cryptography is a prerequisite for comprehending how cryptocurrencies work. - -Asymmetric or public/private key cryptography was developed in the 1970s. Prior to then, the only cryptography available was symmetric. Let’s take a look at how symmetric cryptography works to gain some insight into why asymmetric cryptography was developed and the advantages it has. - -{% include callouts/bigQuote.html - body="Public-key cryptography, or asymmetric cryptography, is a cryptographic system that uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner. The generation of such keys depends on cryptographic algorithms based on mathematical problems to produce one-way functions. Effective security only requires keeping the private key private; the public key can be openly distributed without compromising security." - sourceName="Wikipedia" - sourceUrl="https://en.wikipedia.org/wiki/Public-key_cryptography" -%} - -Alice and Bob want to communicate securely with one another. - - - -To do this Alice creates a message to Bob and scrambles it using a specific formula also called an encryption algorithm. This is done using a secret, or a key. - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/SharedKey-01.jpg" - title="Encryption Process" - bodyText="A: Plain text; B: Encryption Algorithm; C: Cypher text; D: Shared Key." -%} - -Let’s look at a much more simplified example of this… - -Alice wants to encrypt the word “Hello” to send to Bob. She uses the very simple formula of taking each letter in the word and changing it to the letter two spaces over in the alphabet. This formula is the algorithm or key. - -{% include callouts/callout.html - title="Simple Cypher Encryption" - bodyText="Hello → [ move over two spaces in the alphabet ] → Kgnnq" -%} - -{% include callouts/callout.html - title="Simple Cypher Decryption" - bodyText="Kgnnq → Key → Hello" -%} - -If Bob knows this formula, then Alice can securely transmit this message to Bob, and it will look like gibberish to anyone who intercepts the message. - -This works just fine; the problem is with transmitting the key to Bob. How do you securely transfer the key? Anyone who intercepts it will be able to read all the communication between Alice and Bob. - - - -This is a fundamental weakness in symmetric cryptography that was solved by asymmetric cryptography. Lets see how it's done in the next lesson! - diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson06 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson06 2.md deleted file mode 100644 index 5169134c7..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson06 2.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 2 -title: Public and Private Keys -permalink: /courses/bitcoin-for-developers/2/public-and-private-keys ---- -
-
-Asymmetric cryptographic algorithms were first developed in the 1970s and are fundamental to so many of the technologies we use today. It’s used on any secured page on the internet, on your cell phone, at your bank, etc. - -The first asymmetric algorithms: -
- -With asymmetric cryptography, instead of having one key, each party has two keys: a public key and a private key. - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/AliceBobKeys-01.jpg" - title="" - bodyText="A: Alice Private Key; B: Alice Public Key; C: Bob Private Key; D: Bob Public Key." -%} - - -How this works is quite interesting. Alice and Bob can exchange public keys with each other in the open. It does not matter if Charlie obtains a copy of the public keys; all he can do with those keys is encrypted a message to Alice or Bob. - -With Bob’s public key, Alice can encrypt her message to him and transmit it. Charlie, even having both public keys, cannot decipher the message. The only person who can decipher the message is someone in possession of Bob’s private key, in this case, only Bob can do this. - -{% include callouts/callout.html - title="Public Keys" - bodyText="" -%} - -{% include callouts/callout.html - title="Private Keys" - bodyText="" -%} - -Bob can also use Alice’s public key to encrypt a message to Alice. - - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/TextandKeys-01.jpg" - title="" - bodyText="A: Plain text; B: Alice public key; C: Cipher text; D: Alice private key." -%} - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/AlicePublicKey-01-2.jpg" - title="" - bodyText="A: Alice public key." -%} - -Public keys and encrypted messages can now be transmitted in the open and our key thief here, Charlie, will still be unable to read the contents of the message. - -Asymmetric cryptography is an incredibly powerful tool that can be used for a wide variety of applications. - -The first use case is using this technology to encrypt and decrypt messages! However, the bitcoin software makes use of this technology to sign and verify messages, or more specifically, transactions. - -  -

ENCRYPTING VS. SIGNING VS. HASHING

- -
- -Bitcoin, and other cryptocurrencies, are built on cryptography, but actually very little “encryption” is done in the Bitcoin protocol while signing and hashing is used extensively. Let’s be sure we understand the difference. Below are rough explanations of these three related yet different functions. - -{% include callouts/definition.html - title="ENCRYPTION" - bodyText="Scrambling data so that only entities with access to the keys will be able to decipher the message." -%} - -{% include callouts/definition.html - title="SIGNING" - bodyText="Taking data and producing from it a “signature,” another piece of data, that could have only have come from the entity controlling a certain private key." -%} - -{% include callouts/definition.html - title="HASHING" - bodyText="Creating a unique identifier for a specific piece of data." -%} - - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/EncryptSignHash-01.jpg" - title="" - bodyText="A: The quick brown fox jumps over the lazy dog; B: Encrypt; C: Sign; D: Hash." -%} - -Let’s take just a quick look at how the signing, and the verifying of those signatures works on the Bitcoin network. - -Bitcoin uses elliptic curve cryptography, ECDSA, or more specifically the SECP256k1 curve. - - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/BitcoinSigs-01.jpg" - title="" - bodyText="BITCOIN USES SECP256k1 SIGNATURES Elliptic curve cryptography" -%} - -Alice’s wallet will produce a transaction sending funds from an address she controls to an address Bob controls. This transaction data is signed with Alice’s private key. This produces a signature that proves Alice, or anyone in possession of her private key, has authorized the transfer. - -To sign a transaction in Bitcoin, the data is first hashed (which we discussed in Enter the Blockchain Part I) then ran through the an algorithm which uses the private key to produce a signature. - -When trying to verify that signature, you’ll need the transaction data that was signed (in the case of Bitcoin, that would be the transaction hash) the signature, and the public key. That data is then run through a validation algorithm which generally returns a true or false response. - -Cryptography is very much a skill all its own separate from software development. There is a saying in the crypto world, “don’t roll your own crypto.” This phrase expresses the idea that it is very risky to attempt to build your own cryptography tools. There are many tried and tested libraries out there for signing and verifying signatures. - -And now that we’ve covered some basics, we’ll be diving into decentralization and the functioning of decentralized networks in the next lesson. - -
- -Further reading: A (relatively easy to understand) primer on elliptic curve cryptography. diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson07 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson07 2.md deleted file mode 100644 index 870758e4b..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson07 2.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 2 -title: Decentralization and Consensus -permalink: /courses/bitcoin-for-developers/2/decentralization-consensus ---- - -
-
- -Bitcoin was built to enable decentralized agreement, or consensus, on data. Bitcoin’s Proof-of-Work, a mining consensus algorithm, was built to achieve this goal and maintaining this decentralization is fundamental to the systems structure and security model. However, this is a very different structure than most of us are used to working with. Interacting with a blockchain is not like querying a database; it is much more complex. - -Let’s start by taking a look at the beginning of digital, decentralized networks in an effort to gain some insight into this structure. - - - -These networks began with the internet. While the internet itself soon developed a client-server model, many networks online developed a truly decentralized, peer-to-peer structure. Some examples being: - -The decentralized network that is most commonly known is likely BitTorrent which is used for peer-to-peer (P2P) file sharing. It might be helpful to keep this architecture in your head when visualizing the bitcoin network. - - - -Bitcoin is a decentralized, P2P network in a very similar fashion to a file sharing network. (Learn about decentralized file storage here.) - -When you download the Bitcoin client software, it generally comes with the IP address of a few well-known nodes. When the software runs, it queries those nodes to find it’s connections continues like a ripple effect. Bitcoin main net connections happen on port 8333, and the program looks for connections there. - -The software is constantly connecting with peers to receive network data and transaction data. A full node will keep a full copy of the blockchain, check the validity of the data it is receiving, and then pass it along to peers. In this way nodes on the network play an important role in maintaining network consensus. -

FULL NODE VS. LIGHT CLIENT

- -
- -A “full node” is a computer that is running bitcoin software and maintaining a complete copy of the bitcoin blockchain. In contrast, a “light client” is a computer, or sometimes a mobile phone, that is running bitcoin software, but that does not maintain a complete copy of the blockchain. This is often done to save space on a machine or mobile phone. For example, a bitcoin wallet running on a smartphone. In this scenario incoming transactions are validated via a process called SPV, or Simplified Payment Verification. - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/FullNodeLightClient-01.jpg" - title="Full Node or Light Client" - bodyText='WHY RUN A FULL NODE: Running a full node provides a greater level of autonomy, influence in network decisions (see UASF) and increased privacy and security. Light clients rely on other full nodes on the network to provide them with data. A light client has to query another node to find data on a transaction that it is interested in. This can reveal the financial interests of the light client operator.' -%} - -We briefly covered the mining process in lesson two, Enter the Blockchain Part I, and here we’ll dive a bit deeper into consensus algorithms and maintaining consensus long term with governance systems. - -{% include callouts/bigQuote.html body="A consensus algorithm is a process in computer science used to achieve agreement on a single data value among distributed processes or systems. Consensus algorithms are designed to achieve reliability in a network involving multiple unreliable nodes. Solving that issue — known as the consensus problem — is important in distributed computing and multi-agent systems." sourceName="Whatis.com" sourceUrl="https://whatis.techtarget.com/definition/consensus-algorithm" %} - -It’s rather remarkable that a collection of computers, with no central authority, can come to an agreement on the state of the network. This process is called emergent consensus. We call it emergent because it is not brought about explicitly but through the interplay of four processes which happen independently on nodes throughout the network. - -The longest, valid chain with the most accumulated proof-of-work is the chain that a node is programmed to follow. Accumulated proof-of-work can be thought of as a measure of the amount of hashing power or computing power that went into making that chain of blocks. - -Proof-of-Work, discussed in our second lesson, is only one step in this process and can be replaced with other consensus mechanisms such as Proof-of-Stake. -

PUBLIC NETWORK CONSENSUS ALGORITHMS

- -
- - -While we won’t dive into differing consensus algorithms here, it is important to note that many options have been developed since the invention of Nakamoto proof-of-work consensus in 2008. - -

INCENTIVES AND GAME THEORY

-

While Bitcoin is a software project, the network that it creates is sustained and managed with incentives and game theory. Let’s take a look at how that protects the network in the below video:

-' - diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson08 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson08 2.md deleted file mode 100644 index 1cf9b29e6..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson08 2.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 2 -title: Governance -permalink: /courses/bitcoin-for-developers/2/governance ---- - -
-
- -So, we have a decentralized network, that no one entity can control. How do we make changes and upgrades to that network? - -How are changes made on a network that no one controls? This dilemma we call governance. - -While governance solutions have been built into some blockchain protocols, Bitcoin is fairly simple in this regard. There are only a few built-in methods for decisions making. Let’s take a look at how things get done. -

THE BIP PROCESS

- -
- -BIP stands for Bitcoin Improvement Proposal. This is a process for submitting changes to the repo. - -A description of the process and a complete list of BIP’s can be found here. - -Proposed changes should first be discussed on the mailing list, then a pull request submitted. - -Once a proposed change becomes a BIP it goes through peer review and the below process. - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/Process-01.jpg" - title="" - bodyText="A: Draft; B: Deferred; C: Accepted; D: Rejected; E: Withdrawn; F: Final; G: Replaced; H: Active." -%} - -After a BIP is accepted, then the real fun of network implementation begins. -

HOW A BIP BECOMES NETWORK PROTOCOL

- -
- -How difficult the process is depends a lot on the type of change or BIP that is being implemented. -

Types of BIP’s or Tracks.

- -It’s very important to note the difference between a simple code change and a consensus change. Any change affecting the consensus rules on the network will require either a soft fork or a hard fork. - -{% include callouts/note.html - bodyText="In this context “fork” has a different meaning from software fork or a fork in a repo. Here we mean a chain split or a network partition that can result in separate networks." -%} - -

HARD FORKS VS. SOFT FORKS

- -
- -A soft fork is a network upgrade which can be thought of a non-mandatory. Nodes running old versions of the software will still be able to interact with and maintain consensus on the network. - -A hard fork is a network upgrade or change that either forces nodes on the network to upgrade or results in a permanent split in the network. - -{% include callouts/definition.html - title="TEMPORARY FORKS" - bodyText="The most common way in which a fork occurs is when there are separate groups of nodes that have different copies of the blockchain ledger. This can happen when there’s a high transaction volume, and nodes find multiple new blocks which can be confirmed within the rules of the system. In Proof of Work models, the longest chain will always win, so the network will ultimately return to a global consensus quite quickly." -%} - -{% include callouts/definition.html - title="BALANCE OF POWER" - bodyText="There are many different groups in the bitcoin ecosystem that have influence. Miners, developers, wallets and users, exchanges, and merchants. It’s important to remember that while bitcoin core developers can release changes to the protocol, no one has to upgrade to run the new software. That is a choice made by every individual who has a machine running bitcoin." -%} - -The process of transitioning to new consensus rules is called activation. - -There have been a number of methods used in Bitcoin to activate a change: - -{% include callouts/definition.html - title="FLAG DATE" - bodyText="This is a very simple activation method where a new rule becomes active on a specific date." -%} - -{% include callouts/definition.html - title="ISM ISSUPERMAJORITY" - bodyText="This uses miner signaling and was the first version of MASF(described below). This bit of code activates changes once 950 of the last 1000 blocks have signaled for activating the new change." -%} - -{% include callouts/definition.html - title="BIP9 - VERSION BITS" - bodyText="Miner signalling, a way for miners to signal readiness for a soft fork by setting bits in the block header nVersion field." -%} - -{% include callouts/definition.html - title="MASF - MINER ACTIVATED SOFT FORK" - bodyText="In this scenario blocks signal a version and a soft fork is activated through this signaling." -%} - -{% include callouts/definition.html - title="UASF - USER ACTIVATED SOFT FORK" - bodyText="This scenario involves non-mining full nodes updating their software to a version that requires certain rules on the network, perhaps beginning at a flag date after which blocks that do not meet those requirements are not propagated on the network." -%} - -The above is a rough summary as this is a rather complicated situation. Other networks employ more sophisticated methods for determining consensus and activating changes. The Decred project has an interesting model which you can read about here. - -There has been an evolution of methods used to bring about change in Bitcoin. The well-distributed balance of power in the ecosystem has done a good job of preventing any hostile takeovers, it has also made the system very conservative with only the most tried and test and overwhelmingly approved of changes making it to activation. - -The activation process on the bitcoin network is a complicated and constantly evolving process. - -
- -Further reading can be found here: - -Forks, Signaling, and Activation - -Version bits FAQ for miners - -UASF: User Driven Protocol Development - -
- -In the next section we’ll get into technical specifics starting with setting up a node. diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson09 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson09 2.md deleted file mode 100644 index f51b665cd..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson09 2.md +++ /dev/null @@ -1,183 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 3 -title: Bitcoin Nodes -permalink: /courses/bitcoin-for-developers/3/bitcoin-nodes ---- -
-
-Now that we’ve covered the history behind Bitcoin and have a theoretical understanding of how blockchains function, let’s see it in action. - -Thus far when we have said “node” we meant “full node”. As mentioned, full nodes keeps a complete copy of the Bitcoin blockchain and participates in network consensus by checking and forwarding valid transactions. They download every block and transaction and check them against Bitcoin’s consensus rules. - -

THINGS A "FULL NODE" DOES

- -
- - -In these ways, a full node contributes to network “consensus”. - -{% include callouts/note.html title="SPV nodes reminder:" bodyText='Lightweight or thin clients are nodes that use Simplified Payment Verification. SPV is a method for verifying that particular transactions were included in a block without downloading the entire blockchain. This allows you to run software that interacts with the bitcoin network on low resource machines, such as running a wallet on a smartphone. However, using SPV instead of full nodes means the loss of some privacy and security.' %} - -Before we can set up a node there are two more things to consider. Do we want to run on mainnet, testnet or regtest? And which Bitcoin implementation do we want to use? -{% include callouts/definition.html - title="Mainnet" - bodyText="Mainnet is the live Bitcoin network. To fully participate in the Bitcoin ecosystem you’ll want to be running a mainnet node. However, when starting out and testing new applications mainnet is likely not the best option as it comes with the risk of losing coins which have real value. To run a mainnet full node you will need to download the entire ~200GB blockchain." -%} - -{% include callouts/definition.html - title="Testnet" - bodyText="Testnet is a public bitcoin network that is used by developers around the world to test Bitcoin applications. You can find and use Bitcoin testnet coins and exchange them with others on the testnet. These coins very intentionally have no exchange value; they are used simply for testing. To run a testnet node you will need to download the testnet blockchain which is significantly smaller than mainnet at only ~20GB." -%} - -{% include callouts/definition.html - title="Regtest" - bodyText="Regtest allows you to set up your own local blockchain. When you start a node in regtest mode there is no blockchain data to download. You need to create all the blockchain data yourself!" -%} - -Once you know what network you want to run on, you’ll need to choose a client or implementation. Bitcoin core (formerly Bitcoin-Qt), is the reference implementation and is still the most commonly used bitcoin implementation. It is written in C++. However, there are now a number of other options such as Bitcore witch is written in Node.js or btcd which is written in GoLang. - -Here we will walk through instructions for both Bitcoin’s testnet and running in regtest mode using the reference implementation Bitcoin Core, or more specifically the bitcoind daemon. - -{% include callouts/note.html - bodyText='The below instructions are for Ubuntu machines. Mac OS and Windows instructions can be found here.' -%} - -

UBUNTU INSTRUCTIONS

- -
- -{% include callouts/terminal.html - title="Install the Bitcoin Daemon" - user="hannah@ubuntu" - directory="~/" - bodyText="apt-add-repository ppa:bitcoin/bitcoin, apt-get update, apt-get install bitcoind" -%} - -

BITCOIND RESOURCES

- -
- - -Once you have the software installed, we’ll need to configure it. -

TESTNET INSTRUCTIONS

- -
- -{% include callouts/terminal.html - title="Install the Bitcoin Daemon" - user="hannah@ubuntu" - directory="~/" - bodyText="apt-add-repository ppa:bitcoin/bitcoin, apt-get update, apt-get install bitcoind" -%} - - -{% include callouts/terminal.html - title="Start bitcoind" - user="hannah@ubuntu" - directory="~/" - bodyText="bitcoind -testnet -printtoconsole -daemon -server" -%} - -{% include callouts/terminal.html - title="View the debug log in a separate console window" - user="hannah@ubuntu" - directory="~/" - bodyText="tail -f .bitcoin/testnet/debug.log" -%} - -{% include callouts/terminal.html - title="Create a config file in .bitcoin" - user="hannah@ubuntu" - directory="~/" - bodyText="touch bitcoin.conf" -%} - -

THE BITCOIN.CONF FILE

- -
- -{% include callouts/codeSnippet.html - title="Bitcoin.conf Configured for RPC" - bodyText='# Set up RPC, server=1, rpcuser=test, rpcpassword=test, rpchost=127.0.0.1, rpcport=6163, # Run on the testnet, testnet=1, # Specify a directory for testnet data, #datadir=/home/bitcoin/.bitcoin/testnet' -%} - -

REGTEST MODE INSTRUCTIONS

- -
- -{% include callouts/note.html - bodyText='Learn more about regtest.' -%} - -{% include callouts/terminal.html - title="Start bitcoind in regtest mode" - user="hannah@ubuntu" - directory="~/" - bodyText="bitcoind -regtest -printtoconsole -daemon -server" -%} - -{% include callouts/terminal.html - title="View the debug log in a separate console window" - user="hannah@ubuntu" - directory="~/" - bodyText="tail -f .bitcoin/regtest/debug.log" -%} - -{% include callouts/terminal.html - title="Create a config file in .bitcoin/regtest" - user="hannah@ubuntu" - directory="~/" - bodyText="touch bitcoin.conf" -%} - -

THE BITCOIN.CONF FILE

-
- -{% include callouts/codeSnippet.html - title="Bitcoin.conf Configured for RPC" - bodyText="# Set up RPC, server=1, rpcuser=test, rpcpassword=test, rpchost=127.0.0.1, rpcport=6163, # Run on a regtest network, regtest=1, # Connect only to the specified node, connect=[your local IP]" -%} - -

TRY OUT SOME COMMANDS

- -
-{% include callouts/terminal.html - title="Kill bitcoind and restart" - user="hannah@ubuntu" - directory="~/" - bodyText="pkill -9 -f bitcoind, bitcoind [-regtest or -testnet] -printtoconsole -daemon -server" -%} - -{% include callouts/terminal.html - title="Use bitcoin-cli to view your connection to peers" - user="hannah@ubuntu" - directory="~/" - bodyText="bitcoin-cli [-regtest or -testnet] -getinfo" -%} - -{% include callouts/terminal.html - title="Generate a new address to receive coins" - user="hannah@ubuntu" - directory="~/" - bodyText="bitcoin-cli [-regtest or -testnet] getnewaddress" -%} - -{% include callouts/terminal.html - title="Check your balance" - user="hannah@ubuntu" - directory="~/" - bodyText="bitcoin-cli [-regtest or -testnet] getbalance" -%} - -Now that we’ve had a chance to experience bitcoin on the command line, let’s take a step back in our next lesson and be sure we understand in more depth what a bitcoin is. diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson10 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson10 2.md deleted file mode 100644 index caead7265..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson10 2.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 3 -title: What is a Bitcoin? -permalink: /courses/bitcoin-for-developers/3/what-is-a-bitcoin ---- -
-
- -We’ll dive into bitcoin wallets in the next few lessons, but, in order to understand what a wallet is doing, you need to understand what a bitcoin actually is. - -{% include callouts/note.html - bodyText='Have you read the Bitcoin whitepaper yet? If not you really should! Check it out here:https://bitcoin.org/bitcoin.pdf' -%} - -From the bitcoin whitepaper, “We define an electronic coin as a chain of digital signatures.” Bitcoins are not really digital “coins”. They don’t have serial numbers or a set unit; they don’t "live" in a wallet. Bitcoin’s are just divisible and joinable ledger entries that "live" on the bitcoin blockchain. - -Here we’ll introduce you to the concept of UTXO’s or unspent transaction outputs. Every transaction has inputs and outputs. To understand this let’s walk through an example. - -When a bitcoin is first created, it is given to a miner as a mining reward. Currently, the mining reward for a block is 12.5 bitcoin or BTC. The transaction that gives the miner these funds is called a coinbase transaction. The 12.5 BTC is sent to the address that the miner has specified. That 12.5 BTC is now an unspent transaction output that can be used in another transaction. - - - -Let’s imagine that our miner, Alice, now wants to pay for some server space using BTC. She purchases 0.05 worth of hosting from Bob. In that transaction, she uses the only UTXO that she has which is worth 12.5 BTC. - -The transaction breaks up the input worth 12.5 BTC, sending 0.05 to Bob, and 12.449 going back to Alice with the remainder of 0.001 being offered as a transaction fee for the miner who mines the block the transaction is in. - -{% include callouts/callout.html - title="BITCOIN TRANSACTION FEES" - bodyText="Transaction fees on the bitcoin network are not specified but implied in the remainder of any UTXO that is not sent back to the sender as change. Also, fees are generally not calculated base on the value of the transaction but instead based on the size of the transaction data." -%} - -After the transaction is mined, Alice now has a UTXO worth 12.449 and Bob has a UTXO worth 0.05. - - - -We’ll cover bitcoin transactions in some detail in Part II. The important takeaway for the moment is that bitcoin’s are UTXO’s, which are ledger entries, that live on the bitcoin blockchain. Holding bitcoins means holding, managing and securing the private keys that control those UTXO’s that live on the shared network ledger. diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson11 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson11 2.md deleted file mode 100644 index 20b977e20..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson11 2.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 3 -title: Introduction to Wallets and Addresses -permalink: /courses/bitcoin-for-developers/3/intro-to-wallets-and-addresses ---- -
-
- -In bitcoin, a wallet is a bit of an abstract. The bitcoin protocol doesn’t contain the notion of wallets. This concept is created by user interfaces for user comfort. - -Wallets are built for two primary functions: - -Here we will focus primarily on the second function and look at how wallets store private keys, interact with the blockchain and construct, sign and transmit transactions. Primarily we’ll focus on a wallets roll as a keychain for the private keys that control a users funds on the blockchain. - - - -First, let’s take a step back and learn the relationship between public/private key pairs and bitcoin addresses. - -Again, bitcoin uses Elliptic curve cryptography. A generation point on an elliptic curve is used to produce a public key once a private key has been chosen. More information about this process can be found here. - -However, for this lesson we will summarize the process of generating a public key by saying that public keys are derived from private keys and we’ll look at the process of generating bitcoin addresses from public keys. - -Bitcoin makes extensive use of hashing functions. To derive an address from a public key two hashing functions are used, SHA256 and RIPEMD160. - -{% include callouts/codeSnippet.html - title="Address Generation Formula" - bodyText="Address = RIPEMD160(SHA256(Public Key))" -%} - -This results in a 160-bit, 20-byte string that is then base58 encoded the result of which looks like this: - -{% include callouts/codeSnippet.html - title="Address Generation Output" - bodyText="1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZ" -%} - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/PKtoBA-01.jpg" - title="" - bodyText="A: Public Key; B: SHA256; C: RIPEMD160; D: 'Double Hash' or HASH160; E: Public Key Hash (20 bytes/160 bits); F: Base58Check Encode with 0x00 version prefix; G: Bitcoin Address (Base58Check Encoded Public Key Hash)." -%} - -{% include callouts/note.html - bodyText="Bitcoin addresses are usually encoded as base58 which is similar to Base64 but has been modified to avoid both non-alphanumeric characters and letters which might look ambiguous when printed. This was done to help prevent human error when copying the data. In base58 the following similar-looking letters have been removed such as 0 (zero), O (capital o), I (capital i) and l (lower case L) and the symbols '+' & '/'. The remaining characters are, 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz." -%} - -

ADDRESS TYPES AND CHECK ENCODING

- -
-In bitcoin, most data presented to the user is not just base58 encoded, but base58check encoded to help prevent errors. - -This adds prefix data to addresses that can be used to help verify the accuracy of the following data. Here is how this is done. - -A version prefix is added to the address and an additional four bytes are added to the end of the data as a checksum called Base58Check and is used as built-in error-checking to protect against typos. - - -{% include callouts/codeSnippet.html - title="This checksum is created from the hashing the encoded data as follows:" - bodyText="Checksum = SHA256(SHA256(prefix+base58 address))" -%} - -The first 4 bytes of this are then added to the end of the address. - -When an address is typed into a wallet Base58Check code, the decoding software will calculate the checksum of the address on it’s own and compare it to the checksum included in the address. If the two do not match, the address entered is invalid. - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/WalletsandAddresses-01-1.jpg" - title="BASE58CHECK ENCODING" - bodyText="1: Add Version Prefix; 2: Hash (Version Prefix + Payload); 3: Add First 4 Bytes as Checksum; 4: Encode in Base-58. A: Payload; B: Version; C: SHA256; D: First 4 Bytes; E: Checksum; F: Base58 Encode; G: Base58Check Encoded Payload." -%} - -In January of 2012, with BIP16, a new type of bitcoin address was introduced, Pay to Script Hash or P2SH. This type of address is not based on a public key but instead on the hash of a script. Bitcoin scripting is a topic that we’ll cover in depth in Part II of this series. For the moment let’s think of a bitcoin script as a bit of code that needs to return true when run in order for a transaction to be considered valid. It’s an unlocking script. - -A common use case for P2SH addresses is a multi-signature address or multi-sig for short. Any funds sent to this address can only be spent by a transaction that is signed by m of n signatures, 2 of 3 being a very common setup. - -To create a 2 of 3 multi-sig P2SH address a script requiring a valid signature from any 2 of 3 keys is created and then hashed in the same fashion as described above. - -{% include callouts/codeSnippet.html - title="Hash generation for BTC Script" - bodyText="Script hash = RIPEMD160(SHA256(the script))" -%} - -The version prefix that is used depends on which network the address is intended for and whether it is a P2SH (Pay to Script Hash) or P2PKH (Pay to Public Key Hash) address. - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/WalletsandAddresses-02.jpg" - title=" " - bodyText="A: Type; B: Version Prefix (Hex); C: Base58 Result Prefix; D: Bitcoin Address; E: Pay-To-Script-Hash Address; F: Bitcoin Testnet Address." -%} - -{% include callouts/definition.html - title="CONCEPTUALIZE" - bodyText="Bitcoin’s, or UTXO’s, 'live' at bitcoin addresses. In order to transfer those funds the owner of the funds, who is presumably the owner of the private keys the address was derived from, has to sign the transferring transaction with their private key. In this way users don’t really hold bitcoin's, but rather control them with their private keys." -%} - -And now that we have a base for understanding bitcoin addresses, let’s head back to wallets! diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson12 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson12 2.md deleted file mode 100644 index 4787320fa..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson12 2.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 3 -title: Wallet History and Mnemonic Seeds -permalink: /courses/bitcoin-for-developers/3/wallet-history-mnemonic-seeds ---- -
-
- -The following two lessons were written with the goal of providing a good foundation for building or working with Bitcoin wallets. As such we’ll cover a bit of history and then the current de facto standard for Bitcoin wallets which consists of four BIPS, 39, 32, 43 & 44. - -These BIP’s cover mnemonic seeds and hierarchical deterministic(HD) wallets. - -

HISTORY

- -Cryptocurrency wallets have evolved substantially since the first wallet which was included in the original version of the Bitcoin core client. Let’s first discuss some of the history of Bitcoin wallets to understand why these improvements came about. - -

JBOK, OR JUST A BUNCH OF KEYS WALLETS

- - - -This type of wallet is simply a collection of randomly generated private keys with no particular relation to one another. - -While these wallets worked, there was an issue with backing up the wallet data. For greater privacy, addresses were not reused. This means new addresses, and thus new keys, were generated regularly. New addresses were created on each receive transaction, with a cap of 100 addresses/key kept at any time. - -{% include callouts/note.html - bodyText="This includes change transactions. When a UTXO that is larger than the amount being spent is used, the UTXO is split and the remaining balance is returned to the sender as change." -%} - -An early method for backing up a wallet was simply to copy the wallet.dat file that contained the private keys and then store this file in a secure location. However, if regular backups were not taken then they would quickly become outdated. - -If a user attempted to restore a heavily used JBOK wallet, they may find that the keys in their backed up wallet.dat file no longer control any value on the blockchain. Essentially, a backup could quickly become useless. - -Also, backing up a wallet meant storying what was essentially a database file. This made backups not at all user-friendly. - -To solve these problems mnemonic seeds and HD wallets were created. -

MNEMONIC SEEDS

- -The process outlined in BIP 39 is the current best practice for creating wallets with mnemonic seeds. - -So, what is a mnemonic seed? - -It is a set of data encoded as a series of words, usually 12 or 24, which can be used to restore an entire wallet. - -{% include callouts/definition.html - title="MNEMONIC" - bodyText="A device such as a pattern of letters, ideas, or associations that assists in remembering something." -%} - -HD wallets, which we will cover in depth in the next lesson, have a parent private key which can be used to derive many child keys. In this way, one set of data, which is called the “seed”, can be used to migrate or restore a wallet with many keys and addressed. - -It is, however, important to note that the “seed” is more than just the parent private key. The seed also contains the “chain code”. This is a bit of data which is necessary for the derivation of the child keys, which we’ll discuss in the next lesson. - -

HOW THIS WORKS

- -This is a simplified version of the process which is meant simply to give you a starting point. For a more in-depth explanation please see the BIP 39 repo, and chapter 5 of Master Bitcoin 2nd Edition. - -First, the wallet should have some source of entropy which is used to generate 128-256 bits of data. - -This data is then mapped to a predefined dictionary of 2048 words. This is how those 12-24 words that make up the seed are selected. - -Once the seed words have been selected, a “salt” and optionally a password are selected. In BIP39 compatible wallets, the salt is automatically set to “mnemonic” plus the password if one was added. - -{% include callouts/note.html - bodyText="The addition of a password will change the resulting 512-bit seed. This provides an extra security feature. Even if an attacker was able to acquire a wallet mnemonic phrase they would be unable to recreate the necessary seed data without the addition of the password. Also, a wallet can be created that has two passwords, one for normal use and another “duress password” that results in the recreation of a wallet with only a small amount of funds to fool an attacker." -%} - -Once the mnemonic phrase and salt has been selected, they are run through a “key stretching function”. This function hashes the data 2048 times! Which produces the 512-bit wallet seed. - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/Mnemonicseeds-01-1.jpg" - title="MNEMONIC TO SEED" - bodyText="A: Mnemonic Code Words; B: Salt; C: Key Stretching Function; A: M512-Bit Seed." -%} - -

TAKEAWAYS

- -The mnemonic phrase, the parent private key and the seed are not the same things. - -The seed is built from the mnemonic phrase + salt and contains both the parent private key and the chain code. - -The seed contains all the components necessary to migrate or restore an HD wallet. - -Before we move on let's take a quick look at wallets in the context of internet security and usage. Often, when wallet types are being discussed the speaker is referring to what device the wallet seed is stored on or accessed from. This is important from the context of accessing funds and keeping them safe from theft. - -{% include callouts/definition.html - title="HOT WALLETS" - bodyText="A wallet that exists on an internet connected device. In this situation the users private keys are stored on this internet connected device which can make them susceptible to theft. It is recommended to only store a small amount of funds for immediate use on hot wallets." -%} - -{% include callouts/definition.html - title="COLD/HARDWARE WALLETS" - bodyText='This is a wallet that is stored on a device that is "air gapped", has no internet connect. This is often done in the form of a small hardware device. Wallets such as this are recommended for longer term storage.' -%} - -{% include callouts/definition.html - title="CUSTODIAL WALLETS" - bodyText="These are wallets provided by services that hold key on behalf of the user. While this can provide some convenience it is important to note that it involves trusting a third party to store your funds honestly and competently." -%} - -{% include callouts/definition.html - title="PAPER WALLETS" - bodyText="A paper wallet is a common type of 'cold storage'. It’s a method of storing keys offline. This can be done by writing out your wallet seed or private keys on a piece of paper and storing it somewhere safe such as a home fire safe. There are stainless steel versions of these types of wallets that allow you to etch your wallet seeds into a steel plate which provides improved durability." -%} - -Further Reading: - - - -

We’ll have a look at chain codes and HD wallets in the next lesson.

diff --git a/all_collections/_lessons/bitcoin-for-devs_lesson13 2.md b/all_collections/_lessons/bitcoin-for-devs_lesson13 2.md deleted file mode 100644 index 52b4dfe9f..000000000 --- a/all_collections/_lessons/bitcoin-for-devs_lesson13 2.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -layout: lesson -course: bitcoin-for-developers -module: 3 -title: HD Wallets -permalink: /courses/bitcoin-for-developers/3/hd-wallets ---- - -
-
- -The methods explained in BIP’s 32, 43 & 44 are best practice for Bitcoin wallets, and necessary for interoperability with other Bitcoin wallets. - -

WHAT IS AN HD WALLET?

- -There are two types of deterministic wallets, sequential and hierarchical. Here we’ll focus on the industry standard, hierarchical. - -Hierarchical deterministic wallets make managing a wallet and it’s keys dramatically easier than the JBOK’s wallets discussed in lesson 8. These wallets create a tree like structure of a master key, parent keys and children keys. - - - -These wallets are created using a “seed” as discussed in lesson 8. This way an entire wallet, containing many addresses/key, can be migrated or restored using just the mnemonic phrase (and optionally a password). Also in lesson 8 we covered how the mnemonic seed functions. In this lesson we will focus on the functionality of HD wallets and how keys are derived from the master key. - -First let’s introduce this thing called a “chain code”. A chain code is 256 bits of entropy, essentially, a random number. This extra bit of of randomness makes it not possible to determine sibling keys even if one child key is known. It adds security. - -The root of the chain code is derived from the wallet seed. As the wallet key tree is expanded parent chain codes are derived from the root and child chain codes are derived from parent chain codes, etc. - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/HashFunctions-01.jpg" - title="" - bodyText="A: Mnemonic Phrase; B: Seed; C: One-Way Hash Function; D: Left; E: Right; F: Master Private Key; G: Master Public Key; H: Master Chain Code." -%} - -To create a wallet key tree you need the master or parent private key and corresponding public key, the root or parent chain code, and and index number (which we’ll discuss shortly). All of this is run through a hashing function and split into a child private key a corresponding public key and a child chain code. - -The below image is helpful in visualizing this process. - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/HashFunctions-02.jpg" - title="" - bodyText="A: Parent Private Key; B: Parent Public Key; C: Parent Chain Code; D: Index Number; E: One-Way Hash Function; F: Left; G: Right; H: Child Private Key; I: Child Public Key; J: Child Chain Code." -%} - -This process has some really neat features. Child keys and subsequent addresses derived in this fashion are indistinguishable from nondeterministic keys and address. They function entirely as “normal” keys. And child key can not be used to find a parent or sibling keys. You would need both the child private key and the child chain code to derive more children. - -A key, public or private concatenated with the chain code is called an extended key. A key of this type is encoded using Base58Check and uses a special version number that results in the prefix “xprv” for private keys and “xpub” for public keys. While these keys are called “extended” they are extensible and can be used to generate children and entire branches of the wallet tree. - -An extended public key has some very useful features. It can be placed on a public server and used to generate more public keys and addresses, that can be controlled with the wallet seed, all while the private key can remain safely offline. - -This is particularly useful in an e-commerce scenario. Image an online retailer who does a lot of business in bitcoin. It is advantageous to have each order that comes in be paid to a new address. This allows the store managers to associate payment address with specific orders. Without HD wallets and public key derivation, show in the image below, private keys would have to be stored on a public server or publics keys would have to be generated before hand and preloaded on the server. However, with HD wallets, one extended public key from the wallet can be stored on the server and then used to derive new public keys and address for each new order that comes in. - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/HashFunctions-03.jpg" - title="" - bodyText="A: Parent Public Key; B: Parent Chain Code; C: Index Number; D: One-Way Hash Function; E: Left; F: Right; G: Child Public Key;; H: Child Chain Code." -%} - -While an extended public key, or xpub, is very useful it comes with some potential risks. An xpub key contains the chain code, which, if the xpub private key were somehow also know could be used to derive all other child private keys. - -A solution to this problem is a “hardened key”. This is an alternative derivation function which discontinues the relationship between the parent public key and the child chain code. This “hardened” derivation function uses the parent private key, rather than the parent public key, to derive the child chain code. - -{% include callouts/imageWithCaption.html - image="/courses/bitcoin-for-developers/HashFunctions-04.jpg" - title="" - bodyText="A: Parent Private Key; B: Parent Chain Code; C: Index Number; D: One-Way Hash Function; E: Left; F: Right; G: Child Private Key; H: Child Public Key; I: Child Chain Code." -%} - -Using the hardened key derivation function the resulting child private key and chain code are completely different from what would have existed using the standard key derivation function. The new, hardened, branch of keys can be used to produce extended public keys that are not vulnerable to a chain code leak as the chain code they contain cannot be exploited to reveal any private keys. - -In an e-commerce setting, it is best for any xpub keys used on the server to have been derived from a hardened parent. - -In part two of Bitcoin for Developers we’ll take a deep dive into Bitcoin transactions and cover how to integrate bitcoin payments into an e-commerce shop. -

INDEX AND PATH

- - -As you may have noticed mentioned when describing key derivation, an index identifier is used. - -The index is a 32-bit integer that is used to distinguish between normal vs hardened keys. The index is split into two ranges, the first portion is reserved for normal derivation and the second portion reserved for hardened derivation. -

THE PATH

- -Keys in an HD wallet are identified using a path naming convention. Here each level of the tree is separated by a slash. - - - -For example, private keys that are derived from the master private key start with “m” while public keys that were derived from the master public key start with “M”. These are listed in the index as m/0 or M/0. Their children keys will be shown as m/0/0 or M/0/2, etc. - -Keep in mind that this path is read from right to left. So the path M/0/2 is read as the third grandchild of key M/0 which is the is the first child of the master key. - -These paths are very helpful for navigating the key tree created by an HD wallet. Each parent extended key can have 4 billion children, 2 billion “normal” and 2 billion “hardened”. All of those children can have 4 billion grandchildren, etc, without any set limits. - -BIPS 43 and 44 address this complexity issue with some proposed standards. - -The BIP 43 standard uses the first hardened child as as an identifier of the purpose of the tree. - -BIP 44 specifies a structure consisting of five predefined tree levels. Specifically, purpose, coin type, account, change and address index as illustrated below… - -In the BIP 44 standard, the purpose is always set to 44. The coin type specifies which coin this branch of the wallet is for (HD wallets can be used with many cryptocurrencies with a similar structure to Bitcoin). For example Bitcoin is 0 and Litecoin is 2. - -The account level allows the user to divide their wallet for organizational purposes. Perhaps one branch for different divisions of an organization. - -The “change” level has two subtrees, one for creating receiving addresses and one for creating change addresses. - -And lastly, the fifth level is the address index as describes as above. - -So, the third child of the master public key on the Bitcoin network might look something like this… M/44/0/0/0/2. - -Further reading: -