Status: Open
Project Type: Cooperative/Contest - Multiple workers can submit work and the bounty is shared
Time Commitment: Days - weeks
Experience Level: Intermediate/Advanced
Size: USD 5’000 in ICP (at time of distribution)
Deadline: Open
Description
A payment channel on the lightning network is essentially a 2-of-2 multi-sig contract between parties holding Bitcoin. From the perspective of the blockchain, bitcoin is held cooperatively by the 2 parties while each party maintains a local record of its respective ownership. The 2 parties can cooperate at any time to update their balances as frequently as they see fit without making any on-chain Bitcoin transactions.
As long as both parties sign a closure transaction the channel can be closed in a cooperative manner. However, channels can be closed unilaterally by either party via a commitment transaction. If your node goes offline for an extended period of time, the counterparty may attempt to force close the channel via an outdated commitment transaction.
An IC Watchtower canister would be a tamperproof, high reliability, high availability solution that will constantly monitor the channel state data and submit a penalty transaction should the counterparty maliciously attempt to close the channel with an old state.
Requirements
The canister allows for a lightning channel UTXO to be monitored
The canister allows for channel state data to be backed up.
The canister stores and updates the latest balance of the parties involved
The canister is able to read any closure or commitment transaction issued by any of the parties using HTTPS outcalls.
The canister is able to submit a penalty transaction should the commitment transaction be malicious.
Hey @domwoe, @timo I’ve been trying to understand this bounty but I’m quite new to the bitcoin ecosystem so it’s a bit challenging for me. Here is my current understanding:
The canister allows for a lightning channel UTXO to be monitored.
The lightning nodes need to register themselves to a watchtower, and for that the watchtower interface has to follow these specs. I guess I could reuse and adapt the code from rust-teos to run it inside a canister, but I struggle to understand how the RPC communication would work between the node and the canister. Is there any example or guide on how to talk with a canister via RPC?
The canister allows for channel state data to be backed up.
The canister stores and updates the latest balance of the parties involved
By channel state you mean the encrypted penalty transaction and locator received for every transaction done via the registred channels right ? Cause I’ve read that the balances are never revealed to the watchtower.
The canister is able to read any closure or commitment transaction issued by any of the parties using HTTPS outcalls.
My guess is using the HTTPS outcalls to browse a bitcoin explorer (e.g. blockstream.info), and then check if any tx id starts with one of the locator stored in the canister.
The canister is able to submit a penalty transaction should the commitment transaction be malicious.
I was hoping this could be detected by contacting the Bitcoin canister and no trusted third party would be required.
This bounty definitely requires a very deep understanding of Bitcoin, lightning and the Bitcoin canister infrastructure available on the IC. It might also be underestimated by an order of magnitude in terms of work required because there are so many details to figure out.
Yeah it’s also more complex that what I initialy thought, I could definitely use some guidance.
In the rust-teos implementation, the watcher compares the list of locators with the list of transactions from the last block, this every time a new block is received.
Right now I don’t think it’s possible to directly query bitcoin blocks, I don’t see any method allowing that on the system canister.
I don’t think the faulty commitment transaction will ever appear in the list of the transaction_ids returned by the method bitcoin_get_utxos if we use the public key of the node that subscribed to the watchtower as argument, or ? I guess one should call bitcoin_get_utxos with the multi_sig btc address of the channel instead, but the watch tower does not have this information.
