General Archives - Page 12 of 26 - {5} Setfive

Last weekend, the boys and I were at a bar and we started playing on one of those “parlor game” machines. If you’re unfamiliar, they’re basically a computer with a touch screen in a glorified case. They’re loaded up with dozens of games like “spot the difference”, traditional casino games, and of course X-rated versions of everything. As we were burning cash playing, we started thinking out loud that the game would be “cooler” if you could actually win money back. Games like this do exist in Vegas but they’re consequently heavily regulated by gambling related laws. As we were discussing this, someone mentioned building the game using Bitcoin in hopes of skirting gambling regulations. So, how could you go about building a real world game using Bitcoin for payments?

Hardware

The natural choice here would be to run with a WiFi enabled RaspberryPi along with a capacitive touchscreen. I’ve never done any work with touchscreens but it looks like TigerDirect has 22″ Planar ones for under $300. Couple that with a WiFi RaspberryPi kit for $50 and we should be in business for <$500. You could obviously grab a smaller screen but go big or go home right?

Authentication

Now things get interesting. Philosophically, I think you do want to enforce authentication so that users can save scores, carry a BTC balance, and generally make the experience “stickier”. The straightforward approach would be to offer a traditional sign up using an email address and password but that would totally sacrifice leveraging social media. Allowing users to easily “sign in” with Twitter or Facebook would allow you leverage their social graphs to find their friends and drive awareness of the game. An issue I’ve run into in the past is that “kiosks” always ask you to enter you Facebook or Twitter credentials directly on the kiosk – which is a non-starter for most people.

So how can we avoid this? The big idea is that you really just need the user’s OAuth tokens for whatever service they want to use – not their credentials. To do this, you’d need to either distribute an app or have a website where the user could “sign in” while already logged in on Facebook or Twitter on their mobile phone. Then, you’d be able to capture their OAuth tokens and log them in to the kiosk.

Getting the Bitcoin

Ok, so the user is logged in, now we need to get them some Bitcoin to play with. I think what you’d want to do is generate a wallet for each authenticated user and let them transfer in to an address as need be. So since their account is unfunded, they’d be presented with a QR code for an address that they can use to fund it. Another interesting idea would be to let users buy BTC in cash from the bartender which would in turn automatically fund their account. To support this, you’d need an app or website where the bartender could transfer BTC into the user’s wallet after receiving cash on site.

In terms of software to facilitate this, it seems like bitcoinj would be the best option. Written in Java, bitcoinj is a “client node only” implementation of the Bitcoin protocol that allows it to run without a full local copy of the Blockchain. Because of this, bitcoinj will run in resource constrained environments like the RaspberryPi. In addition, bitcoinj supports “simplified payment verification” so you’d be able to clear transactions instantly without waiting for confirmations to settle.

The Games

Graphically and conceptually, the games are all pretty straightforward so your best bet is probably implementing with JavaScript with HTML and CSS. The benefits would be you’re development cycles would be short and you’d be able to develop the games independently of the device itself. With HTML5 hitting it’s stride, you’d also be able to enable “multiplayer” versions using WebSockets.

One interesting consideration is that without being able to definitely vouch for the physical security of the kiosk how can you verify that the running code is authentic?

Sending the Bitcoin

The final step in the dance (and what makes it special) is allowing the user to cash BTC out of their account. I think you’d want to offer the option of allowing the use to generate a “send to” address if they have a mobile wallet and also allow them to cash out in person. If they can generate a “send to” address, they’d have to use the kiosk to scan a QR code where their BTC balance would get sent. To facilitate this, you’d need a webcam attached to the RaspberryPi and then use something like ZXing to decode the data in the QR code.

For the “in-person” option, you’d need to build out functionality to allow the bartender to initiate a transfer from the user’s wallet back to the bar from the web or mobile app. After it settles, they’d simply hand the user back some cash and the account would be settled.

Is this legal?

Therein lays the rub. It probably is but I’m not 100% sure. Eliminating the option to exchange BTC for cash might help the case for legality. Along with that, if you can side step “making odds” as well it might help your case. Would love any thoughts on this!

In the last two weeks, there’s been two frontpage stories coming out of the “sharing economy” space. First up, news broke that Seattle passed new regulation to limit the number of drivers that Uber or Lyft can have on the road at any time, effectively hamstringing both services. Then, over the weekend a story started circulating about an Airbnb stay gone awry involving an orgy, Twitter, and of course the cops. While the stories are wildly different, they both sit at the intersection of the new “sharing economy” and the role of government regulation. Because of this, both stories sparked an intense debate everywhere from The Wall Street Journal to Hacker News. The attitudes and viewpoints of the discourse were interesting and revealing about people’s attitudes towards regulation in the taxi and hospitality space.

