ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-29 📝 Original message: Good morning lisa, > A ...

📅 Original date posted:2021-06-29
📝 Original message:
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