[dlc-dev] Message Serialization Changes

[Chris Stewart]

So when reading through both these PRs, here is my high level takeaway. I'm
going to abstain from commenting on specific proposals in this email until
I am sure I understand the intention of Tibo with his proposals.

Here is my understanding of Tibo's concerns, and I apologize in advance if
I mischaracterize his view points.

Things that Tibo doesn't like about the current Messaging.md
<https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md>

- Inefficient encoding at the byte level
- Nesting of TLV types

Things Tibo does like about the the current Messaging.md format

- Allows for variance of subtypes (I'm assuming this as in #163/#171 we
still have variance of nested types, albeit encoded slightly differently).

>From taking a quick glance at the Lightning message spec
<https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#channel-establishment>,
it appears they have no variance in their message types. We have discussed
this as a desirable feature on dev calls. How many messages would we have
if we wanted to take this approach to this messaging spec?

It seems like this could blow up in complexity rather fast, as some of
deepest types (such as contract descriptor
<https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#the-contract_descriptor-type>)
have variance associated with it (enumerated contracts, numeric contracts)
and then are used in higher level types such as contract_info
<https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#the-contract_info-type>.
My understanding is we would lose a lot of flexibility, especially in the
context of disjoint union contracts where we allow arbitrary enumerated and
numeric contract descriptors to be combined. Please correct me if this is
wrong.

### Things I like about the new proposal

Things that I do like about the sibling concept is it gives type locality.
For instance, if you look at Tibo's proposed contract info type
<https://github.com/discreetlogcontracts/dlcspecs/pull/163/files#diff-b8a9c2888fe05c198758fbe393798cd0802b578f7eb07dbf82cc2c90616f97c3R139>you
can see there now is a clear relationship via the sibling type between
`single_contract_info` and `multi_contract_info`, where as in the current
messaging spec, AFAIK, there isn't a relationship between the two tlv types
we allocated for these messages which are 55342 and 55344. This seems very
similar to algebraic data types to me.

I think it would be useful for Tibo to write out his current implementation
concerns, as we have discussed it on calls, but there hasn't been a writeup
on either #163/#171 indicating the problems with the current specification.

-Chris


On Sat, Sep 18, 2021 at 11:57 AM Nadav Kohen via dlc-dev <
dlc-dev at mailmanlists.org> wrote:

> Hi all,
>
> There are currently two open proposals for simplifying and improving the
> current P2P message serialization protocol:
>
> https://github.com/discreetlogcontracts/dlcspecs/pull/163
> https://github.com/discreetlogcontracts/dlcspecs/pull/171
>
> Which of these proposals do we prefer? They are apparently both very close
> in terms of actually implementing but have structural differences (e.g. one
> is closer, but still not in agreement, with the LN TLV model whereas the
> other makes slightly bigger structural improvements).
>
> Thibaut (and I) would love to hear your thoughts.
>
> Best,
> Nadav
>
> 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/20210919/ff60a8ec/attachment.htm>