On Wed, Sep 06, 2023 at 12:14:08PM -0400, Greg Sanders wrote: > 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 think a bunch of these depends on who's interested in doing the work to roll this out? I guess the path of least resistance would be to start by writing an optional BLIP that gets implemented in one node software (as an opt-in, experimental, feature?), and if that works out okay, implementing it elsewhere and upgrading it for inclusion in the BOLTs? I think the interop requirements are: * #7 routing gossip: does this channel support forwarding PTLCs * #4 onion messages: this is a PTLC payment, not an HTLC one; this is how you calculate the next point when forwarding * #11/#12 invoices: this is a PTLC payment point, not an HTLC payment hash * #3 tx format: this is the on-chain format we use to reveal a PTLC preimage * #2 peer messaging: this is how we pass along signatures for txs It's important (and I think not very hard) to get the first three right ASAP, since those require network/ecosystem-wide upgrades to change; whereas the latter two points can be renegotiated between peers without affecting anyone else. I think all the alternatives in > https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163 fall into the latter two points. So it's probably best to just pick something easy and pleasant to implement and get something that works, and worry about optimising it later? Of course, what's easy/pleasant depends on who's doing the work... > 1) single-sig adaptors vs MuSig2 I think: https://github.com/BlockstreamResearch/scriptless-scripts/pull/24 describes (w/ proof sketch) how to do a single-signer adaptor with musig2; might need some updates, to match the final musig2 API, but I think it's fundamentally okay: ie, you get the "single-sig adaptor" approach, but can just use the musig2 api, so best of both worlds. > 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! If I'm understanding your page correctly, you have to either add or re-order peer messages when updating the commitment txs; so in that case, I guess I'd go with "single-sig adaptor (via musig2 api), sync updates, switch up commitment ordering". Should be comparable efficiency on-chain to HTLCs today, fairly easy to think about/implement, and keeps the 1.5 RTT forwarding delay so adoption shouldn't make UX worse. After there's something working, I could imagine: * adding a feature flag for upgrading a single-sig adaptor to being claimable via a musig2 double-sig key path -- you can still forward after 1.5 RTT, but after 3.5/4.5 RTT you can claim on-chain more cheaply if needed * adding a feature flag for APO support so you only have to sign each PTLC once, not once-per-update * adding a feature flag for 0.5 RTT fast-forwards * adding a feature flag for supporting async updates (maybe useful if you're a high bandwidth node doing fast-forwards?) * etc but unless whoever's implementing is really excited about some of that, seems better to defer it, and keep things simple to start. Cheers, aj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
