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