[dlc-dev] Breaking Changes Discussion

[Nadav Kohen]

Hi all,

So at the last spec meeting we began a general discussion about making
breaking changes to the DLC specs and it didn't really reach a conclusion
so I'd like to continue that conversation here.

Here is my attempt to summarize the state of things:

   - There has functionally been a freeze on breaking changes to the
   dlcspecs repo for many months now.
   - It appears that this is largely due to wanting to be cautious about
   making breaking changes to existing, user-facing applications.
   - On the other hand, the specs are not done and furthermore, none of the
   existing applications are (fully) spec-compliant.
      - Most implementations currently agree on enumerated outcomes and
      oracle messages, but little else.
   - There are a good number of breaking changes in the pipeline including
   (but probably not limited to)
      - P2P message serialization
      - Oracle messages and key infrastructure
      - Event order specification
      - Taproot
   - Roughly, the stances I've heard so far is that
      - Specification changes should continue and it should be on
      implementations to decide how spec compliant (and to which spec
version) to
      be compliant with the goal that someday everyone is compliant to the same
      thing (noting no one is currently at that state anyway)
      - Specification changes shouldn't be made very often and there should
      be some mechanism to group a bunch of changes together (e.g. all four of
      the above as one protocol update with a new version)


I won't put my personal opinions in this discussion starter email (I will
likely do this later in the thread), but here are the questions I think
need to be discussed:


   1. The DLC specification and improvements to it are not done and it
   appears that (partial, non-compliant) implementations have become
   user-facing, what mechanisms are available to us that are the least painful
   for these applications that will allow DLC specification work to continue?
   2. Are there explicit benefits to be gained by freezing development or
   else tagging a version? It is currently unclear (at least to me) what falls
   in the realm of specification-level concerns and what is
   implementation/application-specific concerns.
   3. Explicitly, what are the purported/desired benefits from having a
   unified specification for DLC development and how do these affect the above
   questions?
   4. What is our path forward towards cross-implementation compatibility?


There are likely other considerations I'm missing here so please feel free
to respond on this thread with other things you think are important. Also
people should feel free to respond to any number (including just one) of
these questions.

Best,
Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20210918/df5bb0f9/attachment.htm>