Month: February 2016

Relics from the P2P file-sharing wars

This blogger was recently disconnected from a New York hotel  network with a cryptic error message:

P2P_false_positive.png

Nothing adds up here. p2pnetworking.exe? EXE extension indicates a Windows application—which is not the operating system running on the machine. Even more surprising was the reference to Kazaa (note the misspelling above,) which inspired a trip down memory lane.

The 2000s called; they want their file-sharing wars back.

After Napster

Kazaa was a popular peer-to-peer file sharing application which came to prominence as part of the second generation of P2P designs. It was Napster that kicked off the first-generation, putting MP3 and file-sharing in the limelight, exceeding 20M users at its peak. That success was short-lived. Napster became a lightning rod for litigation by a floundering recording industry, which found a convenient scapegoat for its declining revenue. (It would not be the first or last time that RIAA tilted at wind-mills.) Napster also had an intrinsic weakness: its design fell short of being truly 100% distributed. There was a point of centralization, a single-point-of-failure in Napster the company itself. While users downloaded files directly from each other, indexing and search of content was handled by servers operated by the corporate entity. That gave RIAA all leverage required in arguing that Napster can and should be held accountable for any infringing uses of its platform.

Future developers of file-sharing applications would not make that mistake again. First came Gnutella from the developers of WinAmp, which had been recently acquired by AOL. Its release lead to  awkward moments for the parent company, courting a merger with the content-rich Time Warner at the time. AOL tried putting the genie back in the bottle, but it was too late. Along came many more: Kazaa, Morpheus, eDonkey. These optimized the network topology by taking into account that not every user has the same bandwidth available. Instead of treating all nodes equally in democratic spirit, they deliberately capitalized on powerful machines on high-bandwidth connections, promoting them to “supernodes” responsible for coordination.

Users embraced the new generation of P2P applications— at least until the apps morphed into delivery vehicles for dubious adware and spyware bundled with the installers in some semblance of a business model. Network administrators on the other hand hated P2P with a vengeance because of the massive bandwidth consumption. At first it was colleges that started banning Napster. They claimed the prerogative of fairly distributing network capacity, although RIAA nastygrams no doubt also played a part in scaring the typically tech-illiterate and clueless administrations into policing their own student body. Later the crusade was taken up by ISPs on a much larger scale, with Comcast getting in trouble with FTC after it was caught manipulating BitTorrent traffic.

False positives

That brings us to this mysterious error message from the hotel network.

Kazaa has folded a long time ago. Its official client only ran on Windows. P2P moved on to third-generation designs best exemplified by BitTorrent. But somehow the network monitoring software used by this hotel retained the vestigial traces of the great War On File Sharing from early 2000s. Lying dormant all this time were heuristics on the watch for dreaded P2P traffic, ready to banish those users from the network for their transgressions. (That ban lasted approximately 24 hours in this case.)

As with all unmaintained software, these rules can go haywire when the world changes. It turns out that in this case the omniscient network monitor misidentified Google Hangouts video-conferencing for P2P file sharing. A quick search shows the offending traffic pattern cited in the error message— UDP traffic to port 19305— is among the documented ports associated with Hangouts application. Similarly a reverse DNS lookup for the destination IP points to “1e100.net” domain, which is a Google domain as expected.

Protecting users from themselves?

By itself a false-positive in a network monitoring application is not exactly news. Such heuristics are notoriously unreliable and subject to errors. For starters a given protocol is often implemented by multiple pieces of software written independently of each other. Some may be open-source, others proprietary, yet others “adware” supported by bundled applications. If they are implementing the protocol faithfully, they will look very similar to an external observer watching bits on the network. Just because a machine is emitting network packets that looks like the one emitted by Kazaa does not mean it is Kazaa running on that machine.

Putting aside that conceptual problem, what makes this example truly egregious is the alarmist language in the message and vindictive approach taken by the hotel against would be file-sharers. What is being achieved by singling out P2P applications? “Online activity flagged as malicious.” Malicious towards whom? Certainly not the owner of the laptop. If the hotel has taken on the paternalistic role of protecting customers from dubious software on their own device, where do we draw the line? Should they also start performing deep-packet inspection or blocking known malicious websites?

For that matter, the response after detecting P2P activity is disproportionate. If the network management system can identify file-sharing traffic (it obviously can not, but let’s grant the premise) why not specifically block those connections? Why retaliate by keeping users completely off the network for an extended period of time? Even if we grant the premise that hotels somehow owe it to their guests to protect them from their own malware- which, let’s be clear, file sharing software is not– quarantining the user completely does not further that objective. Redirecting users to a web page that explains risks involved or offers assistance with removing the offending malware is a more constructive approach.

