Lightning Network and Atomic Swaps

Hydranet Team
Stakenet
Published in
8 min readOct 17, 2018

How does Lightning work and what are Atomic Swaps?

In this article we would like to explain what the Lightning Network is and why we can perform Atomic Swaps based on this second layer solution. If you like to read more about the benefits of our SegWit activation, take a look at our previous SegWit article and the updated Stakenet Whitepaper.

The Lightning Network

The heart of the Lightning Network are payment channels. So if you want to understand the Lightning Network, you should first understand the mechanism of unidirectional and bidirectional payment channels.

Unidirectional payment channels

Without Lightning, the classic payment channel only exists between two parties or peers. This technology uses the Multi-Signature (MultiSig) feature and a so-called Locktime. With the MultiSig mechanism you can generate a transaction that requires more than one private key to sign this transaction. This means that the coins associated within the transaction require both parties’ approval to be sent. The Locktime ensure that the coins within the MultiSig are non-transferable for a certain period. Specifically, this looks like this:

Unidirectional payment channels

Let’s say the parties Alice and Bob would like to exchange a very small amount of money more often. Therefore, Alice opens a payment channel by sending a fixed amount, for the example this amount is 10 XSN (that roughly around five USD) to the MultiSig address from Alice and Bob’s key. But before doing so, Alice needs to create a second transaction that sends the 10 XSN to an address she controls for a fixed period of time, let say one week. This transaction is her insurance for safety. If there are problems with Bob and the trade with him cannot take place, the money will be sent back in a week to the address controlled by Alice. The only way to harm her is, that Bob holds the 10 XSN as a “hostage” for a maximum of one week — but not forever. On the one hand, Alice and Bob have now established some kind of disposition-contract, on the other hand, Alice has taken a hedge. Due to this MultiSig transaction, microtransactions can now take place. For this, Alice continuously updates the balance within the MultiSig address. So, if Alice wants to transfer 1 XSN to Bob, she has to update the ownership in the MultiSig address accordingly. After the first actualization, Alice will have 9 XSN and Bob 1 XSN. This interactive update can continue until the Locktime has expired — instantly and without any fees. For all these steps above, only Alice signs the MultiSig transaction. Whereas Bob is free to sign the transaction until the end of the Locktime. As soon as Bob has also segregated the transaction, it will be called to the network. Only now the transaction is executed, and the payment channel will close. The problem of this solution is: If Bob acts profit-orientated, then he can wait until the Locktime has almost run out or Alice’s budget is exhausted. There is no incentive for him to treat Alice fair.

Bidirectional payment channels

The mechanism described above was called unidirectional channel, since only Alice could send Bob her coins. If Alice and Bob want to exchange payments with each other, they need a bidirectional channel. But the whole thing leads to a dilemma: Why should Bob, as in the example above, wait the entire Locktime instead of claiming the whole stake right away? To prevent this, Lightning uses a mechanism of mutual protection.

Bidirectional payment channels

Alice and Bob think of each an individual secure-number before setting up the channel and send each other a hash of this number. As in the case of a unidirectional payment channel, the payment partners generate a MultiSig address. Before sending their MultiSig address to the rest of the network, Alice and Bob each generate a so called Commitment Transaction. In this Commitment Transaction, the funds are split up: one part goes to the creator of the Commitment Transaction itself, and the second part goes to a time-locked address, to which the counterparty has access after a set time. Thus, both have created contracts that prevent fraud.

How do these channels become a network?

So far, so good, but such a bidirectional payment channel is just the first step in the right direction. Before the Lightning Network, all parties would have to create a new channel for each new payment activity. So, if Alice wants to do business with Carol, both business partners would have to set up a payment channel — regardless of whether Carol and Bob already exchange XSN coins or not. Furthermore, such a kind of peer-to-peer channel would be distorted to an extreme and therefore would not be efficient. One approach for subscribers to solve this problem would be to pass transactions on different payment channels. For example, Alice would be able to send money to Carol via Bob. The question is, can Bob be trusted? What is, if Bob is fraudulent, claims the money and just not pass it on? And how to ensure, that Bob does not shut down his Lightning node or has technical issues that forces him to set his node offline?

The Lightning Network

As a solution for these problems, the Lightning Network uses Hashed Timelock Contracts (HTLCs). They guarantee that these issues cannot happen. This works like: Carol thinks up a secret, which is a specific random number with the usage of a cryptographic proof. Carol gives the hash of this secret to Alice. This hash now becomes a pledge. Bob only receives a payment, if he knows this secret. This can be checked by Alice by using the hash. Bob passes the hash through again with the promise to pay, if the recipient knows the secret hash, too. In principle, the path between Alice and Carol may include other participants, all of whom use the hash as a pledge. Using HTLCs, payment channels can be linked between different parties. As you can see, participants in the network, who form a bridge between Alice and Carol as nodes, form the backbone of the Lightning Network. Their importance can be compared to that of miners or minters on the regular blockchain.

The blockchain continues to play a key role in the final settlement of payments and thus in the global consensus. But it is secondary, whether it is the Stakenet blockchain or any other blockchain which is SegWit compatible. Our Lightning Network can also interact with other cryptocurrencies, such as Bitcoin or Litecoin. Due to this, you can finally realize Atomic Swaps, where a channel is open, whose final settlement one saves on different blockchains. This theme leads over to the next part of this article.

Atomic Swaps

Atomic Swapping might be the closest thing to magic we have experienced thus far. It allows any user on one blockchain to ‘swap’ his asset with a peer he has never met on a completely different chain 100% trustless, instant, and with little to no fee involved. It is also the closest solution in protecting privacy while acquiring and trading assets. There is a catch however as Atomic Swaps still require assets to be “hot” and by nature all information associated with these transactions are required public for it to work properly. This is a step in the right direction as a peer to peer system is much more secure than a centralized point of exchange, but still not a perfect system. It is not difficult to spot identities in a P2P market, and with that being considered we figure a user may not want to spend or transact any more than necessary on these platforms. As XSN will have a compatible off chain network of our own, our features can be utilized to provide extra value to this network. This is where our chain comes into play by instantly atomic swapping into an XSN TPoS address, your newly swapped funds will automatically be safe offline and gain interest, without the need to perform extra steps in sending, receiving, or activation of any kind. Rewards gained from these addresses can also be exchanged into a different currency of your choice.

Atomic Swaps

For example, if Alice owns 1 Bitcoin but desires to have 10.000 XSN instead to generate a passive income, she would need sign up at an exchange, which provides trusted trading services as a third-party. However, with atomic swaps, if Bob owns 10.000 XSN and likes to take his profits in 1 Bitcoin instead, then Bob and Alice could make a trade without any need of a trusted third party due the trustless atomic swaps feature, provided by Stakenet.

To prevent any fraudulent behavior, our atomic swaps utilizes what is known as hash time-locked contracts (HTLCs) which are used by the Lightning Network, too. Once again: HTLCs enforce that the entire atomic swap process is truly trustless by ensuring both trading parties fulfill the requirements of the swap. HTLCs forces the recipient of a payment to acknowledge the receiving payment within a set timeslot by generating a cryptographical proof, we call proof of payment. Otherwise the recipient risks losing his right to the claim the set trading conditions to execute the swap.

In our trade example between Alice and Bob, consequently both parties need to submit their transaction to their respective blockchain (Alice on the Bitcoin blockchain, Bob on the XSN blockchain). For Alice to claim Bobs’ 10.000 XSN, she must produce a number that is only known by her to generate the cryptographic hash value to provide her proof of payment. For Bob to claim Alice 1 Bitcoin, he must specify the same number used by Alice, to generate the cryptographic hash to provide his proof of payment.

By entitling a HTLC as linking two blockchains together, the Lightning Network can be entitled as linking payment channels between the involved blockchains. To transact with each other, Alice and Bob must be linked through these payment channels., which are provided by the Lightning Network.

Further information

The advantages of using the Lightning Network to cross communicate between all blockchains within the Stakenet meta network can be summarized very well by using the following four criteria.

Instant payments: Lightning-fast instant payments across the entire blockchain without any limitations caused by the block confirmation times. Due to smart contracts, the security of the transactions is ensured without the need of an on-blockchain transactions, so that a payment speed of milliseconds to seconds can be achieved.

Scalability: Allows the processing of millions to billions of transactions per second across the network. This capability outperforms all previous legacy payment rails and attaches a payment per action/click is now possible without custodians or third-party services.

Low cost: Using an off-blockchain transaction setting profits in exceptionally low fees in the Lightning Network. This enables completely new use cases such as instant micropayments.

Cross blockchains: Cross blockchain transactions will be possible if both chains are connected due a compatible second layer protocol or are supporting the same cryptographic hash function on their own. Given that, it is possible to execute trustless transactions between different blockchains.

--

--