Good morning Rene,
>To me the key revocation system seems pretty complex to handle. In particular
>as Rusty also mentioned on his article (c.f.
>https://medium.com/@rusty_lightning/lightning-watching-for-cheaters-93d365d0d02f
> ) that already in the white paper people knew that potentially a third party
>observing service to detect a cheater is needed. This seems to me like a big
>drawback.
I believe this is also necessary under Decker-Wattenhofer? A potential thief
trying to reuse old invalid state could make sure you will be offline for a few
days, then broadcast (and hope it confirms) the kickoff transaction, wait for
the old invalid state to be valid, and then broadcast the old invalid
commitment transaction. You have to be online after the kickoff transaction
gets confirmed to ensure you can broadcast the latest commitment transaction,
too, or if you plan to be offline for long, you also need some watchtower-like
service under Decker-Wattenhofer. And I believe that watchtowers under
Poon-Dryja need only store the shachain and the funding txid, while watchtowers
under Decker-Wattenhofer would have to store entire relative-timelocked
transactions, leaking economic information at each update to a
Decker-Wattenhofer watchtower, whereas Poon-Dryja watchtowers need to learn
only about shachain updates, and can learn economic information only when
channels get onchain (and honestly, when channels drop onchain everyone knows
the economic information since the blockchain is publicly readable, so it is
not a significant information at that point).
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