Searching for a motive

Because the standard it’s-for-your-own-good excuse does not hold up to scrutiny, we need to look deeper for motives. There are two usual suspects.

“Network management”

This is a euphemism for allocating scarce bandwidth fairly between users with competing interests. This was the putative excuses colleges/universities initially offered for blocking Napster: with everyone downloading music, the application was consuming significant chunk of campus bandwidth. It is also the original excuse ISPs resorted to when explaining their throttling of BitTorrent. P2P was particularly embarrassing for ISPs because it revealed one of the worst-kept secrets of Internet service in the US: while an ISP may advertise 10Mbps speeds to subscribers for a given price, it does not have anywhere near the capacity to provide that speed to all subscribers at the same time. As long as few are maxing out their connection, customers may indeed attain speeds near that advertised upper-bound. But if everyone gets busy downloading music at once, no one gets close to seeing anything close to the effective bandwidth they were mislead to believe they were paying for.

A cafe or hotel providing wireless access to guests faces a similar problem of apportioning its outbound bandwidth, and here there is even less expectation of guaranteed service. Internet access is an incidental amenity not unlike a swimming pool; unlike an ISP selling broadband Internet, it is not the main line of business for the establishment. There is something to be said about fair allocation of scarce bandwidth and preventing one person from consuming a disproportionate share.

But such limits are by definition content-agnostic: a 5MB file occupies exact same number of bits whether it is downloaded off P2P network or streamed from iTunes. There is no justification for singling out a specific protocol, much less one specific application such as Kazaa for exclusion.

Contributory infringement

Avoiding legal headaches related to copyright infringement may be another  motivation to block file-sharing. This blogger is not a lawyer and will refrain from commenting on the creative theories of liability required to hold a hotel responsible for what guests download on the network.

Relics

There is another possibility of course: this “feature” of the hotel network is an ancient relic of a different era. In that less-enlightened time, organizations and businesses were cowed by RIAA/MPAA lawsuits into policing the activity of their own users, forking over for ineffective and blunt network management technologies to demonstrate their commitment to the higher cause of copyright enforcement. Times may have changed. Yet those “features” built into the network keep cropping up in unexpected ways.

CP

 

Scaling Bitcoin vs keeping-up-with-Visa

Continuing on theme of the previous post on Bitcoin scaling challenges, there is an implicit assumption driving the scaling controversy that requires a closer look. It is an article of faith that Bitcoin must scale by orders of magnitude process more transactions, and do so quickly. The benchmark for evaluating increased blocksize proposals (or features that effectively result in same outcome by shuffling bits around, such as segregated witness) remains one dimensional: the throughput of the network measured in transactions processed per second or TPS.

Given current limitations that metric peaks at a theoretical maximum of 7TPS although the jury is out on whether that upper bound can be attained in practice. This is often contrasted against the corresponding numbers for a standard payment network such as Visa. Statements published by Visa— attributed to a decidedly ancient 2010 IBM test—  put those figures at average of 150M per day with a maximum peak rate of 24000TPS.

Before questioning this “keeping-up-with-the-card-networks” mantra, it’s worth noting the paucity of attention paid to other statistics such as confirmation time. Imagine trying to buy coffee with Bitcoin. To be on the safe side, the merchant must wait for the transaction to appear on the Blockchain. Not just on the latest block freshly minted, but a few blocks deeper to rule out the possibility of being reversed by a rare reorganization event. Average 10 minute interval for mining blocks makes for an unpleasant retail experience. There are nascent proposals such as Lightning Network layered on top of the core Bitcoin protocol (as opposed to being modifications to the protocol) designed to facilitate near real-time settlement. They are far from seeing any traction. Meanwhile the 10 minute interval remains an inviolable constraint in the protocol.

Granted, this may not matter when buying coffee. Merchants can manage the risk from operating with zero-confirmation as long as the potential loss from the sale of that item is low-enough and the proportion of honest customers in the population high enough. It is similar to the risk-management decision Starbucks already makes when they swipe card  at checkout without demanding a signature from the card holder. That is a good idea. It keeps the line moving and customers caffeinated. Once in a while there is a stolen credit-card used or some customer disputes the charge. Starbucks is left holding the bag because they have no proof. A signed receipt could provide insurance by shifting liability to the issuer but those extra 20 seconds would translate into lost sales on a busy morning. Now multiply the dollar amounts involved by 100x, and waiting for the network to confirm the transaction starts to make more sense, just as merchants get more picky about receipts and checking ID for big-ticket purchases. (Not to mention that replace-by-fee proposal will make it much easier to double-spend unconfirmed transactions.)

