[dlc-dev] DLC Messaging and Networking

[Antoine Riard]

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