The Lightning network has a different security model than a traditional blockchain. In this blog post we are going to explain how the Lightning network is secured.
How is a Lightning Transaction different from a Bitcoin Transaction?
A Lightning transaction is a signed bitcoin transaction with a special smart contract that has not been included into the bitcoin blockchain yet. Normally transactions that have not been included in a blockchain are considered unsecure. This is because a miner has not spent money to attest to the validity of the transaction.
The smart contract attached to a Lightning transaction is what differentiates a Lightning transaction and a normal Bitcoin transaction. This smart contract allows us to chain unconfirmed transactions together in a secure fashion. The participants in a Lightning smart contract are allowed to repeatedly update the chain of unconfirmed transactions, with only the newest one being valid. This smart contract allows you to claim your peer’s money if they try to publish a old transaction state to the blockchain.
What is a Lightning Transaction State?
A Lightning transaction “state” is the just the balance of the Lightning transaction. For example, this balance could be
Chris: 3 BTC
Suredbits: 2 BTC
This means that Chris is receiving 3 bitcoin in this state, while Suredbits is receiving 2 bitcoin. A different state that is more advantageous to Chris, and less advantageous to Suredbits could be
Chris: 4 BTC
We always want the latest state in the lightning channel to be the only transaction that will be valid on the blockchain. As transactions occur over the Lightning channel some states are more advantageous to you, while other states are more advantageous to your counterparty. This property of “the latest state being the valid state” is achieved by having the special smart contract penalize people that try to broadcast old states.
As an example, let’s say I want to purchase a cryptocurrency market data subscription from Suredbits. I open a Lightning channel with Suredbits with an initial deposit of 5 bitcoin. That means the current state of the channel is:
Chris: 5 BTC
Suredbits: 0 BTC
Let’s assume that Suredbits charges 1 bitcoin for a market data subscription. I send 1 bitcoin over our Lightning channel to Suredbits, so the channel state looks like:
Chris: 4 BTC
Suredbits: 1 BTC
Now I start consuming the market data. Once the market data subscription is over, I may errantly decide that I want to try and cheat Suredbits and get my 1 bitcoin back. If I can successfully cheat by broadcasting the old transaction state I would have 5 bitcoin and Suredbits would have 0 bitcoin. This is bad since I received the data as advertised and I was able to get my money back. This is commonly known as a “charge-back” in the ecommerce world.
Why old Lightning Transaction states matter
The problem here is that I — “Chris”- had a favorable old state on Lightning, where I had 5 bitcoin and Suredbits had 0 bitcoin. If I can, I want to get my one bitcoin back and broadcast the old state to the bitcoin blockchain.
Lightning has been designed to prevent this with a smart contract. The smart contract says that
“If an old state is broadcast to the blockchain by your counterparty, you can take all of your counterparties money”.
So in my example above, if Chris tried to broadcast any old state to the blockchain — in our example where Chris had 5 bitcoin and Suredbits had 0 bitcoin — Suredbits could come and take all of Chris’ money.
This heavily dis-incentivizes cheaters like Chris from trying to broadcast an old state to the Lightning Network. It also protects good actors like Suredbits who are providing services in exchange for Lightning payments.
In December of last year Suredbits released the first ever cryptocurrency market data API where you can stream data and pay for it all on the Lightning Network.