Hey @domwoe here is our proposal for working on this bounty
Proposal for an IC Watchtower Canister
Problem:
Lightning network channels can be unilaterally closed 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.
Solution:
An IC Watchtower canister is 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.
Implementation:
The IC Watchtower canister can be implemented using the following steps:
- Create a canister that can store the following data:
- The lightning channel UTXO
- The channel state data
- The latest balance of the parties involved
- A cryptographic commitment to the channel state data
- Create a function that allows the canister to monitor the blockchain for commitment transactions.
- This function should use HTTPS outcalls to read any commitment transactions issued by any of the parties.
- If the function detects a commitment transaction, it should verify the cryptographic signature and check to see if the commitment transaction is valid.
- If the commitment transaction is valid, the function should update the channel state data and the latest balance of the parties involved.
- Create a function that allows the canister to submit a penalty transaction should the counterparty maliciously attempt to close the channel with an old state.
- This function should use HTTPS outcalls to broadcast a penalty transaction to the lightning network.
- The penalty transaction should be structured in such a way that it can only be claimed by the canister if the counterparty has attempted to close the channel with an old state.
Technical details:
- The cryptographic commitment to the channel state data can be implemented using a variety of techniques, such as a hash function or a Merkle tree.
- The function that monitors the blockchain for commitment transactions can be implemented using a variety of techniques, such as subscribing to a block notification service or periodically polling the blockchain.
- The function that submits a penalty transaction should the counterparty maliciously attempt to close the channel with an old state can be implemented using a variety of techniques, such as broadcasting a signed transaction to the lightning network or using a watchtower service.
More Details:
- Create a new canister project using the Motoko programming language.
- In the canister’s source code, create a struct to store the channel state data. This struct should include the following fields:
- The lightning channel UTXO
- The latest balance of the parties involved
- Create a function to generate a cryptographic commitment to the channel state data. This function can use a variety of techniques, such as a hash function or a Merkle tree.
- Create a function to store the channel state data and the cryptographic commitment in the canister’s storage.
- Create a function to retrieve the channel state data and the cryptographic commitment from the canister’s storage.
-
Here is a pseudocode example of a function that allows the IC Watchtower canister to monitor the blockchain for commitment transactions and update the channel state data and the latest balance of the parties involved:
function monitorBlockchainForCommitmentTransactions() {
// Use HTTPS outcalls to read any commitment transactions issued by any of the parties.
// This can be done by subscribing to a block notification service or periodically polling the blockchain.
commitmentTransactions = getCommitmentTransactions();
// Verify the cryptographic signature of each commitment transaction.
// This can be done using the IC’s built-in cryptography features.
for (commitmentTransaction in commitmentTransactions) {
if (!verifyCryptographicSignature(commitmentTransaction)) {
// The commitment transaction is invalid.
continue;
}
`// The commitment transaction is valid.
// Update the channel state data and the latest balance of the parties involved.
updateChannelStateDataAndLatestBalance(commitmentTransaction);`
}
}
-
There are two main ways to monitor the blockchain for commitment transactions:
Subscribing to a block notification service:
A block notification service is a service that sends notifications to subscribers when a new block is added to the blockchain. This allows subscribers to be notified of new commitment transactions immediately after they are added to the blockchain.
To subscribe to a block notification service, the IC Watchtower canister would need to create an account with the service and provide a callback URL. When the service detects a new block, it would send a POST request to the callback URL with the details of the new block.
The IC Watchtower canister would then need to parse the new block and extract any commitment transactions. Once the commitment transactions have been extracted, the canister can verify their cryptographic signatures and update the channel state data and the latest balance of the parties involved.
Periodically polling the blockchain:
Periodically polling the blockchain involves periodically checking the blockchain for new blocks. If a new block is found, the new block is downloaded and parsed to extract any commitment transactions. Once the commitment transactions have been extracted, the canister can verify their cryptographic signatures and update the channel state data and the latest balance of the parties involved.
The frequency at which the IC Watchtower canister polls the blockchain will depend on a number of factors, such as the desired level of security and the cost of polling the blockchain.
Which method to choose:
-
Subscribing to a block notification service is the most efficient way to monitor the blockchain for commitment transactions. However, block notification services can be expensive, especially if the canister needs to monitor a large number of channels.
-
Periodically polling the blockchain is a less efficient way to monitor the blockchain for commitment transactions, but it is also less expensive. The frequency at which the canister polls the blockchain can be adjusted to balance the cost and security of the system.
The IC Watchtower canister can be implemented to use either method of monitoring the blockchain for commitment transactions. The choice of method will depend on the specific requirements of the canister.
-
To create the function that allows the IC Watchtower canister to submit a penalty transaction should the counterparty maliciously attempt to close the channel with an old state, we can use the following steps:
- Create a function that can generate a penalty transaction.
- This function should take the channel state data and the latest balance of the parties involved as input.
- The function should generate a penalty transaction that is structured in such a way that it can only be claimed by the canister if the counterparty has attempted to close the channel with an old state.
- Create a function that can broadcast a penalty transaction to the lightning network.
- This function should take a penalty transaction as input and broadcast it to the lightning network.
- Combine the two functions into a single function that can submit a penalty transaction should the counterparty maliciously attempt to close the channel with an old state.
Here is a pseudocode example of the function:
`function submitPenaltyTransaction(channelStateData, latestBalance) {
// Generate a penalty transaction.
penaltyTransaction = generatePenaltyTransaction(channelStateData, latestBalance);
// Broadcast the penalty transaction to the lightning network.
broadcastPenaltyTransaction(penaltyTransaction);
}`
This function can be implemented using the Motoko programming language. The function should use the IC’s built-in cryptography features to generate and sign the penalty transaction. The function should also use the IC’s built-in networking features to broadcast the penalty transaction to the lightning network.
Once the function is implemented, it can be used to monitor lightning network channels for malicious closure attempts. If the function detects a malicious closure attempt, it can submit a penalty transaction to the lightning network to protect the canister’s funds.
Security:
The IC Watchtower canister should be implemented with the following security considerations in mind:
- The canister should be tamperproof. This can be achieved by using the IC’s built-in security features, such as Motoko’s type system and the IC’s consensus mechanism.
- The canister should be highly reliable and highly available. This can be achieved by using the IC’s built-in reliability and availability features, such as replication and sharding.
- The canister should be able to detect and prevent malicious activity. This can be achieved by using a variety of techniques, such as signature verification and monitoring for unusual activity.
Comparison to Bitcoin watchtowers:
Bitcoin watchtowers work in a similar way to IC Watchtower canisters. Bitcoin watchtowers monitor the blockchain for commitment transactions and submit justice transactions if the counterparty attempts to close the channel with an old state.
One key difference between IC Watchtower canisters and Bitcoin watchtowers is that IC Watchtower canisters can be implemented in a tamperproof and highly available way using the IC’s built-in security features.
Another key difference is that IC Watchtower canisters can use HTTPS outcalls to read commitment transactions issued by any of the parties. This means that IC Watchtower canisters can be used to monitor lightning network channels that are not hosted on the IC.
Benefits:
The IC Watchtower canister provides a number of benefits, including:
- Increased security: The canister can help to protect lightning network channels from malicious closure attempts.
- Reduced risk: The canister can help to reduce the risk of losing funds due to a malicious closure attempt.
- Peace of mind: The canister can provide peace of mind for lightning network users, knowing that their channels are being monitored and protected.
Cost:
The cost of implementing the IC Watchtower canister will depend on a number of factors, such as the complexity of the implementation and the desired level of security and reliability. However, it is expected that the cost will be relatively low, given the IC’s efficient and scalable architecture.
Conclusion:
The IC Watchtower canister is a valuable tool for lightning network users. It can help to protect channels from malicious closure attempts and reduce the risk of losing funds. The canister is also relatively inexpensive to implement, making it a cost-effective way to improve the security of lightning network channels.
Bounty:
I propose a bounty of USD 5’000 in ICP for the implementation of the IC Watchtower canister.
Timeline:
I propose a timeline of 2 months for the implementation of the IC Watchtower canister.
Team:
Me and Hritwik is interested in implementing the IC Watchtower canister.
Additional Notes:
- I am open to suggestions for improving the proposal.
- I am also open to discussing other aspects of the bounty, such as the budget and the timeline.
Thank you for your time and consideration.
