[dlc-dev] DLC Messaging and Networking

Thibaut Le Guilly thibaut at cryptogarage.co.jp
Tue Mar 29 03:50:30 CEST 2022

Hi Philipp,

Thanks for answering!

> We have no discovery (yet) but takers can provide a maker's address as a
> runtime argument.
> 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.
Thanks for the detailed explanation. Looks like conceptually you're doing
pretty close to what I had in mind :)

> 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).
I think we could use a feature flag and/or some TLV to signal for DLC
support (and possibly provide some useful information). Or are you worried
that even just receiving `init` messages would be too much? I personally
find it appealing to have a single protocol for node discovery and
advertise multiple supported applications.

> 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?
There is indeed a limit, which IIRC is due to the underlying noise
protocol. We discussed that previously and agreed that it should be dealt
with by having some abstraction layer that splits/reconstructs messages
that are too long. It does increase complexity a bit though, but not sure
if it'd be worth using something completely different just because of that.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20220329/cbfa0206/attachment-0001.htm>

More information about the dlc-dev mailing list