diff --git a/_includes/specials/taproot/xx-ln-with-taproot.md b/_includes/specials/taproot/xx-ln-with-taproot.md new file mode 100644 index 0000000000..b471bc4b38 --- /dev/null +++ b/_includes/specials/taproot/xx-ln-with-taproot.md @@ -0,0 +1,194 @@ +*By [ZmnSCPxj][]* + +In this post, we'll look at two privacy features that [taproot][topic taproot] enables +for LN: + +* [PTLCs][topic ptlc] over LN. +* P2TR Channels. + +### PTLCs Over LN + +PTLCs enable [many features][suredbits payment points], with a major +feature for LN being [payment decorrelation][p4tr ptlcs] without +any need to randomize routes.[^route-randomization] Every node along a +single-path or [multipath][topic multipath payments] route can be given a scalar that is used to +tweak each forwarded PTLC, enabling *payment decorrelation* where +individual forwards no longer leak the unique identifier for each +LN payment. + +PTLCs are ***not a privacy panacea***. If a surveillor node sees a +forward with a particular timelock and value, and a second surveillor +node shortly after sees a forward with a *lower* timelock and *slightly +lower* value, then *very likely* those forwards belong to the same +payment path, even if the surveillor nodes can no longer correlate them +via a unique identifying hash. However, we *do* get: + +* Increased uncertainty in the analysis. The probabilities surveilors + can work with are now lower and thus their information is that much + less valuable. +* A *lot* more decorrelation in multipath payments. Separate paths will + not have strong timelock and value correlation with each other, and if + LN succeeds, there should be enough payments that timing + correlation is not reliable either. +* No increase in cost compared to an [HTLC][topic htlc] (and possibly even a slight + cost reduction due to [multisignature efficiency][p4tr + multisignatures]). + +In principle, a pre-taproot channel can be upgraded to support PTLCs without +closing and reopening the channel. Existing channels can host PTLCs by +creating an offchain transaction that spends the existing non-taproot +funding output to a taproot output containing a PTLC. Thus getting +support for PTLCs over LN does not require any cost to users +beyond each node and its channel peers upgrading their software. + +However, to actually use PTLCs, *every* forwarding node from the spender +to the receiver must support PTLCs. This means PTLC support may remain +largely unused until a sufficient number of nodes have upgraded. They +don't all necessary need to use the same protocol (there could be +multiple PTLC protocols), but they all must support some PTLC protocol. +Having to support multiple PTLC protocols would be an added maintenance +burden and I *hope* we do not have too many such protocols (ideally just +one). + +### P2TR Channels + +One solution for improving the decorrelation between the base layer and +the LN layer has been [unpublished channels][topic unannounced channels]---channels whose +existence isn't gossiped on LN. + +Unfortunately, every LN channel is a 2-of-2, and in the current +pre-taproot Bitcoin, every 2-of-2 is *openly* coded. LN is the +most popular user of 2-of-2 multisignature, so any blockchain explorer +can see a 2-of-2 being spent and guess with fairly good probability that +this is a LN channel being closed. The funds can then be traced +from there, and if it goes to another P2WSH output, then that is likely +to be *another* unpublished channel. Thus, even unpublished channels +are identifiable onchain once they are closed, with some level of false +positives. + +Taproot, by using [schnorr signatures][topic schnorr signatures], allows for n-of-n to look exactly +the same as 1-of-1. With some work, even [k-of-n][topic threshold signature] will also look the same +as 1-of-1 (and n-of-n). We can then propose a feature where an LN +channel is backed by a P2TR UTXO, i.e. a +P2TR channel, which increases the *onchain* privacy of +unpublished channels.[^two-to-tango] + + + +This (rather small) privacy boost also helps published channels as well. +Published channels are only gossiped until they are closed, so somebody +trying to look for published channels will not be able to learn about +*historical* channels. If a surveillor wants to see every published +channel, it has to store all that data itself and cannot rely on any +kind of "archival" node. + +In addition, taproot keypath spends are 38.5 vbytes (70%) smaller than +LN's existing P2WSH spends. Unfortunately, you **cannot upgrade +an existing pre-taproot channel to a P2TR channel**. The +existing channel uses the existing P2WSH 2-of-2 scheme and has to be +closed in order to switch to a P2TR channel. + +In theory, the actual funding transaction outpoint is really a concern +of the two nodes that use the channel. Other nodes on the network will +not care about what secures the channel between any two nodes. However, +published channels are shared over the LN gossip network. When a +node receives a gossiped published channel, it consults its own trusted +blockchain fullnode, checking if the funding outpoint exists, and more +importantly **has the correct address**. Checking the address helps +ensure that it is difficult to spam the channel gossip mechanism; you +need actual funds on the blockchain in order to send channel gossip. +Thus, in practice, even P2TR channels require some amount +of remote compatibility; otherwise, senders will ignore these channels +for routing, as they cannot validate that those channels *exist*. + +### Time Frames + +I think the best way to create time frames for features on a distributed +FOSS project is to look at *previous* features and how long they took, +and use those as the basis for how long features will take to actually +deploy.[^planning-details] + +The most recent new major feature that I believe is similar in scope to +PTLCs over LN is [dual-funding][topic dual funding]. Lisa Neigut created an initial +proposal for a dual-funding protocol in [BOLTs #524][], with the [first +dual-funded channel on mainnet][neigut first dual funded] being +[opened][first dual funded tx] almost 2 years and 6 months later. +Dual-funding only requires compatibility with your direct peers. PTLCs +over LN require compatibilty with all routing nodes on your +selected paths, including the receiver, so I feel justified in giving +this feature a +50% time modifier due to the added complication, for an +estimate of 3 years and 9 months starting from when a specific PTLC +protocol is proposed. + +For P2TR channels, we should note that while this is "only" +between two direct peers, it also has lower benefits. Thus, I expect it +will be lower priority. Assuming most developers prioritize +PTLC-over-LN, then I expect P2TR channels will start +getting worked on by the time the underlying [SIGHASH_NOINPUT][topic sighash_noinput] or other +ways to implement Decker-Russell-Osuntokun ("[Eltoo][topic eltoo]") are available. + +[^route-randomization]: + A payer can choose a very twisty path (i.e. route randomization) to + make HTLC correlation analysis wrong, but that has its drawbacks: + + * Twisty paths are costlier *and* less reliable (more nodes + have to be paid, and more nodes need to *successfully* forward + in order for the payment to reach the destination). + * Twisty paths are longer, meaning the payer is telling *more* + nodes about the payment, making it *more* likely they will hit + *some* surveillor node. + Thus, twisty paths are not necessarily a perfect improvement + in privacy. + +[^planning-details]: + Yes, details matter, but they also do not: from a high enough + vantage point, the unexpected hardships of some aspect of + development and the unexpected non-hardships of other aspects + of development cancel out, and we are left with every major + feature being roughly around some average time frame, with + any unexpectedly high bonus or malus being "just noise". + + Yes, there are more developers now, that also means we need + to get greater agreement on various details and more + implementation-specific concerns ("mythical man-month"). + Yes, we now know more today about how LN works, but + what we know is how LN works pre-taproot, and we + might actually have to unlearn some of those lessons in a + post-taproot world. + If we want to make **accurate** estimates as opposed to + **feel-good** estimates, we should use methods that avoid + the [planning fallacy][WIKIPEDIAPLANNINGFALLACY]. + + Thus, we should just look for a similar previous completed + feature, and *deliberately ignore* its details, only looking + at how long the feature took to implement. + +[^two-to-tango]: + When considering unpublished channels, remember that + it takes two to tango, and if an unpublished channel is + closed, then one participant (say, an LN service provider) + uses the remaining funds for a *published* channel, a blockchain + explorer can guess that the source of the funds has some + probability of having been an unpublished channel that was + closed. + +{% include references.md %} +{% include linkers/issues.md issues="524" %} +[zmnscpxj]: https://zmnscpxj.github.io/about.html +[suredbits payment points]: https://suredbits.com/payment-points-monotone-access-structures/ +[WIKIPEDIAPLANNINGFALLACY]: https://en.wikipedia.org/wiki/Planning_fallacy +[neigut first dual funded]: https://medium.com/blockstream/c-lightning-opens-first-dual-funded-mainnet-lightning-channel-ada6b32a527c +[first dual funded tx]: https://blockstream.info/tx/91538cbc4aca767cb77aa0690c2a6e710e095c8eb6d8f73d53a3a29682cb7581 +[russell deployable ln]: https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf +[p4tr ptlcs]: / {% comment %}FIXME{% endcomment %} +[p4tr multisignatures]: / {% comment %}FIXME{% endcomment %} diff --git a/_posts/en/2021-06-23-preparing-for-taproot.md b/_posts/en/2021-06-23-preparing-for-taproot.md index 3e7013795a..f9f9fc699e 100644 --- a/_posts/en/2021-06-23-preparing-for-taproot.md +++ b/_posts/en/2021-06-23-preparing-for-taproot.md @@ -62,5 +62,9 @@ h2:not(:first-of-type) { margin-top: 3em; } {% include specials/taproot/en/05-taproot-notebooks.md %} +## Using Taproot in Lightning + +{% include specials/taproot/xx-ln-with-taproot.md %} + ## Footnotes {:.no_toc}