<div dir="ltr"><div>Hi ZmnSCPxj, </div><div><br></div><div>> It seems to me, that the only safe way to implement a trustless WatchTower,</div><div>> is for the node to generate a fully-signed justice transaction, IMMEDIATELY</div><div>> after every commitment transaction is revoked, and transmit it to the</div><div>> WatchTower.</div><div><br></div><div>No, one doesn't need to transmit the entire justice transaction. Instead,</div><div>the client simply sends out the latest items in the script template, and a</div><div>series of _signatures_ for the various breach outputs. The pre-generated</div><div>signature means that the server is *forced* to reproduce the justice</div><div>transaction that satisfies the latest template and signature. Upfront, free</div><div>parameters such as breach bonus (or w/e else) can be negotiated.</div><div><br></div><div>> The WatchTower would have to store each and every justice transaction it</div><div>> received, and would not be able to compress it or use various techniques to</div><div>> store data efficiently. </div><div><br></div><div>In our current implementation, we've abandoned the "savings" from</div><div>compressing the shachain/elkrem tree. When one factors in the space</div><div>complexity due the *just* the commitment signatures, the savings from</div><div>compression become less attractive. Going a step father, once you factor in</div><div>the space complexity of the 2-stage HTLC claims, then the savings from</div><div>compressing the revocation tree become insignificant.</div><div><br></div><div>It's also worth pointing out that if the server is able to compress the</div><div>revocation tree, then their necessarily linking new breach payloads with a</div><div>particular channel. Another downside, is that if you go to revocation tree</div><div>compression, then all updates *must* be sent in order, and updates cannot be</div><div>*skipped*.</div><div><br></div><div>As a result of these downside, our current implementation goes back to the</div><div>ol' "encrypted blob" approach. One immediate benefit with this approach is</div><div>that the outsourcing protocol isn't so coupled with the current _commitment</div><div>protocol_. Instead, the internal payload can be typed, allowing the server</div><div>to dispatch the proper breach protocol based on the commitment type. The</div><div>blob approach can also support a "swap" protocol which is required for</div><div>commitment designs that allow for O(1) outsourcer state per-client, like the</div><div>scheme I presented at the last Scaling Bitcoin.</div><div><br></div><div>-- Laolu</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Apr 15, 2018 at 8:32 PM ZmnSCPxj via Lightning-dev <<a href="mailto:lightning-dev@lists.linuxfoundation.org">lightning-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi all,<br></div><div><br></div><div>Nicolas Dorier was requesting additional hooks in c-lightning for a simple WatchTower system: <a href="https://github.com/ElementsProject/lightning/issues/1353" target="_blank">https://github.com/ElementsProject/lightning/issues/1353</a><br></div><div><br></div><div>Unfortunately I was only able to provide an interface which requires a *trusted* WatchTower. Trust is of course a five-letter word and should not be used in polite company.<br></div><div><br></div><div>My key problem is that I provide enough information to the WatchTower for the WatchTower to be able to create the justice transaction by itself. If so, the WatchTower could just make the justice transaction output to itself and the counterparty, so that the WatchTower and the counterparty can cooperate to steal the channel funds: the counterparty publishes a revoked transaction, the WatchTower writes a justice transaction on it that splits the earnings between itself and the counterparty.<br></div><div><br></div><div>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. The WatchTower would have to store each and every justice transaction it received, and would not be able to compress it or use various techniques to store data efficiently. The WatchTower would not have enough information to regenerate justice transactions (and in particular would not be able to create a travesty-of-justice transaction that pays out to itself rather than the protected party). In practice this would require that node software also keep around those transactions until some process has ensured that the WatchTower has received the justice transactions.<br></div><div><br></div><div>Is there a good way to make trustless WatchTowers currently or did this simply not reach BOLT v1.0?<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div>_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div>