[dlc-dev] DLC Messaging and Networking

[Philipp Hoenisch]

Hi all,

thanks for bringing this up @Thibaut. It's a topic we have been 
discussing internally extensively in the past :)

On 26/3/2022 12:04 am, Thibaut Le Guilly wrote:
> Hi all,
>
> [...]
> _itchy-sats:_
>
>  1. Not implemented (or applicable, single maker?)
>
We have no discovery (yet) but takers can provide a maker's address as a 
runtime argument.


> # 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 almost all our past projects we distinguished between two types of 
nodes: makers and takers. The makers have something to offer, and the 
takers want to find the "best" suitable offer. What is "best" is 
debatable but one important criteria is that these offers can actually 
be taken, i.e. they are real.

So I think you bring up an important topic: DoS and spam protection: 
this is really hard in a peer2peer network so we decided to split 
discovery up into two parts:

1. Node discovery
2. Order discovery

(1) node discovery: In our case, node discovery means, that makers 
announce their intention to offer something somewhere. Our past projects 
made use of rendezvous nodes [0] or gossipsub [1].

Rendezvous nodes are some form of registry servers where nodes can 
register themselves and gossipsub is a pub-sub protocol on top of gossip.

In our case: the makers registered themselves with the trading pairs 
they want to offer and their connection details at an rendezvous node, 
or broadcast their details via gossip. Note: this announcement does not 
include any offer details which can expire such as rates, amounts, etc.
Takers can connect to these rendezvous nodes or subscribe to the 
gossipsub channels and will receive an up2date list of makers who are 
online.

(2) Order discovery: once the taker has a list of makers they open up a 
connection to each maker. This can either be build by polling, i.e. the 
takers "ask" the maker for the latest offers or it can be a pushed based 
approach where the maker tell the taker whenever their offer has changed.

This allows us to push the "spam" protection to the taker side who can 
build up some form of reputation. E.g. a simple naive approach was to 
cut the connection to a maker from the taker side if an order was not 
"real" and never connect to them again. That way, the makers have an 
incentive to provide only takeable offers.

That being said, rendezvous nodes or gossipsub have their advantages and 
disadvantages (e.g. speed vs central point of failure). If we assume 
that splitting the protocols up in 1) node discovery and 2) order 
discovery makes sense then:

In regards to point Using Bolt #10 for point 1). The question is, would 
you re-use existing LN infrastructure for that? If we were to use it, 
then you would get a list of nodes and you'd need to ask each of them if 
they are offering some sort of DLC products. In a big network, where 
suddenly many nodes come only, you could by accident DoS smaller nodes 
with this.

I guess, we'd need to extend that standard slightly to express what the 
nodes registered at this server have to offer (e.g. pure LN vs DLC-based 
products).

In regards to using BOLT #8 for the transport layer: Am I reading it 
correctly that the maximum size of any Lightning message must not exceed 
65535 bytes? That could be an issue for DLCs no?

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

Cheers,

Philipp


[0] rendezvous protocol: 
https://github.com/libp2p/specs/blob/master/rendezvous/README.md
[1] gossipsub: 
https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20220328/381219aa/attachment.htm>