Blockchain Applications

This chapter will be about all the features offered by the bitcoin blockchain as an application platform. We will consider the application building primitives, which form the building blocks of any blockchain application.

The bitcoin system was designed as a decentralized currency and payment system. However, most of its functionality is derived from much lower-level constructs that can be used for much broader applications. It can become an application platform offering trust services to applications, such as smart contracts.

Building Blocks (Primitives)

When operating correctly and over the long term, the bitcoin system offers certain guarantees, which can be used as building blocks to create applications. These include:

  • No Double-Spend
  • Immutability
  • Neutrality
  • Secure Timestamping
  • Authorization (Digital Signatures)
  • Auditability
  • Accounting (inputs always equal outputs + fees)
  • Nonexpiration (valid transaction doesn’t expire)
  • Integrity
  • Transaction Atomicity (either mined or not)
  • Discrete Units of Value (Outputs can either be spent or unspent)
  • Quorum of Control (multisignature scripts)
  • Timelock/Aging
  • Replication (on every node)
  • Forgery Protection (it’s not possible to spend non-existing output)
  • Consistency
  • Recording External State (a transaction can commit a data value, via OP_RETURN)
  • Predictable Issuance (≤21 million, at a predictable outcome)

The list of building blocks is not complete and more are added with each new feature introduced into bitcoin.

Applications from Building Blocks

The building blocks offered by bitcoin are elements of a trust platform that can be used to compose applications. Here are some examples of applications that exist today and the building blocks they use:

Proof-of Existence (Digital Notary)

Immutability + Timestamp + Durability. A digital fingerprint can be committed with a transaction to the blockchain, proving that a document existed (Timestamp) at the time it was recorded. The fingerprint cannot be modified ex-post-facto (Immutability) and the proof will be stored permanently (Durability).

This is how it works: You simply hash your file. Afterwards, you include the hash in a transaction which uses the OP_RETURN operator. ProofofExistence provide a user interface for this process.

Kickstarter (Lighthouse)

Consistency + Atomicity + Integrity. If you sign one input and the output (Integrity) of a fundraiser transaction, others can contribute to the fundraiser but it cannot be spent (Atomicity) until the goal (output value) is funded (Consistency).

Payment Channels

Quorum of Control + Timelock + No Double Spend + Nonexpiration + Censorship Resistance + Authorization. A multisig 2-of-2 (Quorum) with a timelock (Timelock) used as the “settlement” transaction of a payment channel can be held (Nonexpiration) and spent at any time (Censorship Resistance) by either party (Authorization). The two parties can then create commitment transactions that double-spend (No Double-Spend) the settlement on a shorter timelock (Timelock).

Counterparty

Here is the official describtion of Counterparty:

“The Counterparty protocol is open source and extensively tested. Besides allowing users to create and trade any kind of digital token, Counterparty enables anyone to write specific digital agreements, or programs known as Smart Contracts, and execute them on the Bitcoin blockchain. …. By using the Bitcoin’s decentralized ledger network and Counterparty’s built-in scripting language, real-world scenarios can now be transformed into code and executed automatically with no need for an intermediary.”

It uses the OP_RETURN opcode or metadata in the place of addresses in 1-of-N multisignature transactions to implement a protocol layer. The additional protocol layer can be interpreted by applications that are Counterparty-aware

Counterparty can be used as a platform for other applications and services, in turn. For example, Tokenly is a platform built on top of Counterparty that allows content creators, artists, and companies to issue tokens that express digital ownership and can be used to rent, access, trade, or shop for content, products, and services. Other applications leveraging Counterparty include games (Spells of Genesis) and grid computing projects (Folding Coin).

Sidechains

Sidechains are a separate blockchain, that is connected to a main blockchain through a two-way peg. Two-way peg refers to the mechanism by which coins are transferred between sidechains and back at a fixed or otherwise deterministic exchange rate.

Two-way peg

Actually, if you transfer coins from bitcoin to a Sidechain, the coins are not really transferred, but locked. While the funds are locked, you get the same amount of coins on the Sidechain. In this way, double-spending is blocked. The coins on the bitcoin blockchain can be unlocked locking the corresponding coins on the Sidechain.

