Part II | 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 II, which starts with the core module of OmniBOLT — — Atom Swap among Channels. Also, you can check the Part I here. Now, let’s start to dig deeply into 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

5. Atom Swap among Channels

6. Applications：collateral lending, online pet store, etc

7. Implementation and API for wallet

5. Atom Swap among Channels

In general, atomic swaps take place between different blockchains, for exchanging tokens with no trust of each other. Channels defined in OmniBOLT can be funded by any token issued on OmniLayer. If one needs to trade his tokens, say USDT, for someone else’s Bitcoins, both parties are required to acknowledge receipt of funds of USDT and BTC, within a specified timeframe using a cryptographic hash function. If one of the involved parties fails to confirm the transaction within the timeframe, then the entire transaction is voided, and funds are not exchanged, but refunded to original account. The latter action ensures to remove counterparty risk.

The standard swap procedure between channels is:

- where Tx 1 transfers 1000 USDT to Bob in channel `[Alice, USDT, Bob]`, locked by Hash(R), t1 and Bob's signature.- Tx 2 transfers 1 BTC to Alice in channel `[Alice, BTC, Bob]`, locked by Hash(R), t2(`t2 < t1`) and Alice's signature .

Hashed TimeLock Swap Contract (HTLSC) consists of two seperated HTLCs with extra specified exchange rate of tokens and time lockers.

Simply there are 5 steps in a swap. In step 3, Alice sends R to Bob, hence she can unlock transaction 2 to get her 1 BTC in the channel [Alice, BTC, Bob]. Therefore Bob knows R, and use R to unlock his 900 USDT in the channel [Alice, USDT, Bob].

No participant is able to cheat. After inputting R in each channel, the transaction 1 and 2 turn into general commitment transactions, which is the same procedure that how an HTLC transforms to a commitment transaction.

In channel [Alice, USDT, Bob], Alice creates an HTLC and its mirror transactions on Bob side, with time locker t1, which in the diagram is 3 days as an example.

At the same time, Bob creates another HTLC in the channel [Alice, BTC, Bob] and its mirror transactions on Alice side, sending the agreed number of BTCs to Alice. Time locker t2 is set to be 2 days, less than t1=3 days.

Atomic swap is the foundation of lots of blockchain applications. Next chapter will present some examples, which are intuitive and will help our readers to build much more complex applications for real-world businesses.

6. Applications：collateral lending, online pet store, etc

Following examples use multi-stage atomic swaps for specific scenarios. The procedures shall be implemented as a piece of program written in a turing complete language, like Javascript or Solidity, calling OBD API to complete the fundamental tasks. All participants shall run the programs to check if all the transactions are valid and if the counterparties are honest.

Collateral Lending Contract (CLC)

Collateral Lending Contract serves this certain purpose:

“ You deposit something valuable as mortgage in an escrow account, and I lend money to you according to a proper LTV(Loan to Value). If you repay the loan within agreed deadline, Iwill return your mortgage. If you don’t, your mortgage will be mine. ”

Actually an HTLSC creates an escrow accounts for participants in a loan. We assume a normal scenario:

Bob wants to borrow 900 USDT from Alice, he uses his 1 BTC as collateral.

So Bob initiates a swap (HTLSC 1):

Bob → Alice: swap(amount = 1 BTC, property = USDT, exchange rate = 900, time_locker = 30 days, Hash(R1), …).

This creates HTLSC in channel [Alice, BTC, Bob].

Alice → Bob: swap_accepted(amount = 900 USDT, exchange_rate = 900, time_locker = 20 days, Hash(R1), …).

This creates HTLSC in channel [Alice, USDT, Bob].

Meanwhile, Bob needs to create the redeem swap (HTLSC 2) to get his 1 BTC back:

Bob → Alice: swap(amount = 900 USDT, property = BTC, exchange_rate = 1/900, time_locker = 60 days, Hash(R2), …).

This creates HTLSC in channel [Alice, USDT, Bob].

Alice → Bob: swap_accepted(amount = 1 BTC, exchange_rate = 1/900, time_locker = 50 days, Hash(R2), …).

This creates HTLSC in channel [Alice, BTC, Bob].

Only when the participants accepted the two swaps, and their OBDs helps to create all the corresponding transaction required by HTLSC, Bob is able to use R1 to get his 900 USDT by HTLSC 1 in channel [Alice, USDT, Bob], hence Alice gets 1 BTC as collateral from Bob.

And after a timeframe, Bob wants to redeem his 1 BTC. He uses R2 in HTLSC 2 to get his 1 BTC back by HTLSC 2 in channel [Alice, BTC, Bob], hence Alice gets her 900 USDT back in channel [Alice, USDT, Bob].

Of course, Alice can require a loan rate according to her knowledge of the price of BTC. For example, she requires Bob to create a swap with exchange rate 1/905. Then she will get 905 USDT when Bob redeems his BTC.

Online Pet Store

This example is one stage swap, which is quite straight forward:

Alice issues smart asset “PET” on OmniLayer, for each token represents a crypto cat.
Bob establishes an USDT channel and a PET channel with Alice, and funds the USDT channel.
Bob creates a HTLSC to pay Alice 100 USDT for one cat.

That’s it :-)