From niftynei at gmail.com Tue Jun 29 02:21:58 2021 From: niftynei at gmail.com (lisa neigut) Date: Mon, 28 Jun 2021 21:21:58 -0500 Subject: [Lightning-dev] Interactive tx construction and UTXO privacy, some thoughts Message-ID: Hey all, The dual-funding proposal has been up for a while now, and while we've had some really great reviews from a few people (@ariard + @rustyrussell thanks for your comments in particular). As a refresher, the PR is available here: https://github.com/lightningnetwork/lightning-rfc/pull/851. I wanted to make a quick summary of some of the biggest objections to the protocol. Most of these were made during the course of the 2018 spec meeting in Adelaide and while we've done a decent job of architecting around them, I wanted to make them explicit. If there's more to add, please do. ## Point One One: dual-funding (really the collaborative transaction protocol) requires you to share your UTXO set with the channel peer. This is true, in a 'limited' sense, where 'UTXO set' is actually constricted to 'UTXOs you're using for funding transactions'. On the face of it, this seems to be quite concerning to folks. Here's a few things that I think make this less concerning than it might appear at the outset. First, let's consider the current opening case. You (or your channel peer) constructs a transaction and shares the TXID and outpoint that the funding output can be found at. This transaction is published and mined, after the transaction is at sufficient depth a gossip announcement is broadcast to the entire network, explaining where the transaction can be found. Under the current protocol, it's reasonable\* to conclude that every UTXO in the funding transaction belongs to a single party, the opener. Assuming that all the UTXOs in your wallet will, at some point, end up in a lightning channel, all of your UTXOs will be *publicly* associated with your node at some point (in the current model). Your UTXO set is only private in the present, given a long enough time period (and channel opens) they will all be tied to your node. For this reason, it's probably not a great idea to fund wallets using a separate wallet that hasn't been coinjoined or otherwise obfuscated. In fact, I think you can make a fairly decent argument (under the existing UTXO model) for not mixing lightning funds with any funds you wish to remain truly private/unassociated to an 'entity'. Given that you're currently telling everyone what UTXOs your node owns (or at least has a 50/50 chance of owning..) let's consider the interactive transaction protocol. Assuming a 2-party dual-funded open, as an outside observer it's much more difficult to tell which UTXOs belong to who (though you can probably guess given input amounts and change outputs; maybe a good heuristic for opens is to use whole UTXOs). In this on-chain respect, the dual-funding protocol is no worse, and in the best case much better for on-chain coin-analysis heuristics than the current protocol. \* There are a few clear exceptions where other protocols (such as Pool, iiuc) have been developed that make this heuristic bunk as they *also* build a multi-party transaction, however afaik all of these other protocols (joinmmarket, pool) still require sharing your UTXOs with another (trusted) party, difference is you know in theory where "the Pool auctioneer" lives, whereas you don't really know much about "any random node that wants to open a channel". Seems like there might be some room in this space for better information about prospective channel peers... ## Point Two Two: an active prober can use the interactive transaction protocol to discover your wallet's entire UTXO set. Given the assumption that all of your node funds will, at some point, be used to open a lightning channel, a single attacker discovering a subset of your UTXOs is simply a 'fast-forward' of what will eventually become public information. That being said, much smarter minds (e.g. JoinMarket, which suffers from a very similar issue in what I would argue an even more privacy-conscious context) than mine have employed the PoDLE protocol to make the discovery of every UTXO more costly for a potential attacker. This is something we can add quite trivially to the protocol, at the cost of grossly increasing the gossip traffic. Worth noting that even without PoDLE you can much slow this type of attack by reusing the same UTXO across every open attempt, being choosy about which peers you do offer liquidity up to (do they have other established channels? what's their uptime?) etc. A dedicated attacker could probably figure out your UTXO set, but that's not much different from the current system; the only difference is the span of time it takes them to figure it out. ## Things We've Done to Counter This: I had the pleasure of finally meeting Nadav of SuredBits and DLC fame in Miami a few weeks ago. The DLC team has adopted a version of the interactive transaction protocol for their own purposes. Nadav pointed out that the protocol we landed on for lightning interactive construction transactions is *quite* interactive; the DLC version modified it to use batching to transmit the input/output sets (the interactive protocol is one-by-one). The rationale for doing the addition of inputs and outputs in a non-batched fashion is that this allows for you to interleave UTXOs from a variety of sources, for example multiple channel opens in the same tx. With the current protocol, you can initiate a dual-funded open with many peers at the same time, each of which may contribute UTXOs and outputs for their own respective channel opens or UTXO consolidations etc. This gives us the real possibility of doing multiparty coinjoins on lightning. In fact, this is currently possible with c-lightning *today* using the multifundchannel command (h/t to ZmnSCPjx for the original framework for multifund opens). As written, the interactive transaction protocol is exceedingly flexible. We traded off succinctness for some plausible deniablity wrt any UTXOs you send to any peer -- are they yours or are they some third party's? How to tell? I think it's interesting to point out that "succinctness" in rounds of required interaction is typically a *highly* desirable trait for any cryptographic protocol. The establishment of a lightning channel relationship, however, isn't a cryptographic signature. A lightning channel, by its very nature, is typically a highly interactive relationship between two peers. Increasing the rounds of messaging required to establish the channel doesn't change the overall interactivity profile of a channel's operation, thus adding rounds of comms to channel open is generally a no-op in terms of performance/uptime requirements of a node's operations. ## How important is UTXO privacy on lightning? Obviously important. But given that the real transactions happen inside of channels, invisibly, and that your public channels really truly are public via the gossip protocol the much more important "thing" in the lightning arena isn't your UTXO privacy so much as *not* associating your identity with your node. ## Does Taproot fix this? I'm not up to date enough on the progress of Taproot scripts, however, assuming the current requirement that every routing node is able to independently verify the opening output script via the signatures provided in the channel_announcement, it seems reasonable that on-chain transactions will still be assignable to a node given gossip data. (Purely on-chain analysis will be stymied, however.) # In Exitus There are legitimate concerns regarding sharing UTXOs with other peers in the process of opening a channel. The current protocol, as implemented, introduces a mechanism for some plausible deniability wrt who those UTXOs actually belong to, as well as providing the tools for building multi-party coinjoins as opens. Further, with PoDLEs, we can at least achieve a similar level of protection as JoinMarket currently enjoys. Finally, regardless of what open mechanism you're using, it's worth reiterating that best practice is to not *ever* tie your identity to your lightning node. And it may be worth reconsidering what wallet source you're using to fund announced channel opens. -------------- next part -------------- An HTML attachment was scrubbed... URL: