-
Notifications
You must be signed in to change notification settings - Fork 1
/
tipuesearch_content.json
1 lines (1 loc) · 34.9 KB
/
tipuesearch_content.json
1
{"pages":[{"title":"Papers","text":"2016 Your Data Center Switch is Trying Too Hard Xin Jin, Nathan Farrington, and Jennifer Rexford ACM Symposium on SDN Research ( SOSR 2016), Santa Clara, California, March 14–15, 2016 ( PDF ) 2015 Invited Talk: Enabling Data Center SDN with Stateless Source Routing Nathan Farrington European Conference on Optical Communications ( ECOC 2015), Valencia, Spain, September 28–October 1, 2015 (Slides: PDF ) 2014 Invited Talk: The Dawn of Channelized Ethernet Nathan Farrington IEEE Sympoisum on High-Performance Interconnects (Hot Interconnects 22), Mountain View, California, USA , August 26-27, 2014 (Slides: PDF ) Building a data-center network with optimal performance and economy Daniel Tardent and Nathan Farrington Lightwave, July 10, 2014 ( HTML ) Invited Talk: 100GbE Lambda Switching for Data Center Networks Nathan Farrington OIDA 100GbE per Lambda for Data Center Workshop , San Jose, California, USA , June 12-13, 2014 (Slides: Keynote 6 ) The OIDA and the Ethernet Alliance organized a workshop to study 100 Gigabit Ethernet over a single wavelength, for the data center market. In my opinion, it is much too early to be worried about this. 2013 Integrating Microsecond Circuit Switching into the Data Center George Porter, Richard Strong, Nathan Farrington, Alex Forencich, Pang-Chen Sun, Tajana Rosing, Yeshaiahu Fainman, George Papen, and Amin Vahdat ACM SIGCOMM , Hong Kong, China, August 2013 ( PDF ) This is amazing stuff. You should read it. Invited Paper: Facebook's Data Center Network Architecture Nathan Farrington and Alexey Andreyev IEEE Optical Interconnects Conference , Santa Fe, New Mexico, May 7, 2013 ( PDF ) (Slides: Keynote ) (Slides: PDF ) Invited Paper: A 10 μs Hybrid Optical-Circuit/Electrical-Packet Network for Datacenters Nathan Farrington, Alex Forencich, Pang-Chen Sun, Shaya Fainman, Joe Ford, Amin Vahdat, George Porter, and George Papen OFC / NFOEC , Anaheim, California, March 2013 ( PDF ) Invited Talk: How to Make Optical Communication Products that Facebook Will Want to Buy Future Needs of \"Scale-Out\" Data Centers: An OIDA Workshop for Stakeholders Anaheim, California, March 2013 (Slides: PowerPoint ) 2012 Optics in Data Center Network Architecture Nathan Farrington Dissertation, UC San Diego, December, 2012 ( PDF ) Invited Talk at Microsoft Research Redmond, Washington, October 2012 Hunting Mice with Microsecond Circuit Switches Nathan Farrington, George Porter, Yeshaiahu Fainman, George Papen, and Amin Vahdat ACM HotNets , Redmond, WA , October 2012 ( PDF ) (Slides: Keynote ) (Slides: PDF ) (Slides: MOV ) ( BibTeX ) This paper proposes a new scheduling algorithm for fast, microsecond-scale data center circuit switches, called traffic matrix scheduling. An advantage of traffic matrix scheduling over the previous hotspot scheduling is that more traffic can be offloaded to the circuit-switched portion of the data center network, making circuit switches much more useful than previously thought. A Demonstration of Ultra-Low-Latency Datacenter Optical Circuit Switching Nathan Farrington, George Porter, Pang-chen Sun, Alex Forencich, Joseph Ford, Yeshaiahu Fainman, George Papen, and Amin Vahdat ACM SIGCOMM Demo , Helsinki, Finland, August 2012 ( PDF ) One weakness of the Helios paper is that the relatively long switching time of 30ms limited the usefulness of the resulting hybrid network. So we developed our own optical circuit switch that is 1,000x faster than Helios. We demonstrated our switch at the SIGCOMM conference. Invited Talk at Broadcom San Jose, California, May 2012 Invited Talk at Big Switch Networks Palo Alto, California, May 2012 2011 Hardware Requirements for Optical Circuit Switched Data Center Networks Nathan Farrington, Yeshaiahu Fainman, Hong Liu, George Papen, and Amin Vahdat OFC / NFOEC , Los Angeles, March 2011 ( PDF ) ( Slides ) ( BibTeX ) While working on the Helios project, we discovered that many of the optical communication devices commonly used in data center networks, such as electronic dispersion compensators ( EDC ) and transimpedence amplifiers ( TIA ), are not optimized for quickly recovering after a loss of light. However, we did find that such technology exists and future data center networks could be engineered for high performance when using optical circuit switches. 2010 Invited Talk at Amazon.com Seattle, Washington, November 2010 Helios: A Hybrid Electrical/Optical Switch Architecture for Modular Data Centers Nathan Farrington, George Porter, Sivasankar Radhakrishnan, Hamid Hajabdolali Bazzaz, Vikram Subramanya, Yeshaiahu Fainman, George Papen, and Amin Vahdat ACM SIGCOMM , New Delhi, India, August 2010 ( PDF ) ( Slides ) ( BibTeX ) Traditionally, local area networks, including data center networks, have been constructed using switched Ethernet. A typical 10G Ethernet switch uses 12.5W per port, and cost upwards of $500 per port or more. There is a cheaper source of bandwidth: optical circuit switching. This paper describes how we constructed a data center network using an optical circuit switch and what we had to do to achieve good performance. Scale-Out Networking in the Data Center Amin Vahdat, Mohammad Al-Fares, Nathan Farrington, Radhika Niranjan Mysore, George Porter, and Sivasankar Radhakrishnan IEEE Micro , July/August 2010 ( PDF ) ( BibTeX ) This is an overview paper of our recent work and a great place to start when learning about the field of data center networking. It covers: commoditization , merchant silicon , scaling Ethernet , and scheduling TCP flows . Invited Talk at HP Labs Palo Alto, California, March 2010 Report on WREN 2009 — Workshop: Research on Enterprise Networking Nathan Farrington, Nikhil Handigol, Christoph Mayer, Kok-Kiong Yap, and Jeffrey C. Mogul ACM SIGCOMM Computer Communication Review ( CCR ) , January 2010 ( PDF ) ( BibTeX ) This is a collection of paper summaries and transcriptions from the first WREN workshop. 2009 Data Center Switch Architecture in the Age of Merchant Silicon Nathan Farrington, Erik Rubow, and Amin Vahdat IEEE Symposium on High-Performance Interconnects , New York, August 2009 ( PDF ) ( Slides ) ( BibTeX ) One of the primary reasons for low server utilization in data centers is that the data center network is oversubscribed (underprovisioned). This is necessary due to the non-commodity (super-expensive) nature of current commercial data center switches. This paper describes how to construct a 3,456-port 10G Ethernet switch out of \"merchant silicon\", i.e. switch chips designed for low-end commodity Ethernet switches. It is likely that future data center networks will be constructed almost entirely from merchant silicon, just as modern data center servers contain commodity Intel or AMD processors. Scaling Data Center Switches Using Commodity Silicon and Optics Nathan Farrington, Erik Rubow, and Amin Vahdat ACM SIGCOMM Poster , Barcelona, Spain, August 2009 ( PDF ) A poster version of the Merchant Silicon paper. PortLand: A Scalable Fault-Tolerant Layer 2 Data Center Network Fabric Radhika Niranjan Mysore, Andreas Pamboris, Nathan Farrington, Nelson Huang, Pardis Miri, Sivasankar Radhakrishnan, Vikram Subramanya, and Amin Vahdat ACM SIGCOMM , Barcelona, Spain, August 2009 ( PDF ) ( BibTeX ) Both Layer 2 Ethernet forwarding (learning bridge, minimum spanning tree, broadcast) and Layer 3 IP routing (longest-prefix matching, routing protocols) have problems scaling to large numbers of servers in the data center. This paper describes a new forwarding mechanism called PortLand designed specifically for data centers with much better scaling properties than either traditional Layer 2 or Layer 3 forwarding. Now, at least from a network address viewpoint, it is possible to treat all hosts in a data center as interchangeable components. Additionally, a PortLand network will never contain a forwarding loop. Multipath TCP under MASSIVE Packet Reordering Nathan Farrington UC San Diego Tech Report, June 2009 ( PDF ) ( Slides ) This was my \"Research Exam\", an in-depth survey of a specific area leading to a Masters degree. I have always been fascinated by how simultaneously good and bad TCP is across a wide range of networks and communication patterns. One design feature of TCP is that duplicate acknowledgements are used as an early indicator of packet loss, and hence an early indicator of congestion. Unfortunately, packet reordering will cause the receiver to transmit duplicate acknowledgements, fooling the sender into thinking that the network in congested. This limits opportunities for parallelism in data center networks, which by design have multiple paths between hosts for both increased capacity and fault tolerance. This report looks at historical approaches for fixing TCP so that eventually we will be able to fully utilize multipath data center networks. 2005 Before going to grad school, I worked for the Navy as a robotics research engineer. Transitioning Unmanned Ground Vehicle Research Technologies Estrellina Pacis, H. R. Everett, Nathan Farrington, Greg Kogut, Brandon Sights, Ted Kramer, M. Thompson, David Bruemmer, Doug Few. SPIE Proc. 5804: Unmanned Ground Vehicle Technology VII , Orlando, FL , March 2005 2004 Intelligent behaviors for a convoy of indoor mobile robots operating in unknown environments Nathan Farrington, Hoa Nguyen, Narek Pezeshkian SPIE Proc. 5609: Mobile Robots XVII , Philadelphia, PA , October 2004 Towards a Warfighter's Associate: Eliminating the Operator Control Unit H. R. Everett, Estrellina Pacis, Greg Kogut, Nathan Farrington, S. Khurana. SPIE Proc. 5609: Mobile Robots XVII , Philadelphia, PA , October 2004 Segway Robotic Mobility Platform Hoa Nguyen, J. Morrell, K. Mullens, Aaron Burmeister, S. Miles, Nathan Farrington, K. Thomas, Doug Gage. SPIE Proc. 5609: Mobile Robots XVII , Philadelphia, PA , October 2004 A Segway RMP -based robotic transport system Hoa Nguyen, Greg Kogut, R. Barua, Aaron Burmeister, Narek Pezeshkian, D. Powell, Nathan Farrington, M. Wimmer, B. Cicchetto, C. Heng, V. Ramirez. SPIE Proc. 5609: Mobile Robots XVII , Philadelphia, PA , October 2004 Maintaining Communication Link for Tactical Ground Robots Hoa Nguyen, Nathan Farrington, Narek Pezeshkian. AUVSI Unmanned Systems North America, Anaheim, CA August 2004 Enhancing Functionality and Autonomy in Man-Portable Robots Estrellina Pacis, H. R. Everett, Nathan Farrington, David Bruemmer. SPIE Proc. 5422: Unmanned Ground Vehicle Technology VI , Orlando, FL , April 2004 Maintaining Communication Link for a Robot Operating in a Hazardous Environment Hoa Nguyen, Narek Pezeshkian, A. Gupta, Nathan Farrington. American Nuclear Society 10th Intl. Conf. on Robotics and Remote Systems for Hazardous Environments, Gainesville, FL , March 2004","tags":"uncategorized","url":"papers.html"},{"title":"Patents","text":"US Patent 9,668,037 Detector remodulator and optoelectronic switch Haydn Frederick Jones, Andrew George Rickman, Aaron Zilkie, Nathan Farrington ( PDF ) US Patent 9,438,970 Detector remodulator and optoelectronic switch Haydn Frederick Jones, Andrew George Rickman, Aaron Zilkie, Nathan Farrington ( PDF ) US Patent 9,417,396 Optoelectronic switch Andrew Rickman, Nathan Farrington ( PDF ) US Patent 8,842,688 Reducing cabling complexity in large-scale networks Amin Vahdat, Nathan Farrington ( PDF )","tags":"uncategorized","url":"patents.html"},{"title":"Bitcoin (2008)","text":"Abstract In this article, I review the original 2008 Bitcoin paper by Satoshi Nakamoto [1] . Jake Lerner from UC Berkeley has also published a review [2] . Commentary Bitcoin has recently been in the news because its price reached an all-time high of about 3,000 USD per coin. This was up from a 1-year low of about 570 USD per coin. Google Trends shows that the search term \"bitcoin\" also reached an all-time high, coinciding with the peak price. What is Bitcoin? Is it the digital equivalent of gold? According to bitcoin.org : Bitcoin is an innovative payment network and a new kind of money. So from this one-line definition, it would appear that the folks at bitcoin.org do in fact believe that Bitcoin is money. Is it commodity money? Fiat money? Or perhaps it is a new form of money? What about the innovative payment network and how does that fit in? Let's crack open the 2008 Bitcoin paper and see how Nakamoto originally presented Bitcoin to the world! Review The People Problem Nakamoto jumps right into the people problem: eCommerce currently requires both the buyer and the seller to trust some 3rd-party to process the electronic payment. Nakamoto argues that the involvement of a trusted 3rd-party leads to the following problems or limitations: seller is impacted because non-reversible transactions are not possible both buyer and seller are impacted because transaction costs are higher both buyer and seller are impacted because microtransactions are impractical buyer is impacted because seller requires more information about buyer than necessary seller is impacted because buyer fraud exists (reversing a transaction?) In addition to this list of problems and limitations, I would also add the following: both buyer and seller are impacted because trusted 3rd-party requires more information about buyer and seller than necessary While I do agree that these are real problems, I would argue that the world has done quite well with this model so far. Sellers would prefer to have non-reversible transactions, but due to competition, sellers would often wish to accept reversible forms of payment, such as credit cards. Transaction costs are not fun, but they are also not exorbitant. Compared with government taxes, transaction costs are almost negligible. It is true that microtransactions have yet to materialize in this model. However, it is possible to buy inexpensive items such as an iTunes song for 0.99 USD . From my observations, buyers and sellers are actually not concerned with disclosing information about themselves. And finally, fraud has not shutdown credit card companies, online auction sites such as eBay, or major online merchants such as Amazon.com. But let's keep reading, because even though the problems that Nakamoto identified may not be pressing, the existence of something like Bitcoin could open up new opportunities to create value for many people. The Technical Problem Technical Problem #1: Transferring Physical Money Removing the trusted 3rd-party would seem to require a world where the buyer could transfer physical money to the seller. But this is often impractical. First, for small amounts of money, the fixed shipping costs could be impractical. A current US postage stamp is 0.49 USD , which is about 50% of the cost of a 0.99 USD iTunes song. Second, the time taken for payment to reach the seller is often on the order of the time taken for the seller's product to reach the buyer. This means that if the seller were to wait until receiving payment, it would effectively double the total transaction time. This problem could be fixed by having both the buyer and the seller ship simultaneously, but that exposes the seller to the risk of buyer fraud. Third, sending actual physical money exposes the buyer to both the risk of theft in transit and the risk of seller fraud. The risk of theft in transit can be reduced by introducing another trusted 3rd-party, in this case USPS , by converting the buyer's money into a USPS money order. The risk of seller fraud can be reduced by choosing buyer-vetted sellers, which increases prices by reducing competition, and by limiting the maximum purchase to an amount that the buyer can afford to lose, which increases prices by incurring opportunity costs. From the previous paragraph, most may conclude that it is simply faster and safer to utilize trusted 3rd-parties for eCommerce. Technical Problem #2: Detecting Double Spending in Digital Money The first technical problem focused on a buyer transferring physical money directly to a seller. The second technical problem focuses on a buyer transferring digital money directly to a seller. What would this digital money look like and why doesn't it exist today (in 2008)? It is possible to create a digital coin (also called a digital token) by using public key cryptography. Here is the definition of a coin, as expressed in Python, using the description from the paper. 1 class Coin : 2 \"\"\"Example of a digital coin, as described in the paper. 3 4 NOTE: This is my own interpretation of the paper and most likely does 5 not correspond with Bitcoin or any other actual cryptocurrency. 6 \"\"\" 7 def __init__ ( self , first_owner_pubkey , first_owner_privkey ): 8 \"\"\"Create a new coin, using the public and private keys of the 9 original owner.\"\"\" 10 self . transactions = [{ 11 'owner_pubkey' : first_owner_pubkey 12 'signature' : first_owner_privkey . sign ( hash ( first_owner_pubkey )) 13 }] 14 def transfer ( self , new_owner_pubkey , current_owner_privkey ): 15 \"\"\"Transfer this coin to a new owner.\"\"\" 16 prev_transaction = self . transactions [ - 1 ] 17 self . transactions . append ({ 18 'owner_pubkey' : new_owner_pubkey 19 'signature' : current_owner_privkey . sign ( hash ( prev_transaction + prev_transaction . owner_pubkey )) 20 }) 21 def verify ( self ): 22 \"\"\"Verify that this coin has a valid chain of ownership.\"\"\" 23 prev_transaction = None 24 for transaction in self . transactions : 25 if prev_transaction is None : 26 prev_transaction = transaction 27 continue 28 prev_transaction . owner_pubkey . verify ( transaction . signature ) 29 prev_transaction = transaction A coin is a list of transactions, where each transaction represents the transfer of ownership of the coin to a new owner. Nakamoto uses the term transaction , but in this context, it may be better to use a term such as transference . Anyone can verify that the coin was transferred properly by walking the list of transactions from beginning to end, and verifying the signature stored in each transaction using the public key stored in the previous transaction. With this definition of a coin firmly established, Nakamoto explains the technical problem of double spending . Double spending occurs when an owner, Oscar, makes a copy of his coin, and transfers copy \"A\" to Alice and copy \"B\" to Bob (without telling Alice about Bob's coin and without telling Bob about Alice's coin). In order to prevent chaos, it is imperative that if double spending occurs, that it is at least detected. But the only way to ensure that double spending is detected is to observe all transactions across all coins in the economy. Nakamoto mentions that previous solutions have proposed a trusted 3rd-party to be the one to observe and sanction all transactions. But this proposed solution does not solve the original problem of seeking to avoid the use of trusted 3rd-parties. Proposed Solution The proposed solution to the problem of double spending is really the main contribution of this paper. In a nutshell, Nakamoto proposes holding all currency, and the transactions that record transfers of currency, in a public database called a distributed timestamp service . This new system solves the problem of double spending by making all transactions public. For example, Bob (and everyone) can see that Oscar \"double spent\" his coin because he previously transferred his coin to Alice. With such a distributed timestamp service available, Nakamoto notes For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The remainder of this section presents the proposed solution by following the paper outline. Timestamp Server First, Nakamoto defines a traditional timestamp service that takes a block of data as input and produces a timestamp as output. The timestamp proves that the block of data existed prior to the creation of the timestamp, but does not say when the block of data was actually created (in terms of real human time). In fact, the \"timestamp\" itself is the output of a hash function and does not correspond to real human time. But the timestamp can be associated with real human time by publishing the timestamp. Here is the definition of a timestamping service, as expressed in Python, using the description from the paper. 1 class TimestampService : 2 \"\"\"Example of a timestamp service, as described in the paper. 3 4 NOTE: This is my own implementation of a timestamp service and most 5 likely does not correspond with any actual timestamp service. 6 \"\"\" 7 def __init__ ( self ): 8 \"\"\"Create a new (empty) timestamp service.\"\"\" 9 self . blockchain = [] 10 self . hashchain = [] 11 def add_block ( self , block ): 12 \"\"\"Add a new block to the blockchain.\"\"\" 13 self . blockchain . append ( block ) 14 if len ( self . hashchain ) == 0 : 15 self . hashchain . append ( hash ( block )) 16 else : 17 self . hashchain . append ( self . hashchain [ - 1 ] + hash ( block )) 18 def get_timestamp ( self ): 19 \"\"\"Return the most recent hash from the hashchain.\"\"\" 20 if len ( self . hashchain ) == 0 : 21 return None 22 return self . hashchain [ - 1 ] So how does this timestamp service solve the double spending problem? In my opinion, Nakamoto is not so clear on this point. I could imagine that blocks could contain coins. By timestamping a block containing a coin, one is proving that Alice is the first recipient of a given coin, and not Bob. And from the previous section, it is enough to prove the first recipient in order to solve the double spending problem. So far, all is well. But wait! Who runs the timestamp service? This traditional solution does not work for our needs because it requires a trusted 3rd-party. Proof-of-Work What is proof-of-work? Sometimes one would like to control access to a shared resource to prevent abuse of that resource. Dwork and Naor (1992) [3] presented a scheme where if Alice wants to access a shared resource, she is required to \"pay\" for access by performing some busywork. Access to the resource is then contingent on Alice's ability to prove that she has in fact done this busywork. If Alice wishes to submit some message x to the shared resource, then the busywork takes the form of computing a moderately hard function y = f ( x ) . Alice then submits both the message and the proof-of-work together ( x , y ) . Principals agree not to accept messages without valid proofs-of-work. Bob can validate Alice's proof-of-work by computing y ' = f ( x ) and verifying that y = y ' . As an optimization, the moderately hard function f ( x ) can be chosen so that checking y is much faster than computing y . Nakamoto describes a particular proof-of-work function f ( x ) that involves searching for an input x where the hash of that input y = f ( x ) begins with a particular number k ≥ 1 of zero bits, which gets exponentially harder with k . In order to keep up with Moore's law over time, the parameter k is chosen (increased?) automatically so that a desired number of blocks are created each hour. Distributed Timestamp Service In my opinion, Nakamoto does not present this section of the paper very clearly. Nakamoto is describing the design of a distributed timestamp service where proof-of-work is required to timestamp a block, i.e., to add a block to the blockchain. The key is that all of the principals agree on how to verify that a block has been timestamped correctly. All principals possess a complete copy of the blockchain. Here is the definition of a distributed timestamping service, as expressed in Python, using the description from the paper. 1 class DistributedTimestampService : 2 \"\"\"Example of a distributed timestamp service, as described in the paper. 3 4 NOTE: This is my own implementation of a distributed timestamp service 5 and most likely does not correspond with any actual timestamp service. 6 \"\"\" 7 def __init__ ( self , k ): 8 \"\"\"Create a new (empty) distributed timestamp service.\"\"\" 9 self . k = k 10 self . blockchain = [] 11 def add_block ( self , block ): 12 \"\"\"Add a new block to the blockchain.\"\"\" 13 block . prev_hash = 0 14 if len ( self . blockchain ) > 0 : 15 block . prev_hash = hash ( self . blockchain [ - 1 ]) 16 block . N = 0 # start with random number? 17 while True : 18 block . N += 1 19 if bin ( hash ( block ))[ 2 : 2 + self . k ] == 0 : 20 self . blockchain . append ( block ) 21 break 22 def verify_block ( self , block ): 23 \"\"\"Return True if a given block should be added to the blockchain 24 and also add it to the blockchain.\"\"\" 25 prev_hash = 0 26 if len ( self . blockchain ) > 0 : 27 prev_hash = hash ( self . blockchain [ - 1 ]) 28 if block . prev_hash != prev_hash : 29 return False 30 if bin ( hash ( block ))[ 2 : 2 + self . k ] != 0 : 31 return False 32 self . blockchain . append ( block ) 33 return True So now we have the distributed timestamp service we mentioned at the beginning of this section. The rest of this section deals with loose ends. Network The paper clearly describes the Bitcoin protocol. Essentially, blocks contain broadcasted transactions (coins) and there is a great race to extend the block chain. Incentive Why should everyone race to extend the blockchain? For money of course! Each new block created also creates a new bitcoin, owned by the person who created the block. This is inflationary. There is also a non-inflationary incentive: transaction fees. A transaction must specify an input value and an output value. If the output value is less than the input value, then the person who creates the block keeps the difference for himself as a transaction fee. Reclaiming Disk Space Not everyone needs to have a full copy of the blockchain in order to use Bitcoin. Nakamoto describes how the use of Merkle Trees allow parts of the blockchain to be discarded without affecting the ability to validate later blocks. Simplified Payment Verification Combined with the previous section, anyone can verify a payment using only a subset of the blockchain. Combining and Splitting Value Do we need a separate transaction for each minimum unit of currency (later named a satoshi after the author), or can we have a single transaction for a larger amount? A transaction has one or more inputs (coins that Alice owns) and one or two outputs (Alice and Bob, where Bob is the recipient). I felt that this section of the paper was vague. Author's Evaluation of the Proposed Solution Throughout the paper, Nakamoto comments on how such-and-such particular feature enables some property of the system, or prevents some problem. On preventing attacks : We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent … To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. Section 11 (Calculations) gives a mathematical treatment on how computationally difficult it would be for an attacker to double spend, and presents a theorem without proof. On determining representation in majority decision making : The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one- IP -address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one- CPU -one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. On simultaneous broadcasts : Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof- of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one. On dropped broadcasts : New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long. Block broadcasts are also tolerant of dropped messages. If a node does not receive a block, it will request it when it receives the next block and realizes it missed one. On incentives to participate : By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. On incentives to stay honest : 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. On the blockchain getting too large to use : A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4. 2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1. 2GB per year, storage should not be a problem even if the block headers must be kept in memory. On privacy : … privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone … As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner. My Analysis of the Problems, Proposed Solution, and Evaluation I do not believe that the people problems identified in Bitcoin, the paper, are of great importance. However, I do believe that Bitcoin, the system, is making itself important by disrupting many elements of society and government. The technical problems identified in the paper are real and well presented. Frankly, Nakamoto did a poor job explaining the proposed solution. One really has to dig into this paper to understand the system. Also, Nakamoto did a poor job analyzing the proposed solution. Overall, this is not a very good paper. That said, I would still encourage everyone to read this paper because there is no other technical source for Bitcoin that is as authoritative as this one. But honestly I think one would have to read the source code to really understand the system. Contributions In my opinion, the main contribution of this paper is Nakamoto's proposed solution to the problem of double spending, and his evaluation of how computationally infeasible it is to double spend using his solution. The \"great race\" is an ingenious mechanism to align the incentives of the principals. The second contribution of this paper is modeling a transaction with multiple inputs and two outputs. The rest of the paper, and the individual elements of the proposed solution, e.g., coins, timestamp service, proof-of-work, Merkle Trees, etc., were published previously. Future Directions Bitcoin has come a long way since 2008, and I don't think that it is possible to objectively write this section. One could look at the original questions and criticisms from the 2008 to 2009 timeframe to better understand what folks thought were the future directions for Bitcoin back then. Lingering Questions I understand that there is a bit of a mystery surrounding the author, Satoshi Nakamoto. The conventional wisdom is that his name is a pseudonym. But some folks question whether or not it was the work of a single author. I offer my own opinion as a system researcher. Yes, I believe that Satoshi Nakamoto is a single person. First, my observation in life is that the best work tends to come from a single creative mind, and Bitcoin is clearly a very cleverly engineered system. Second, there are editorial deficiencies in this paper which would have been caught if there had been multiple authors. Some of the passages are a bit awkward. And some of the descriptions are overly terse. The author either has graduate-level training, or is one of the very rare individuals that can teach themselves how to conduct research. I would guess that it is the latter as it appears to me that the paper is copying the style and format of academic literature but is missing some key traditional structures. For example, although there are citations, there is no related work section. There is also no future work section, and there is no performance evaluation. This paper would not have been accepted to a top-tier conference as it is currently written. The paper describes how the most common attack would be to rewrite history to allow an attacker to double spend his own coins. To date, has this ever actually happened in Bitcoin? Would there be any tell-tale signs that this happened? Should we be investing in energy companies and semiconductor fabs? In the olden days of yore, wealth was measured in cattle. In the future, will wealth be measured in computational power and access to electrical power? Take-Away Message I really enjoyed reading this paper. If I had read it back in 2008, then I would have thought that Bitcoin was a really well-engineered system. It solves many different problems, any of which would prevent Bitcoin from being practical. Currently Bitcoin is struggling with scalability problems. Years of system research and practical experience at companies like Google have shown that scalability is a very difficult property to architect for without the practical experience of getting it wrong a few times. As of mid 2017, most of the eCommerce world continues to operate as it did in 2008, with VISA , MasterCard, American Express, Discover, and a bit of PayPal for good measure. On the other hand, Bitcoin currently has a market cap of about 41B USD . Where did all of this wealth come from? From someone's imagination. References [1] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. Available at: https://people.eecs.berkeley.edu/~raluca/cs261-f15/readings/bitcoin.pdf [2] Jake Lerner. UC Berkeley CS 261 Fall 2015 Scribe Notes: October 6: Bitcoin. UC Berkeley Scribe Notes, 2015-10-08. Available at: https://people.eecs.berkeley.edu/~raluca/cs261-f15/scribenotes/Bitcoin.pdf [3] C. Dwork and M. Naor. Pricing via Processing or Combatting Junk Mail. Advances in Cryptology — CRYPTO ' 92. Available at: http://www.weizmann.ac.il/mathusers/naor/ PAPERS /pvp.pdf","tags":"paper reviews","url":"bitcoin-2008.html"}]}