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 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.
>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
