To scale Bitcoin payments, the Lightning Network was designed such that peers can exchange payments off-chain through a payment channel. In essence, a payment channel is a financial relationship between two peers that enables them to move funds to one another by updating the state of the balances for each peer.
In Lightning, each successful payment is represented by a valid and signed Bitcoin transaction that reflects how the funds locked in the funding transaction are currently distributed between the channel partners. This transaction is known as a “commitment transaction”.
Since every commitment is a valid Bitcoin transaction, it can be published on-chain at any time. This means that if for any reason you can’t negotiate a collaborative close transaction for the payment channel with your partner, you can just publish the last commitment transaction on-chain to close the channel.
But what if your channel partner tries to cheat and steal your money by publishing an old commitment transaction that reflects an old state where he has more funds on his side than he currently has?
There must be a way to incentivize peers to act honestly; this is where penalty transactions come into place.
A penalty transaction can be used by the cheated party to claim all the funds in the channel if the cheater publishes an old commitment transaction on-chain. This works because commitment transactions are represented by the HTLC contract, which enforces how the coins in a lightning channel can be spent.
In a scenario where Alice is paying Bob, the HTLC contract if written in English would say something along these lines:
- Alice will pay Bob 0.5 BTC if Bob can reveal the secret of the hash he provided to Alice and provide a valid signature for his public key.
- If Bob doesn’t reveal the secret in a 500-block period, Alice can get her 0.5 BTC back.
- All the funds locked in the channel can be redeemed by whoever can provide a valid signature for the revocation public key present in this contract.
This third clause is what is used by the cheated party to create a penalty transaction. Let’s follow the lifetime of the channel in the images above and simulate a penalty transaction.
Alice starts by broadcasting a funding transaction on-chain which locks 1 BTC in the 2-of-2 multi-signature output that can only be spent if both Alice and Bob sign the transaction. After that, Alice and Bob will hold their respective transactions off-chain until one or both of them decides to close the channel. The first transaction that is held off-chain is a refund transaction that pays Alice her 1 BTC back.
With the funding transaction confirmed and the refund transaction created, Alice and Bob can update the channel state. Initially, Alice pays Bob 0.2 BTC. Behind the curtains, Alice’s node sends a “commitment signed” message to Bob’s node. Bob’s node responds to this message with a “revoke and acknowledge” message to “revoke” the refund transaction and acknowledge the new commitment.
The “Commitment Signed” message sent by Alice gives Bob the signature he needs to create a new commitment. Bob, in return, sends Alice the revocation key that can be used by her to punish Bob if he publishes the previous commitment on-chain.
Alice and Bob will negotiate the revocation keys based on information provided by both partners, therefore no party can unilaterally sign with the revocation key. The negotiation of the revocation keys at each new state of the payment channel means that both partners are agreeing on a new state for their channel and that the previous one is now considered invalid.
After the exchange of these messages, both parties have all the information they need to update the state of the channel safely. Each partner holds a slightly different version of the commitment transaction that reflects the new channel state.
Alice holds a commitment transaction with two outputs. The first one pays 0.8 BTC to Bob if he presents a valid signature for the revocation key or it pays 0.8 BTC to Alice after a 500-block delay. The second output pays Bob 0.2 BTC.
Bob, in his turn, also holds a commitment transaction with two outputs. One that pays 0.2 BTC to Alice if she presents a valid signature for the revocation key or it pays 0.2 BTC to Bob after a 500-block delay. The other output pays Alice 0.8 BTC.
This arrangement of asymmetrical transactions is used for every new commitment. One output pays the local balance to the local node after a prearranged delay or it pays the remote node if he can present a valid signature for the revocation key. The other output pays the remote balance to the remote node.
Now Alice advances the channel state by paying Bob 0.5 BTC. In this new state, Alice holds 0.3 BTC and Bob holds 0.7 BTC. They negotiate the new state by computing new revocation keys and creating a new commitment transaction.
Now Bob sends 0.2 BTC over to Alice. By now this should be easy! Note that because any of the commitment transactions can be published on-chain at any time, each partner needs to hold all respective revocation keys. Otherwise, they might be unable to punish the cheater. This is the commitment transaction for this state.
Let’s pretend that Bob goes rogue and tries to cheat on Alice. He notices that at one point he had 0.7 BTC on his local balance and cheats on Alice by publishing the commitment transaction for this channel state on-chain.
Even if this transaction gets confirmed on-chain, Bob has to wait for 500 blocks to be able to spend the 0.7 BTC locked in the first output. Alice’s node is watching Bitcoin’s confirmed and unconfirmed transactions. Since Bitcoin is a distributed network, the node will eventually detect Bob’s cheating attempt because it knows that the input corresponds to the funding transaction for Alice’s channel with Bob.
To penalize Bob’s cheating attempt, Alice will need the revocation key for this particular commitment. With this information in her hands, she can publish on-chain transaction that spends both outputs of Bob’s outdated commitment to a wallet she owns.
When Alice’s transaction gets confirmed on-chain, Alice will have successfully penalized Bob. Bob can’t spend the first output anymore because that would be a double spend – an attempt to spend an output more than once – which is a violation of Bitcoin’s consensus rules. It’s also worth noting that a penalty transaction moves all of the funds locked in the channel to the cheated party. This means that if Bob locks 1 BTC to a lightning channel and tries to cheat, he’ll lose 1 BTC.
Concluding
As we’ve seen, Lightning users need to constantly monitor Bitcoin’s blockchain and memory pool of unconfirmed transactions to be able to punish cheating attempts. Going offline for extended periods means risking the assets locked in lightning channels. Voltage’s Nodes can help you achieve better uptime when compared with using your own hardware. Hiring watchtowers to monitor the blockchain for you is also a good practice.