The Sidechain helps to process data from the main blockchain. This is a workaround for the tradeoff between security and speed, which we would have by scaling up the main chain, for example bitcoin.

Federation

Federation describes the middleman between the two chains. It controls the funds and assets between the two chains and can be controlled by either cooperations or plain code.

Some Sidechains don’t need a federation, but they are useful.

However, the Sidechain is still responsible for their own security and need their own validators/miners.

It is even possible to mine both, the Side- and main chain at once, without requiring more processing power (Merge-Mining).

Payment Channels and State Channels

Payment channels are part of the broader concept of a state channel, which represents an off-chain alteration of state, secured by eventual settlement in a blockchain.

They allow transaction between two parties to be held outside of the bitcoin blockchain (off-chain).

Actually, the term channel is a metaphor. State channels are virtual constructs represented by the exchange of state between two parties, outside of the blockchain.

Basic Concept of State Channels

In the entire lifetime of the channel, only two transactions need to be submitted for mining on the blockchain. The first one is called the anchor transaction (or funding transaction), which establish a channel.

The two parties then exchange signed transactions, called commitment transactions, that alter the initial state. These transactions are valid transactions in that they could be submitted for settlement by either party, but instead are held off-chain by each party pending the channel closure.

When exchanging commitment transactions the two parties also invalidate the previous states, so that the most up-to-date commitment transaction is always the only one that can be redeemed. 

Finally, the channel can be closed either cooperatively, by submitting a final settlement transaction to the blockchain, or unilaterally, by either party submitting the last commitment transaction to the blockchain. A unilateral close option is needed in case one of the parties unexpectedly disconnects. The settlement transaction represents the final state of the channel and is settled on the blockchain.

How Payment Channels work

Firstly, the two parties pay bitcoin to a 2-of-2 multisignature address, each of them holding a key. Here is an example for demonstration:

Funding transaction (on-chain):

Bob 1 BTCAlice 1 BTC
Bob and Alice set up a payment channel by creating a 2-of-2 multisignature address. Both are paying 1 bitcoin to this address.

Commitment transaction #1 (off-chain):

Bob 1,5 BTCAlice 0,5 BTC
Alice pays Bob 0,5 BTC. This is done by creating a transaction which would send 1,5 BTC to Bobs personal address and 0,5 BTC back to Alice address. Both parties sign and can verify the this transaction. However, this transaction isn’t added to the blockchain.

…many commitment transactions later…

Settlement transaction (on-chain):

Bob 0,76 BTCAlice 1,24 BTC
After many commitment transactions, they want to close the payment channel. This is done by adding the last transaction to the blockchain.

Some notes:

  • If, for example, Bob doesn’t sign transactions after the funding transaction, the funds are effectively lost (both signatures are required).
  • Alice could take any of the commitment transactions Bob has countersigned and transmit one to the blockchain.
Importance of Timelocks

Both of these problems can be solved with timelocks. Alice constructs the funding and refund transactions at the same time. She signs the funding transaction but doesn’t transmit it to anyone. Alice transmits only the refund transaction to Fabian and obtains his signature.

The refund transaction acts as the first commitment transaction and its timelock establishes the upper bound for the channel’s life.

Now that Alice has a fully signed refund transaction, she can confidently transmit the signed funding transaction knowing that she could redeem the funds in the future.

Every commitment transaction the parties exchange during the life of the channel, will be timelocked into the future. But the delay will be slightly shorter for each commitment so the most recent commitment can be redeemed before the prior commitment it invalidates.

This implementation needs nothing more than absolute transaction-level timelocks (nLocktime). Script-level timelocks, CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY, can be used to construct more flexible and complex state channels.

Final Words

These are just a few examples of blockchain applications. In the future, many more will come and expand the scope of bitcoin beyond payments and beyond financial instruments, to encompass many other applications where trust is critical.

Complex payment channels, like the Lightning network, is rising at a phenomenal speed which will help people all over the world. I’m really excited about what the future holds for us.