[dlc-dev] Breaking Changes Discussion

[Chris Stewart]

   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?

I think with breaking changes, I think it needs to be easy for old
implementations to "fail fast and loud". Whatever the change is, it needs
to be easy for existing _deployed_ nodes to understand that there has been
a new feature into the dlc spec and their node software cannot understand
that upgrade unless they update. Perhaps this means you want to
automatically disconnect from your peer.

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.

I don't know.

3. Explicitly, what are the purported/desired benefits from having a
unified specification for DLC development and how do these affect the above
questions?

To allow for dlc wallets to collaboratively build DLCs between each other.
This means they need to speak the same negotiation protocol, and agree on
the onchain parameters for both funding transactions for the DLC and the
CETs. Similar to how C-lightning and LND can open channels between each
other, we want to open DLCs between Atomic Finance and Suredbits, or Crypto
Garage and Atomic Finance.

4. What is our path forward towards cross-implementation compatibility?

I think this is a good question for implementations that are less
developed. AFAIK, bitcoin-s has tried to implement the specifications as
they get merged into master for the dlcspecs repo.

There is a lot of work to be done outside of the specification regardless
of changing the spec, such as implementing a transport layer. We have
another email on the mailing list talking about changing the messaging
protocol, which introduces work for people that have implemented the
messaging spec, and doesn't really reduce the work (they still have to
implement something!) for people that haven't implemented the messaging
spec.

In my mind, interoperability would mean that two implementations can open a
DLC with each other the same way two lightning implementations can open a
channel between each other. I'm not sure if any proposed changes on the
specification are going to help this, it's a matter of applying elbow
grease to get it done.

The smallest integration test that could accomplish this is opening an
enumerated outcome DLC between two peers on the network.

-Chris

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

> 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
>
> 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/538e6681/attachment.htm>