bitcoin Archives - {5} Setfive - Talking to the World

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:

Sub $300 price as of January 2015: Anyone who still thinks Bitcoin is a good speculative investment is in for a world of hurt but that’s probably a good thing. As speculators and early adopters leave the market we’ll see less flash crashes like the infamous BearWhale
Continuing volatility: I think Marc is understating the impact volatility has on Bitcoin adoption. Businesses may have the opportunity to convert BTC to fiat almost immediately but consumers that are holding bitcoin in wallets are still getting hit hard by the high volatility. This is especially problematic on sites like Coinbase where “buy” transactions take several days to settle and the price is locked in when the transaction starts, potentially short changing the user.
Limited use cases: Marc’s analogy is a bit lacking. I think a more powerful one is when the first iPhone came out did anyone imagine we’d be hailing cabs, paying for groceries, and tracking our fitness all from what was at the time a glorified palm pilot (that was harsh). Ultimately, it’s hard to predict how new technology will evolve, especially when its helping to create completely new markets.

In addition to Marc’s thoughts, here’s a couple of other themes to consider going into 2015:

Blockchain sans financial Bitcoin: Leveraging the “blockchain” without using Bitcoin as a financial instrument received a lot of mindshare in the latter half of 2014. Unfortunately, as it’s been pointed out by others the “tokens” on the network need to have some value in order to incentivize miners to secure transactions. Stepping back though, I think it’s worth discussing what a “paid” or community supported blockchain looks like. You already trust and pay Amazon to run your servers, why not to run your blockchain infrastructure?
Security and Bitstamp: The big news this week was that Bitstamp lost $5 million worth of Bitcoin out of their hot wallet. Big companies have lost everything from photos and emails to USB sticks full of social security numbers so it shouldn’t really be a surprise that someone could steal bitcoin as well. Although it makes great clickbait, all this demonstrates is that computer security is really hard.
Legislation: Since December of 2014 the community has been anxiously waiting the revisions to New York’s Bitlicense proposal. Given how important New York is as a financial hub, it’s probably a good bet that other jurisdictions will follow with similar legislation once Bitlicense is announced. Because of this, legislation is the single greatest existential threat to bitcoin.

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.

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:

Contracts including an external Oracle. To my knowledge this has not yet been implemented.
m-of-n / multisig transactions – requiring at least some number of private keys to be present. This has been implemented with varying degrees of wallet support.
Securely and permanently storing arbitrary data inside the blockhain. Implemented and what we’re interested in!

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:

Make sure the private key field is populated
Under “Check Address” click “Refresh” to get the info about the public address
If there are any unspent transactions, click one to use it in the new transaction
If you want to actually send some Satoshi fill in a destination address and amount
Otherwise, you can enter up to 40 bytes of data in the OP_RETURN field
Click “Send” and you should see the transaction ID that was created
You can view the details for the transaction on https://blockchain.info/

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.

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.

So what are some key takeaways from using bitcoinj?

Test on the TestNet: Although debugging new code with live money would be thrilling. the TestNet allows you to develop against the Bitcoin network without using “live” coins. With bitcoinj, if you instantiate TestNet3Params you’ll connect into the Testnet.
TestNet Fountains: Testing is pretty tough without some coins but luckily you can use fountains to grab some. http://faucet.xeno-genesis.com/ worked well for me to grab some coins. Just a heads up, TestNet transactions take awhile to get broadcast and included into the Blockchain so be patient.
Extend WalletAppKit: WalletAppKit is a utility class which helps bootstrap everything you need for a SPV wallet and will save you some headaches. I started off trying to hand roll everything and quickly switched over to extending WalletAppKit.
Chain API: Since the Chain API can be used on the TestNet it’s useful for testing your own applications. Specifically, Bitcoinj treats sending and receiving coins to “yourself” weirdly so it’s more effective to use Chain to test transactions.
Coin.parseCoin: Sorting out how many Satoshis you want to send is surprisingly difficult since sendCoins accepts a Coin object. Luckily, Coin.parseCoin will accept a BTC value and return representative Coin object.
Blockchain downloads and wallet start up slow down development: Even in SPV mode, it still takes a non-trivial amount of time to “catch up” if your client hasn’t been running for awhile. On top of that, starting up the wallet takes a few minutes since it has to discover and connect to beers. What this translates to is resuming development after being away for a while is slow and the “edit, compile, test” loop isn’t as tight as usual.
It’s real money: This should go without saying but once you’re running on the live Bitcoin network you’re playing with real money so be careful. If your keys get out anyone will be able to move your coins out of your addresses. So be careful what you check in on git and if you’re building something public definitely take a second to lock down your server.

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!

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!

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…

Tag: bitcoin

Bitcoin: Looking forward to 2015

Bitcoin: Creating transactions with OP_RETURN outputs

Bitcoin: Tips for building a native Bitcoin app