Part I | OmniBOLT Detailed Introduction

Published in

OmniBOLT

6 min readMar 11, 2020

To help community better understand OmniLayer, OmniBOLT, Lightning Network and related programs, we make a solid essay to explain them in detail, and we break them down into two parts, this piece is the Part I. At the same time, we present the core module of OmniBOLT —— Atom Swap among Channels within the Part II, which can be checked here. So, let’s start to explore the lightning network flagship protocol: OmniBOLT !

Intro

Lightning network aims to scale the Bitcoin network, facilitating quick off-chain payment of Bitcoin among independent peers on the network. Based on its fundamental theory, OmniBOLT defines the quick circulation protocol for smart assets layer on Bitcoin network, especially for those issued by OmniLayer protocol.

Because of the fundamental support of smart asset, not only BTC instant payment is supported as the currently implemented LND and BOLT, but also the following advantages:

Instant payment of smart assets issued on OmniLayer.
Cross channel atomic swap of different assets.
Decentralized exchange on top of lightning channels with quick exchange speed.
Collateral Lending contract based on atomic swap.
More flexible contracts for Decentralized Finance.

Reders who have interest shall directly go to the OmniBOLT specification repository on Github: chapter 6: DEX, Collateral Lending Contract, online store … ( https://github.com/LightningOnOmniLayer/Omni-BOLT-spec/blob/master/OmniBOLT-06-Mortgage-Loan-Contracts-for-Crypto-Assets.md) to seek more examples.

OmniBOLT greatly extends the ability of the Bitcoin lightning network. It appeared on August 1st, 2019.

Content

1 Lightning network and OmniLayer

2 Concept

3 Revocable Sequence Maturity Contract Explained

4 Hash Time-Locked Contract Explained

1. Lightning network and OmniLayer

Based on the fundamental theory of Lightning network, OmniBOLT specification describes how to enable OmniLayer assets to be transferred via lightning channels, and how can OmniLayer assets benefit from the novel quick payment theory. According to the layer-2 protocol BOLT (Basis of Lightning Technology) specification for off-chain bitcoin transfer, we propose this OmniLayer specific protocol to expand the horizons of the basic theory, to support wider perspective of assets.

OmniBOLT itself does not issue tokens. All tokens are issued on OmniLayer, and enter the OmniBOLT network through P2(W)SH backed channels, being locked on the main chain, and can be redeemed on the OmniLayer main chain at any time.

2. Concept

OBD: OmniBOLT Daemon.
channel: A channel refers to Poon-Dryja channel in lightning network. Channel is denoted by [Alice, USDT, Bob], which means Alice and Bob build a channel and fund it by USDT.
property: refers to tokens issued on OmniLayer, the same to “asset”.
RSMC: Revocable Sequence Maturity Contract is composed to punish malicious peers, who broadcasts elder commitment transactions to get more refund than what’s exactly in his balance.
HTLC: Hashed Time-Lock Contract chains multiple channels for transferring tokens from one peer to another, between whom there is no direct channel established.
Commitment Transaction: is created but not broadcast, and may be invalidated by next commitment transaction.
BR: Breach Remedy transaction is used in RSMC, that if Alice is cheated by broadcasting an elder commitment transaction, BR will send all her money to Bob.
RD: Revocable Delivery transaction pays out from the 2–2 P2SH transaction output, when Alice broadcast the latest legitimate commitment transaction. It sends money to Bob immediately and will send money to Alice after relative, say 100 blocks, from current block height.
HED: HTLC Execution Delivery
HT: HTLC Timeout
HBR: HTLC Breach Remedy, the breach remedy transaction in HTLC
HTRD: HTLC Timeout Revocable Delivery, the revocable delivery transaction in HTLC
HTBR: HTLC Timeout Breach Remedy, punishes Alice who broadcasts the elder hash time-locked transaction during the time lock period.
Atomic Swap: Atomic swap technology enables the exchange of one cryptocurrency for another without using centralized intermediaries, such as exchanges.
HTLSC: Hashed TimeLock Swap Contract, which consists of two separate HTLCs with extra specified exchange rate of tokens and time lockers.

3. Revocable Sequence Maturity Contract Explained

In order to avoid malicious counterparty who rejects to sigh any payment out of the P2SH transaction, so that the money is forever locked in the channel, we construct a Commitment Transaction where one is able to revoke a transaction. This is the first place we introduce the Revocable Sequence Maturity Contract (RSMC), invented by Poon and Dryja in their white paper, in this specification.

So the funding_created message does not mean both parties really deposite money into the channel. The first round communication is just simply setup a P2SH address, construct funding transaction but unbroadcasted and construct a RSMC. After that, Alice or Bob can broadcast the funding transaction to transfer real Omni assets into the channel.

The following diagram shows the steps we MUST do before any participants broadcast the funding/commitment transactions. BR1a (Breach Remedy) can be created later before the next commitment transaction is contructed.

In general, RSMC consists of the following 5 steps:

step 1: Alice constructs a temporary 2–2 multi-sig address using Alice’s temporary private key Alice2 and wait Bob’s signature: Alice2 & Bob.

step 2: Alice constructs a promise payment C1a out of Alice & Bob, one output is 60 USDT to Alice2 & Bob, and the other output is 40 USDT to Bob.

step 3: RD1a is the first output of C1a, which pays Alice 60 USDT, but with a sequence number preventing immediate payment if Alice cheat.

step 4: Bob signs C1a and RD1a, sends back to Alice.

step 5: OBD constructs refund transaction: C1a/RD1a.

This diagram shows a commitment transaction take place within a channel, illustrating how the status have been transferred.

4. Hash Time-Locked Contract Explained

“A bidirectional payment channel only permits secure transfer of funds inside a channel. To be able to construct secure transfers using a network of channels across multiple hops to the final destination requires an additional construction, a Hashed Timelock Contract (HTLC).”
— Poon & Dryja, The Bitcoin Lightning Network: Scalable Off-chain Instant Payments

A big and common misleading explanation in chaining the channels using HTLC is that if Alice wants to pay 10 USDT to David, she can use 2 hops to reach David:

Alice ---(10 USDT)---> Bob ---(10 USDT)---> Carol ---(10 USDT)---> David

It is confusing, because there is no concept of personal account in lightning. The only building block lightning use case is channel. So the correct hops are:

[Alice --(10 USDT)--> Bob] ==(Bob has two channels)== [Bob --(10 USDT)--> Carol] ==(Carol has two channels)== [Carol --(10 USDT)--> David][A, USDT, B] stands for the channel built by A and B, funded by USDT.

Alice transfers 10 USDT to Bob inside the [Alice, USDT, Bob] channel, then Bob transfers 10 USDT to Carol inside the [Bob, USDT, Carol] channel, and finally Carol sends 10 USDT to David in [Bob, USDT, Carol].

An HTLC implements this procedure:

If Bob can tell Alice R, which is the pre-image of Hash(R) that some one else (Carol) in the chain shared with Bob 3 days ago in exchange of 10 USDT in the channel [Bob, USDT, Carol], then Bob will get the 10 USDT fund inside the channel [Alice, USDT, Bob], otherwise Alice gets her 10 USDT back.

Equipped with HTLC, the internal transfer of fund [Alice --(10 USDT in HTLC)--> Bob] is then an extra unbroadcasted output from funding transaction embedded together with RD1a/BR1a.