Hi Thibaut,
> My view, which hasn't changed much since I started working on DLC, is that
> we should try to reuse as much as possible from the LN specifications and
> infrastructure because:
>
> - while they might not be perfect, a lot of people have spent a lot of
> time on them, and I'm not sure that we can come up with something better,
> - it feels right to reuse the parts that can be; hopefully there will be
> other p2p applications on top of bitcoin in the future, and it (I) would be
> sad to see each application re-inventing a new way of doing things,
> - if doing DLC over LN, there is no choice.
I agree here. On point 2, I think that a lot of current (and future) "p2p trading" bitcoin protocols (coinjoins [0], liquidity ads, peerswap, etc) are sharing the requirements for peers/offers discovery. It could make sense to have one unified communication infrastructure across the ecosystem. Threat models are likely converging (spams, front-running, price manipulations, etc).
> That being said, LN specs don't define everything we need and not always
> work well with DLC. One thing I can think of as an example is node
> announcements that only get considered valid if they are with a channel
> announcement. For us we would need to find other ways of protecting from
> DoS.
LN devs are currently thinking of moving towards a privacy-preserving channel announcement protocol, based on UTXO ownership. Though it might take years as the adequate cryptosystems implementations are more-or-less non-existent iirc. In the meantime, we might use cleartext "at least X sats" UTXO ownership as there is no concept of public channel in DLC. But not great for privacy.
> Then it feels like point 2 and 4 need to be specified somehow, but as long
> as we agree on the transport layer (again BOLT #8 seems to me like the way
> to go), there shouldn't be any big hurdle.
For point 2 and point 4, I think we'll need to envision some bulletin boards style server where the offers are published, persisted for some duration and retrievable, in a privacy-preserving fashion by nodes. We might reuse in some way LN onion messages there, as it's currently uncoupled from relaying HTLCS only [1]
If we think it makes sense to share the DLC networking infrastructure with other bitcoin "p2p trading" protocols, it could be interesting to discuss with those communities to converge on a common list of requirements. Even if the specification effort is conducted by dlcspecs. Standards are great!
Antoine
[0]
https://reyify.com/blog/blue-sky-joinmarket-thoughts[1]
https://github.com/lightning/bolts/pull/759