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

Le ven. 25 mars 2022 à 09:05, Thibaut Le Guilly <thibaut@cryptogarage.co.jp> a écrit :
Hi all,

During the last specification meeting we discussed DLC messaging and networking and how each implementation has taken different directions. This is rather unfortunate as it makes it impossible for different implementations to interoperate (the whole point of the specification effort in the first place). This is also mainly because at the moment the specifications fall short of covering the needs of a complete DLC application. In my view, these needs are:
  1. Node discovery/bootstrapping
  2. Sharing/accepting offers to/from other peers
  3. Contract establishment
  4. Oracle and oracle announcement discover
The specs currently only cover point 3, and not even fully.

# Current status

This is my current view of what approaches are used by different implementations for each of these points (please correct if it's wrong):
rust-dlc: 
  1. BOLT #10 (reuses LDK) 
  2. Not implemented
  3. DLC spec messages + BOLT #8
  4. Oracle server (HTTPS)
bitcoin-s:
  1. Not implemented (AFAIK)
  2. Custom message over Tor (offer mailbox)
  3. DLC spec messages over Tor
  4. Suredbits oracle explorer (HTTPS?)
atomic-finance:
  1. IRC server
  2. IRC server
  3. DLC spec messages over TCP/IP (+TLS?)
  4. Surebits oracle (HTTPS, predefined oracle)
itchy-sats:
  1. Not implemented (or applicable, single maker?)
  2. Custom protocol over TCP/IP (+TLS?)
  3. Custom protocol over TCP/IP (+TLS?)
  4. gun oracle (predefined oracle)
# Proposal

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.
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.

In order to successfully establish a DLC across two different implementations (and without copy pasting contract data), they need to agree on point 3 at the very minimum. While at the moment the specs only mention[1] BOLT #8, I think it would make sense to enforce it.

For the other points, it's not as critical for implementations to agree, but BOLT #10 to cover point 1 also feels quite natural.

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.

Happy to hear what other people think!

Cheers,

Thibaut

[1] https://github.com/discreetlogcontracts/dlcspecs/blob/08c781021b52cf2a729bec5222c08efe3386fe3a/Messaging.md#overview

dlc-dev mailing list
dlc-dev@mailmanlists.org
https://mailmanlists.org/mailman/listinfo/dlc-dev