Practical PTLCs, a little more concretely



Summary:

Greg's email discusses the importance of turning attention to PTLCs (Payment-Channel Time-Locked Contracts) as taproot channels are soon to be deployed. He believes it is helpful to recap technical topics like PTLCs, which have been ongoing for over half a decade. In that spirit, he has made an attempt to drill down deeper into PTLCs and has shared a gist on GitHub (https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163).Greg spent some time examining what the messages in PTLCs would look like, considering various factors such as single-sig adaptors vs MuSig2, async updates vs sync (also known as "simplified updates"), the amount of message re-ordering, and futuristic updates to mempool/consensus, including ANYPREVOUT-like updates. He hopes that these choices will be compatible with schemes like overpayment and stuckless, increasing the reliability of payments.The detailed messages provided by Greg are pedantic and can be packaged in different ways. He clarifies that he included the details of what was being sent because it helped him keep track of correctness. He did not specify the inclusion of "fast-forward" as previously envisioned, as it was considered "future work." Greg believes that once fast-forward is included, there will be numerous engineering choices to consider.Greg concludes his email by suggesting that the information he provided serves as a useful refresher and could potentially lead to discussions about the performance and engineering considerations related to PTLCs. He also mentions the possibility of initiating a standardization effort. However, he acknowledges that there is a chance that his understanding may be incorrect and invites feedback from the recipients of the email.


Updated on: 2023-09-07T01:55:49.240521+00:00