Cryptocurrency Cabal

The goal of this assignment is for everyone to gain experience analyzing the blockchain and understanding of the anonymity of bitcoin (and mechanisms that are used to increase or decrease it), and to hopefully help the FBI catch some heinous criminals.

Collaboration Policy

For this assignment, you may either work alone or with one other person of your choice. If you work with a partner, you should together submit one assignment with both of your names on it that reflects your combined efforts. You may, and are encouraged to, discuss all of the problems with anyone else you want (both on-line using the course web site or any other means you choose, and in person).

Submission

Submit your answers as a single ZIP file using this link. The name of your file should be <your email ID>-ps3.zip (if you worked alone) or <partner1 email ID>-<partner2 email ID>-ps3.zip. Your submission should include a PDF document containing all your written (non-code) answers, all of the source code for your programs, and any additional data you think it useful to provide.

Warm-Up: Manual Exploration

You should have received by email a list of bitcoin addresses that were given to us by the FBI. These are addresses that were used to collect ransom payments from victims of bitcoin ransomware attacks. In the scheme perpetrators encrypt a victim’s files and then demand that ransom payment be made to a specific bitcoin address in return for the key to decrypt the files.

One of the addresses are marked with your email ID. The intent of this is to ensure that the examination efforts are well distributed over the provided addresses. For the manual exploration question, you should start with that address (but feel free to look at any of the addresses in the file, and for the programmatic analysis questions, you’ll want to use all the addresses).

You can use any tool you want to answer these questions, but we suggest using blockchain.info. One useful thing you can do there is look at the taint analysis to see which other addresses a given addresses is interacting with (e.g., examine the reverse taint analysis to see the addresses that are receiving bitcoin from the given address).

Problem 1.
(a) What address are you investigating?
(b) When was that address in use?
(c) How many victims appear to have paid into the address?
(d) How much was collected from each victim (the most relevant value would be the value in US dollars at the time of the payment)? Did all the victims pay the same amount, or did the requested amount vary by victim?
(e) How did the ransomist (owner of this address) distribute the proceeds? Is there a percentage split, or some other fee being paid by the ransomist to other addresses?
(f) What else can you learn about the operation starting from your transaction?
(g) Added 4 Nov: If you are answering Problem 1 after class Wednesday, also answer: How is your address similar to and different from what has been observed by other students for other addresses?

Since our goal is to learn as much as we can about the overall operation, you should post your answers to Problem 1 (for your address) as a comment on this page.

Privacy in the Blockchain

The questions in the section focus on this paper:

A Fistful of Bitcoins: Characterizing Payments among Men (sic) with No Names by Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage. Internet Measurement Conference, 2013.

You should also read:

Chapter 6: Bitcoin and Anonymity, from Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, Steven Goldfeder. Bitcoin and Cryptocurrency Technologies

Problem 2. Part of the strategy used in the Sarah Meiklejohn et al. paper was for the authors to open accounts with services and conduct transactions with questionable merchants.
(a) Why was it useful to actually conduct transactions with merchants operating in dark markets to conduct this research?
(b) What ethical and legal issues does contudcting a transaction with a questionable merchant raise?

Problem 3. The Heuristic 1 (Section 4.3) used to detemine sets of public addresses owned by the same entity is based on the assumption that all inputs to a bitcoin transaction are controlled by the same entity. According to the paper, “the sender in the transaction must know the private signing key belonging to each public key used as an input, so it is unlikely that the collection of public keys are controlled by multiple entities (as these entities would need to reveal their private keys to each other).” Explain why this is not actually true. (A good answer will consider in more detail what is needed in the unlocking script to spend each input.)

Problem 4. The analysis in this paper was done before hierarchical deterministic wallets became standard. How does the widespread use of HD wallets today impact the effectiveness of their Heuristic 2?

Blockchain APIs

One way to analyze the blockchain is to run a full bitcoin node, and operate on your own local copy of the blockchain. This requires downloading and processing a large amount of data (approximately 45 GB today). Instead, you can use an external service that provides an API for interacting with the blockchain. Several such APIs exist including blockchain.info, Bitpay’s Insight API, and BlockCypher’s Blockchain API.

For this assignment, you are welcome to use any services and open source bitcoin libraries and openly-licensed code you want, but must follow the license requirements of any code you use and credit this code in your submission.

The starting examples we provide will use Python and the BlockCypher Blockchain API, and we provide some directions to get started using this next (but feel free to use other tools if you prefer).

Setting up BlockCypher API

