ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-12 📝 Original message: Good morning list, We ...
📅 Original date posted:2018-11-12
📝 Original message:
Good morning list,
We were not able to discuss this topic much at recent summit, but I noticed that lnd has some code related to watchtowers already. From my bare knowledge of go, it seems data structures and messages so far, without actual logic, but please inform me if I am incorrect.
I assume much of the watchtowers code and design in lnd is by Conner, simply because, he discussed this on this list earlier this year.
I have seen recently, some paper about paying watchtowers by actually simulating breaches. You would give a watchtower some txid+blob pair, then send that txid and see if the watchtower claims it. If it does, then you have evidence of liveness and correct behavior, and have also paid for and incentivized the watchtower to operate correctly.
Note however that watchtowers would require to keep all encrypted blobs that are keyed to the same partial txid. I.e. watchtowers need to store the pair in a set with the set looking at the entire txid+blob as the identity of the object. Otherwise it would be possible, if your watchtower is identified by your counterparty, for the counterparty to give the commitment transaction's txid with a randomly-generated blob to your watchtower before it gives the revocation key to you. However, this remains your counterparty best avenue of attack, is to simply spam your watchtower until it runs out of resources and crashes.
I have described the above problem before here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html with an unsatisfactory solution.
--
I have also been thinking about watchtowers compatible with Decker-Russell-Osuntokun channels.
As I understand, in a separate thread, laolu is promoting that Decker-Russell-Osuntokun channels can simply "update" the blob side of a txid-blob entry, with the txid being the kickoff/trigger transaction. As I point out, unless the watchtower identifies the user somehow, this is unsafe; if I can identify your watchtower, then after you update it but before I attack, I can "update" the blob side with a randomly-generated, invalid blob. And if the watchtower identifies the user, then this leaks the privacy of the user to the watchtower, and what would then be the point of encrypted blob? https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001264.html
I am curious what Conner and the other lnd developers are planning for these issues? You seem to be the first movers into this, and I cannot read go well enough to decipher what plans you have.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181112/b4c31c0c/attachment.html>;
📝 Original message:
Good morning list,
We were not able to discuss this topic much at recent summit, but I noticed that lnd has some code related to watchtowers already. From my bare knowledge of go, it seems data structures and messages so far, without actual logic, but please inform me if I am incorrect.
I assume much of the watchtowers code and design in lnd is by Conner, simply because, he discussed this on this list earlier this year.
I have seen recently, some paper about paying watchtowers by actually simulating breaches. You would give a watchtower some txid+blob pair, then send that txid and see if the watchtower claims it. If it does, then you have evidence of liveness and correct behavior, and have also paid for and incentivized the watchtower to operate correctly.
Note however that watchtowers would require to keep all encrypted blobs that are keyed to the same partial txid. I.e. watchtowers need to store the pair in a set with the set looking at the entire txid+blob as the identity of the object. Otherwise it would be possible, if your watchtower is identified by your counterparty, for the counterparty to give the commitment transaction's txid with a randomly-generated blob to your watchtower before it gives the revocation key to you. However, this remains your counterparty best avenue of attack, is to simply spam your watchtower until it runs out of resources and crashes.
I have described the above problem before here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html with an unsatisfactory solution.
--
I have also been thinking about watchtowers compatible with Decker-Russell-Osuntokun channels.
As I understand, in a separate thread, laolu is promoting that Decker-Russell-Osuntokun channels can simply "update" the blob side of a txid-blob entry, with the txid being the kickoff/trigger transaction. As I point out, unless the watchtower identifies the user somehow, this is unsafe; if I can identify your watchtower, then after you update it but before I attack, I can "update" the blob side with a randomly-generated, invalid blob. And if the watchtower identifies the user, then this leaks the privacy of the user to the watchtower, and what would then be the point of encrypted blob? https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001264.html
I am curious what Conner and the other lnd developers are planning for these issues? You seem to be the first movers into this, and I cannot read go well enough to decipher what plans you have.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181112/b4c31c0c/attachment.html>;