Revocation Secrets in Lightning Network Security
TECHNICAL
1/9/20252 min read


PROTECTING THE INITIAL DEPOSIT
Please see the first article on the lightning network before continuing as it gets technical. When the multi-sig is created and Alice funds it with 1 BTC in this case, both Alice and Bob sign a transaction Authorising Alice to withdraw the balance automatically upon its creation (Assuming she deposited it) making it a valid bitcoin transaction which can be broadcast on-chain at anytime to close the channel and allow the funds to be withdrawn, this is done to Allow Alice to withdraw her funds locked in the multi-sig wallet if Bob was to abandon the wallet and not sign any further transactions preventing valid transactions being broadcast from the multi-sig wallet
BROADCASTING PRIOR CHANNEL STATES TO THE BLOCKCHAIN
Alice is sending Bob 0.1 BTC a month through the channel within the lightning wallet as payment for his work. After the first month Alice would have sent 0.1 BTC so that Alice has 0.9 BTC and Bob has 0.1 BTC within the channel. After the first month Alice and Bob both sign a transaction updating the balances, with Alice having 0.9 BTC and Bob having 0.1 BTC. What is to stop Alice from broadcasting the previous valid transaction to the bitcoin network with her balance as 1 BTC and Bob's balance as 0 BTC, thus robbing bob? something called revocation secrets is the solution
ATTEMPTING TO BROADCAST PRIOR STATES
Assuming Alice is paying Bob for his work on a monthly basis, after each month a new valid commitment transaction (Valid bitcoin transaction not yet published to the blockchain) is created increasing the balance of Bob and decreasing the balance of Alice within the channel. Without extra security mechanisms in place, Alice would be able to publish the prior commitment transactions on chain and withdraw more than what she owns. In order to prevent this, these previous transactions will need to somehow made invalid so that only the latest state of the channel can be withdrawn on chain
Without any mechanisms, the commitment transaction logic would look like the following
Pay 0.9 BTC to Alice
Pay 0.1 BTC to Bob
On each commitment transaction, there is integrated logic in which if the revocation secret is known, then the funds meant to be paid to Alice will be paid to Bob along with the funds allocated to Bob, so he gets everything in this case and the logic would look like the following
if revocation secret:
pay 0.9 BTC to Bob
else:
pay 0.9 BTC to Alice
Pay 0.1 BTC to Bob
The revocation secret is published by Alice when a new transaction is created, allowing exploits to be closed
We can see that if Bob has the revocation secret and this transaction is published, then it follows the logic and Bob gets to take Alice's share, disincentivising her from publishing this transaction if Bob has the revocation secret (which would be when a new transaction is created). This would make it against the dishonest party's best interests to publish the previous transaction
Both Bob and Alice broadcast different revocation secrets to eachother with each transaction update




Get in Touch
We'd love to hear from you! Reach out for questions, feedback or other enquiries
Reach
info@bitesizedblockchain.com
Bite Sized is not affiliated with these brands in any way










Grab your daily web 3 byte