[Bit]coin flipping: “Scala is a perfect match for Bitcoin”

Whether they realize it or not, more than 95 percent of all Bitcoin users use Bitcoin Core. Although there are nearly 400 people who have written code and had it merged into Bitcoin Core, there are ongoing initiatives to try and get more developers familiar with the Bitcoin Core code base. We talked to Chris Stewart, CEO and co-founder of SuredBits, about the current state of Bitcoin, the role of Bitcoin Core and what it’s like to implement a spv-node for the Bitcoin protocol in Scala.

JAXenter: You are a contributor to Bitcoin Core. How has Bitcoin Core evolved? Are there many developers eager to contribute to the open source project?

Chris Stewart: Bitcoin was started by a person (or group of people) under pseudonym ‘Satoshi Nakamoto’. Satoshi originally posted his white paper and hosted some code online outlying the concept of Bitcoin. The idea of digital cash was not a new one; still, Satoshi was able to combine various existing systems to actually solve the ‘double spend’ problem. Bitcoin Core has continued to attract developers. Nearly 400 people have actually written code and had it merged into Bitcoin Core, while many more have contributed to review, design, etc. We also have ongoing initiatives to try and get more developers familiar with the Bitcoin Core code base.

JAXenter: According to the official website, Bitcoin Core is “a direct descendant of the original Bitcoin software client released by Satoshi Nakamoto after he published the famous Bitcoin whitepaper.” What’s your take on that? Is Bitcoin Core the real deal or just an attempt to carry Satoshi Nakamoto’s work? Could you explain a bit?

Chris Stewart: Bitcoin Core is the reference implementation of Bitcoin. Some of the code in the code base was literally written by Satoshi Nakamoto who vanished in 2011. Almost all Bitcoin users use Bitcoin Core ( more than 95 percent). Bitcoin Core also has the most talented team of developers in the space which have brought some really innovative ideas to Bitcoin. There are other implementations, such as bitcoin-s which is a project I work on, to target other platforms like the JVM.

We have ongoing initiatives to try and get more developers familiar with the Bitcoin Core code base.

JAXenter: Why is Bitcoin Core 0.13.0 a major release and what’s next for Bitcoin Core?

Chris Stewart: We call major releases any release that ends in a .0. This release contains the code to deploy segregated witnesses to the network. this solves a few issues that have plagued the project for a while now while also offering a transaction throughput increase to the network. Segregated witnesses will actually be deployed to the network 0.13.1. After that, you can expect work on support for things like Lightning and Sidechains at the protocol level.

I don’t think there has been a successful blockchain besides the Bitcoin blockchain.

JAXenter: What attracted you to Bitcoin?

Chris Stewart: It’s a way to transfer money on the internet in a fast, trustless way. This wasn’t possible before Bitcoin. Now it is possible to build financial applications that are based on principled mathematics systems instead of policy-driven financial institutions. It also allows for permissionless innovation, which we have seen time and time again leads to economic growth and improvement of people’s lives.

JAXenter: It has become clear that blockchain has a future outside of Bitcoin. But do you think it can cannibalize the cryptocurrency? Can Bitcoin become obsolete?

Chris Stewart: It definitely won’t cannibalize the cryptocurrency. I don’t think there has been a successful blockchain besides the Bitcoin blockchain. There has a been a lot of smoke and mirrors, sales pitches, and vaporware, but nothing that is being used to transfer money/assets in production. I really doubt Bitcoin will become obsolete, just for the sheer fact the talented group of people that work on the project.

JAXenter: You are currently working on implementing a spv-node for the Bitcoin protocol in Scala. Why Scala? Could you talk a bit about this project?

Chris Stewart: Scala is a nice balance between principled languages like OCaml & Haskell and practicality like Java. Scala has things like immutability by default and algebraic data types, which go a long way in being able to reason about the current state of your system, and how adding new things (such as new contract types) change your system.

SPV (simple payment verification) is meant to be a lightweight bitcoin client that allows you to verify payments on the network with downloading the entire blockchain (~100GB worth of data). Scala has a nice library to build this called Akka, which allows you to build asynchronous typesafe systems — which is a perfect match for Bitcoin and other financial applications in my mind.

The bitcoin-s-spv-node project is still under heavy development, but if you would like to follow along (or contribute!) you can ‘star’ or ‘watch’ us on GitHub here.

Modeling Bitcoin payments with a finite state machine

We are currently working on implementing a spv-node for the Bitcoin protocol in Scala. One of the most obvious things you want to do with Bitcoin is a receive a payment, there are numerous ways to do this, but one of the simplest ways, in my opinion, is modeling it with a finite state machine.

From Wikipedia:

A finite–state machine (FSM) or finite–state automaton (FSA, plural: automata), or simply a state machine, is a mathematical model of computation used to design both computer programs and sequential logic circuits. It is conceived as an abstract machine that can be in one of a finitenumber of states.

If we think abstractly about a payment over the bitcoin network, a payment we are receiving from another user on the network has a certain set of states. We can model these various states with a finite state machine fairly easily, when one state is complete we transition to another state. Scala has a very useful library called Akka, which we are using for the networking on bitcoin network. Inside of Akka, there is support for finite state machines here using the `become` construct.

In bitcoin-s’ payment actor, we use this to transition from various states inside of the actor. For instance, when a payment is made to an address we request the full transaction using the GetData message on the bitcoin network. Once we receive the full transaction, we verify that an output on that transaction paid to our address.

There are 6 states that our payment actor goes through when confirming a payment on the bitcoin network

1.) Creates a bloom filter, sends the bloom filter to a node on the network

2.) Nodes matches the bloom filter, sends a txid that matched the filter back to us via an inventory message

4.) We verify the transaction given to us has an output that matches the address we expected a payment to.

5.) When another block is announced on the network, we send a merkle block message to our peer on the network to see if the transaction was included in that block.

6.) Verify that the transaction is included in the block with the information given by the merkle block message according to BIP37.

This is really useful to manage the various states that a bitcoin payment can be in. We have used finite state machines in other places, for instance, our PeerMessageHandler, which handles all of the logic for connecting to a peer on bitcoin network.

Gabriela Motroc is editor of JAXenter.com and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Recommended For You

Interviewed in this article

Chris Stewart

Chris Stewart is the CEO and co-founder of SuredBits, a California-based company which sells live data in exchange for bitcoin using the ‘pay per request’ model.