10.02.2016 Views

Bitcoin and Cryptocurrency Technologies

1Qqc4BN

1Qqc4BN

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

lock themselves could tell us. This is shown in Figure 10.7, each block would contain a pointer both<br />

to its predecessor as well as to the most recent block that satisfied ​hash < target / 4​.<br />

How far can we push this? Can we pick arbitrarily large multiples? Not really. The logic here is similar<br />

to pooled mining, but in reverse. In pooled mining, the pool operator verifies shares, which are blocks<br />

with a lowered difficulty (that is, a higher target value). Miners find many more shares than blocks, so<br />

the operator must do extra work to verify them. The benefit of doing so is the ability to estimate the<br />

miner’s hash power much more accurately — the variance of the estimate is lower.<br />

Here we see the opposite tradeoff. As we do less <strong>and</strong> less work to estimate the total amount of work<br />

that has gone into building the chain, our estimate will have a greater <strong>and</strong> greater variance. Here’s an<br />

example. Suppose ​N=4​, so that without the skiplist solution, we’d check that there are 4 blocks that<br />

satisfy ​hash < target​. The expected amount of work that an adversary must do to fool us is 4 times the<br />

average amount of work needed to find a block.<br />

Suppose the adversary only does half this amount of work. If we do the math, it turns out that this<br />

adversary has a 14% chance of finding 4 blocks that satisfy ​hash < target​. On the other h<strong>and</strong>, with a<br />

skiplist solution with a factor of 4, the adversary’s task would be to find a single block that satisfies<br />

hash < target/4​. In this scenario, the lazy adversary who only does half the expected amount of work<br />

will be able to fool us with a probability of 40% instead of 14%.<br />

10.7 Ethereum <strong>and</strong> Smart Contracts<br />

We have seen several ways to use <strong>Bitcoin</strong>’s scripting language to support interesting applications,<br />

such as an escrowed payment transaction. We’ve also seen how <strong>Bitcoin</strong> script is somewhat limited,<br />

with a small instruction set that isn’t Turing‐complete. As a result, some new altcoins propose adding<br />

application‐specific functionality. Namecoin was the first example but many others have proposed<br />

cryptocurrencies much like <strong>Bitcoin</strong> but supporting gambling, stock issuance, prediction markets, <strong>and</strong><br />

so on.<br />

What if, instead of needing to launch a new system to support every application, we built a<br />

cryptocurrency that could support ​any​application we might dream up in the future? This what<br />

Turing‐completeness is all about: to the best of our knowledge, a Turing‐complete programming<br />

language lets you specify any functionality that is possible to be specified by any other computer. To<br />

some extent, the situation today harkens back to the early days of computers themselves in the<br />

1940s: increasingly complicated machines were being built for various specific applications during<br />

World War II (such as brute‐forcing keys used by mechanical cipher machines or determining firing<br />

trajectories for naval artillery), motivating researchers to build the first reprogrammable<br />

general‐purpose computers that could be used for any conceivable applications.<br />

285

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!