This is a preview of how your content will look on export. To export the complete content in DOC format, click the blue export button in the upper right corner of this page.
Reading Group: Regulating the "blockchain"
This is a reading group to discuss the application of law and regulation to cryptocurrency and distributed ledger technology.
  • 1 What was Bitcoin, what will it be? The techno-economic imaginaries of a new money technology

    What was Bitcoin, what will it be? The techno-economic imaginaries of a new money technology

  • 2 Bitcoin's Academic Pedigree

    Bitcoin's Academic Pedigree

  • 3 Is Blockchain Different than Bitcoin?

    Richard Gendal Brown, Chief Technology Officer at R3 CEV, discusses different types of blockchain innovation.

  • 4 Mastering Bitcoin - Chapter 2

    Mastering Bitcoin is a book for developers, but the first two chapters cover bitcoin at a level that is approachable to non-programmers. Anyone with a basic understanding of technology can read the first two chapters and get a great understanding of bitcoin.

  • 5 IRS Virtual Currency Guidance: Virtual Currency Is Treated as Property for U.S. Federal Tax Purposes; General Rules for Property Transactions Apply

    This notice describes how existing general tax principles apply to transactions using virtual currency. The notice provides this guidance in the form of answers to frequently asked questions.

  • 6 When (and If) Income is Realized from Bitcoin Chain-Splits

    While income can be realized from a chain-split, it need not be realized at the time of the chain-split, or, possibly, ever, for federal income tax purposes.

  • 7 Ethereum Design Rationale - Accounts and not UTXOs

    Ethereum Design Rationale – Accounts and not UTXOs

    Blockchain-level protocol

    This section provides a description of some of the blockchain-level protocol changes made in Ethereum, including how blocks and transactions work, how data is serialized and stored, and the mechanisms behind accounts.

    Accounts and not UTXOs

    Bitcoin, along with many of its derivatives, stores data about users' balances in a structure based on unspent transaction outputs (UTXOs): the entire state of the system consists of a set of "unspent outputs" (think, "coins"), such that each coin has an owner and a value, and a transaction spends one or more coins and creates one or more new coins, subject to the validity constraints:

    1. Every referenced input must be valid and not yet spent
    2. The transaction must have a signature matching the owner of the input for every input
    3. The total value of the inputs must equal or exceed the total value of the outputs

    A user's "balance" in the system is thus the total value of the set of coins for which the user has a private key capable of producing a valid signature.

    (Image from

    Ethereum jettisons this scheme in favor of a simpler approach: the state stores a list of accounts where each account has a balance, as well as Ethereum-specific data (code and internal storage), and a transaction is valid if the sending account has enough balance to pay for it, in which case the sending account is debited and the receiving account is credited with the value. If the receiving account has code, the code runs, and internal storage may also be changed, or the code may even create additional messages to other accounts which lead to further debits and credits.

    The benefits of UTXOs are:

    1. Higher degree of privacy: if a user uses a new address for each transaction that they receive then it will often be difficult to link accounts to each other. This applies greatly to currency, but less to arbitrary dapps, as arbitrary dapps often necessarily involve keeping track of complex bundled state of users and there may not exist such an easy user state partitioning scheme as in currency.
    2. Potential scalability paradigms: UTXOs are more theoretically compatible with certain kinds of scalability paradigms, as we can rely on only the owner of some coins maintaining a Merkle proof of ownership, and even if everyone including the owner decides to forget that data then only the owner is harmed. In an account paradigm, everyone losing the portion of a Merkle tree corresponding to an account would make it impossible to process messages that affect that account at all in any way, including sending to it. However, non-UTXO-dependent scalability paradigms do exist.

    The benefits of accounts are:

    1. Large space savings: for example, if an account has 5 UTXO, then switching from a UTXO model to an account model would reduce the space requirements from (20 + 32 + 8) * 5 = 300 bytes (20 for the address, 32 for the txid and 8 for the value) to 20 + 8 + 2 = 30 bytes (20 for the address, 8 for the value, 2 for a nonce(see below)). In reality savings are not nearly this massive because accounts need to be stored in a Patricia tree (see below) but they are nevertheless large. Additionally, transactions can be smaller (eg. 100 bytes in Ethereum vs. 200-250 bytes in Bitcoin) because every transaction need only make one reference and one signature and produces one output.
    2. Greater fungibility: because there is no blockchain-level concept of the source of a specific set of coins, it becomes less practical, both technically and legally, to institute a redlist/blacklisting scheme and to draw a distinction between coins depending on where they come from.
    3. Simplicity: easier to code and understand, especially once more complex scripts become involved. Although it is possible to shoehorn arbitrary decentralized applications into a UTXO paradigm, essentially by giving scripts the ability to restrict what kinds of UTXO a given UTXO can be spent to, and requiring spends to include Merkle tree proofs of change-of-application-state-root that scripts evaluate, such a paradigm is much more complicated and ugly than just using accounts.
    4. Constant light client reference: light clients can at any point access all data related to an account by scanning down the state tree in a specific direction. In a UTXO paradigm, the references change with each transaction, a particularly burdensome problem for long-running dapps that try to use the above mentioned state-root-in-UTXO propagation mechanism.

    We have decided that, particularly because we are dealing with dapps containing arbitrary state and code, the benefits of accounts massively outweigh the alternatives. Additionally, in the spirit of the We Have No Features principle, we note that if people really do care about privacy then mixers and coinjoin can be built via signed-data-packet protocols inside of contracts.

    One weakness of the account paradigm is that in order to prevent replay attacks, every transaction must have a "nonce", such that the account keeps track of the nonces used and only accepts a transaction if its nonce is 1 after the last nonce used. This means that even no-longer-used accounts can never be pruned from the account state. A simple solution to this problem is to require transactions to contain a block number, making them un-replayable after some period of time, and reset nonces once every period. Miners or other users will need to "ping" unused accounts in order to delete them from the state, as it would be too expensive to do a full sweep as part of the blockchain protocol itself. We did not go with this mechanism only to speed up development for 1.0; 1.1 and beyond will likely use such a system.

  • 8 The UCC and Bitcoins: Solution to Existing Fatal Flaw

    Would you purchase a house if you had no information on mortgages encumbering it? Of course not; yet, that is analogous to what buyers of bitcoin are doing every day – purchasing without information about liens on their bitcoins. This article identifies (1) the fatal flaw in the current Bitcoin ecosystem created by Uniform Commercial Code (“UCC”) Article 9 (Secured Transactions) and (2) the solution presented by UCC Article 8 (Investment Securities).

  • 9 Negotiability, Property, and Identity

    Focus on Section III. “PROPERTY AND IDENTITY

  • 10 Does 18 U.S.C. § 1960 create felony liability for bitcoin businesses?

    Attorney Brian Klein explains how relatively recent changes to a federal law make it a felony to run an unlicensed bitcoin business whether you knew you needed a license or not.

  • 11 Bitcoin exchange operator tied to hacks gets 5-1/2 years U.S. prison

    Anthony Murgio, 33, of Tampa, pleaded guilty on Jan. 9 to three conspiracy counts, including bank fraud and operating an unlicensed money transmitting business. The sentence was roughly half as long as prosecutors had sought.

  • 12 FinCEN Virtual Currency Guidance

    The Financial Crimes Enforcement Network is issuing this interpretive guidance to clarify the applicability of the regulations implementing the Bank Secrecy Act to persons creating, obtaining, distributing, exchanging, accepting, or transmitting virtual currencies.

  • 13 Former CEO Of Bitcoin Exchange Company Sentenced

    Former CEO Of Bitcoin Exchange Company Sentenced

  • 14 Liberty Reserve Special Measure

  • 15 Ripple Labs Settlement Agreement

You've reached the bottom of your content preview.
To view the rest in your browser, click here.
To export the complete content in DOC format, click the blue export button in the upper right corner of this page.

(Note: If you view the entire playlist, any changes you've made to export settings will be lost. Large playlists may temporarily freeze your browser while loading, as well.)