Install Python. Start by downloading and installing Python (https://www.python.org/downloads/release/python-350/. Note that Python V3 is incompatible with Python V2 (on MacOSX, the default python is Python 2.7.2; to use Python 3, use python3). Even if you are not familiar with Python, if you feel comfortable learning a new language on the fly you should be fine jumping right into this assignment. If you prefer a more structured intro to Python there are many tutorials available, including http://www.learnpython.org/.

Install the Blockcypher Python library. The BlockCypher Python library provides a convenient way to use the APIs. To install it, execute pip install blockcypher (in the command shell).

Here is some example code that uses the BlockCypher API to find all the addresses which received bitcoin directly from a sending address:

import blockcypher

def get_receivers(sending_address):
    receiving_addresses = set()
    r = blockcypher.get_address_details(sending_address)
    for tx in r['txrefs']: # loop through all transactions
        hash = tx['tx_hash']
        transaction = blockcypher.get_transaction_details(hash)
        # was this address an input
        sender = False
        for input in transaction['inputs']:
            if sending_address in input['addresses']:
                sender = True
                break
        if sender:
            for output in transaction['outputs']:
                for adr in output['addresses']:
                    receiving_addresses.add((adr, output['value']))

    return receiving_addresses

def satoshi_to_BTC(sval):
    return sval / 100000000

sender = '1Ez69SnzzmePmZX3WpEzMKTrcBF2gpNQ55'
print ("Received from " + sender + ": ")
for receiver in get_receivers(sender):
    print("   " + receiver[0] + " (" + str(satoshi_to_BTC(receiver[1])) + " BTC)")

To avoid API limits, you will want to obtain an API key, and add an api_key=APIKEY parameter to your requests:

   txdetails = blockcypher.get_transaction_details(tx, api_key=API_KEY)

You can also use direct web API requests:

     r = requests.get('https://api.blockcypher.com/v1/btc/main/addrs/' + adr 
       	 	       + '/full', params={'token': API_KEY}).json()

To learn if an address is connected with a known wallet, you can use the WalletExplorer.com API (note the WalletExporer API is not publicly documented, but Aleš Janda, the WalletExplorer developer, kindly made it available to us):

def address_display(adr):
    try:
        r = requests.get('https://www.walletexplorer.com/api/1/address-lookup?address=' 
		         + adr + '&caller=virginia.edu').json()
        return adr + " (" + r['label'] + ")"
    except:
        return adr

Mixing Services

Before looking at the ransomware addresses, get some practice using a blockchain API by examining a simple mixer (as far as we can tell, the ransomwarists are not actually using any mixing service, though).

In transaction 0197dabc3c31c8221b5d7883a9d03240bcf7a3042e1bf6dcc26c8d3aa60c58ab, Dave sent 0.01523 BTC to the mixing service BitMixer.io.

BitMixer is a mixing service for the impatient - it will send the input amount, less the collected fees, to the requested output address immediately after the input transaction is confirmed (a single confirmation is enough for small amounts, so the mixer output transaction is very likely to be in the next block in the blockchain). (In this case, Block 379818).

Note BitMixer’s fee structure: “Our minimum fee is 0.5% plus 0.0005 BTC for every forward address. We recommend to set higher custom fee to prevent advanced amount-based blockchain analysis.” (They don’t, to many customers dismay, actually make any promises about their maximum fee.)

Problem 5. Assuming you know the output transaction is in the block immediately following the input transaction and that BitMixer’s actual fee on this transaction is between 0.5% + 0.0005 BTC and 0.6% + 0.0005 BTC (but don’t know anything else), how big is the anonymity set for the output transaction? (Hint: use the blockcypher API to look at all the output values for transactions in the target block.)

Challenge Bonus. Which address is the output address? Your answer should include (a) a wager amount indicating your confidence (up to 10 points), which you win or lose depending on the correctness of your answer, and (b) an explanation of why you think that is the actual output address.

Problem 6. The BitMixer.io site suggests, “In order to further enhance the security of your transactions we provide the opportunity to use two or more forward addresses as well as convenient time delays.” How much does it enhance anonymity to split your output across two forward addresses? (A good answer will get into how using two forward addresses impacts both the size of the anonymity set and the computational cost of performining the de-anonymizing analysis. A great answer would actually test this by examining the blockchain to get a concrete result.)

Follow the Ransomware Money

Now it’s time to follow the money! We’ll provide a few hints for things to do, but you should use these as starting points and form your own ideas about ways to explore the blockchain.

First, we examine the direct transactions involving the ransomware addresses (in the suspects.txt file provided to you). Since we know these addresses were used to collect money from ransomware victims, we are more interested in looking at transactions where bitcoin is sent from the ransomware collection addresses to other addresses.

Problem 7. Write a program that reads in a file containing suspect addresses (e.g., the suspects.txt file containing the ransomware payment addresses that was sent to you), and examines the blockchain to find addresses that receive bitcoin from the suspect addresses. By using the WalletExplorer API, you should be able to find some interesting transactions, including one where the ransomware address sent bitcoin to an address WalletExplorer identifies as being “BitPay.com-old”. Report on any interesting transactions found by your program.

If the criminals are more careful, they should avoid making any revealing transactions directly from the collection addresses, and instead try to hide their money flows by making lots of transfers between other addresses (or, if they trust a mixnet operator sufficiently, use a mixer to disconnect their money trail).

So, we want to figure out if there are any common addresses that eventually receive coin from more than one of the starting addresses. This could detect if the suspect addresses are running received coins through a mixnet, but outputting to the same address eventually, which could mean payments to the same vendor.

A good approach to this problem could be writing a program that iteratively follows successive outputs from a series of seed addresses down to a reasonable depth and then checks for overlap between sets. We want to find addresses that eventually receive bitcoin sent from more than one of the ransom collection addresses, since these are likely to be addresses involved in meaningful transactions.

Problem 8. Write a program that reads in a file containing suspect addresses (e.g., the suspects.txt file containing the ransomware payment addresses that was sent to you), and outputs a list of all the addresses that eventually receive bitcoin from more than one of the suspect addresses. The receiving addresses are not limited to direct transactions, but could receive funds through a sequence of transactions starting from suspect addresses. From the ransonware payment addresses you should be able to find at least 34 such addresses (including the 18dwCxqqmya2ckWjCgTYReYyRL6dZF6pzL address which was already known to the FBI to have been used by the ransomware operation.)

We are also interested in finding out the relative importance of the addresses found. You can determine this based on factors such as amount of bitcoins they receive, number of seed addresses they are associated with, or how many hops away the addresses are on average from associated seed addresses. You can also use the WalletExplorer.com API to see if the addresses found are associated with known wallets.

Problem 9. Improve your program to provide additional information about the addresses found, and order the addresses according to the total value they received connected to the starting addresses.

The final problem is open-ended. Your goal is to hopefully find some information that would be useful to the FBI, or short of that, to at least impress your classmates.

We have a few suggested options below (from which you can select one to do). If you have a better idea for what to do, though, feel free to do that instead. If you want to do anything that involves interacting with criminals, though, please discuss your idea with the course staff and get permission before doing anything potentially risky!

Problem 10 (option 1). Develop and implement a new strategy for exploring the ransomware transactions, and report on what you find.

Problem 10 (option 2). Try applying your programs to other interesting sets of addresses. There are lots of potential sources of such addresses, including, of course, searching the blockchain itself for addresses involved in interesting transactions. (You can also look at posts such as 9 Infamous Bitcoin Addresses or Blockchain.info’s list of popular addresses.)

Problem 10 (option 3). Figure out how a mixing service like BitMixer.io (or select another one) works, and how much anonymity it really provides.

Submission

Follow the submission instructions at the beginning of this page by 8:29pm on Sunday, 8 November. If you do find anything of particular interest, please let us know right away, though!

Credits: This assignment was developed by Ori Shimony and David Evans for Cryptocurrency Cabal Fall 2015. We thank Jeremy D’Errico, Benjamin Blome, David Cochran, and Stuart VonCanon from the FBI (Richmond Office) for providing the impetus and data for this assignment. We thank Aleš Janda for making the WalletExplorer API available to us.

PS2: The Blockchain

Sun, 20 Sep 2015 00:00:00 +0000

Problem Set 2:
The Blockchain

Due: Friday, 9 October at 8:29pm

Purpose

The goal of this assignment is for everyone in the class to understand how bitcoin mining and the blockchain work, and evaluate risks to the blockchain.

Collaboration Policy

For this assignment, everyone should submit their own assignment and should writeup their own answers to the questions. You may, and are encouraged to, discuss all of the problems with anyone else you want (both on-line using the course web site or any other means you choose, and in person).

Submission

Submit your answers as a single PDF file using this link. The name of your file should be <your email ID>-ps2.pdf.

Your submission should include clearly marked answers for all the problems (highlighted in yellow). None of the questions require submitting a program, although you may find it helpful to write programs to develop your answers. If the code you write is less than a page, it is best to just include it in the PDF writeup. If it is longer, you may submit separate code files (and mention them in the PDF submission).

Blockchain Consensus

These questions concern the original bitcoin paper:

Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008.

Problem 1. In Section 6, Satoshi writes: “The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.”

What are the assumptions necessary to support Satoshi’s claim that it is more profitable for a greedy attacker with a majority of the mining power “to play by the rules”? (other than the assumption that the greedy attacker is a “he”)

Problem 2. At the end of Section 11, Satoshi presents a table for p < 0.001, where it is listed “q=0.45 z=340”. What does this mean in plain English, expressed in a short sentence?

Problem 3. For that same table, what would the z values be for p < 0.05 (instead of p < 0.001)?

Merkle Trees and Storage

Bitcoin uses Merkle Trees to record transactions in a way that enables a single hash to be used to record a set of transactions, and a small (logarithmic in the number of transactions) number of hashes to be sufficient to verify a transaction. In this question, you’ll explore another use of Merkle Trees to provide verifiable cloud storage.

Imagine you are storing a database using a cloud storage provider, since you do not have local storage. Assume that you have just enough local storage to store a small number of cryptographic hashes or keys. You fear, however, that your storage provider may be skimping, and may not actually be storing all of your data.

So, you want to verify each record as you receive it, to make sure the data is the same as what you wrote. In order to do so, you are willing to write extra cryptographic information with each write, but need to limit the amount of local storage.

Assume we are storing n records, and we can query the server for the i-th record for any i from 0 to n - 1. The data content of the i-th record will be denoted as data[i].

Problem 4. One naive approach would be to just sign each record data with a private key, and verify the signature on reading it.

(a) There is a problem with this scheme unless the bytes of data[i] indicate that it is in fact from i-th index. What is this problem?

(b) Suppose we perform a write at position i, both data and signature. Later on, when we read it back, if the signature matches the data, can we be sure that it is indeed the data item we wrote? Explain.

Problem 5. Another approach would be hashing the concatenation of all records in the database. This hash is a small item that can be stored locally.

(a) What is the write/read/verify procedure for this system?

(b) How does the cost of reading and writing to the database scale with n (the number of records)?

Problem 6. Instead of using the concatenating all the records linear, they were organized into a Merkle tree.

(a) What is the write/read/verify procedure for this system?

(b) How does the cost of reading and writing to the database scale with n (the number of records)?

Blockchain

These questions are related to this paper (and what was covered in Class 10 and Class 11):

Ittay Eyal and Emin Gün Sirer, Majority is not Enough: Bitcoin Mining is Vulnerable, November 2013.

Orphaned Blocks are blocks that are submitted to the bitcoin network, and that are valid, but do not become part of the longest (consensus) blockchain.

One way to detect selfish mining is to be on the lookout for “orphaned” blocks, or blocks that were mined but never became part of the final blockchain.

Let’s say you set up a node to monitor orphaned blocks, and you are in a favorable position in the network that allows you to observe all orphaned blocks. Assume that the hashing difficulty stays constant and the expected block rate is constant at 10 minutes per block.

Problem 7.
(a) If a mining pool has 15% (α = 0.15) of the total network hashing power, how many blocks is it expected to find in a day?

(b) Obtain a general formula for expected number of blocks a mining pool with α fraction of the total hashing power should find in t minutes.

For the next questions, you may assume a very simplified network model where you can view the network having two “supernodes”: one represents a particular mining pool, and the other represents all other nodes in the network. The latency between the two supernodes is L seconds.

With this simple (but very unrealistic) model, we assume that when one supernode announces a block, all of the rest of the network learns of the new block L seconds later (but no one learns of it before that).

Problem 8. Assuming all of the miners are honest, what is the expected number of orphaned blocks per day for an honest mining pool with hashing power α and latency L (as simplified above).

Problem 9. How does this change if the mining pool is mining selfishly? (For this question, assume that the selfish mining pool learns of a block announced by the rest of the network as soon as it is announced, so will immediately announce any withheld blocks at that time. That is, you may still assume the simplified latency L model, but that the selfish mining pool has a spy in the other supernode with a low-latency direct connection to the mining pool.)

Pool Hopping

Answer either question 10A or 10B (your choice).

Problem 10A. In class, we saw how pool-hopping can be used to game a “proportional” reward scheme. Design a simple reward scheme that eliminates pool-hopping incentive. In particular, derive the expected reward for your scheme and show that it does not depend on time since last block (or any variable controlled by the miner).

Problem 10B. In upcoming classes, we will have visits from a law professor (who also works for the State Department on international cyberlaw and promulgating the open Internet) and an FBI agent who works on criminals using bitcoin for ransom. Come up with at least one good question that you would like one of them to answer.

Bonus Opportunities

The following questions are suggestions for further work, but it is not expected that everyone will solve them. (Note that some of these could be starting ideas for larger projects, although a good answer to any of them would be most impressive.)

Challenge 1. The network model in questions 8 and 9 is very unrealistic. Answer these questions for a more realistic model of the bitcoin network, and compare your results with the actual rates of orphaned blocks. To better detect misbehaving miners, you would want to also look into the contents of the dual blocks (note that the one that was orphaned is not necessarily the one from the selfish miner). There is an API for obtaining orphaned blocks provided by https://api.biteasy.com.

Challenge 2. The analysis in the paper and in class assumed that if the selfish miner is ahead by 2 blocks, it will always win by releasing the blocks when it observes a new block on the blockchain. It could still lose if the rest of the network finds a second block before the selfish miner’s blocks have propagated over the network. How does this possibility impact the analysis?

Challenge 3. The site that was demonstrated in Class 11 uses a very simple model to estimate the profitability of a particular bitcoin miner. Produce a better model, and use it to evaluated the expected profit (or loss) for mining hardware such as Antminer S7. A better model would need to capture expected increases in the difficulty, cost of capital, and other costs of mining besides electricity.

Submission

Follow the submission instructions at the beginning of this page by 8:29pm on Friday, 9 October.

PS1: Bitcoin Transactions

Tue, 01 Sep 2015 00:00:00 +0000

Problem Set 1: Bitcoin Transactions

Due: Tuesday, 15 September at 8:29pm

Purpose

The goal of this assignment is for everyone in the class to understand how keys, addresses, and transactions work in bitcoin. In addition, this assignment should help everyone get up-to-speed with the software tools (including the Go programming language) we will use in later assignments.

Collaboration Policy

For this assignment, everyone should submit their own assignment and should writeup their own answers to the questions as well as execute all the required transactions with your own keys.

You may, and are encouraged to, discuss all of the problems with anyone else you want (both on-line using the course web site or any other means you choose, and in person), and it is okay to share code with others so long as you understand everything in all of the code you use.

Submission

Submit your answers as a single PDF file using this link. The name of your file should be <your email ID>-ps1.pdf. (In addition to the PDF file you submit, you may submit a separate spend.go file with your code for question 11, or incorporate that code into the PDF submission.)

Your submission should include clearly marked answers for all the problems (highlighted in yellow).

Blockchain Sleuthing

You should have received some bitcoin at the address you submitted in the registration form. (If you did not receive any bitcoin, contact the course staff right away!)

From that transaction, you have an address that was used to send you the bitcoin. For these questions, your goal is to figure out what you can about the way bitcoin was distributed to the class. For these questions, manual sleuthing should be sufficient (although ambitious students may find ways to automate this).

Problem 1. Answer the following questions about the transaction where you received the bitcoin. If you received more than one transfer, include all the transaction IDs).