Keeping up with the Visas

The narrative animating Bitcoin XT envisions a world with ubiquitous Bitcoin usage. Not only do consumers worldwide purchase their coffee at the corner store in cryptocurrency instead of swiping/inserting/tapping their credit-card, but they get to pay the rent, stream music online, access journalism behind a paywall, settle that debt to a friend who paid for dinner and wire money overseas to the cousin traveling in Timbuktu. In this expansive vision, it’s not only Visa and PayPal who are on the way to extinction. Check clearing and its automated cousin ACH, Federal Reserve Wire Network, the international SWIFT system, peer-to-peer payments such as Venmo, proprietary alternatives such as PayPal, Western Union etc. all face competition from Bitcoin eating into their market share. Naturally that one-network-to-rule-them-all must boast the combined capacity of all of the “deprecated” systems it replaces.

In case such a formidable list of incumbents being obsoleted at once has not already cast some doubts on the feasibility of this vision, let’s dive deeper into one scenario: replacing card networks. We can ask what incentives would drive mass-adoption of Bitcoin as an alternative to using payment cards. This can quickly become a complicated comparison with multiple categories: PIN-debit vs credit vs charge-card vs prepaid, retail vs online payments etc. Here we pick one representative case that today accounts for the bulk of such transactions by volume.

Case study: how (not) to disrupt in-store payments

There are multiple participants involved in a transaction when a consumer buys a TV  from a big-box retail store using their credit card: cardholder, merchant, payment network, issuing bank, not to mention all of the invisible middlemen behind the scenes facilitating that transaction such as the payment processor or the vendors who manufactured the point-of-sale terminal. [Quick refresher] In order to switch over to using Bitcoins, one or more parties must see a compelling benefit.

It’s certainly not the card network or the issuer. They would be out of the picture, disintermediated by an open system where anyone can pay anyone else without going through gate-keepers for access to the network. Despite initial forays into exploring crypto-currency, they have little to gain from watching their consumer credit business evaporate overnight. Issuing banks are already earning money hand over fist from interchange-fees and interest on balances carried by consumers.

Could it be the consumer? The privacy afforded by Bitcoin is not exactly much of a help when walking into a store dotted with surveillance cameras, or for that matter using a smart-phone that requires an Internet connection to broadcast the bitcoin transaction. It’s even worse when considering the economics. One can only spend existing funds with Bitcoin; a credit card allows deferring payments, to handle fluctuations in cash flow by carrying a balance. Worse, consumers receive an effective discount (albeit small one) from credit-card transactions. In the face of increasing competition, issuers are increasingly splitting their profits with customers in the form of airline miles, fungible points exchangeable for gifts or straight cash-back rewards. For a card averaging 1% rewards, paying for a $1000 TV in BTC amounts to leaving $10 on the table.

Merchant perspective

Merchants are the prime candidate to agitate for bitcoin. Frustrated by high card-processing fees, perennially on the lookout for cheaper alternatives (so much that several large US retailers banded together to create their own) they are seemingly the ideal cheerleaders for cryptocurrency. The economic pressure is particularly strong for segments with low profit margins: grocery-chains and large department stores often boast net profits in the single-digit percents. Forking over 2% of the gross sale for the privilege of accepting Visa/MC/Amex starts to sting. Irreversibility of Bitcoin transactions is another selling point. There is no longer the dreaded problems of charge-backs caused by fraudulent transactions. (That’s a bug from the consumer perspective: it is a safety feature to be able to call someone and complain when a card is stolen, and not be on the hook for unauthorized charges— or at least maintain that illusion of zero liability. But merchants greatly appreciate not having to worry about a sale getting reversed.)

Yet in-store payments are exactly the scenario where adoption is challenging because of the long settlement time, coupled with 0-confirmation being unsustainable long term. Let’s assume merchants will eat the cost of upgrading their point-of-sale equipment to accept Bitcoin. Realistically, they were far from enthusiastic about chip-and-PIN or NFC adoption, until card networks threatened a liability-shift pitting them against issuers, but in this case the lure of drastically lower processing fees could alter the equation. It would still require widespread adoption of Lightning or equivalent solution for instant settlement before that investment pays off. This would be much less of an issue for online purchases: given the additional lag involved in digging up the item out of a warehouse, packaging and shipping, an extra half-hour wait is noise. (But even that may change with the rise of same-day delivery and other services compressing the timeline from placing the order to a package showing up.) To wit, success stories of using Bitcoin at Sears/CVS/Home Depot turn out to be enabled by an intermediary exchanging Bitcoins for gift-cards, which are then processed by existing channels at the point-of-sale. Those merchants are not directly accepting Bitcoin; they do not have a Bitcoin address or operate a node on the network.**

