Category: Bitcoin

Bitcoin: Looking forward to 2015

By Ashish Datta | 1 Comment on Bitcoin: Looking forward to 2015

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.

Bitcoin: Creating transactions with OP_RETURN outputs

By Ashish Datta | Leave a Comment on Bitcoin: Creating transactions with OP_RETURN outputs

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.

Bitcoin: Tips for building a native Bitcoin app

By Ashish Datta | Leave a Comment on Bitcoin: Tips for building a native Bitcoin app

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!