a. What is the transaction ID?

b. What was the transaction fee for the transaction? (Give your answer in BTC, as well as current approximate US dollar value.)

c. What was the total value of all the transactions in the block containing your transfer? (Note: https://blockchain.info provides this info conveniently, although you could compute it yourself)

d. How long did it take from when the transaction was received until it had 3 confirmations? (Include an explanation of how you estimated this in your answer.)

Bitcoin advocates often taut its “anonymity”, but bitcoin transactions are actually publicly visible.

Problem 2. See how much can you figure out about the way bitcoin was transferred to students in the class, starting from your transactions.

a. Identify the bitcoin addresses of what are likely to be other students in the class (you could potentially find all of them, but it is enough to find 3).

b. Trace back the source of the bitcoin as far as you can. Bonus points if you can figure out from which exchange the bitcoin was purchased and when.

c. (Bonus) Can you learn anything about where the send of the bitcoin is located geographically? (In this case, you have external information to know I’m in Charlottesville, but what could you learn about the sender’s probable location just from the information in the blockchain?)

Hints:

Start by looking at the transaction that sent bitcoin to your receiving address. You can search for this by searching for your recieving address at https://blockexplorer.com, https://insight.bitpay.com/, https://blockchain.info, or many other sites that provide information about the bitcoin blockchain.
You can go forward, by following what happened with the “change” from that transaction.
You can go backward, by following transactions to the sending address.

Problem 3. Suppose a malicious developer wanted to distribute a bitcoin wallet implementation that would steal as much bitcoin as possible from its users with a little chance as possible of getting caught. (a) Explain things a malicious developed might do to create an evil wallet. (b) How confident are you your money is safe in the wallet you are using, and what would you do to increase your confidence if you were going to store all of your income in it?

Getting GOing

You are free to use any programming language and open source bitcoin libraries and openly-licensed code you want for this assignment, but must follow the license requirements of any code you use and credit this code in your submission.

The directions we provide use the BTC Suite library for bitcoin, implemented in the Go.

Most of you do not have any experience using Go, but it is not a difficult language to learn coming from experience with Java (which all of you have), and although its not my favorite programming language it is a language that nearly everyone finds enjoyable to use and it is becoming widely used in industry (especially at Google, where it was developed). The main reason we are using it for this, though, is because the BTC library is the best bitcoin library we are aware of, and it is written in Go.

If you are comfortable learning a new programming language by diving right into moderately complex programs and figuring out things as you go, you should be able to jump right into this assignment. If you prefer a more structured introduction to Go, there are many tutorials available, including the Tour of Go. The Go by Example site is very helpful. For more documentation, visit https://golang.org/doc/.

Obtain the Starting Code

Install Go. Start by downloading and installing Go. The latest version is go1.5, which is the version you should use.

Make sure to create a directory to contain your workspace and set the GOPATH environment variable to point to that location (these commands are for the Mac OS X shell and the bash shell on Linux):

$ mkdir go_workspace
$ export GOPATH=$Home/go_workspace

Install BTCD. Follow the directions to install btcd from btcsuite.

Setting up git. Before continuing with this assignment, you should set up git and your github account and follow the directions there to set up your private repository containing the starting code for ps1. (It may seem like overkill to use git for this assignment since you will not need to write much code or work with teammates on this one. But, it is good to get experience using git and will become necessary to work effectively with teammates for later projects.)

Once you have finished setting up your ps1 repository, it should contain the files:

keypair.go: code for generating a bitcoin key pair (including its public address).
spend.go: code for generating a bitcoin transaction.

Elliptic Curve Cryptography

The btcsuite library includes, btcec, an implementation of the ECDSA digital signatures algorithm using the secp256k1 elliptic curve used by bitcoin.

Examine the btcec.go code. For example, you should be able to find the y² = x³ + 7 curve in this code.

Elliptic curves for cryptography needs really big numbers. The modulus for the secp256k1 curve is found on line 929:

 secp256k1.P = fromHex("FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F")

This should be the value 2²⁵⁶ - 2³² - 2⁹ - 2⁸ - 2⁷ - 2⁶ - 2⁴ - 1.

Problem 4. Verify that the modulus used as secp256k1.P in btcec.go is correct. You can do this either using math/big, Go’s bit integer library to do computations on such large numbers, or by computing it by hand. (For your answer, just show how you verified the modulus. Including a snippet of code is fine.)

Generating a Key Pair

We have provided code in keypair.go that generates a bitcoin key pair. You can try running this by running go run keypair.go (or you can compile it with go build keypair.go and then run the resulting executable keypair). It will print out the generated private key and corresponding public bitcoin address. (Try running it a few times to see that it produces a different key pair each time.)

Keys for ECDSC are generated by choosing a random private key, k, and finding the corresponding public key by “multiplying” it by G, the generator point. (Multiplication here is not standard multiplication, but multiplication on the elliptic curve, as discussed in Class 3.) The point G is defined by lines 912-3):

