Lightning over taproot with PTLCs



Summary:

The Lightning Network protocol for Bitcoin transactions is set to receive a replacement for BOLT#2 and BOLT#3. This new proposal focuses on implementing PTLCs while minimizing data storage requirements, latency, on-chain footprint, and third-party analysis. The proposal also introduces support for HTLCs and uses musig and musig2 to combine keys and sign for them. Adaptor signatures and revocable secrets are also used in this proposal.The proposal introduces four layers of transactions: funding, balance, inflight, and layered transactions. Both Alice and Bob have the same balance transaction with different signatures for it. Inflight transactions can be updated immediately without requiring a round trip. To construct layered transactions, the number of times a given inflight transaction has been updated is represented by "i".The Lightning Network protocol generates a second level revocable secret by Bob, which allows Alice to update the in-flight transaction spending her balance as well as any dependent layered transactions. Refunding or cancelling an htlc/ptlc requires a two-phase commit with 1.5 round trips. The funds locked in Alice's balance can be spent in different ways. However, Alice may face challenges when claiming funds if the inflight transaction contains an htlc output and she hasn't retained the old htlc details, or if the inflight transaction contains a ptlc output and she hasn't retained the old ptlc details. Lastly, preliminary work is needed to define specs/BIPs for musig and musig2, and adaptor signatures.


Updated on: 2023-05-23T16:16:14.167013+00:00