Why Nostr? What is Njump?
2023-06-09 12:50:07
in reply to

ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-16 📝 Original message: Hi all, Nicolas Dorier ...

📅 Original date posted:2018-04-16
📝 Original message:
Hi all,

Nicolas Dorier was requesting additional hooks in c-lightning for a simple WatchTower system: https://github.com/ElementsProject/lightning/issues/1353

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.

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.

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.

Is there a good way to make trustless WatchTowers currently or did this simply not reach BOLT v1.0?

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180415/51a0da32/attachment.html>;
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l