secp256k1.Gx = fromHex("79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798")
secp256k1.Gy = fromHex("483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8")

The resulting point is the public key. It is easy to derive the public key from the private key, but believed to be hard to learn anything useful about the private key from the public key. The belief that it is hard to reverse the elliptic curve multiplication is based on the assumption that it is hard to compute discrete logarithms, which is not proven, but underlies much of modern cryptography.

The code for generating a new keypair is in keypair.go:

func generateKeyPair() (*btcec.PublicKey, *btcec.PrivateKey) {
   priv, err := btcec.NewPrivateKey(btcec.S256())
   if err != nil {
       // There was an error. Log it and bail out
       log.Fatal(err)
   }
   return priv.PubKey(), priv
}

The important work is done by the NewPrivateKey function.

Problem 5. What are all the things you need to trust if you are going to send money to the key generated by running keypair.go? You should assume that you are an ultra-paranoid multi-billionaire who intends to transfer her entire fortune to the generated address.

Generating a Vanity Address

Anyone can have a bitcoin address like 1H7tu2qUAyyr5aX1WA17eyvbetAGyqxfKZ or 1L3iGYBD5wbiki2SYUT5wmupy4TTgmEBg3, but suppose you want a bitcoin address that includes the name of your cat or your birthday.

Problem 6. Define a function,

func
generateVanityAddress(pattern string) (*btcec.PublicKey,
*btcec.PrivateKey)

where pattern is a regular expression. It should return a valid key pair where the corresponding public address matches the pattern.

You should be able to use your function to generate an address that includes the digits of pi in sequence: generateVanityAddress("3.*1.*4.*1.*5.*9.*") or contains dave without any adjacent letters (generateVanityAddress("[0-9]dave[0-9]")) in its public bitcoin address. In deciding how vain you want to be for the next exercise, think about how the running time scales with the number of strings that match the target pattern.

Problem 7. Use your generateVanityAddress function to create your own vanity address. Its up to you to decide what to put in your vanity address, but it should be clear that your address is not a typical random one. If you are extra vain, create a address where your name appears at the beginning (after the initial 1). (Note that uppercase ‘O’ and ‘I’ and lowercase ‘l’ are not used in any address, so if your name includes these letters you will have to be creative.)

Problem 8. Is your vanity address more or less secure than the first address you generated?

There are on-line services that produce vanity addresses, like http://bitcoinvanitygen.com/. You should contemplate briefly whether using such a site is more vain or stupid.

Bitcoin Transactions

Having an address is not much fun without any funds!

You should have received some money to the address you submitted in PS0. For these questions, you will need to have actual money to transfer, so be careful to make small transfers for these questions in case something goes wrong. (In the event that you do lose all of your bitcoin, you can get a new transfer to an adress of your choosing by explaining to me what you have learned about software development and or best practices. It is not necessary to buy your own bitcoin, even if you lose all of the original transfer.)

