[dlc-dev] DLC Messaging and Networking

Thibaut Le Guilly thibaut at cryptogarage.co.jp
Fri Mar 25 14:04:37 CET 2022


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20220325/e14ca1af/attachment.htm>


More information about the dlc-dev mailing list