Some of you might be aware of the “other” Bitcoin blockchain — testnet3 — which is mined in parallel to the main blockchain — mainnet — and since coins on testnet are entirely worthless we can develop safely without our mistakes being too costly.
Testnet coins are worthless - but useful. They are useful because they are worthless.
To receive testnet coins we can either mine them or withdraw some from a faucet. Although the difficulty of mining on testnet is orders of magnitudes lower than on mainnet it still takes too long for our needs. A faucet is simply a website run by a Bitcoin volunteer, who has mined some coins, where we can ask to be sent some coins to our wallets.
Maybe not so surprisingly Xenog, one of the developers of Haskoin, is such a volunteer and using his faucet we can acquire some coins. I requested 0.3 coins which I received moments later to my wallet.
It’s time to get our hands dirty. Let’s begin bootstrapping our Haskell development environment. Before we proceed it’s probably fair to note that it’s very early days for Bitcoin development using Haskell and like users of most languages one should expect the Bitcoin libraries to be changing rapidly.
Never the less the authors of Haskoin have done a remarkable job implementing a Bitcoin library in Haskell from scratch — this includes most (if not all) the low-level elliptic curve cryptography functionality. They are distributing the library with a public domain license but their aim is to build a commercial wallet service on top of the library. Please consider signing up for their service to show them your support.
Now I will show you how to create a sandboxed environment for your Bitcoin projects. This will reduce the risk of dependency conflicts (a.k.a. dependency hell) by installing a sandboxed version of all the dependencies independent of other projects. Later we will see how we can share a sandbox between different Bitcoin projects. We will also likely require the bleeding edge development version of Haskoin pulled from GitHub and in due time I’ll show you how to link the development version to your sandboxed project.
In this blog post I’m going to concentrate on Bitcoin wallets which will be our foundation for a more developer-oriented discussion. Wallets are analogous to web browsers in that they are the main interface for end users to interact with the network. In its simplest form it is a file which contains a collection of private keys. In addition the wallet software usually takes care of communicating with peers, managing the blockchain and keeping records of wallet transactions.
The reference wallet implementation,
bitcoind, is as previously discussed at the same time a full node which means it can take several days to sync with the rest of the network and the copy of every transaction from the inception of Bitcoin till present time consumes between 20 and 30 GB of hard disks.
In some cases the blockchain management is either impractical or impossible - for example in the case of mobile wallets. Without mobile wallets Bitcoin’s adoption is severely diminished. This has lead to two different proposals which are quite different:
Simple Payment Verification (SPV) aims to reduce the amount of blockchain data needed to verify transactions. This is mostly achieved by storing block headers only for transactions which are not managed by the wallet and reduces the data to roughly 8 MB. This seems to be the preferred methodology of the Bitcoin core developers but there is still a significant overhead in managing the peer to peer connections. Multibit is probably the most popular SPV wallet implementation.
Stratum wire protocol which outsources the management to a node containing the full blockchain - a stratum server - and allows the wallet to communicate with the node using JSON-RPC over multiple transport layers. Historically the protocol was used by the Electrum lightweight wallet only and it’s just recently that the protocol is being proposed formally. This method sacrifices a bit of anonymity and security for convenience. However client implementations can connect to multiple stratum servers and only accept blockchain data if the majority of the stratum servers agree.
There are other types to consider like web wallets which usually are full node wallets implemented as a service. This implies a complete trust between the wallet owner and the service provider. Another interesting type of wallets are “wallet protection services” that are springing to life after the M-of-N Standard Transactions proposal was accepted.
In my future blog posts I’ll be exploring different implementations but first things first; next up bootstrapping our development environment.
Bitcoin is an exciting new technology invented by the mysterious Satoshi in 2009 which has been gaining some serious traction in the last few months. Although there are many introductory blog posts about Bitcoin there aren’t necessarily many which tackle the subject from a developer’s perspective.
I am a bit of a late-comer to the Bitcoin scene only to have started to pickup interest in late 2013 and then purely from a functional perspective which means I didn’t care so much about Bitcoin as a store-of-value but more as a transfer-of-value kind of mechanism. Since then I have been absorbing every piece of Bitcoin information I can get my hands on. Slowly I have started to realize that its true potential is far beyond the promise of being able to send money securely and cheaply from A to B. If this potential materializes I’m guessing that the monetary value of bitcoins will increase by a factor of 10 - 50 over the coming decade (from its current $600 value).
To further explore the possibilities of Bitcoin I’m going to be experimenting with it by writing some Haskell code and blogging about the experience. My choice of using Haskell will of course limit the number of readers but I hope to advance the Bitcoin ecosystem for Haskell a bit along the way. I would like to set the scene by defining some basic terminology in a paragraph or two.
Bitcoin is a distributed peer-to-peer database which collects transactions into an ordered chain of blocks, called the blockchain. Transactions are signed and verified using public key cryptography. I am going to assume basic knowledge of public key cryptography and only mention that the creators of Bitcoin chose elliptic curve algorithms as the basis for deriving the public key from the private key instead of its more common counterpart, DSA/RSA.
In general there are three different kinds of peers running the Bitcoin network; miners, nodes and wallets. To complicate matters peers can be a linear combination of those peer types, e.g. the original
bitcoind client is a full node and a wallet which can be run as a miner as well.
Since the database is distributed where miners and nodes keep a full copy of the database there must be a way to agree on the contents of the database. In Bitcoin this is achieved by letting the miners vote (a.k.a. proof of work) and the number of votes is proportional to the number of CPU cycles available to the miner. This means that the database can become temporarily inconsistent but as long as no single party controls the majority of the CPU power in the network the database will safely converge to a unified version.
Nodes receive blocks and transactions from peers. Once proven cryptographically valid the node stores and relays the block or the transaction to its peers. The purpose is to improve the time taken to distribute data within the network, which usually happens within seconds.
In part 2 I will be taking a closer look at wallets, their purpose and different implementations.