Problem 9. Make a small (e.g., 1 mBTC) transfer from your wallet address to your vanity address. You can do this using your MultiBit wallet. Find the transaction in the blockchain (you can do this by searching for your vanity address at insight.bitpay.com or blockchain.info). You will need the transaction ID for the next exercise. (For your answer, just provide the transaction ID.)

Once you have located the transaction that sends bitcoin to your vanity address you should notice several things.

Your wallet most likely send bitcoins to your address and back to a new address. We call this second address the ‘change’ address. Notice that each output has an ordered position. This index (known as the vout) along with the transaction ID lets us uniquely identify transaction outputs. This is important if you want to use those outputs in a new transaction.

Problem 10. Transfer some bitcoin from your vanity address to someone else in the class (you can use one of the addresses you identified in Problem 2). To do this you can run spend.go in ps1. You can provide the parameters needed for the transaction at the command line (it is not necessary to modify the code).

If done correctly the script should look this when executed:

> go run spend.go \
      -privkey "f3942c1e1...87" \
      -toaddress "19WmbY4nDcjAEv6wb5rcd5E6MutVMXBZzy" \
      -txid "9070329c2850d9b1dadeaa8683039b273beb58a27812172e31e397cf19fd5ca0" \
      -vout 0
Here is your raw bitcoin transaction:
0100000001a05cfd19cf97e3312e171278a258eb3b279b038386aadedab1d950289c327090000000006a47304402201d2fd4818cf4f4faa8\
4bbd407e5477c2a3722b137339460ff99c7255ad63bcc802201d991cad02e62d24fb4db2527a456159e069567116a325ee09186061395839\
e901210324594ad7124d0812e060200b66cc5199142e9adc42b0cd0c40f457eac4005d5dffffffff01f78a0100000000001976a9145d624b\
a9f2c55817af8b819ed4aaae55a36e256288ac00000000
The sending api responded with:
{"txid":"e5f4cb8e3736cab91ff4eb889bc8af659f1d8d398b3f934c8d63871b495d9065"}

I’ve left out most of my private key, since posting your private key on the web is not a very smart thing to do!

Notice that when the command above is run with these parameters it only works once. If you try to run it again you should get an API error since the input transaction has already been spent.

Problem 11. The provided spend.go code sends the full amount of the input transaction (less the network fee) to the destination address. Modify the program to add an

-amount
   <value>

flag that takes the amount to transfer in satoshi. If the amount available in the specified transaction output (less the network fee) exceeds the amount to send, your program should print an error message. Otherwise, it should send the requested amount to the toaddress, and send the change back to your address.

Try using your modified spending code to send a small amount to another address, and do another transaction to check that the change you receive back is still spendable.

Problem 12. (Bonus) Try to double spend the same bitcoin. Figure out as much as you can about what happens when the double spend transactions are attempted. See if you can get a transaction to appear on the list of double spends. See how close you can get to obtaining two verified transactions spending the same coin (e.g., can you achieve two transactions with at least one confirmation each?)

Please don’t try to actually rip anyone off; only attempt double spending with your own addresses (or those of willing classmates). You are not expected to actually be able to double-spend successfully (if this were easy, bitcoin would not work well as a currency!), but should be able to learn something by attemting to do this.

Submission

Follow the submission instructions at the beginning of this page by 8:29pm on Tuesday, 15 September.

Getting Started with Github

Tue, 20 Jan 2015 00:00:00 +0000

Getting Started with Github

For this course you will need to use github to manage your code and submit your assignments. Git is a widely used version control system originally developed by Linus Torvalds for use in managing development of the Linux operating system kernel. Github is company that provides free web-hosting for git repositories.

Follow the instructions below to get started using git and set up the repository you will use for this class (we’ll talk more about git in class, but this should be enough to get started):

Register for a student github account: https://github.com/edu

Note: you need to do this even if you already have a public github account, unless you have a paid account to support non-public repositories. With the student account, you will be able to have non-public repositories for free.

You will need to verify your email address (which must be a .edu address), and then go back to the https://github.com/edu page to fill in a form to request a student account. You should then receive a “Powerup get!” message from github, and be able to create private repositories with your account.
Set up git on the machine you will use for course assignments. Follow the instructions here: https://help.github.com/articles/set-up-git. Follow the instructions to download and install a git client for your OS (Mac, Windows).

Using git for CCC

For some of the assignments in this course, we will provide starting code in a git repository and you will need to use separate private repository for each assignment. (After the assignment is due, you can make this repository public, both to share it as you wish, and to free up another private repository since the number of private repositories you get with your free education account is limited.)

Typically, you need to fetch the code skeleton from the respective public repository of the course every time before you start working.

The general process of working on projects is to (we’ll go through each step in detail below):

Create a private repository on github.
Clone the repository, so you have a local working copy.
Get the code skeleton from the course repo, merge it into your working copy, and push to the main repository.
Edit code and text files in your local copy.
push the local changes to the main repository.

As you do the assignment, you should commit and push your changes regularly.

Setting up the Repository

Let’s take PS1 as an example. Here’s what you should do.

1. Create a new repository named ps1.

Visit https://github.com/repositories/new
Select “Private” for the type of repository. (If you got a student discount correctly, this should be available for free. If it asks you for a credit card, go back to step 1 of setting up github.)
Keep the “Initialize this repository with a README” unchecked, since you will fetch it later from a public repository.

2. Clone the empty private repository to your working environment. Instead of mygithubname below, use your github username.

:::text
git clone https://github.com/mygithubname/ps1.git

If you haven’t set up SSH keys for github, you’ll need to enter your github username and password.

3. Fetch the code skeleton from the course repository to your private repository. Enter the working directory of your empty repository and add a remote repository named starting, merge the code, and push it to your private repository by executing:

:::text
git remote add starting git@github.com:CryptoCurrencyCabal/ps1.git
git pull starting master
git push --tags origin master

Working with Files

Now you can write your own code in editor and save it to files. You can see what files have changed by running: git status. You should see something like this:

:::text
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   break_daves_key.go

In this example, nothing has been added to commit but untracked files are present.

To add the files to the main repository:

:::text
git add break_daves_key.go

You should try running git status again to see the files that will be committed. Note that add stages the file in its current state! If you modify the file after the add, the version of the file when you did the add is the version that will be committed.

Then,

:::text
git commit

commits the staged files to the main repository. This will launch and editor for you to enter a commit message. You can use -m to provide a message at the command line instead:

:::text
git commit -m 'I am no longer afraid of commitment!'

Your actual commit messages you use should be clear and useful. It is tempting to use lazy commit message, but you will regret this as your projects get more complex and code breaks in mysterious ways.

If you want to skip the two-stage commit, you can do:

:::text
git commit -a

to automatically add all new and changed files to the commit.

At this point, the changes are stored in your local repository, but not yet in the main repository. Once you have changes you want to push to the main repository:

:::text
git push

After this, all the changes are now pushed to the main repository at github. Visit your repository in github to see the result.

This seems like a lot of steps, but by providing a full local repository and making the steps of staging and pushing to the remote repository explicit, git provides developers with a lot of control over repositories that becomes very useful when several (or many) developers are working on the same project and trying to combine each others changes (or recover from mistakes).

There are many resources for learning more about git. The free book, Pro Git by Scott Chacon is recommended.

Classes

Mon, 01 Jan 0001 00:00:00 +0000