The opinion towards the new regulations in Seattle were overwhelmingly negative, ranging from claims of stifling innovation to accusations of outright corruption. Empirically, it seems that most people, even outside of early adopters, have generally positive feelings about Uber and Lyft. It might be because of the horrible experiences people have had in normal cabs or because of the perception of hackney companies as entrenched monopolies but I think it’s primarily due to people’s perception of risk surrounding Uber or Lyft. As a non-user, the perception of how “risky” it is to have Uber drivers operating in your city is probably near zero. Given how small a percentage of total drivers they’ll make up and that “licensed cab drivers” typically already operate in the area, I don’t think many people feel threatened by having additional drivers potentially ferrying people around their city. Because of this, it’s been easier for people to take hold of the “sharing economy” narrative where Lyft or Uber who were empowered to make a living are suddenly shut out by corrupt, entrenched interests.

Contrast this with the reactions from the same people to the Airbnb story, which ranged from disgust that someone would rent out their condo to strangers through feelings that Airbnb should be held liable for the actions of an independent third party. There’s no argument that the Airbnb story is significantly more disturbing, but it isn’t the first time something like this has happened and it certainly won’t be the last. So why such a different, visceral reaction? It’s perceived risk. As a non-user, the perceived risk to having Airbnb operate in your area is undeniably significant. Take a typical condo apartment building where every occupant is either a member of a condo association or a vetted rental tenant. Introducing the possibility of short term, “random occupants” certainly sounds risky and unnerving to anyone living in the building. Anyone considering the situation immediately evaluates worst case scenarios, “what if they’re criminals?” or “drug dealers?” and so on. Compared to driving, where interactions with strangers is a given, introducing “random interactions” into a scenario where it’s unexpected seems to push people towards favoring legislation.

As a whole, the emergence of the new “sharing economy” is probably a net positive. Despite that, companies are certainly thumbing their nose at government regulation and entrenched players which is going to cause ruffled feathers along the way. To win the hearts and minds, companies will definitely need to manage the perception of how risky their services are both to users and non-users alike.

I was catching up with a friend of mine yesterday who’s looking to build a company in the wearables space and we started chatting about fast the wearables has been growing. The conversation stuck with me and as I left lunch I started wondering what the next big “tools” markets were going to be. The “tools” metaphor is referring to the observation that during a gold rush it’s usually more profitable to sell the pickaxes, wheelbarrows, and other supplies that miners need versus prospecting for gold yourself. Chris Dixon has an interesting post describing this phenomenom that’s worth a read, Selling pickaxes during a gold rush. Some recent examples would include the growth of collaborative open source development fostering GitHub and the shift to “cloud infrastructure” spawning PaaS companies like Heroku. Anyway, so what areas might end up creating $1bn+ tools markets?

IoT and Wearables

2014 might well go down as the year of The “Internet of things” (IoT), everyone is buzzing about it, everyone wants to leverage it, and everyone is a bit confused by it. The market is still immature but there’s already a flurry of competing standards and technologies. Looking just at connectivity, developers could potentially dealing with NFC, RFID, and Bluetooth LE. Given this early fragmentation and the wide range of potential applications, I think it’s a good bet that the IoT tools market will grow quickly over the course of the year. Locally, ThingWorx has already had a succesful exit and the Boston Business Journal is already throwing around nicknames.

On the consumer side, wearables is already a large market and its only projected to grow larger. Currently, the “activity tracker” space is fairly consolidated but that’ll certainly change as devices emerge to track different metrics through different technologies. The net result of this is that anyone looking to aggregate data from a heterogeneous set of devices will face an uphill battle. To combat this, we’ll definitely see tools emerging to help manage this complexity and create uniform interfaces. RunKeeper’s Health Graph is an early player here and they’ll certainly continue to innovate.

Cryptocurrencies

Bitcoin (and *coin) baby! Even though an $8bn market cap isn’t enough to buy WhatsApp, it’s certainly nothing to sneeze at. At this point, it’s still to early to declare that Bitcoin is “here to stay” but it’s definitely going to hang out for a bit. Given its immense disruptive potential and the archaic nature of existing financial infrastructure software, it’s almost a certainty that hugely successful “tool” companies will be built in the cryptocurrency space. From the “Bitcoin” version of payment processors like Braintree to electronic brokerage software like Interactive Brokers I think we’re going to see dozens of interesting cryptocurrency companies.

SaaS cloud wrangling

In the last few years, the number of SaaS products a typical company uses has grown exponentially. Nearly every function in a typical company has been influenced by SaaS products, from marketing and sales to accounting and strategy planning everyone’s data is now “in the cloud”. Despite the the availability of APIs, it’s become increasingly difficult to extract, manipulate, and analyze all the data stored within cloud services. Ad-hoc reports that used to involved combining a few Excel sheets now might require costly custom development. Tom Rikert of a16z has a great post describing the early stages of companies addressing this market and more will certainly follow suit. After the groundwork is laid, we’ll certainly see Google Now style “smart insights” to help companies discover new opportunities and insights.

Making predictions is always risky business and hopefully I don’t look back with these and facepalm. Anyway, would love to hear what anyone thinks in the comments.

