Published on: 2022-12-26T19:18:38+00:00
In a recent post, John addresses two corrections and discusses an extension of the FFO protocol. Firstly, he corrects the link for reference [8] to https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html as pointed out by David A. Harding. Secondly, John describes the extension of the FFO protocol, which faces a problem where revealing the per-commitment key would allow the other party to spend the output. To resolve this issue, the party that puts their State transaction on-chain can create a new Individual transaction that spends the first output of their State transaction.The Lightning Network is a second-layer scaling solution for Bitcoin designed to enhance the speed and efficiency of micropayments. However, scalability issues persist, and two-party channels are crucial for Bitcoin to be widely used in a trust-free manner. Hash Time-Locked Contracts (HTLCs) are utilized to enable payments across multiple channels within the Lightning Network. When one party becomes unresponsive, the HTLC must be resolved on-chain, resulting in two problems.Firstly, the HTLC's expiry must be delayed to account for the time required to close the factory and put the channel containing the HTLC on-chain. This inefficient use of capital leads to long waits for payment receipts. Secondly, closing a factory due to the need to resolve an HTLC on-chain allows a single unresponsive party to force the closure of the entire factory, limiting the scalability of Bitcoin.To address these challenges, factory-optimized channel protocols have been introduced. The post introduces the PFO, FFO, and FFO-WF protocols, which aim to decouple the resolution of HTLCs from the latency of closing the channel factory. Additionally, the FFO and FFO-WF protocols allow HTLCs to be resolved on-chain without closing the channel factory, making them suitable for watchtower-freedom and one-shot receives for casual users.The FFO-WF protocol modifies the FFO protocol by introducing a relative delay before Alice can time out an HTLC offered to Bob. This delay allows Bob to remain off-chain after the HTLC's expiry, even if Alice intentionally becomes unavailable. However, this modification introduces a risk that Alice may never put her State transaction on-chain, preventing Bob from receiving payment for HTLCs offered to him. To mitigate this risk, Bob's Commitment transaction is adjusted to ignore the HTLC control results and pay all HTLC amounts to Bob. However, the State and Commitment transactions are delayed enough to ensure that Alice can always get hers on-chain.Furthermore, the post highlights that these protocols are based on the TP protocol introduced by Law and inspired by Lightning's use of HTLC-timeout and HTLC-success transactions to resolve HTLCs before verifying the unrevoked status of their associated Commitment transaction. Detailed information on these developments can be found in the BOLT specifications and other research papers. Recent proposals such as the TAPLEAF_UPDATE_VERIFY covenant opcode and Channel Eviction from Channel Factories by New Covenant Operations demonstrate ongoing efforts by Bitcoin developers to improve the Lightning Network.Overall, these protocols represent a significant enhancement to the Lightning Network, enabling efficient scaling of Bitcoin factories. They are optimized for factories, allowing casual users to utilize one-shot receives and dedicated users to employ watchtowers with logarithmic storage.
Updated on: 2023-08-01T00:54:28.836820+00:00