1: What is Money?
2: Cryptography
3: Signatures
4: Checkup 1
5: Becoming Paranoid
6: Hash Functions
7: The Blockchain
8: Mining
9: Mining Economics (and Checkup 2)
10: Subverting Bitcoin
11: More Mining
12: Script
13: Law and Policy (Tom Dukes visit)
14: Crime (FBI visit)
15: Scripting Transactions
16: Midterm
17: Business (Josh Cincinatti visit)
18: Confirmations
19: Anonymity
20: Hidden Services
21: Scaling Bitcoin (Alex Kuck and Nick Skelsey visit)
22: Zero Knowledge Proofs
23: Before Bitcoin (Digicash)
24: Altcoins
25: Project Proposal Presentations
26: Jeopardy!
27: Project Presentations 1
28: Project Presentations 2

Classes

Mon, 01 Jan 0001 00:00:00 +0000

Registration

Wed, 26 Aug 2015 00:00:00 +0000

Course Registration

Due: 8:29pm on Saturday, 29 August

To register for the course, you need to setup a bitcoin wallet (so don’t wait until the last minute to do this).

MultiBit HD is a good choice for this. See https://bitcoin.org/en/choose-your-wallet for information on bitcoin wallets. Be aware that you probably do not have time to download the full blockchain before this assignment is due, so need to use a lightweight wallet (we will learn what this means later in the class).

After creating a wallet, you should find the Recieving Address which you will need for one of the questions. If you used MultiBit HD, you will see this by clicking “Request” (to request payment), and copy the “Recipient Address”. It should be a string like, 19WmbY4nDcjAEv6wb5rcd5E6MutVMXBZzy. Note that your wallet may create several recipient addresses, so you won’t see the same address each time you do this.

It is not necessary now, or at any time during this class, for you to actually buy bitcoins with your own money. If you are inclined to do this, be careful, and don’t use any funds you cannot afford to lose!

Submit the form below (also avaible as direct link):

Syllabus

Sat, 22 Aug 2015 00:00:00 +0000

Syllabus

Meetings: Mondays and Wednesdays, 2:00-3:15pm in Olsson 120.

Teachers: David Evans and Samee Zahur
Assistant: Ori Shimony

Office Hours: Mondays 5-6:30pm (Ori, Rice 442); Wednesdays 3:15-4:30pm (Samee, Rice 442); Thursdays 2:30-3:30pm (Dave, Rice 507). Office hours will be updated on the course calendar.

Course Site: http://bitcoin-class.org/

Readings: We will not follow a textbook closely, but will have several readings from two books (both of which are freely available):

