Two-party eltoo w/ punishment



Summary:

The conversation between Antoine Riard and Anthony Towns centers around the eltoo/chia variant, which aims to create a lightning-like network over the top of chia. The purpose of this innovation is to simplify the implementation process by introducing a cryptographic puzzle that allows the witness to be produced once and only once. This is achieved by encoding the logic directly as a script and exchanging CHECKSIGFROMSTACK-like signatures for updating the state. The two-party setup simplifies the process, making it easier to reason about the limits.Alice can publish an update K transaction, and then Bob can publish an update transaction K > N, where N represents the latest version of the channel. This construction ensures a strict bound on the shared_delay encumbered in the on-chain publication of the channel. However, the symmetric transactions can lead to an attack where Alice broadcasts update K and forces Bob to generate a new version of update N. Breaking the symmetry means that if A does a unilateral close, B can immediately confirm the closure, releasing all funds for both parties. There is still a case of Bob broadcasting an old state and Alice's watchtowers colluding to prevent her honest funds' access, potentially preventing the HTLC-timeout. The penalty transactions should not be delegated to untrusted watchtowers, and the whole channel funds might be lost in case of RB.n signing key compromise. One solution could be to have a channel balance between the watchtower and the user, where the tower balance is the payment for the WA.n broadcast. Eltoo channels would simplify the implementation of distributed towers by Lightning implementation, notably handling concurrent broadcast w.r.t chain asynchronicity issues, and hopefully removing the concern of commitment transaction key duplication by the tower.In addition to eltoo/chia, the Lightning Network could see payment forwarding significantly sped up with the introduction of a "fast-forward" protocol upgrade proposal. However, there are concerns over the risk of funds being locked up if the recipient goes offline, as well as the possibility of Bob attempting to confirm his own unilateral close. To address these concerns, the proposed solution would require Alice to send her partial signatures to allow Bob to accept the new state unilaterally and for Alice to be able to claim the funds if Bob broadcasts UB.n. This could be achieved through an adaptor signature approach or a CTV-like approach. The email also discusses potential solutions for paying watchtowers in the Lightning Network while ensuring they are compensated fairly and reliably. One suggestion is to give the watchtower a pre-signed transaction WA.n, which includes an output for a new lightning channel between the user and the watchtower with an initial capacity of the user's funds. The user can then off-chain update the state of the channel so that the watchtower's balance reflects how much the user is willing to contribute in fees if the watchtower does its job. The user can always claim a penalty via WA.n->RA.n if the watchtower acts improperly, giving them the ability to compensate the watchtower up to that penalty while still making a profit. However, this solution does not generalize to redundant untrusted watchtowers. There is also discussion around watchtowers and how they might impact privacy by leaking information about their topology.


Updated on: 2023-06-03T11:00:54.137300+00:00