Over the last two weeks, there’s been two high profile negative Bitcoin incidents. First up, was Mt. Gox announcing that they were temporarily halting withdrawls and then soon after Silk Road 2.0 announcing that they been hacked and ~$2 million of BTC had been stolen. In both situations, the sites are blaming “transaction malleability”, what is supposedly a well known Bitcoin exploit, as the root cause of the issues. Predictably, most of the commentary surrounding both of these incidents has been that they’re both in fact cover ups for the site admins stealing the “lost” bitcoin. Regardless of what turns out to be true, both incidents are raising some interesting questions about bitcoin.

As I understand it, the “transaction malleability” vulnerability is an implementation specific issue that’s already been fixed in the “official” bitcoin client. This is directly contradictory to what Mt. Gox announced and one of the lead Bitcoin developers actually went as far as calling out Mt. Gox in Why Mt. Gox is full of shit. It isn’t clear if Mt. Gox is being intentionally dishonest, but this spat does raise an interesting issue of trusting the software that you’re using. Looking at the software we use on a daily basis, there’s a remarkable lack of transparency into how systems are built, if they’ve been audited, and if they’re composed of independently verifiable open source components. From the software that switches trains on tracks to the code that powers your cell phones, we generally don’t really know how the sausage was ultimately made. In general, things seem to work “OK” without consumers knowing these details but for people to be confident in Bitcoin payment systems they’ll ultimately demand transparency into the underlying implementations.

Another interesting point surfaced by this issue is the irreversibility of Bitcoin transactions. The Silk Road 2.0 announcement really highlights this, since they’re basically pleading with whoever stole the coins to “give them back”. It’s pretty clear that the inability to rollback transactions is going to make combating Bitcoin fraud a herculean task as the volume of transactions grows. Without a mechanism to “undo” a transaction, the majority of fraud prevention will have to rely on preventively blocking transactions as opposed to mediating them after the fact. There are certainly benefits to not being able to reverse transactions but Bitcoin will definitely need a strategy to combat issues like this.

Anyway, I’m still bullish on Bitcoin, the community has shown that it’s resilient and overall it’s definitely better to work out the kinks with $2 million instead of $200 million at stake. It looks like Mt. Gox is close to resuming normal activity and Silk Road 2.0 has recently announced that it’ll reimburse coins to everyone that was affected by the hack. Now if only the price would get back to $1000/coin…

In the last few months there’s been a handful blog posts basically themed “Redshift vs. Hive”. Companies from Airbnb to FlyData have been broadcasting their success in migrating from Hive to Redshift in both performance and cost. Unfortunately, a lot of casual observers have interpreted these posts to mean that Redshift is a “silver bullet” in the big data space. For some background, Hive is an abstraction layer that executes MapReduce jobs using Hadoop across data stored in HDFS. Amazon’s Redshift is a managed “petabyte scale” data warehouse solution that provides managed access to a ParAccel cluster and exposes a SQL interface that’s roughly similar to PostgreSQL. So where does that leave us?

From the outside, Hive and Redshift look oddly similar. They both promise “petabyte” scale, linear scalability, and expose an SQL’ish query syntax. On top of that, if you squint, they’re both available as Amazon AWS managed services through Elastic Mapreduce and of course Redshift. Unfortunately, that’s really where the similarities end which makes the “Hive vs. Redshift” comparisons along the lines of “apples to oranges”. Looking at Hive, its defining characteristic is that it runs across Hadoop and works on data stored in HDFS. Removing the acronym soup, that basically means that Hive runs MapReduce jobs across a bunch of text files that are stored in a distribued file system (HDFS). In comparison, Redshift uses a data model similar to PostgreSQL so data is structured in terms of rows and tables and includes the concept of indexes.

OK so who cares?

Well therein lays the rub that everyone seem to be missing. Hadoop, and by extension Hive (and Pig) are really good at processing text files. So imagine you have 10 million x 1mb XML documents or 100GB worth of nginx logs, this would be a perfect use case for Hive. All you would have to do is push them into HDFS or S3, write a RegEx to extract your data and then query away. Need to add another 2 million documents or 20GB of logs? No problem, just get them into HDFS and you’re good to go.

Could you do this with Redshift? Sure, but you’d need to pre-process 10 million XML documents and 100GB of logs to extract the appropriate fields, and then create CSV files or SQL INSERT statements to load into Redshift. Given the available options, you’re probably going to end up using Hadoop to do this anyway.

Where Redshift is really going to excel is in situations where your data is basically already relational and you have a clear path to actually get it into your cluster. For example, if you were running three x 15GB MySQL databases with unique, but related data, you’d be able to regularly pull that data into Redshift and then ad-hoc query it with regular SQL. In addition, since the data is already structured you’d be able to use the existing format to create keys in Redshift to improve performance.

Hammers, screws, etc

When it comes down it, it’ll come down to the old “right tool for the right job” aphorism. As an organization, you’ll have to evaluate how your data is structured, the types of queries you’re interested in running, and what level of abstraction you’re comfortable with. What’s definitely true is that “enterprise” data warehousing is being commoditized and the “old guard” better innovate or die.

Category: General

Bitcoin: How would you build a “parlor game”?