Re: [Lightning-dev] Interactive tx construction and UTXO privacy, some thoughts
Hi Lisa, First of all great work on dual-funding and I appreciate this write up too. A couple thoughts I had. > 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 > 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. I think there’s still enough 50-50 doubt. With careful consideration to coin selection, you can keep that 50-50 across all your channels too. With a determined enough prober, they can get 100% proof of your funds for future channels. That would be what my main concern is, going from doubt to certainty. That said, I think what’s important here is that the whole world doesn’t know, unless of course the bad actor publishes to the whole world out of band. But it can’t be figured out after the fact. I do think combining a picky acceptor with your idea that you keep using the same UTXO until it gets used is a nice approach. I am not aware of how PoDLE works yet, but I do know with other coinjoining protocols, there’s a coordinator involved to handle bans, bad actors, etc. Perhaps eventually we can see a sort of coordinator(s) develop here as well. One that can be used to help facilitate multi openings via dual-funding and/or handle the bad actors that might be probing. For instance, say someone has proof that another node backed out with a specific UTXO they were offering up. They could post that information to a coordinator that keeps track of others as well. Whenever a new dual-funding request comes in, the coordinator can be queried (perhaps for a small fee), to check it’s DB of bad actors/UTXOs. It would be centralized, but could be distributed to multiple coordinators, or even just your own if you have multiple nodes you’d like to share that logic between. This wouldn’t be on the protocol level, just a thought I had that could help solve the problem. In either case, I should probably look at how PoDLE/JoinMarket solves this at all given like you said, it’s a problem amongst a way more privacy minded context. Even the fact that dual-funding exists in the world is a net positive alone to help give some doubt to all channel openings from now on. Regards, Anthony On 28 Jun 2021, at 21:21, lisa neigut wrote: > 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
Re: [Lightning-dev] Interactive tx construction and UTXO privacy, some thoughts
Good morning lisa,
> 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.
Possibly, a difference between the DLC use-case and the Lightning use-case is
that the DLC use-case has a definite deadline when the contract expires,
whereas the Lightning use-case has no definite end termination for the channel.
In addition, DLC requires transmitting significant amounts of data measurable
in megabytes, whereas Lightning transmits little 32-byte blobs (well not really
mostly 1366-byte onion-wrapped packages but still much tinier than the
megabytes of adaptor signatures in DLCs).
So the DLC setup stage getting hit with the optimization hammer (as a
collateral damage from the optimization hammer being used on the actual core
DLC) seems like a reasonably thing happening in the DLC use-case.
Finally, there is a big enough directory of Lightning nodes that you can
reasonably pick up this directory in lots of places, pick some random number of
them to channel to, and then make channels to them, and making them in a single
tx is always a good thing.
Whereas I imagine that the DLC use-cases (even in the future) are more limited
userbase (and with payment points on Lightning I believe the smaller and
shorter-term DLCs can run on top of Lightning), so the opportunity to aggregate
may be much rarer in DLCs than in Lightning channel opens.
> ## 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.
I broadly agree here --- published channels trade off onchain privacy (marking
"hey this UTXO is totally owned by these two peeps!") but gain offchain privacy
("no, that is not my payment, somebody else asked me to forward it, promise!")
>
> ## 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.)
Hmm wait Taproot fixes this?
We can drop/reinterpret `short_channel_id` post-Taproot?
Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Interactive tx construction and UTXO privacy, some thoughts
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
