[Lightning-dev] Trustless WatchTowers?

ZmnSCPxj ZmnSCPxj at protonmail.com
Mon Apr 16 23:30:27 UTC 2018


Good morning Laolu,

> Hi ZmnSCPxj,
>
>> It seems to me, that the only safe way to implement a trustless WatchTower,
>> is for the node to generate a fully-signed justice transaction, IMMEDIATELY
>> after every commitment transaction is revoked, and transmit it to the
>> WatchTower.
>
> No, one doesn't need to transmit the entire justice transaction. Instead,
> the client simply sends out the latest items in the script template, and a
> series of _signatures_ for the various breach outputs. The pre-generated
> signature means that the server is *forced* to reproduce the justice
> transaction that satisfies the latest template and signature. Upfront, free
> parameters such as breach bonus (or w/e else) can be negotiated.

Thank you, I understand.

> As a result of these downside, our current implementation goes back to the
> ol' "encrypted blob" approach. One immediate benefit with this approach is
> that the outsourcing protocol isn't so coupled with the current _commitment
> protocol_. Instead, the internal payload can be typed, allowing the server
> to dispatch the proper breach protocol based on the commitment type. The
> blob approach can also support a "swap" protocol which is required for
> commitment designs that allow for O(1) outsourcer state per-client, like the
> scheme I presented at the last Scaling Bitcoin.

Can you describe the "encrypted blob" approach to me? Or point me to materials?

I imagine that in this case, the protected node hands a (txid, blob) pair to the WatchTower.  If the WatchTower sees a transaction that matches the given txid, it gets some information from the actual transaction to decrypt the blob (e.g. use the encrypted commitment index in `nLockTime` and `nSequence` as a decryption key); the blob is the justice transaction (or just a template type and its signatures as you describe above).

Do you have a description of the WatchTower protocol used in lnd? It may be useful to be intercompatible.

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180416/d6bc4c75/attachment.html>


More information about the Lightning-dev mailing list