Bitcoin and Cryptocurrency Technologies

More documents

Recommendations

Info

as political commentary on the motivation for starting Bitcoin. It also serves as a sort of proof that the first block was mined after the story came out on January 3, 2009. One way in which the coinbase parameter has since been used is to signal support by miners for different new features. To get a better feel for the block format and transaction format, the best way is to explore the block chain yourself. There are many websites that make this data accessible, such as blockchain.info. You can look at the graph of transactions, see which transactions redeem which other transactions, look for transactions with complicated scripts, and look at the block structure and see how blocks refer to other blocks. Since the block chain is a public data structure, developers have built pretty wrappers to explore it graphically. 3.5 The Bitcoin network So far we’ve been talking about the ability for participants to publish a transaction and get it into the block chain as if this happens by magic. In fact this happens through the Bitcoin network. It’s a peer-to-peer network, and it inherits many ideas from peer-to-peer networks that have been proposed for all sorts of other purposes. In the Bitcoin network, all nodes are equal. There is no hierarchy, and there are no special nodes or master nodes. It runs over TCP and has a random topology, where each node peers with other random nodes. New nodes can join at any time. In fact, you can download a Bitcoin client today, spin up your computer as a node, and it will have equal rights and capabilities as every other node on the Bitcoin network. The network changes over time and is quite dynamic due to nodes entering and leaving. There isn’t an explicit way to leave the network. Instead, if a node hasn’t been heard from in a while — three hours is the duration that’s hardcoded into the common clients — other nodes start to forget it. In this way, the network gracefully handles nodes going offline. Recall that nodes connect to random peers and there is no geographic topology of any sort. Now say you launch a new node and want to join the network. You start with a simple message to one node that you know about. This is usually called your seed node, and there are a few different ways you can look up lists of seed nodes to try connecting to. You send a special message, saying, “Tell me the addresses of all the other nodes in the network that you know about.” You can repeat the process with the new nodes you learn about as many times as you want. Then you can choose which ones to peer with, and you’ll be a fully functioning member of the Bitcoin network. There are several steps that involve randomness, and the ideal outcome is that you’re peered with a random set of nodes. To join the network, all you need to know is how to contact one node that’s already on the network. What is the network good for? To maintain the block chain, of course. So to publish a transaction, we want to get the entire network to hear about it. This happens through a simple floodingalgorithm, sometimes called a gossip protocol. If Alice wants to pay Bob some money, her client creates and her node sends this transaction to all the nodes it’s peered with. Each of those nodes executes a series of checks to determine whether or not to accept and relay the transaction. If the checks pass, the node 90
in turn sends it to all of its peer nodes. Nodes that hear about a transaction put it in a pool of transactions which they’ve heard about but that aren’t on the block chain yet. If a node hears about a transaction that’s already in its pool, it doesn’t further broadcast it. This ensures that the flooding protocol terminates and transactions don’t loop around the network forever. Remember that every transaction is identified uniquely by its hash, so it’s easy to look up a transaction in the pool. When nodes hear about a new transaction, how do they decide whether or not they should propagate it? There are four checks. The first and most important check is transaction validation — the transaction must be valid with the current block chain. Nodes run the script for each previous output being redeemed and ensure that the scripts return true. Second, they check that the outputs being redeemed here haven’t already been spent. Third, they won’t relay an already-seen transaction, as mentioned earlier. Fourth, by default, nodes will only accept and relay “standard” scripts based on a small whitelist of scripts. All these checks are just sanity checks. Well-behaving nodes all implement these to try to keep the network healthy and running properly, but there’s no rule that says that nodes have to follow these specific steps. Since it’s a peer-to-peer network, and anybody can join, there’s always the possibility that a node might forward double-spends, non-standard transactions, or outright invalid transactions. That’s why every node must do the checking for itself. Since there is latency in the network, it’s possible that nodes will end up with a different view of the pending transaction pool. This becomes particularly interesting and important when there is an attempted double-spend. Let’s say Alice attempts to pay the same bitcoin to both Bob and Charlie, and sends out two transactions at roughly the same time. Some nodes will hear about the Alice → Bob transaction first while others will hear about the Alice → Charlie transaction first. When a node hears either of these transactions, it will add it to its transaction pool, and if it hears about the other one later it will look like a double-spend. The node will drop the latter transaction and won’t relay it or add it to its transaction pool. As a result, the nodes will temporarily disagree on which transactions should be put into the next block. This is called a race condition. The good news is that this is perfectly okay. Whoever mines the next block will essentially break the tie and decide which of those two pending transactions should end up being put permanently into a block. Let’s say the Alice → Charlie transaction makes it into the block. When nodes with the Alice → Bob transaction hear about this block, they’ll drop the transaction from their memory pools because it is a double-spend. When nodes with the Alice → Charlie transaction hear about this block, they’ll drop the transaction from their memory pools because it’s already made it into the block chain. So there will be no more disagreement once this block propagates to the network. Since the default behavior is for nodes to hang onto whatever they hear first, network position matters. If two conflicting transactions or blocks get announced at two different positions in the network, they’ll both begin to flood throughout the network and which transaction a node sees first will depend on where it is in the network. 91
Page 1 and 2:
Bitcoin and Cryptocurrency Technolo
Page 3 and 4:
Preface — The Long Road to Bitcoi
Page 5 and 6:
work, there is also the issue of co
Page 7 and 8:
Finally, CyberCash has the dubious
Page 9 and 10:
This was the first serious digital
Page 11 and 12:
and so on — powers of two. That w
Page 13 and 14:
Figure 3 shows the user side of the
Page 15 and 16:
initial cost to acquire all the equ
Page 17 and 18:
the system is to record the relativ
Page 19 and 20:
original design. However, after Bit
Page 21 and 22:
A final reason that’s often cited
Page 23 and 24:
Chapter 1: Introduction to Cryptogr
Page 25 and 26:
Figure 1.2 Because the number of
Page 27 and 28:
Property 2: Hiding The second pr
Page 29 and 30:
ecome: ● ● Hiding: Given H(
Page 31 and 32:
SHA‐256 uses a compression functi
Page 33 and 34:
Figure 1.5 Block chain.A block c
Page 35 and 36:
Figure 1.7 Merkle tree. In a Mer
Page 37 and 38:
throughout this book. 1.3 Digital S
Page 39 and 40: Figure 1.9 Unforgeability game.
Page 41 and 42: andomness just in making a signatur
Page 43 and 44: 1.5 A Simple Cryptocurrency Now let
Page 45 and 46: The first key idea is that a design
Page 47 and 48: Figure 1.13 A PayCoins Transa
Page 49 and 50: Perusing the NIST standard that def
Page 51 and 52: Chapter 2: How Bitcoin Achieves Dec
Page 53 and 54: state of the system. The implicatio
Page 55 and 56: consensus is somewhat pessimistic,
Page 57 and 58: Implicit Consensus. This assumpt
Page 59 and 60: Figure 2.2 A double spend attempt.
Page 61 and 62: In general, the more confirmations
Page 63 and 64: Figure 2.4 The block reward is c
Page 65 and 66: puzzle‐friendliness property from
Page 67 and 68: possible outcomes, and the probabil
Page 69 and 70: theory problem that’s not easily
Page 71 and 72: this interlocking interdependence b
Page 73 and 74: Further reading The Bitcoin whitepa
Page 75 and 76: Chapter 3: Mechanics of Bitcoin Thi
Page 77 and 78: In this example, Alice specifies tw
Page 79 and 80: 3.2 Bitcoin Scripts Each transactio
Page 81 and 82: the Bitcoin language and one has to
Page 83 and 84: exactly the same script, which is i
Page 85 and 86: in the normal case, this isn’t th
Page 87 and 88: Technically all of these transactio
Page 89: The header mostly contains informat
Page 93 and 94: Figure 3.10 Block propagation ti
Page 95 and 96: that actually affect them. So they
Page 97 and 98: that the old version would accept a
Page 99 and 100: Exercises 1. Transaction validation
Page 101 and 102: Chapter 4: How to Store and Use Bit
Page 103 and 104: software can automatically turn the
Page 105 and 106: The cryptographic magic that makes
Page 107 and 108: may never know (or care) who the co
Page 109 and 110: Given this stringent requirement, s
Page 111 and 112: There is a formula called Lagrange
Page 113 and 114: Ideally, the site will encrypt thos
Page 115 and 116: seen exchanges that fail due to bre
Page 117 and 118: Figure 4.5: Proof of liabilities.
Page 119 and 120: crypto and we won’t cover it here
Page 121 and 122: Figure 4.8: Payment process involvi
Page 123 and 124: transaction can't create coins, but
Page 125 and 126: of U.S. dollars per day pass throug
Page 127 and 128: Now if you look at a particular sec
Page 129 and 130: alance of 500,000 BTC. It then sign
Page 131 and 132: Chapter 5: Bitcoin Mining This chap
Page 133 and 134: In most cases you'll try every sing
Page 135 and 136: You can see in Figure 5.3 that over
Page 137 and 138: steady‐state, the period to find
Page 139 and 140: TARGET=(65535
Page 141 and 142:
Disadvantages of GPU mining. GPU
Page 143 and 144:
may be the fastest turnaround time
Page 145 and 146:
Figure 5.10: Evolution of mining
Page 147 and 148:
Hopefully, over time the embodied e
Page 149 and 150:
Still, if we could replace Bitcoin
Page 151 and 152:
Figure 5.11: Illustration of uncert
Page 153 and 154:
Figure 5.13: Mining rewards. Thr
Page 155 and 156:
Some mining hardware even supports
Page 157 and 158:
By April 2015, the situation looks
Page 159 and 160:
Figure 5.15 Forking attack.A mal
Page 161 and 162:
Temporary block‐withholding attac
Page 163 and 164:
the transaction from address X
Page 165 and 166:
Chapter 6: Bitcoin and Anonymity
Page 167 and 168:
Unlinkability. To understand unl
Page 169 and 170:
eason is that use cases that we cla
Page 171 and 172:
But this reveals something. The tra
Page 173 and 174:
the other hand, are often not new a
Page 175 and 176:
Figure 6.5. Labeled clusters.
Page 177 and 178:
Luckily, this is a problem of commu
Page 179 and 180:
they are unhappy with anonymity pro
Page 181 and 182:
Fees should be all-or-nothing. M
Page 183 and 184:
Somebody looking at this transactio
Page 185 and 186:
a single transaction that combines
Page 187 and 188:
just minting one doesn’t automati
Page 189 and 190:
Efficiency. Recall the statement
Page 191 and 192:
We start with Bitcoin itself, which
Page 193 and 194:
An alternative design to Zerocoin i
Page 195 and 196:
elieve the same thing. So consensus
Page 197 and 198:
of developers who maintain Bitcoin
Page 199 and 200:
The interesting case is if the fork
Page 201 and 202:
eing effectively bankrupt. As of ea
Page 203 and 204:
In an important sense it doesn't ma
Page 205 and 206:
of illegal items becomes potentiall
Page 207 and 208:
arrest. So although Ulbricht was th
Page 209 and 210:
kind of business that will handle l
Page 211 and 212:
een enough time for sellers to buil
Page 213 and 214:
The text refers to “activities in
Page 215 and 216:
A book that looks at the history of
Page 217 and 218:
It’s easy to see how Bitcoin’s
Page 219 and 220:
Why might memory‐hard and memory
Page 221 and 222:
Until recently, it wasn’t known i
Page 223 and 224:
meaning the exponential growth peri
Page 225 and 226:
Next, consider the problem that SET
Page 227 and 228:
In Permacoin, each miner Msto
Page 229 and 230:
Interestingly, these concerns have
Page 231 and 232:
they can perform the signatures on
Page 233 and 234:
schemes also require a small amount
Page 235 and 236:
to provide an effective solution, t
Page 237 and 238:
Chapter 9: Bitcoin as a Platform In
Page 239 and 240:
means that if you actuallydo
Page 241 and 242:
CommitCoin exploits this property.
Page 243 and 244:
features without needing to change
Page 245 and 246:
would just look like a dollar bill.
Page 247 and 248:
you. In particular, you can’t use
Page 249 and 250:
To solve this problem we can once a
Page 251 and 252:
NBA draft lottery.One example th
Page 253 and 254:
that there’s no way for anyone to
Page 255 and 256:
to predict the low‐level fluctuat
Page 257 and 258:
design, because miners have to veri
Page 259 and 260:
Here's another example, this time f
Page 261 and 262:
You can also trade shares for futur
Page 263 and 264:
Order books.The final piece o
Page 265 and 266:
Chapter 10: Altcoins and the Crypto
Page 267 and 268:
Attracting miners has special impor
Page 269 and 270:
with the launch date of the altcoin
Page 271 and 272:
Namecoin is technically interesting
Page 273 and 274:
10.3 Relationship Between Bitcoin a
Page 275 and 276:
Switching costs are certainly not z
Page 277 and 278:
If our altcoin is merge‐mined, we
Page 279 and 280:
When we think about a rational mine
Page 281 and 282:
DepositA [Altcoin block chain] Refu
Page 283 and 284:
Sidechains. The sidechains vision i
Page 285 and 286:
lock themselves could tell us. This
Page 287 and 288:
written in bytecode and executed by
Page 289 and 290:
Bitcoin. In particular, there are c
Page 291 and 292:
The simple binary Merkle tree used
Page 293 and 294:
Chapter 11: Decentralized Instituti
Page 295 and 296:
Bitcoin, Alice can remotely transfe
Page 297 and 298:
only these signatures of limited fo
Page 299 and 300:
11.3 Template for Decentralization
Page 301 and 302:
Sidebar: trust.Some people in th
Page 303 and 304:
competition among intermediaries. P
Page 305 and 306:
To drive home the mismatch between
Page 307 and 308:
Conclusion to the book Some people
show all

Bitcoin and Cryptocurrency Technologies

Create successful ePaper yourself

Delete template?

Save as template?