[dlc-dev] Message Serialization Changes

[Thibaut Le Guilly]

Hi Chris,

> 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

What I mainly don't like about the current format, even without thinking
about the inefficiency, is that we have hard coded values that need to be
kept around in implementations for no good reason (in addition to length
prefixes).
Also we are supposed to ask to reserve the type numbers we are using from
the custom LN message space (at some point?), but are we really going to
ask for like 20 types when in practice we actually need maximum 4? Now
assuming we ask only for 4, we end up having future messages with type
numbers completely apart from the first ones (e.g. see
https://github.com/discreetlogcontracts/dlcspecs/pull/170#discussion_r676235523
).
But to be clear, my main motivation in reviewing the serialization is
getting rid of ~15 constants that are of no use, and a maintenance burden.

Apart from that, the proposals also give us:
* The increased in efficiency you mentioned
* TLV streams at the end of messages for extensibility
* Protocol versioning (if we want that, personally I think we do)

Then I must apologize but I didn't really get the rest of your message
about variance of subtypes. In most aspects I think the proposed changes
give a functionally equivalent format compared to the previous one. I think
there was maybe the discussion about whether we wanted optional fields or
not but I don't feel that's what you're referring to so I would need a bit
more explanation to answer you.

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

Good point updated the description of #163 (
https://github.com/discreetlogcontracts/dlcspecs/pull/163#issue-621730888)

Tibo

On Mon, Sep 20, 2021 at 3:18 AM Chris Stewart <chris at suredbits.com> wrote:

> 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
>>
>
> 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/20210920/27c410fc/attachment.htm>