Improving Payment Latency by Fast Forwards

Summary:

The email thread explores the benefits of eltoo fast forwards and how it could lead to a new type of custodial Lightning Network (LN) provider. Currently, non-custodial LN phone apps require users to keep the app open to receive payments. To address this issue, providers can handle receiving payments on behalf of users. While this could potentially allow providers to steal money in the FF state, it is still a significant reduction in risk compared to a full custodial solution.The Poon-Dryja Fast Forwards work differently from other solutions as they do not build up a long chain of HTLC txes. Instead, an old update tx is superseded by a later update tx, ensuring that overhead is at most one extra update tx, regardless of how many HTLCs are offered while Bob has its privkey offline. However, the "HTLCs" in Poon-Dryja are not simple contracts but revocable HTLCs, which come with additional dependent transactions.It is crucial to note that for a set of simplex Alice-to-Bob payments, Bob should not provide the revocation keys of older commitment transactions to the cashier. This is because the "true" Bob has access to all the activity of Carol, including all communications between Carol and Alice. If Carol is corrupted by Alice, she can delete all the SigA's coming from Alice, including that needed by every "commitment transaction owned by Bob". This can prevent Bob from unilaterally closing the channel, leading to hostage-taking of all the Bob-side funds in the channel, not just in-flight HTLCs.To mitigate this vulnerability, Bob can take snapshots of the backing datastore periodically, or the signature datastore could be an append-only log, which is only periodically reaped of truly obsolete signatures by Bob. Additionally, it is recommended that Carol not be given the entire set of revocation keys B[0]..B[n]. Instead, she should only receive previous revocation keys by Bob as a hardened derivation from the keys held by Kelly. This is safe since later "commitment transaction owned by Bob" has more and more funds in HTLCs going to Bob.Until Bob puts Kelly online and gets access to the entire sequence of revocation keys, Carol cannot provide revocation keys for previous states. Thus, as long as Kelly is offline, Alice and Carol have to reuse the same revocation key. Only when there is a Bob->Alice transfer (i.e., Bob sends out money) does the revocation key need to be exposed to Carol for sending to Alice. The sequence of revocation keys is derived from the master privkey held by Kelly, so Kelly is needed. We need Kelly to be online anyway for sends, so this is not an additional requirement.The article also highlights security vulnerabilities in lightning network transactions, such as signature-deletion attacks that can result in hostage-taking of funds. If Bob does not take necessary mitigations, he can be vulnerable to such attacks. Hostaging of funds occurs when one participant loses the ability to unilaterally close, which can happen if Carol reveals all the revocation keys to Alice.

Updated on: 2023-06-02T18:28:18.565044+00:00