Realistically, even highly motivated merchants can not unilaterally force consumers to adopt a new payment system. They can certainly express strong preferences towards minimizing transaction processing costs. They can nudge consumers in that direction, for example by setting minimum amounts for using cards. They can try passing on card fees to consumers or equivalently, offering discounts for cash- although that turns out to be so fraught with contractual issues that few venture there. They can lobby for structural changes behind the scenes: the Durbin amendment made it cheaper to process debit transactions. Some have even gotten into the open-loop card business by partnering with issuers, following the if-you-can’t-beat-them-join-them mantra. (That Costco-branded American Express card, which recently blew up in a very public spate between the two companies, let Costco share in revenue generated from cardholders while also reducing its own processing costs.) But at the end of the day, merchants must adopt to the existing payments ecosystem. As long as they conclude card-acceptance increases revenue by driving sales, they have an incentive to offer that option. In order for Bitcoin to become a viable alternative, there must exist a market segment of customers ready to spend Bitcoin and unable/unwilling to transact any other way. That critical mass does not exist at the moment, and it is far from clear that a demographic can emerge that simultaneously embraces Bitcoin while shunning mobile wallets such as Apple Pay or Android Pay, forcing merchants hand in having to cater to that preference.

Capitalizing on the unusual fee structure

The preceding issues reflect less on inherent flaws in Bitcoin than the current framing of scaling debate. The push for rapidly expanding block-size is predicated on the assumption that limited network capacity is holding back Bitcoin from achieving its manifest destiny of disrupting consumer payments. Build it and they will come, that argument goes. But the real question is not whether Bitcoin can compete with credit-cards in raw capacity, but whether it can compete on economical terms. For that matter, whether it needs to compete in order to be considered successful in its own right. Observe that wire-transfers move billions of dollars everyday, but no one has  penned an article announcing the demise of FedWire due to its inability to pay for coffee down the street. Payment systems have strengths and weaknesses. Even in its infancy, there are many applications where Bitcoin already outshines other alternative.

One theme uniting those scenario is fast and low-cost movement of funds. Writing a check does not incur any fees for either sender or recipient, but it is slow and requires physical shipment of pieces of paper. Wire transfers are real-time but come with hefty fees for individuals. Peer-to-peer systems such as Venmo and Google Wallet can move funds instantly at no-cost within the system, but they suffer from the problem of getting money into & out of the system; hefty credit-card fees are passed on to the consumer.

A  crucial special case of low-friction P2P transfers are cross-border remittances. If wiring money from one bank to another in the US sounds like an expensive proposition, imagine being a migrant worker trying to send money overseas to family. WorldBank tracks global remittances, and recently estimated an average ~7.5% fee globally. That estimate hides the true range of figures: trying to send $200 from Germany to China would incur a whopping 17% in fees. It’s not even a function of geography- France and Algeria are close but the average fee is 15%. Bitcoin vastly undercuts these expensive channels, translating into billions of dollars saved.

A core developer recently raised the alarm about Bitcoin development increasingly focusing on settlement scenarios instead of direct payments. There is a good reason for that bias: it plays to existing strengths of the design. Bitcoin is one of the most efficient ways of moving large sums around. Fees are charged per byte of the transaction. That is a very unusual metric because it is independent of the value moved. Under this regime a transaction moving a million dollars may pay less in fees than one moving a few dollars. By contrast most systems charge fees ad valorem. For credit cards those rates can hover around 2-3%. Even the Durbin amendment capping fees on PIN-debit set those limits as fixed cost plus 0.05% of the amount, retaining the proportionality feature. Bitcoin is unique in decoupling fees from the utility of the transaction as measured in the amount changing hands. It’s as if a bank decided to charge for check-cashing not based on the face value of that check, but on the thickness of paper used.

All of these applications still require Bitcoin to continue scaling up its throughput. Key difference is that the throughput targets are much lower than required for playing catch-up to Visa/MasterCard/Amex. Nor do these changes need to happen on an aggressive schedule, playing a game-of-chicken with hard forks. These markets are emerging gradually, with adoption driven organically because Bitcoin is a compelling  improvement over existing alternatives. No one will give up on Bitcoin because their transfer did not settle faster than Western Union or charged a few more Satoshis in network fees.

CP

** Ironically the intermediary eGiftCards itself uses yet another intermediary (Coinbase) for processing the Bitcoin transaction, and never directly taking on the risk of double-spending or currency volatility of BTC/USD. So much for direct peer-to-peer payments.