From gsanders87 at gmail.com Wed Sep 6 16:14:08 2023 From: gsanders87 at gmail.com (Greg Sanders) Date: Wed, 6 Sep 2023 12:14:08 -0400 Subject: [Lightning-dev] Practical PTLCs, a little more concretely Message-ID: Hi devs, Since taproot channels are deploying Soon(TM), I think it behooves us to turn some attention to PTLCs as a practical matter, drilling down a bit deeper. I've found it helpful to recap technical topics that have been going on for over half a decade(ala ln-symmetry), and PTLCs fall into that bucket. In that spirit I made an attempt: https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163 I spent some time drilling down exactly what the messages would look like, varying: 1) single-sig adaptors vs MuSig2 2) async updates vs sync aka "simplified updates" 3) amount of message re-ordering 4) futuristic updates to mempool/consensus, including ANYPREVOUT like updates Hopefully all these choices are compatible/orthogonal to schemes like overpayment, stuckless, and other exciting jargon to increase reliability of payments. The messages detailed are pedantic and couple be packaged any which way; I just couldn't keep track of correctness without detailing what was being sent. I didn't specify "fast-forward" as previously envisioned since that was deemed "future work", and once there I think the engineering choices balloon up quite a bit. Hopefully this is a useful refresher and can perhaps start the discussion of where on the performance/engineering lift curve we want to end up, maybe even leading up to a standardization effort. Or maybe all this is wrong, let me know! Best, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: