<div>Good morning list,<br></div><div><br></div><div>We were not able to discuss this topic much at recent summit, but I noticed that lnd has some code related to watchtowers already.&nbsp; 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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>I have seen recently, some paper about paying watchtowers by actually simulating breaches.&nbsp; You would give a watchtower some txid+blob pair, then send that txid and see if the watchtower claims it.&nbsp; If it does, then you have evidence of liveness and correct behavior, and have also paid for and incentivized the watchtower to operate correctly.<br></div><div><br></div><div>Note however that watchtowers would require to keep all encrypted blobs that are keyed to the same partial txid.&nbsp; 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.&nbsp; 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.&nbsp; However, this remains your counterparty best avenue of attack, is to simply spam your watchtower until it runs out of resources and crashes.<br></div><div><br></div><div>I have described the above problem before here: <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html</a> with an unsatisfactory solution.<br></div><div><br></div><div>--<br></div><div><br></div><div>I have also been thinking about watchtowers compatible with Decker-Russell-Osuntokun channels.<br></div><div><br></div><div><div>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.&nbsp; 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.&nbsp; 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? <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001264.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001264.html</a><br></div><div><br></div><div>I am curious what Conner and the other lnd developers are planning for these issues?&nbsp; You seem to be the first movers into this, and I cannot read go well enough to decipher what plans you have.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><br></div><div><br></div></div><div><br></div>