We’re just about a week into 2015 and investor Marc Andreessen just “tweetstormed” his thoughts surrounding Bitcoin as we move further into the year. If you need some perspective, check out State of Bitcoin 2015: Ecosystem Grows Despite Price Decline from Coindesk before reading the storm below:
Looking through his tweets, a couple of the big ideas are worth expanding on:
In addition to Marc’s thoughts, here’s a couple of other themes to consider going into 2015:
2014 was definitely an exciting year for bitcoin and looking forward 2015 might be a “make or break” year for adoption, startups, and the future of cryptocurrency.
Posted In: Bitcoin
Last week on the train back to my parents’ place for Christmas I decided to follow @wmougayar’s example and read a couple of landmark Bitcoin and cryptocurrency papers. If you’re interested, William’s list is here and includes an interesting cross section of topics. Out of the list, Satoshi’s original paper Bitcoin: A Peer-to-Peer Electronic Cash System helped clarify the specifics of how Bitcoin works and why it has potential to be incredibly important. At nine pages including graphics and footnotes it’s both short and accessible so if you’re on the fence just go read it.
After reading the paper and following down the Bitcoin wiki rabbit hole I rediscovered the Script page on the Bitcoin wiki. Disregarding some cases, one of the key features of a blockchain is that new transactions must contain inputs from a previous transaction. With Bitcoin specifically, in order to use the output of a previous transaction you need to supply inputs that cause the previous output’s “Script” to evaluate to true. The Bitcoin wiki has a more eloquent explanation but at a high level this scripting functionality theoretically allows the Bitcoin blockchain to be used for things like:
So stepping back a bit why would you want to store data inside the blockchain? As it turns out the blockchain has a few properties that make this an attractive proposition. First off, because of the public/private key cryptography scheme it’s only possible to “spend” the coins in an address if you know the address’ corresponding private key. Concretely, assuming that private keys remain secret I can’t create a transaction using an address that you control as an input and viceversa. So by creating a successful transaction you can vouch for the fact that you do in fact own a private key which may have in turn been used to sign an email to me, been used to buy a beer at a bar, and so on.
Next, once a Bitcoin transaction has a sufficient number of confirmations the data contained within it is effectively immutable. So for a nominal fee you can create something that is “set in stone”. In comparison, creating and running a similar system from scratch would be extremely expensive. And finally, the blockchain is distributed so thousands of machines have a copy of what’s happened. Barring exceptional circumstances, you’ll have access to the data even if a high percentage of nodes fail.
For all of this to “click” you’ll need an overall understanding of how Bitcoin transactions work under the bonnet. Ken Shriff has an excellent write up at Bitcoins the hard way: Using the raw Bitcoin protocol explaining what pieces go into creating a raw Bitcoin transaction. What makes an OP_RETURN output special is that the OP_RETURN keyword immediately marks the output as nonspendable while also accepting a second parameter of up to 40 bytes. That second parameter is where we’re going to stick our immutable data and since the output isn’t spendable creating this transaction won’t cost any coin.
As much as I love getting my hands dirty I decided to cheat a bit and use bitcoinjs-lib to build the transaction and then Chain to push it to the Bitcoin network. As it turns out, it’s possible to use bitcoinjs-lib in a browser via Browserify but you’ll need to hand modify the output to export “Buffer”. I have a “Dashboard” setup at http://code.setfive.com/btcscript/ with this all set up and it’s viewable on GitHub at https://github.com/Setfive/setfive.github.com/tree/master/btcscript. To use this, you’ll need a private key in WIF (Wallet Interchange Format) for an address with coins or you can generate keys and fund the address.
From there, you’ll need to take the following steps:
I created a transaction using 1vaRGdVr9pqr9kEqJLoSMdN5MsjXBUrTN and if you can see the details at 1f5d645dde93a663427c60b3fb7d139f37343446e39a9d97bf56c4138083b109. If you scroll to the bottom under “Output Scripts” you’ll see the full output Scripts along with the data I included with the OP_RETURN keyword. Additionally, the guys at coinsecrets.org are tracking transactions with OP_RETURN outputs so your transaction should appear there.
Anyway, that’s how OP_RETURN works. We’re hacking away on Bitcoin Scripts in general and will follow up with a post soon.
Posted In: Bitcoin
I’m pretty bullish on Bitcoin so a few months ago I set out to build a “pure” Bitcoin related application. Specifically, I was looking to build an application that leveraged the Bitcoin network directly, without using any third party APIs or services. The goal behind avoiding third party services was to explore how difficult using the Bitcoin network directly is and also to embrace Bitcoin’s decentralized nature and not rely on another company to move coins.
Conceptually the way the Bitcoin network works is relatively straightforward. You move coins by creating transactions which are just messages written and cryptographically signed in a specific format and then you listen for transactions which include your addresses to keep your balance up to date. Of course, the devil is in the details and there’s a dauntingly large number of them. For example, Ken Shiriff explains how to craft a transaction by hand in Bitcoins the hard way: Using the raw Bitcoin protocol and it’s no easy read. Given that just crafting transactions involved so much code, I started researching existing open source libraries that facilitate working with Bitcoin.
After doing some research, it looked like the most popular approach to interfacing with the network directly was to run the bitcoind deamon and then make RPC calls to the exposed functions. Objectively, using RPC calls to bitcoind qualifies as a “pure” solution but I still didn’t love it. After a bit more searching, I came across bitcoinj which is a pure Java library for working with Bitcoin.
Unlike bitcoind, bitcoinj is a library so its designed to be embedded in other codebases and it supports simplified payment verification (SPV) which allows it to operate without downloading the entire blockchain, ~25GB as of today. On top of this, its written in Java so it’s easy to use from Scala, something I’d been looking to experiment with.
Anyway, this was my first time building something Bitcoin related and it was a positive experience. The project is still private but I’ll definitely share it once it’s released. As always, questions or comments are welcome!
Posted In: Bitcoin
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?
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?
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.
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.
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?
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.
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!
Posted In: General
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…
Posted In: General