Author: Anthony Towns 2023-09-19 12:29:53+00:00
Published on: 2023-09-19T12:29:53+00:00
The email discusses the implementation of a new feature called PTLC (Point Time Lock Contract) in node software. The sender suggests starting with writing an optional BLIP (BOLT Improvement Proposal) as a way to roll out the feature. They mention that it would be best to focus on interop requirements such as routing gossip, onion messages, invoices, tx format, and peer messaging. These requirements involve making changes at a network/ecosystem-wide level. The sender emphasizes the importance of getting the first three requirements right as soon as possible, while the latter two can be renegotiated between peers without affecting others.The sender suggests picking something easy and pleasant to implement initially and optimizing it later. They provide a link to a GitHub pull request that describes how to do a single-signer adaptor using musig2. They believe this approach combines the benefits of a "single-sig adaptor" while utilizing the musig2 API. The sender also mentions the need to add or re-order peer messages when updating commitment transactions.In terms of efficiency, the sender believes the chosen approach should be comparable to HTLCs (Hash Time Lock Contracts) currently used. It should be relatively easy to think about and implement, and should not worsen the user experience due to a 1.5 round-trip time (RTT) forwarding delay.Once the initial implementation is working, the sender suggests adding feature flags for upgrading the single-sig adaptor to claimable via a musig2 double-sig key path, APO support (signing each PTLC once), 0.5 RTT fast-forwards, and supporting async updates. However, they advise deferring these additions unless the implementer is particularly enthusiastic about them, in order to keep things simple at the start.
Updated on: 2023-09-21T01:53:13.657003+00:00