Andreas M. Antonopoulos, Mastering Bitcoin: Unlocking Digital Cryptocurrencies. (You can use the free version of the book available at https://github.com/aantonop/bitcoinbook, but would probably benefit from buying the printed version).
Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, Steven Goldfeder. Bitcoin and Cryptocurrency Technologies.

In addition to those books, we will have several readings from both general audience publications, technical documents, and research papers.

Overview

For the past 10,000 years, humans have been seeking better ways to store and transfer value. Cryptocurrencies (most notably bitcoin), provide a way to do this using bits alone without any centralized authority. In this course, we will learn about the cryptographic foundations for cryptocurrencies; networking, software, hardware, and security issues relevant to designing and implementing a cryptocurrency, and consider the economic, legal, and political issues raised by cryptocurrencies.

Expected Background

Students entering this course are expected to be comfortable reading, designing, and writing complex programs that involve thousands of lines of code distributed over many modules. You should be fairly comfortable with math, at least enough to analyze probabilities.

You should be comfortable learning how to use a new programming language features and APIs by reading their documentation (or source code when no documentation is available), and not be surprised when you are expected to learn a new language on your own or to seek documentation beyond what was provided in class.

Students are not expected to have significant previous experience with cryptography (although such background will certainly be helpful).

Some specific things we expect of students entering this course:

You should have some experience programming in at least one programming language, and not be afraid of needing to learn new languages.
You have written at least one program with over 1000 lines of code.
You should understand basic probability and be able to figure out things like the probability that 100 tosses of a fair coin do not result in any tails.
You should understand at least as much about complexity and computability as is covered in Dori-Mic and the Universal Machine.
You should find computing exciting and delighting, and believe you can use computing to make the world a better place.

If you do not satisfy any of these expectations, that doesn’t mean you cannot take the class, but you need to let one of the course teachers know about it at the beginning of the semester.

Honor Pledge

This course focuses on how to establish trust among distrusting people using mathematics, computing, and networking. As a student at Mr. Jefferson’s University, you are intrinsically trusted.

We take advantage of this trust to provide a better learning environment for everyone. In particular, students in this class are expected to follow these rules:

I will not lie, cheat or steal. If I am unsure whether something would be considered lying, cheating or stealing, I will ask before doing it.
I will carefully read and follow the collaboration policy on each assignment. I will not abuse resources, including any submissions or solutions for assignments from last semester’s version of this course, that would be clearly detrimental to my own learning.

In addition to the honor rules, students in this class are also expected to follow these behaviors:

I will do what I can to help my fellow classmates learn. Except when specifically instructed not to, this means when other students ask me for help, I will attempt to provide it. I will look at their answers and discuss what I think is good or bad about their answers. I will help others improve their work, but will not give them my answers directly. I will try to teach them what they need to know to discover solutions themselves.
I will ask for help. I will make a reasonable effort to do things on my own first (or with my partners for group assignment), but will ask my classmates or the course staff for help before getting overly frustrated. There are many ways to ask for help including the course website and office hours.
I grant the course staff permission to reproduce and distribute excerpts from my submissions for teaching purposes. If may opt-out of this by adding a comment to your code, but without an explicit opt-out comment we assume you agree to it. Excerpts will be used anonymously when illustrating a misunderstanding or common problem, and with credit when showing an interesting or exemplary answer.
I will not invest money I cannot afford to lose in cryptocurrencies. The main topic of this course is cryptocurrencies, and students will be encouraged to gain experience using bitcoin to conduct real transactions (but will not be expected to spend any personal money on bitcoin). Please be aware that bitcoin is very volatile, and that you could lose all the money in your bitcoin wallet if you make a programming error or lose your key. It would be foolish and reckless to convert any money you would be upset about losing into a cryptocurrency.
I will provide useful feedback. I realize that this is a new and experimental course, and it is important that I let the course staff know what they need to improve the course. I will not wait until the end of the course to make the course staff aware of any problems. I will provide feedback either anonymously or by contacting the course staff directly. I will fill out all requested surveys honestly and thoroughly.

Assignments

The course will have one midterm, three problem sets, one final project, and a (discretionary) final exam. In addition, there will be several check-ups (short tests in class, with opportunities to revise and improve answers after discussion) and short assignments that may involve reading assignments and posting answers and questions on the course website.

Exams. The midterm is Wednesday, 21 October. The final exam is scheduled for Friday, 11 December (2-5pm). This time will be used to schedule short oral exams for students who have not already demonstrated strong understanding of the course topics.

Problem Sets. The problem sets will involve writing programs and solving problems to understand transactions in bitcoin (Problem Set 1), bitcoin nodes and mining (Problem Set 2), blockchain analysis (Problem Set 3). For some assignments, you will be encouraged to work with one or two other people in a small team.

Final Project. For the final project, you are free to work on anything relevant to cryptocurrencies. Some suggestions for project ideas will be posted on the course website. Students who have ambitious ideas for a project may be able to arrange with the course staff to expand the project to substitute for other assignments (such as Problem Set 3).

Schedule

A tenative and (continually) updated schedule is available as a Google calendar. (You can view this calendar on the course site, or incorporate in as iCal calendar into your own calendar using this link. Except when noted otherwise, assignments are due at 8:29pm on the due date.

The main expected due dates: (updated 28 October 2015, see archived version for original)

Saturday, 29 August: Registration
Monday, 7 September: Checkup 1 (in class)
Tuesday, 15 September: Problem Set 1: Bitcoin Transactions
Wednesday, 23 September: Checkup 2 (in class)
Friday, 9 October: Problem Set 2: Blockchain
Wednesday, 21 October: Midterm Exam
Sunday, 8 November: Problem Set 3: Blockchain Analysis
Friday, 13 November: Project Pre-Proposal
Monday, 23 November: Project Update
Monday, 7 December: Last class
Friday, 11 December: Final Exam (discretionary)

Dates shown here are subject to change based on how the semester progresses, but with ample warning.

Grading

We prefer to spend our time focused as much as possible on teaching, and as little as possible on grading. The assignments in this class are designed to maximize learning, rather than primarily for assessment.

That said, we understand that students do need to be assigned grades at the end of the semester, and sometimes grades can be a powerful and effective motivator as well as a useful way to measure progress and understanding.

Grades will be determined based on your performance on all the class assignments and class contributions (including postings on the course site). Some assignments may be graded by randomly looking at selected answers, rather than reading everything submitted.

There is no set weighting among these things, and in general, if there is some combination of the above that demonstrates that you have gotten what we hope out of the class then you will receive an A grade.

Final Project Reports

Wed, 16 Dec 2015 00:00:00 +0000

The final project reports and sites are now posted: Project Reports

Thanks to everyone for your contributions to the class!
Enjoy winter break.

Class 28: Project Presentations 2

Mon, 07 Dec 2015 00:00:00 +0000

The Evolution of Bitcoin Script Interpreter (Acacia Dai)
A Bandwidth Based “Proof of Work” (Alishan Hassan)
Bitcoin at Point of Sale (Elizabeth Kukla)
Vending on Dark Net Markets (Collin Berman)
Donation Accountability (Kienan Adams)
Understanding Mobile Bitcoin Wallet (Ziqi Liu)
BitSniffer: a Tool for Linkability Analysis (Ryan Anderson, Sam Prestwood, Luke Gessler)
Taking Down Silk Road (Gardner Fiveash)
How Much is Bitcoin Worth: Pricing Differences Across Exchanges and Time (Quentin Moore)
Analysis of the viability of Bitcoin replacing as a National Currency (Peter Leng)
Evaluating BlockCypher’s Confidence Level (Dean Makovsky and Joseph Tobin and Kevin Zhao and Vignesh Kuppusamy)

Class 27: Project Presentations 1

Wed, 02 Dec 2015 00:00:00 +0000

Developing a Distributed Distributed Consensus Protocol Consensus Protocol (Alec Grieser)
Blockchain Voting (Sugat Poudel, Austin J. Varshneya, Xhama Vyas)
BitMingle (Carter Hall, Reid Bixler)
Beyond the Lightning Network - Exploring How to Scale Bitcoin (Muthu Chidambaram)
Mixing with Miners (Morgan Locks)
Pruning Nodes (Cyrus Malekpour)
Bitcoin Block-size Options (Michael Parisi Presicce)
Bitcoin Controversy and Conflicts of Interest (Jacob Freck)
Detecting Selfish Mining in Bitcoin and Litecoin (Fangyang Cui)
Geopolitical Strategy and Bitcoin (Eashan Kaw)

Class 26: Cryptocurrency Jeopardy

Mon, 30 Nov 2015 00:00:00 +0000

Schedule

Wednesday, 2 Dec and Monday 7 Dec: Final Project Presentations. See Class 25 for schedule.

These people are scheduled to present Wednesday: Alec Grieser, (Sugat Poudel, Austin J. Varshneya, Xhama Vyas), (Carter Hall, Reid Bixler), Muthu Chidambaram, Morgan Locks, Cyrus Malekpour, Michael Parisi Presicce, Jacob Freck, Fangyang Cui, Eashan Kaw, Cody Robertson.

Don’t forget to send the link to your presentation before 11:59am on the day you are presenting!

Office hours: normal office hours will continue until December 11: Mondays 5-6:30pm (Ori in Rice 442), Wednesdays after class (Samee in Rice 442), Thursdays 2:30-3:30 (Dave in Rice 507).

Friday, 4 December, 3:30pm in Rice 130: Department of Computer Science, Distinguished Alumni Seminar Series

Adrienne Felt, Staff Software Engineer, Google
Friday, 4 December 2015, 3:30pm in Rice Auditorium
(Reception after talk in Rice 4th Floor Atrium)

MAKING SECURITY USABLE (FOR A BILLION USERS)

How do you know if a website is “safe”? The security community puts enormous effort into detecting malware, stopping the next Heartbleed, and sandboxing bad content. Google Chrome’s usable security team sits at the front end of this work: we build the UI that tells end users what’s going on with their privacy and security. What you see as a single icon might be the end product of months of work by engineers, designers, security experts, and user researchers. I’ll explain some of the engineering and design challenges that we face, and give insight into the day-by-day work done by a security team that serves more than a billion browser users.

Bio: Adrienne Porter Felt leads Google Chrome’s usable security team, whose goal is to help people make safe decisions while using Chrome. Along with her team, Dr. Felt is responsible for building and improving the security warnings, indicators, and settings that you see in Chrome today. Previously, Dr. Felt was a research scientist on Google’s security research team, where she examined how browser users react to security warnings. She received a PhD in computer science from UC Berkeley, and a BS from the University of Virginia in 2008.

Monday, 7 December (11:59pm): Project Final Reports. See Class 25 for details.

Slides

The slides below include all the Jeopardy questions, even ones we didn’t get to in class. You shouldn’t expect to get asked trivia questions in the oral final exam (and will not be asked to phrase your answers in the form of a question!), but some of the substantive questions here would make good questions to ask during the exam (in particular, I’d recommend looking at the unused questions in Unlocking Script and Crypto Curves as good potential exam questions).

Download slides (with annotations)

Class 25: Project Pitches

Mon, 23 Nov 2015 00:00:00 +0000

Schedule

Today! (8:29 pm): Project Progress Reports due (see Class 23.)

Wednesday, 2 Dec and Monday 7 Dec: Final Project Presentations (see below).

Monday, 7 December (11:59pm): Project Final Reports (see below)

Today’s Presentations

Understanding Mobile Bitcoin Wallet
Ziqi Liu

Visual Explorer for Addresses and their Relations
Ryan Anderson, Sam Prestwood, Luke Gessler

How Much is Bitcoin Worth: Pricing Differences Across Exchanges and Time
Quentin Moore

Analysis of the viability of Bitcoin replacing as a National Currency
Peter Leng

Beyond the Lightning Network - Exploring How to Scale Bitcoin
Muthu Chidambaram

Mixing with Miners
Morgan Locks

Bitcoin Block-size Options
Michael Parisi Presicce

Bitcoin Controversy and Conflicts of Interest
Jacob Freck

Understanding Takedowns
Gardner Fiveash

Detecting Selfish Mining in Bitcoin and Litecoin
Fangyang Cui

Geopolitical Strategy and Bitcoin
Eashan Kaw

Evaluating BlockCypher’s Confidence Level
Dean Makovsky and Joseph Tobin and Kevin Zhao and Vignesh Kuppusamy

Pruning Nodes
Cyrus Malekpour

Divergence of Alt Coins and their Concurrent Developments
Cody Robertson

A Bandwidth Based “Proof of Work”
Alishan Hassan

Developing a Distributed Distributed Consensus Protocol Consensus Protocol
Alec Grieser

The Evolution of Bitcoin Script Interpreter
Acacia Dai

Project Final Presentations

The final project presentations will be in class on Wednesday, 2 December and Monday, 7 December. The presentation will count for approximately 50% of the grade for your final project.

The schedule of the presentations is below. Each team will have 5 + (N - 1) minutes to present your project (where N is the number of team members; so a 4-person team will have 8 minutes). Your presentation should be well prepared and enthusiastically delivered!

You should send a link to your presentation (PDF, PowerPoint, or anything that works in Firefox browser) to ccc-staff before 11:59am on the day you are scheduled to present. If your presentation includes a demo that’s great, but it needs to be designed in a way that can be set up quickly and used effectively.

Wednesday, 2 December:
Developing a Distributed Distributed Consensus Protocol Consensus Protocol (Alec Grieser)
Blockchain Voting (Sugat Poudel, Austin J. Varshneya, Xhama Vyas)
Distributed Bitcoin Mixing with Interest (Carter Hall, Reid Bixler)
Beyond the Lightning Network - Exploring How to Scale Bitcoin (Muthu Chidambaram)
Mixing with Miners (Morgan Locks)
Pruning Nodes (Cyrus Malekpour)
Bitcoin Block-size Options (Michael Parisi Presicce)
Bitcoin Controversy and Conflicts of Interest (Jacob Freck)
Detecting Selfish Mining in Bitcoin and Litecoin (Fangyang Cui)
Geopolitical Strategy and Bitcoin (Eashan Kaw)
Divergence of Alt Coins and their Concurrent Developments (Cody Robertson)

Monday, 7 December:
The Evolution of Bitcoin Script Interpreter (Acacia Dai)
A Bandwidth Based “Proof of Work” (Alishan Hassan)
Bitcoin at Point of Sale (Elizabeth Kukla)
Vending on Dark Net Markets (Collin Berman)
Analyzing the Feasibility of a Donation Accountability System in Bitcoin (Kienan Adams)
Understanding Mobile Bitcoin Wallet (Ziqi Liu)
Visual Explorer for Addresses and their Relations (Ryan Anderson, Sam Prestwood, Luke Gessler)
Understanding Takedowns (Gardner Fiveash)
How Much is Bitcoin Worth: Pricing Differences Across Exchanges and Time (Quentin Moore)
Analysis of the viability of Bitcoin replacing as a National Currency (Peter Leng)
Evaluating BlockCypher’s Confidence Level (Dean Makovsky and Joseph Tobin and Kevin Zhao and Vignesh Kuppusamy)

Project Final Reports

To submit your final report, send an email to ccc-staff@cs.virginia.edu with subject line Project Report: Title and cc-ing all of your team members. The official deadline for the final reports is Monday, 7 December (11:59pm), but extensions will be granted upon request so long as extending the deadline for this does not interfere problematically with your other courses and responsibilities.

The email should be plaintext containing:

A title for your project (this is the title I will use on the public page listing all the projects; add a * if it is different from the title currently listed on Project).
A one-sentence description of your project. This should be a clear, well-written sentence that will be enough for someone to understand what you did and why.
A URL that points to a publicly-viewable web page that describes your project. The linked page can (and probably should) contain links to other pages (e.g., a website that is your actual project or a github repo with your project code). For example, the link you send could be a link to http://my-project-site.org/about.html or https://github.com/your-repo/README.md, which is a page describing your project, as well as containing links to the main project site. Please try to put your project site somewhere that will not expire when you graduate from UVa, but that can survive forever.
Your project report, either as a PDF attachment, or a URL. Your project report should be a well-written and readable paper about your project. For most projects, this should include at least: (1) the motivation for your project, (2) background, including a description of related work (with references), (3) explanation of what you did, and (4) your results. For projects that do not involve building something, it may make more sense for it to be a more integrated report.

Discretionary Final Exams

By the end of this week, everyone should receive an email with your status in the class (including feedback on PS3).

The main message of this email will be guidance as to whether or not you should schedule a final exam. The main options are:

You’re well positioned to get an A in the class. So long as you do a decent job on the project, you’ll get an A and don’t need to do the final exam.
You are approaching what you need to do to convince us you deserve an A in the class, but need do more. If your project is outstanding, that may be enough to make the case. If not, you’ll have a last chance to do so by doing a final exam.
From what you’ve done so far, we’re not convinced you understand cryptocurrencies well enough to earn an A in the class. You should plan on doing a final exam to convince us otherwise!

For students receving options 1 or 2, we’ll try to give feedback on your final projects are quickly as possible so you know whether or not a final exam will be recommended.

The final exam will be an oral exam where you will explain how bitcoin works, and then answer a few follow-up questions. These will be scheduled during the scheduled final exam time (Friday, 11 December 2-5pm) and other times.

Cryptocurrency Cabal

Project Reports

Projects

Projects

Projects

PS3: CSI: Blockchain

Problem Set 3: CSI: Blockchain

Purpose

Collaboration Policy

Submission

Warm-Up: Manual Exploration

Privacy in the Blockchain

Blockchain APIs

Setting up BlockCypher API

Mixing Services

Follow the Ransomware Money

Submission

PS2: The Blockchain

Problem Set 2: The Blockchain

Purpose

Collaboration Policy

Submission

Blockchain Consensus

Merkle Trees and Storage

Blockchain

Pool Hopping

Bonus Opportunities

Submission

PS1: Bitcoin Transactions

Problem Set 1: Bitcoin Transactions

Purpose

Collaboration Policy

Submission

Blockchain Sleuthing

Getting GOing

Obtain the Starting Code

Elliptic Curve Cryptography

Generating a Key Pair

Generating a Vanity Address

Bitcoin Transactions

Submission

Getting Started with Github

Getting Started with Github

Using git for CCC

Setting up the Repository

Working with Files

Classes

Classes

Registration

Course Registration

Syllabus

Syllabus

Overview

Expected Background

Honor Pledge

Assignments

Schedule

Grading

Final Project Reports

Class 28: Project Presentations 2

Class 27: Project Presentations 1

Class 26: Cryptocurrency Jeopardy

Schedule

Slides

Class 25: Project Pitches

Schedule

Today’s Presentations

Project Final Presentations

Project Final Reports

Discretionary Final Exams

Problem Set 3:
CSI: Blockchain

Problem Set 2:
The Blockchain