[dlc-dev] DLC Messaging and Networking

Matthew Black matthew at atomic.finance
Sat Mar 26 19:54:57 CET 2022


Hey guys,

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]


I agree that there should be some type of bulletin board style server where
offers are published. It seems to me that using IRC servers might be the
most effective place for this to exist.

Financial contracts such as options, futures, etc. require quick price
discovery, especially in an often volatile market like Bitcoin. I find it
difficult to imagine price discovery of these types of contracts occurring
over a P2P network like Lightning being viable.

Using an IRC server introduces a centralized point of failure, however it
is easy for clients to have fallback servers in case one server goes down.
The JoinMarket coinjoin protocol uses IRC and has several fallback servers
[1].

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


Note, IRC should only be used for Step 1, since accept and sign messages
would easily exceed the 512 char limit.

As Thibaut mentioned, Atomic has been experimenting with using IRC for
price and node discovery (mostly for initial communication with a market
maker) [2].

We decided on using a new message type called `OrderOffer` which is simply
a `DlcOffer` without funding inputs (to avoid giving away privacy of utxos
on a public bulletin board). It is currently susceptible to a spam of
offers from a malicious party, so some type of blacklisting system would
likely need to be put in place.

I could imagine various markets popping up for OTC offers in various IRC
channels, such as #dlc-options-short-calls, #dlc-options-long-calls,
#dlc-betting-presidential-election-2024, etc. In the case that the
underlying IRC server goes down, all clients can simply switch to another
server and continue using the same channels for price and node discovery.

[1]
https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/aabfd3f7c2ec33391b89369bd1fe354659f10f0f/jmclient/jmclient/configure.py#L140

[2]
https://gist.github.com/matthewjablack/b0d57081a4cb96809e81d788b1d58793

On Sat, Mar 26, 2022 at 8:00 AM <dlc-dev-request at mailmanlists.org> wrote:

> Send dlc-dev mailing list submissions to
>         dlc-dev at mailmanlists.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mailmanlists.org/mailman/listinfo/dlc-dev
> or, via email, send a message with subject or body 'help' to
>         dlc-dev-request at mailmanlists.org
>
> You can reach the person managing the list at
>         dlc-dev-owner at mailmanlists.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dlc-dev digest..."
>
>
> Today's Topics:
>
>    1. DLC Messaging and Networking (Thibaut Le Guilly)
>    2. Re: DLC Messaging and Networking (Antoine Riard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 25 Mar 2022 22:04:37 +0900
> From: Thibaut Le Guilly <thibaut at cryptogarage.co.jp>
> To: dlc-dev at mailmanlists.org
> Subject: [dlc-dev] DLC Messaging and Networking
> Message-ID:
>         <CABPZDUz3EhhQz=
> GbfeC0GEYGbAbm5SP9kseCOgC_VPTo7jASZA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 25 Mar 2022 21:18:56 -0400
> From: Antoine Riard <antoine.riard at gmail.com>
> To: Thibaut Le Guilly <thibaut at cryptogarage.co.jp>
> Cc: dlc-dev at mailmanlists.org
> Subject: Re: [dlc-dev] DLC Messaging and Networking
> Message-ID:
>         <CALZpt+G2Jo7w=
> aoSyT65i6djji2URvMO1_gTtfH3ZHFNmTHW4w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
>
> dlc-dev mailing list
> dlc-dev at mailmanlists.org
> https://mailmanlists.org/mailman/listinfo/dlc-dev
>
>
> ------------------------------
>
> End of dlc-dev Digest, Vol 13, Issue 6
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20220326/1b45f58c/attachment-0001.htm>


More information about the dlc-dev mailing list