From 7694ede81f8be9b2c3ee51ac8f8d09c10ee6e684 Mon Sep 17 00:00:00 2001 From: Nagaraj Hubli Date: Tue, 3 Jun 2014 14:54:12 +0530 Subject: [PATCH 01/14] minor change In the last sentence, since we are referring to the older wallets first as... "This allows the importing wallet to distinguish between private keys originating from older or newer wallets" At the end of the sentence it would be nice to have "uncompressed, or the compressed respectively", rather than "compressed, or the uncompressed" --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index 5c3cb674..2435203b 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -351,7 +351,7 @@ The compressed public key, above, corresponds to the same private key, meaning t Compressed public keys are gradually becoming the default across bitcoin clients, which is having a significant impact on reducing the size of transactions and therefore the blockchain. However, not all clients support compressed public keys yet. Newer clients that support compressed public keys have to account for transactions from older clients which do not support compressed public keys. This is especially important when a wallet application is importing private keys from another bitcoin wallet application, because the new wallet needs to scan the blockchain to find transactions corresponding to these imported keys. Which bitcoin addresses should the bitcoin wallet scan for? The bitcoin addresses produced by uncompressed public keys, or the bitcoin addresses produced by compressed public keys? Both are valid bitcoin addresses, and can be signed for by the private key, but they are different addresses! -To resolve this issue, when private keys are exported from a wallet, the Wallet Import Format that is used to represent them is implemented differently in newer bitcoin wallets, to indicate that these private keys have been used to produce _compressed_ public keys and therefore _compressed_ bitcoin addresses. This allows the importing wallet to distinguish between private keys originating from older or newer wallets and search the blockchain for transactions with bitcoin addresses corresponding to the compressed, or the uncompressed public keys. Let's look at how this works in more detail, in the next section. +To resolve this issue, when private keys are exported from a wallet, the Wallet Import Format that is used to represent them is implemented differently in newer bitcoin wallets, to indicate that these private keys have been used to produce _compressed_ public keys and therefore _compressed_ bitcoin addresses. This allows the importing wallet to distinguish between private keys originating from older or newer wallets and search the blockchain for transactions with bitcoin addresses corresponding to the uncompressed, or the compressed public keys respectively. Let's look at how this works in more detail, in the next section. [[comp_priv]] ===== Compressed Private Keys From 4c3f9a691915f74887d5be6a5c82c005b38b80a3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erik=20Wahlstr=C3=B6m?= Date: Tue, 3 Jun 2014 16:18:09 +0200 Subject: [PATCH 02/14] Update ch04.asciidoc Suspected typos. --- ch04.asciidoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index 5c3cb674..447a228b 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -131,7 +131,7 @@ or \end{equation} ++++ -The +mod p+ (module prime number p) indicates that this curve is over a finite field of prime order +p+, also written as latexmath:[\(\mathbb{F}_p\)], where p = 2^256^ - 2^32^ - 2^9^ - 2^8^ - 2^7^ - 2^6^ - 2^4^ - 1\)], a very large prime number. +The +mod p+ (modulo prime number p) indicates that this curve is over a finite field of prime order +p+, also written as latexmath:[\(\mathbb{F}_p\)], where p = 2^256^ - 2^32^ - 2^9^ - 2^8^ - 2^7^ - 2^6^ - 2^4^ - 1\)], a very large prime number. Because this curve is defined over a finite field of prime order instead of over the real numbers it looks like a pattern of dots scattered in two dimensions, which makes it difficult to visualize. However, the math is identical as that of an elliptic curve over the real numbers shown above. As an example, below is the same elliptic curve over a much smaller finite field of prime order 17, showing a pattern of dots on a grid. The +secp256k1+ bitcoin elliptic curve can be thought of as a much more complex pattern of dots on a unfathomably large grid. @@ -583,7 +583,7 @@ Another way to find a vanity address is to outsource the work to a pool of vanit Vanity addresses can be used to enhance _and_ to defeat security measures, they are truly a double-edged sword. Used to improve security, a distinctive address makes it harder for adversaries to substitute their own address and fool your customers into paying them instead of you. Unfortunately, vanity addresses also make it possible for anyone to create an address that _resembles_ any random address, or even another vanity address, thereby fooling your customers. -He could advertise a randomly generated address (e.g. 1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy) to which people to send their donations. Or, Eugenio could generate a vanity address that starts with 1Kids, to make it more distinctive. +He could advertise a randomly generated address (e.g. 1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy) to which people can send their donations. Or, Eugenio could generate a vanity address that starts with 1Kids, to make it more distinctive. In both cases, one of the risks of using a single fixed address (rather than a separate dynamic address per donor) is that a thief might be able to infiltrate your website and replace it with their own address, thereby diverting donations to themselves. If you have advertised your donation address in a number of different places, your users may visually inspect the address before making a payment to ensure it is the same one they saw on your website, on your email, and on your flyer. In the case of a random address like "1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy", the average user will inspect the first few characters "1J7mdg" perhaps and be satisfied that the address matches. Using a vanity address generator, someone with the intent to steal by substituting a similar-looking address can quickly generate addresses that match the first few characters: @@ -615,7 +615,7 @@ Paper wallets can be generated easily using a tool such as the client-side Javas .An example of a simple paper wallet from bitaddress.org image::images/paper_wallet_simple.png["paper_wallet_simple"] -The disadvantage of the simple paper wallet system is that the printed keys are vulnerable to theft. A thief who is able to gain access to the paper can either steal it or photograph the keys and take control of the bitcoins locked with those keys. A more sophisticate paper wallet storage system uses BIP0038 encrypted private keys. The keys printed on the paper wallet are protected by a passphrase that the owner has memorized. Without the passphrase, the encrypted keys are useless. Yet, they still are superior to a passphrase protected wallet because the keys have never been online and must be physically retrieved from a safe or other physically secured storage. +The disadvantage of the simple paper wallet system is that the printed keys are vulnerable to theft. A thief who is able to gain access to the paper can either steal it or photograph the keys and take control of the bitcoins locked with those keys. A more sophisticated paper wallet storage system uses BIP0038 encrypted private keys. The keys printed on the paper wallet are protected by a passphrase that the owner has memorized. Without the passphrase, the encrypted keys are useless. Yet, they still are superior to a passphrase protected wallet because the keys have never been online and must be physically retrieved from a safe or other physically secured storage. .An example of an encrypted paper wallet from bitaddress.org. The passphrase is "test" image::images/paper_wallet_encrypted.png["paper_wallet_encrypted"] From b4468d0aa993dd76e2db64e7f91cf9e8bc95e18b Mon Sep 17 00:00:00 2001 From: "Minh T. Nguyen" Date: Tue, 3 Jun 2014 21:54:28 -0700 Subject: [PATCH 03/14] Correcting the math of the range of patterns for 1Kids* reported with Issue #38 --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index 9416f070..4d88aa81 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -547,7 +547,7 @@ In our first chapter, we introduced Eugenio, a children's charity director opera ===== Generating Vanity Addresses -It's important to realize that a bitcoin address is simply a number represented by symbols in the Base-58 alphabet. The search for a pattern like "1Kids" can be seen as searching for an address in the range from "1Kids11111111111111111111111111111" to "1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz". There are approximately 58^31^ (approximately 4.6 * 10^54^) addresses in that range, all starting with "1Kids". +It's important to realize that a bitcoin address is simply a number represented by symbols in the Base-58 alphabet. The search for a pattern like "1Kids" can be seen as searching for an address in the range from "1Kids11111111111111111111111111111" to "1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz". There are approximately 58^29^ (approximately 1.4 * 10^51^) addresses in that range, all starting with "1Kids". .The range of vanity addresses starting with "1Kids" |======= From 40c25b65cb838645eb95aacbb0b267559d1f31bf Mon Sep 17 00:00:00 2001 From: "Minh T. Nguyen" Date: Thu, 5 Jun 2014 23:00:43 -0700 Subject: [PATCH 04/14] Using the correct public key and x/y coordinates as reported by Issue #39 --- ch04.asciidoc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index 4d88aa81..057298c2 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -165,8 +165,8 @@ K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD * G ---- K = (x, y) where, -x = 325D52E3B7...E5D378 -y = 7A3D41E670...CD90C2 +x = F028892BAD...DC341A +y = 07CF33DA18...505BDB ---- To visualize multiplication of a point with an integer, we will use the simpler elliptic curve over the real numbers - remember, the math is the same. Our goal is to find the multiple kG of the generator point G. That is the same as adding G to itself, k times in a row. In elliptic curves, adding a point to itself is the equivalent of drawing a tangent line on the point and finding where it intersects the curve again, then reflecting that point on the x-axis. @@ -316,21 +316,21 @@ Here's the public key generated by the private key we created above, shown as th .Public Key K defined as a point +K = (x,y)+ ---- -x = 325D52E3B7...E5D378 -y = 7A3D41E670...CD90C2 +x = F028892BAD...DC341A +y = 07CF33DA18...505BDB ---- Here's the same public key shown as a 512-bit number (130 hex digits) with the prefix +04+ followed by +x+ and then +y+ coordinates, as +04 x y+: .Uncompressed Public Key K shown in hex (130 hex digits) as +04xy+ ---- -K = 04325D52E3B7...CD90C2 +K = 04F028892BAD...505BDB ---- [[comp_pub]] ===== Compressed Public Keys -Compressed public keys were introduced to bitcoin to reduce the size of transactions and conserve disk space on nodes that store the bitcoin blockchain database. Most transactions include the public key, required to validate the owner's credentials and spend the bitcoin. Each public key requires 513 bytes (prefix \+ x \+ y), which when multiplied by several hundred transactions per block, or tens of thousands of transactions per day, adds a significant amount of data to the blockchain. +Compressed public keys were introduced to bitcoin to reduce the size of transactions and conserve disk space on nodes that store the bitcoin blockchain database. Most transactions include the public key, required to validate the owner's credentials and spend the bitcoin. Each public key requires 513 bits (prefix \+ x \+ y), which when multiplied by several hundred transactions per block, or tens of thousands of transactions per day, adds a significant amount of data to the blockchain. As we saw in the section <> above, a public key is a point (x,y) on an elliptic curve. Since the curve expresses a mathematical function, a point on the curve represents a solution to the equation and therefore if we know the x-coordinate we can calculate the y-coordinate by solving the equation y^2^ mod p = (x^3^ + 7) mod p. That allows us to store only the x-coordinate of the public key point, omitting the y-coordinate and reducing the size of the key and the space required to store it by 256 bits. A 50% reduction in size in every transaction adds up to a lot of data saved over time! @@ -340,11 +340,11 @@ Whereas uncompressed public keys have a prefix of +04+, compressed public keys s .Public Key Compression image::images/pubkey_compression.png["pubkey_compression"] -Here's the same public key generated previously, shown as a +compressed public key+ stored in 264-bits (66 hex digits) with the prefix +02+ indicating the +y+ coordinate is even: +Here's the same public key generated previously, shown as a +compressed public key+ stored in 264-bits (66 hex digits) with the prefix +03+ indicating the +y+ coordinate is odd: .Compressed Public Key K shown in hex (66 hex digits) as +K = {02 or 03} x+ ---- -K = 02325D52E3B7...E5D378 +K = 03F028892BAD...DC341A ---- The compressed public key, above, corresponds to the same private key, meaning that it is generated from the same private key. However it looks different from the uncompressed public key. More importantly, if we convert this compressed public key to a bitcoin address using the double-hash function (RIPEMD160(SHA256(K))) it will produce a _different_ bitcoin address. This can be confusing, because it means that a single private key can produce a public key expressed in two different formats (compressed and uncompressed) which produce two different bitcoin addresses. However, the private key is identical for both bitcoin addresses. From 26c929da6637c02e4b67015cbf8e36b35d25e6f3 Mon Sep 17 00:00:00 2001 From: "Minh T. Nguyen" Date: Thu, 5 Jun 2014 23:04:48 -0700 Subject: [PATCH 05/14] A public key should be 520 bits / 65 bytes; reported by Issue #39 --- ch04.asciidoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index 057298c2..64e62fb8 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -320,7 +320,7 @@ x = F028892BAD...DC341A y = 07CF33DA18...505BDB ---- -Here's the same public key shown as a 512-bit number (130 hex digits) with the prefix +04+ followed by +x+ and then +y+ coordinates, as +04 x y+: +Here's the same public key shown as a 520-bit number (130 hex digits) with the prefix +04+ followed by +x+ and then +y+ coordinates, as +04 x y+: .Uncompressed Public Key K shown in hex (130 hex digits) as +04xy+ ---- @@ -330,7 +330,7 @@ K = 04F028892BAD...505BDB [[comp_pub]] ===== Compressed Public Keys -Compressed public keys were introduced to bitcoin to reduce the size of transactions and conserve disk space on nodes that store the bitcoin blockchain database. Most transactions include the public key, required to validate the owner's credentials and spend the bitcoin. Each public key requires 513 bits (prefix \+ x \+ y), which when multiplied by several hundred transactions per block, or tens of thousands of transactions per day, adds a significant amount of data to the blockchain. +Compressed public keys were introduced to bitcoin to reduce the size of transactions and conserve disk space on nodes that store the bitcoin blockchain database. Most transactions include the public key, required to validate the owner's credentials and spend the bitcoin. Each public key requires 520 bits (prefix \+ x \+ y), which when multiplied by several hundred transactions per block, or tens of thousands of transactions per day, adds a significant amount of data to the blockchain. As we saw in the section <> above, a public key is a point (x,y) on an elliptic curve. Since the curve expresses a mathematical function, a point on the curve represents a solution to the equation and therefore if we know the x-coordinate we can calculate the y-coordinate by solving the equation y^2^ mod p = (x^3^ + 7) mod p. That allows us to store only the x-coordinate of the public key point, omitting the y-coordinate and reducing the size of the key and the space required to store it by 256 bits. A 50% reduction in size in every transaction adds up to a lot of data saved over time! @@ -342,7 +342,7 @@ image::images/pubkey_compression.png["pubkey_compression"] Here's the same public key generated previously, shown as a +compressed public key+ stored in 264-bits (66 hex digits) with the prefix +03+ indicating the +y+ coordinate is odd: -.Compressed Public Key K shown in hex (66 hex digits) as +K = {02 or 03} x+ +.Compressed Public Key K shown in hex (66 hex digits) as +K = {02 or 03} x+ ---- K = 03F028892BAD...DC341A ---- From 56f093a8ec69755ab1389bd4a770a700a6f563fd Mon Sep 17 00:00:00 2001 From: "Minh T. Nguyen" Date: Fri, 6 Jun 2014 07:53:31 -0700 Subject: [PATCH 06/14] Changing casing of millibits to milliBits following the standard on https://en.bitcoin.it/wiki/MilliBit --- ch01.asciidoc | 2 +- ch02.asciidoc | 2 +- ch03.asciidoc | 6 +++--- ch04.asciidoc | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index 95689687..be2500eb 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -165,7 +165,7 @@ First, Joe has to figure out the exchange rate so that he can give the correct a .ZeroBlock - A bitcoin market-rate application for Android and iOS image::images/zeroblock.png["zeroblock screenshot"] -Using one of the applications or websites above, Joe determines the price of bitcoin to be approximately $100 US dollars per bitcoin. At that rate he should give Alice 0.10 bitcoin, also known as 100 millibits, in return for the $10 US dollars she gave him. +Using one of the applications or websites above, Joe determines the price of bitcoin to be approximately $100 US dollars per bitcoin. At that rate he should give Alice 0.10 bitcoin, also known as 100 milliBits, in return for the $10 US dollars she gave him. Once Joe has established a fair exchange price, he opens his mobile wallet application and selects to "send" bitcoin. He is presented with a screen requesting two inputs: diff --git a/ch02.asciidoc b/ch02.asciidoc index 287ef6ed..2d92a983 100644 --- a/ch02.asciidoc +++ b/ch02.asciidoc @@ -61,7 +61,7 @@ A description for the payment: "Purchase at Bob's Cafe" Unlike a QR code that simply contains a destination bitcoin address, a "payment request" is a QR encoded URL that contains a destination address, a payment amount and a generic description such as "Bob's Cafe". This allows a bitcoin wallet application to pre-fill the information to send the payment while showing a human-readable description to the user. See <>, for more details. You can scan the QR code above with a bitcoin wallet application to see what Alice would see. ==== -Bob says "That's one-dollar-fifty, or fifteen millibits". +Bob says "That's one-dollar-fifty, or fifteen milliBits". Alice uses her smartphone to scan the barcode on display. Her smartphone shows a payment of +0.0150 BTC+ to +Bob's Cafe+ and she selects +Send+ to authorize the payment. Within a few seconds (about the same time as a credit card authorization), Bob would see the transaction on the register, completing the transaction. diff --git a/ch03.asciidoc b/ch03.asciidoc index 2344ede2..d7528805 100644 --- a/ch03.asciidoc +++ b/ch03.asciidoc @@ -479,7 +479,7 @@ $ bitcoind getnewaddress 1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL ---- -Now, we can use this address to send a small amount of bitcoin to our bitcoind wallet from an external wallet (assuming you have some bitcoin in an exchange, web wallet or other bitcoind wallet held elsewhere). For this example, we will send 50 millibits (0.050 bitcoin) to the address returned above. +Now, we can use this address to send a small amount of bitcoin to our bitcoind wallet from an external wallet (assuming you have some bitcoin in an exchange, web wallet or other bitcoind wallet held elsewhere). For this example, we will send 50 milliBits (0.050 bitcoin) to the address returned above. We can now query the bitcoind client for the amount received by this address, and specify how many confirmations are required before an amount is counted in that balance. For this example, we will specify zero confirmations. A few seconds after sending the bitcoin from another wallet, we will see it reflected in the wallet. We use +getreceivedbyaddress+ with the address and the number of confirmations set to zero (0): @@ -634,7 +634,7 @@ $ bitcoind decoderawtransaction 0100000001d717...388ac00000000 } ---- -The transaction decode shows all the components of this transaction, including the transaction inputs and outputs. In this case we see that the transaction that credited our new address with 50 millibits used one input and generated two outputs. The input to this transaction was the output from a previously confirmed transaction (shown as the vin txid starting with +d3c7+ above). The two outputs correspond to the 50 millibit credit and an output with change back to the sender. +The transaction decode shows all the components of this transaction, including the transaction inputs and outputs. In this case we see that the transaction that credited our new address with 50 milliBits used one input and generated two outputs. The input to this transaction was the output from a previously confirmed transaction (shown as the vin txid starting with +d3c7+ above). The two outputs correspond to the 50 millibit credit and an output with change back to the sender. We can further explore the blockchain by examining the previous transaction referenced by its txid in this transaction using the same commands (eg. +gettransaction+). Jumping from transaction to transaction we can follow a chain of transactions back as the coins are transmitted from owner address to owner address. @@ -713,7 +713,7 @@ $ bitcoind getblock 000000000000000051d2e759c63a26e247f185ecb7926ed7a6624bc31c2a } ---- -The block contains 367 transactions and as you see above, the 18th transaction listed (+9ca8f9...+) is the txid of the one crediting 50 millibits to our address. The +height+ entry tells us this is the 286384th block in the blockchain. +The block contains 367 transactions and as you see above, the 18th transaction listed (+9ca8f9...+) is the txid of the one crediting 50 milliBits to our address. The +height+ entry tells us this is the 286384th block in the blockchain. We can also retrieve a block by its block height using the +getblockhash+ command, which takes the block height as the parameter and returns the block hash for that block: diff --git a/ch04.asciidoc b/ch04.asciidoc index 64e62fb8..002567cb 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -1,4 +1,4 @@ -[[ch04_keys_addresses_wallets]] + [[ch04_keys_addresses_wallets]] == Keys, Addresses, Wallets === Introduction From 49444f7d64a8ec1d27acd654afa6c0e0eec0e56e Mon Sep 17 00:00:00 2001 From: "Minh T. Nguyen" Date: Fri, 6 Jun 2014 07:56:13 -0700 Subject: [PATCH 07/14] Correcting the block number of Alice's transaction as reported by Issue #40 --- ch02.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch02.asciidoc b/ch02.asciidoc index 2d92a983..0ebd2a27 100644 --- a/ch02.asciidoc +++ b/ch02.asciidoc @@ -236,7 +236,7 @@ A few minutes later, a new block, #277317 is mined by another miner. As this new In the diagram below we can see block #277316, which contains Alice's transaction. Below it are 277,315 blocks, linked to each other in a chain of blocks (blockchain) all the way back to block #0, the genesis block. Over time, as the "height" in blocks increases, so does the computation difficulty for each block and the chain as a whole. The blocks mined after the one that contains Alice's transaction act as further assurance, as they pile on more computation in a longer and longer chain. The blocks above count as "confirmations". By convention, any block with more than 6 confirmations is considered irrevocable, as it would require an immense amount of computation to invalidate and re-calculate six blocks. We will examine the process of mining and the way it builds trust in more detail in <>. [[block-alice]] -.Alice's transaction included in block #277,317 +.Alice's transaction included in block #277,316 image::images/Blockchain_height_and_depth.png["Alice's transaction included in a block"] === Spending the transaction From 9b6e7716455489c525cf76a43d76a44ea181ea8d Mon Sep 17 00:00:00 2001 From: "Minh T. Nguyen" Date: Fri, 6 Jun 2014 08:13:13 -0700 Subject: [PATCH 08/14] Better wording for 'be they are legitimate governments' from issue #41 --- ch01.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index be2500eb..c143207d 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -28,7 +28,7 @@ Issuers of paper money are constantly battling the counterfeiting problem by usi When cryptography started becoming more broadly available and understood in the late 1980s, many researchers began trying to use cryptography to build digital currencies. These early digital currency projects issued digital money, usually backed by a national currency or precious metal such as gold. -While these earlier digital currencies worked, they were centralized and as a result they were easy to attack by governments and hackers. Early digital currencies used a central clearinghouse to settle all transactions at regular intervals, just like a traditional banking system. Unfortunately, in most cases these nascent digital currencies were targeted by worried governments and eventually litigated out of existence. Some failed in spectacular crashes when the parent company liquidated abruptly. To be robust against intervention by antagonists, be they are legitimate governments or criminal elements, a digital currency is needed to avoid the use of a central currency issuer or transaction clearing authority that could be a single point of attack. Bitcoin is such a system, completely de-centralized by design, lacking any central authority or point of control that can be attacked or corrupted. +While these earlier digital currencies worked, they were centralized and as a result they were easy to attack by governments and hackers. Early digital currencies used a central clearinghouse to settle all transactions at regular intervals, just like a traditional banking system. Unfortunately, in most cases these nascent digital currencies were targeted by worried governments and eventually litigated out of existence. Some failed in spectacular crashes when the parent company liquidated abruptly. To be robust against intervention by antagonists, whether they are legitimate governments or criminal elements, a digital currency is needed to avoid the use of a central currency issuer or transaction clearing authority that could be a single point of attack. Bitcoin is such a system, completely de-centralized by design, lacking any central authority or point of control that can be attacked or corrupted. Bitcoin represents the culmination of decades of research in cryptography and distributed systems and includes four key innovations brought together in a unique and powerful combination. Bitcoin consists of: From 80196d30885f445aab7f3c05bcbbce8ed8ba2d58 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Wed, 4 Jun 2014 00:17:57 -0400 Subject: [PATCH 09/14] ch5 outline --- ch05.asciidoc | 81 ++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 70 insertions(+), 11 deletions(-) diff --git a/ch05.asciidoc b/ch05.asciidoc index ce66bdfa..ee1dc9e9 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -1,17 +1,70 @@ == Chapter 5 - Transactions === Introduction -=== ScriptPubKey and ScriptSig + +=== Transactions and the Blockchain + +==== Transaction Lifecycle +===== Creating Transactions +===== Broadcasting Transactions +===== Validating and Propagating Transactions +===== Mining Transactions into Blocks + +==== Transaction Fees +==== Transaction Validation +===== Validation Limits +==== Transaction Locktime +==== Transaction Irrevocability +==== Transaction Self-Sufficiency + + +=== Transaction Structure +=== Transaction Outputs and Inputs + +[TIP] +==== +Outputs come first, chicken and egg. +==== + +==== Transaction Outputs +===== Spending Conditions (Encumbrances) +===== Unspent Transaction Outputs (UTXO) + +[TIP] +==== +The are no accounts or balances in bitcoin, only UTXO. +==== + +==== Transaction Inputs +===== Spending the Transaction Outputs +===== Unlocking the Conditions (Encumbrance Satisfaction) +==== Transaction Fees + + +=== Standard Transactions +==== Pay to Public Key Hash (P2PKH) +==== Simple Pubkey +==== Mutli-Signature +==== Data Injection (OP_RETURN) +==== Pay to Script Hash (P2SH) +===== Redeem Script and isStandard Validation + +=== Non-Standard Transactions + +=== Transaction Scripts and Script Language + +==== Scripting Language +==== Turing Incompleteness +==== Stateless Verification +==== Transaction Script Operands + +==== Script Construction (Lock + Unlock) [[scriptSig and scriptPubKey]] .Combining scriptSig and scriptPubKey to evaluate a transaction script image::images/scriptSig_and_scriptPubKey.png["scriptSig_and_scriptPubKey"] -=== Transaction Script Language -=== Stack-Based Script Evaluation -=== Common Transaction Scripts - -==== Pay to Public Key Hash - +=== Standard Transaction Scripts +==== Pay to Public Key Hash Script Example [[P2PubKHash1]] .Evaluating a script for a Pay-to-Public-Key-Hash transaction (Part 1 of 2) image::images/Tx_Script_P2PubKeyHash_1.png["Tx_Script_P2PubKeyHash_1"] @@ -20,8 +73,14 @@ image::images/Tx_Script_P2PubKeyHash_1.png["Tx_Script_P2PubKeyHash_1"] .Evaluating a script for a Pay-to-Public-Key-Hash transaction (Part 2 of 2) image::images/Tx_Script_P2PubKeyHash_2.png["Tx_Script_P2PubKeyHash_2"] +==== Pubkey Script Example +==== Multi-Signature Scripts Example +==== P2SH Script Example + +=== Scripts and Signatures +==== Elliptic Curve Digital Signature Algorithm +===== Signing with the Private Key +===== Validating a Digital Signature +==== Types of Signature Hashes -=== Complex Transaction Scripts -=== P2SH Scripts -=== Multi-Signature Scripts -=== Transaction Malleability \ No newline at end of file +=== Transaction Malleability From 5a56fab327f92ec06397e919ac3d3cca8c43b09a Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Sat, 7 Jun 2014 10:53:28 -0700 Subject: [PATCH 10/14] ch5 intro --- ch05.asciidoc | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/ch05.asciidoc b/ch05.asciidoc index ee1dc9e9..852190b7 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -1,12 +1,31 @@ == Chapter 5 - Transactions === Introduction +Transactions are the most important part of the bitcoin system. Everything else in bitcoin is there to ensure that transactions can be created, propagated on the network, validated, and finally added to the global ledger of transactions, the blockchain. Transactions are data structures that encode the transfer of value between participants in the bitcoin system. Each transaction is an public entry in bitcoin's global double-entry bookkeeping ledger, the blockchain. + +In this chapter we will examine all the various forms of transactions, what they contain, how to create them and how they are verified and made part of the permanent record of all transactions. + === Transactions and the Blockchain +Transactions are grouped together into blocks, which are in turn linked in a long chain called the blockchain. This forms the authoritative ledger of all transactions since bitcoin's beginning in 2009. The blockchain is the subject of the next chapter, where we will examine the formation of the authoritative record through the competitive process of proof-of-work, also known as mining. The details of mining will be left for the next chapter. In this chapter, however we will see how transactions relate to the blockchain by tracing their journey from the moment they are created until they are included in the blockchain. + ==== Transaction Lifecycle + +A transaction's lifecycle starts with the transaction's creation, also known as origination. The transaction is then signed, with one or more signatures indicating the authorization to spend the funds referenced by the transaction. The transaction is then broadcast on the bitcoin network, where each network node (participant) alidates and propagates the transaction until it reaches (almost) every node in the network. Finally, the transaction is verified by a mining node and included in a block of transactions that is recorded on the blockchain. Once recorded on the blockchain and confirmed by sufficient subsequent blocks (confirmations), the transaction is a permanent part of the bitcoin ledger and is accepted as valid by all participants. The funds allocated to a new owner by the transaction can then be spend in a new transaction, extending the chain of ownership and beginning the lifecycle of a transaction again. + ===== Creating Transactions + +In some ways it helps to think of a transaction in the same way as a paper cheque. Like a cheque, a transaction is an instrument that expresses the intent to transfer money and is not visible to the financial system until it is submitted for execution. Like a cheque, the originator of the transaction does not have to be the one signing the transaction. Transactions can be created online or offline by anyone, even if they are not able to sign for the funds spent by the check. While a cheque references a specific account as the source of the funds, a transaction references a specific previous transaction as its source (also known as an "input"), rather than an account. + +Once a transaction has been created, it is signed by the owner (or owners) of the source funds. If it was properly formed and signed, the signed transaction is now valid and contains all the information needed to execute the transfer of funds. Now, the valid transaction has to reach the bitcoin network so that it can be propagated until it reaches a miner for inclusion in the pubic ledger, the blockchain. + ===== Broadcasting Transactions + +Next, a transaction needs to get on to the bitcoin network so that it can be propagated and eventually executed by inclusion in the blockchain. Since the transaction is signed and contains no confidential information, private keys or credentials, it can be broadcast using any underlying network transport that is convenient. Unlike credit card transactions, for example, which contain sensitive information and can only be transmitted on encrypted networks, a bitcoin transaction can be sent over any network, even broadcast by radio or printed on paper. As long as it can reach a bitcoin node that will propagate it into the bitcoin network, it doesn't matter how it is transported to the first node. In essence, a bitcoin transaction is just 300-400 bytes of data that needs to reach any one of tens of thousands of bitcoin nodes. Bitcoin transactions can therefore be sent to the bitcoin network over insecure networks such as Wifi, Bluetooth, NFC, Chirp, barcodes or by copy and paste in a web form. In extreme cases, a bitcoin transaction could be transmitted over packet radio, satellite relay or shortwave using burst transmission, spread spectrum or frequency hoping to evade detection and jamming. A bitcoin transaction could even be encoded as smileys (emoticons) and posted in a forum or sent as a text message or Skype chat message. It is virtually impossible to stop anyone from sending a bitcoin transaction to the bitcoin network for execution. + ===== Validating and Propagating Transactions + + ===== Mining Transactions into Blocks ==== Transaction Fees From d66601c0a679256460ea2140dff73aba270b5518 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Sat, 7 Jun 2014 11:58:06 -0700 Subject: [PATCH 11/14] ch5 outline work --- ch05.asciidoc | 38 +++++++++++++++++++++++++++++++++----- 1 file changed, 33 insertions(+), 5 deletions(-) diff --git a/ch05.asciidoc b/ch05.asciidoc index 852190b7..3321a18d 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -1,4 +1,7 @@ +[[ch5]] == Chapter 5 - Transactions + +[[ch5_intro]] === Introduction Transactions are the most important part of the bitcoin system. Everything else in bitcoin is there to ensure that transactions can be created, propagated on the network, validated, and finally added to the global ledger of transactions, the blockchain. Transactions are data structures that encode the transfer of value between participants in the bitcoin system. Each transaction is an public entry in bitcoin's global double-entry bookkeeping ledger, the blockchain. @@ -9,34 +12,55 @@ In this chapter we will examine all the various forms of transactions, what they Transactions are grouped together into blocks, which are in turn linked in a long chain called the blockchain. This forms the authoritative ledger of all transactions since bitcoin's beginning in 2009. The blockchain is the subject of the next chapter, where we will examine the formation of the authoritative record through the competitive process of proof-of-work, also known as mining. The details of mining will be left for the next chapter. In this chapter, however we will see how transactions relate to the blockchain by tracing their journey from the moment they are created until they are included in the blockchain. +[[tx_lifecycle]] ==== Transaction Lifecycle -A transaction's lifecycle starts with the transaction's creation, also known as origination. The transaction is then signed, with one or more signatures indicating the authorization to spend the funds referenced by the transaction. The transaction is then broadcast on the bitcoin network, where each network node (participant) alidates and propagates the transaction until it reaches (almost) every node in the network. Finally, the transaction is verified by a mining node and included in a block of transactions that is recorded on the blockchain. Once recorded on the blockchain and confirmed by sufficient subsequent blocks (confirmations), the transaction is a permanent part of the bitcoin ledger and is accepted as valid by all participants. The funds allocated to a new owner by the transaction can then be spend in a new transaction, extending the chain of ownership and beginning the lifecycle of a transaction again. +A transaction's lifecycle starts with the transaction's creation, also known as origination. The transaction is then signed, with one or more signatures indicating the authorization to spend the funds referenced by the transaction. The transaction is then broadcast on the bitcoin network, where each network node (participant) validates and propagates the transaction until it reaches (almost) every node in the network. Finally, the transaction is verified by a mining node and included in a block of transactions that is recorded on the blockchain. Once recorded on the blockchain and confirmed by sufficient subsequent blocks (confirmations), the transaction is a permanent part of the bitcoin ledger and is accepted as valid by all participants. The funds allocated to a new owner by the transaction can then be spend in a new transaction, extending the chain of ownership and beginning the lifecycle of a transaction again. +[[tx_origination]] ===== Creating Transactions In some ways it helps to think of a transaction in the same way as a paper cheque. Like a cheque, a transaction is an instrument that expresses the intent to transfer money and is not visible to the financial system until it is submitted for execution. Like a cheque, the originator of the transaction does not have to be the one signing the transaction. Transactions can be created online or offline by anyone, even if they are not able to sign for the funds spent by the check. While a cheque references a specific account as the source of the funds, a transaction references a specific previous transaction as its source (also known as an "input"), rather than an account. Once a transaction has been created, it is signed by the owner (or owners) of the source funds. If it was properly formed and signed, the signed transaction is now valid and contains all the information needed to execute the transfer of funds. Now, the valid transaction has to reach the bitcoin network so that it can be propagated until it reaches a miner for inclusion in the pubic ledger, the blockchain. -===== Broadcasting Transactions +[[tx_bcast]] +===== Broadcasting Transactions to the Bitcoin Network + +Next, a transaction needs to get on to the bitcoin network so that it can be propagated and eventually executed by inclusion in the blockchain. Since the transaction is signed and contains no confidential information, private keys or credentials, it can be broadcast using any underlying network transport that is convenient. Unlike credit card transactions, for example, which contain sensitive information and can only be transmitted on encrypted networks, a bitcoin transaction can be sent over any network, even broadcast by radio or printed on paper. As long as it can reach a bitcoin node that will propagate it into the bitcoin network, it doesn't matter how it is transported to the first node. In essence, a bitcoin transaction is just 300-400 bytes of data that needs to reach any one of tens of thousands of bitcoin nodes. Bitcoin transactions can therefore be sent to the bitcoin network over insecure networks such as Wifi, Bluetooth, NFC, Chirp, barcodes or by copy and paste in a web form. In extreme cases, a bitcoin transaction could be transmitted over packet radio, satellite relay or shortwave using burst transmission, spread spectrum or frequency hoping to evade detection and jamming. A bitcoin transaction could even be encoded as smileys (emoticons) and posted in a forum or sent as a text message or Skype chat message. Bitcoin turned money into a data structure making it virtually impossible to stop anyone from sending a bitcoin transaction to the bitcoin network for execution. -Next, a transaction needs to get on to the bitcoin network so that it can be propagated and eventually executed by inclusion in the blockchain. Since the transaction is signed and contains no confidential information, private keys or credentials, it can be broadcast using any underlying network transport that is convenient. Unlike credit card transactions, for example, which contain sensitive information and can only be transmitted on encrypted networks, a bitcoin transaction can be sent over any network, even broadcast by radio or printed on paper. As long as it can reach a bitcoin node that will propagate it into the bitcoin network, it doesn't matter how it is transported to the first node. In essence, a bitcoin transaction is just 300-400 bytes of data that needs to reach any one of tens of thousands of bitcoin nodes. Bitcoin transactions can therefore be sent to the bitcoin network over insecure networks such as Wifi, Bluetooth, NFC, Chirp, barcodes or by copy and paste in a web form. In extreme cases, a bitcoin transaction could be transmitted over packet radio, satellite relay or shortwave using burst transmission, spread spectrum or frequency hoping to evade detection and jamming. A bitcoin transaction could even be encoded as smileys (emoticons) and posted in a forum or sent as a text message or Skype chat message. It is virtually impossible to stop anyone from sending a bitcoin transaction to the bitcoin network for execution. +[[tx_propagation]] +===== Propagating Transactions on the Bitcoin Network -===== Validating and Propagating Transactions +Once a bitcoin transaction is sent to any node connected to the bitcoin network, the transaction will be validated by that node and then propagated to all other nodes that it is connected to. Within a few seconds, a valid transaction will propagate from node to node, in an exponentially ripple across the network until all connected nodes have received it. +To prevent spamming, denial of service attacks or other nuisance attacks agains the bitcoin system, every node will independently validate every transaction before propagating it further. A malformed transaction will not get beyond one node. The rules by which transactions are validated are explained in more detail in <<>> +[[tx_mining]] ===== Mining Transactions into Blocks +[[tx_fees_intro]] ==== Transaction Fees + +[[tx_validation]] ==== Transaction Validation + +[[tx_validation_limits]] ===== Validation Limits + +[[tx_locktime]] ==== Transaction Locktime + +[[tx_irrevocability]] ==== Transaction Irrevocability + +[[tx_selfsufficiency]] ==== Transaction Self-Sufficiency - +[[tx_structure]] === Transaction Structure + +[[tx_inputs_outputs]] === Transaction Outputs and Inputs [TIP] @@ -44,6 +68,7 @@ Next, a transaction needs to get on to the bitcoin network so that it can be pro Outputs come first, chicken and egg. ==== +[[tx_outs]] ==== Transaction Outputs ===== Spending Conditions (Encumbrances) ===== Unspent Transaction Outputs (UTXO) @@ -53,9 +78,12 @@ Outputs come first, chicken and egg. The are no accounts or balances in bitcoin, only UTXO. ==== +[[tx_inputs]] ==== Transaction Inputs ===== Spending the Transaction Outputs ===== Unlocking the Conditions (Encumbrance Satisfaction) + +[[tx_fees]] ==== Transaction Fees From 37350b3d580f088a05ae0efb22334c0d5fa9193d Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Sat, 7 Jun 2014 11:59:35 -0700 Subject: [PATCH 12/14] warning to readers - no comments, issues or PRs yet, still heavily editing --- ch05.asciidoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ch05.asciidoc b/ch05.asciidoc index 3321a18d..6bea133d 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -1,6 +1,8 @@ [[ch5]] == Chapter 5 - Transactions +*DRAFT: DO NOT SUBMIT ISSUES OR PULL REQUEST YET, DRAFT IN PROGRESS AND FREQUENTLY MODIFIED* + [[ch5_intro]] === Introduction From 0464511207c634c70b82bb10e9f77801e19a951b Mon Sep 17 00:00:00 2001 From: Michalis Kargakis Date: Sun, 8 Jun 2014 03:41:59 +0300 Subject: [PATCH 13/14] Display header on ch04 correctly --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index 002567cb..64e62fb8 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -1,4 +1,4 @@ - [[ch04_keys_addresses_wallets]] +[[ch04_keys_addresses_wallets]] == Keys, Addresses, Wallets === Introduction From de7efe9eb95b58b1cf524eeec609558873fdf1e1 Mon Sep 17 00:00:00 2001 From: "Minh T. Nguyen" Date: Tue, 10 Jun 2014 22:39:02 -0700 Subject: [PATCH 14/14] Changing 'a 50% reductio'n to 'almost 50% reduction' suggested by Issue #43 --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index 64e62fb8..6abd6882 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -332,7 +332,7 @@ K = 04F028892BAD...505BDB Compressed public keys were introduced to bitcoin to reduce the size of transactions and conserve disk space on nodes that store the bitcoin blockchain database. Most transactions include the public key, required to validate the owner's credentials and spend the bitcoin. Each public key requires 520 bits (prefix \+ x \+ y), which when multiplied by several hundred transactions per block, or tens of thousands of transactions per day, adds a significant amount of data to the blockchain. -As we saw in the section <> above, a public key is a point (x,y) on an elliptic curve. Since the curve expresses a mathematical function, a point on the curve represents a solution to the equation and therefore if we know the x-coordinate we can calculate the y-coordinate by solving the equation y^2^ mod p = (x^3^ + 7) mod p. That allows us to store only the x-coordinate of the public key point, omitting the y-coordinate and reducing the size of the key and the space required to store it by 256 bits. A 50% reduction in size in every transaction adds up to a lot of data saved over time! +As we saw in the section <> above, a public key is a point (x,y) on an elliptic curve. Since the curve expresses a mathematical function, a point on the curve represents a solution to the equation and therefore if we know the x-coordinate we can calculate the y-coordinate by solving the equation y^2^ mod p = (x^3^ + 7) mod p. That allows us to store only the x-coordinate of the public key point, omitting the y-coordinate and reducing the size of the key and the space required to store it by 256 bits. An almost 50% reduction in size in every transaction adds up to a lot of data saved over time! Whereas uncompressed public keys have a prefix of +04+, compressed public keys start with either a +02+ or a +03+ prefix. Let's look at why there are two possible prefixes: since the left side of the equation is y^2^, that means the solution for y is a square root, which can have a positive or negative value. Visually, this means that the resulting y-coordinate can be above the x-axis or below the x-axis. As you can see from the graph of the elliptic curve, the curve is symmetric, meaning it is reflected like a mirror by the x-axis. So, while we can omit the y-coordinate we have to store the _sign_ of y (positive or negative), or in other words we have to remember if it was above or below the x-axis, as each of those options represents a different point and a different public key. When calculating the elliptic curve in binary arithmetic on the finite field of prime order p, the y coordinate is either even or odd, which corresponds to the positive/negative sign as explained above. Therefore, to distinguish between the two possible values of y, we store a +compressed public key+ with the prefix +02+ if the +y+ is even, and +03+ if it is odd, allowing the software to correctly deduce the y-coordinate from the x-coordinate and uncompress the public key to the full coordinates of the point.