Posts Tagged ‘computer security’
I spent some time this week reading about Bitcoin, an electronic currency designed to eliminate the need for intermediaries in online financial transactions. Currently financial institutions, such as banks, credit card companies, and wallet services, keep track of electronic account balances and transactions. Parties transacting electronically rely on the institutions as trusted middlemen to ensure that transactions are authentic and that ownership of cash properly changes from the payer to the receiver. Bitcoin’s defining feature is that it addresses these needs by publicly posting each transaction to a record that is computationally difficult to falsify.
Bitcoin resolves the basic problem of verifying a transaction’s authenticity via the well-known method of public and private keys. A nice and simple layman’s introduction to this concept can be found here. Each Bitcoin participant is identified by a public key which serves as your account number (you can have as many as you want). In order for one public key to pay money to another public key, the paying account must sign the transaction with its corresponding private key. In plain English, there is a way to affix a convincing signature to a transaction (like your signature on a check, but harder to forge) that verifies that the payer does recognize it.
While this is interesting and important, these ideas predate Bitcoin, and it is really the fraud-resistant distributed public record that distinguishes Bitcoin’s ideas. Without getting too deep into technical detail (in no small part because I am not qualified to do so), the idea behind Bitcoin’s public record is that in order to be validated, transaction data must be “hashed” into valid solutions that cannot be found by any known method except brute-force trial and error. For more mathematically inclined readers: a block of timestamped transaction data D is salted with a variable x, called a nonce, and distributed computing nodes try to find x such that f(D,x), where f is the SHA-2 hash function, is sufficiently small. D always includes a signature of a previous block of transaction data. Once a node finds a valid nonce it broadcasts its solution widely, and any (honest) node that receives and verifies it will start working on finding a nonce for new transactions. Bitcoin rewards creators of valid blocks with new bitcoins and transaction fees, giving an incentive to participate in block validation.
If you didn’t follow that, the important takeaways are that all Bitcoin transactions are stored in a public record, and although anyone can add to the public record, it is computationally intensive to do so. Each block of validated transactions is linked to a prior validated block and timestamped. Because each and every transaction is part of the public record, the balance of cash in each Bitcoin wallet (as identified by a public key) is also a matter of public record. And because adding to the record is hard, a fraudster who wants to rewrite historical transactions realistically needs to harness more computing power than that of all honest participants combined.
The Bitcoin white paper, from which I learned a lot of what is written above, very logically compares the publicly recorded block chain of transactions to the ticker tape of a stock exchange. But when reading it I was also reminded of the record of activity people leave on social networks, which on Facebook has recently been made explicit with the Timeline feature. Status updates, photos, academic and job history, music you were listening to, etc. can be thought of as social “transactions.” Some transactions are solitary (such as status updates), but many are between more than one party (relationships, presence at a bar, where you worked last year) and might demand verification such as that which is done in Bitcoin with public key signatures.
Right now the operators of social networks are the trusted owners of the social information we want to share, serving an analogous role to trusted financial intermediaries in electronic transactions. The operators keep records and accounts of your activity and will verify multi-party transactions: if you want to say you’re in a relationship with someone else on the network he or she has to accept, if you want to share your music playlist then your music player needs to broadcast (“scrobble”) your playlist to the social network operators.
The issue of double spending does not have a direct analog (although your significant other may object if you try to double-spend your relationship status). But Bitcoin’s ticker-tape approach to solving the double-spending problem not only gives it a social network-like framework but also suggests a method by which social network data could become independent of its operators. If a standard protocol for social network “transactions” were established, users could create a distributed network of computational nodes that, like Bitcoin’s nodes, would receive updates from transactors and attempt to validate them. Periodically blocks of social updates would be “solved,” broadcast to other nodes, and confirmed into the main block chain. The network would exist outside the ownership of any one site, and so there wouldn’t be a role for social network sites per se. But individual websites could allow users to sign in directly with their public key the way that some sites currently use Facebook Connect/Google Accounts as their login system. And in fact some of these sites might be for no other purpose than to bring people with common interests together and present shared social data in a format relevant to those interests, making them no different from targeted-audience social networks today.
There are surely drawbacks to the distributed public approach as well. The most glaring one that I can think of is that there are no obvious incentives for running a computing node here. Another is the question of whether a distributed network can field all the data that the major social networks currently deal with every second. Perhaps the data would be so voluminous that only full companies could afford to participate, which might effectively reinsert them as intermediaries into the equation. I am not saying the distributed approach is the right one, but merely offering food for thought.
Likewise, the Bitcoin white paper, written by Bitcoin inventor Satoshi Nakamoto, approaches its topic with this sort of intellectual curiosity, as an idea to be explored, implemented, and tried. The paper is in written in the style of an academic paper, and reads like neither a sales pitch nor an anti-banking screed. I do recommend it; though it will help to know some computer science, the paper is not especially abstruse by academia’s standards, and you can use Google to help get by. (Not to mention the intriguing mystery surrounding the author: it is generally unknown who “Satoshi Nakamoto” is and whether that is his real name.)
N.B.: I do not advocate investing in bitcoins. I think they are an interesting social experiment but also a very risky financial proposition, as they are not widely accepted and are very volatile with respect to the US dollar. Please do not convert any amount of money that you cannot afford to lose into bitcoins on the basis of this post.