[dlc-dev] dlc-dev Digest, Vol 8, Issue 4
Matthew Black
matthew at atomic.finance
Tue Oct 5 01:57:34 CEST 2021
Hey everyone,
These are my current thoughts on the situation.
1. I agree that having a way for old implementations to "fail fast and
loud" is ideal. I originally thought this was achieved by having different
types for each message (i.e. DlcOfferV0, DlcOfferV1, etc.) which would
signify breaking changes if a message type was unknown. So it seems to me
like it would be good to lockdown the purpose of `protocol_version` and
message versioning.
2. I would agree that we should not stop making breaking changes to the DLC
specifications, especially since there are no clients that are fully
spec-compliant, and the only implementations that are interoperable are the
Suredbits oracle and Atomic Finance node and app.
However, we should be wary of a series of breaking changes, since there are
still lots of live oracle announcements that are currently being used for
DLCs that are not expiring for another 3 months. For this reason, I think
it's essential that clients and oracles implement these changes in a way
that is backwards compatible, or provide multiple versions of these
announcements and attestations. At the moment, this really just involves
coordination between Suredbits and Atomic Finance. Additionally, I think it
would be wise to push towards a stable *specification* version to avoid
this causing grief in the near future.
3. To add to the previous discussion, not only should DLCs be able to be
opened between different implementations, but also it should be possible
for oracle announcements and attestations to be provided from and to all
implementations.
4. I agree that our path forward for cross-compatibility should not come
from trying to be immediately compatible. Node-DLC and CAL-Finance
libraries have aimed to be spec-compliant for the features that were most
pressing for us (I think we're still missing multi-oracle support and
PolynomialPayoutCurvePiece) but have not tested compatibility with the
bitcoin-s implementation for example (other than their oracle setup)
As of right now, the proposed changes involve some tricky breaking changes
for existing implementations, particularly oracles. As it stands there are
many oracle events in the wild with no idea how many clients are using
these oracle announcements due to the private nature of DLCs, and many of
these announcements ending 3 months from now. I don't think this is
necessarily a specification concern, but will simply require some
additional development to ensure backwards compatibility, and an upgrade
path for both clients and oracles. This of course means that if there are
multiple breaking changes introduced, it may take longer for oracles and
clients to update to the latest V0.
I think test vectors for each specification document once we have a
finalized V0 is a great idea. Another important aspect to ensuring
cross-implementation compatibility will be deciding on a transport layer.
Node-DLC has an implementation that works over IRC currently, but I suspect
using the lightning transport layer would make more sense for the wider
community.
Looking forward to the continued discussion!
Cheers,
Matt
On Wed, Sep 29, 2021 at 6:00 AM <dlc-dev-request at mailmanlists.org> wrote:
> Send dlc-dev mailing list submissions to
> dlc-dev at mailmanlists.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailmanlists.org/mailman/listinfo/dlc-dev
> or, via email, send a message with subject or body 'help' to
> dlc-dev-request at mailmanlists.org
>
> You can reach the person managing the list at
> dlc-dev-owner at mailmanlists.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dlc-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Breaking Changes Discussion (Nadav Kohen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 28 Sep 2021 22:57:23 -0400
> From: Nadav Kohen <nadavk25 at gmail.com>
> To: Chris Stewart <chris at suredbits.com>
> Cc: dlc-dev at mailmanlists.org
> Subject: Re: [dlc-dev] Breaking Changes Discussion
> Message-ID:
> <
> CACCxFs5oD_9xmjVBzS-MhyEZUNwfkKzQta2EtgZUYyWYLGufdA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> Here are my current thoughts on these questions, would be happy to continue
> this discussion though as I am open to changing my positions.
>
> 1) I agree that the solution here seems to be having a way for nodes to
> detect and broadcast the version they are running. I believe this is easily
> solvable by adding a `protocol_version` field as Thibaut has already
> proposed (and perhaps an additional error message detailing that you have
> an incompatible version). That said, adding such a field is itself a
> breaking change and so I would like to note that in my mind, the
> responsibility on existing deployed nodes of dealing with this problem lies
> with the implementations themselves.
>
> 3) I agree that our goal should be general DLC-ecosystem compatibility not
> only between different implementation's nodes but also between different
> backends and front-ends and other such components that should be
> compatible. Since this is the goal of having a specification, my view on 2
> is the following:
>
> 2) We should not stop making breaking changes to the DLC specification. As
> it currently stands, no implementation is fully specification compliant and
> no implementations are currently cross-compatible (beyond small components
> e.g. bitcoin-s oracle and atomic-finance client, but no two client-side
> implementations are compatible in any real sense). As such, there is
> currently no holistic gain (specifically the goals mentioned above by Chris
> and by me for 3) to having the specification as is, and more specifically I
> do not believe that any implementation currently has plans of supporting
> the entire specification as it currently exists, without any breaking
> changes.
>
> My view is that what has happened is that around February or March of this
> year (2021), many implementations had a change in priorities from trying to
> build out the spec and implementations approaching compatibility with each
> other to building stand-alone self-compatible implementations that were
> user-facing, user-friendly and usable by a larger audience. I don't think
> that this change in priorities is a negative thing, but I do think it
> happened and as a result breaking changes to the specification and to
> implementations essentially stopped happening altogether initiating an
> informal but functional freeze on some aspects of DLC development. I don't
> believe that individual implementations should be discouraged from pursuing
> stable versions of working (non-compliant) DLC code, quite the opposite,
> but I do want to argue that there is no real reason why this approach
> should hinder specification development.
>
> I don't see why the DLC specification should remain unchanged and
> unfinished due to resistance towards breaking changes if the
> implementations that are trying to be stable are already specification
> in-compatible and that, generally speaking, there aren't plans for
> cross-stable-implementation compatibility under any notion of "the current
> spec version". I see no reason why the specification can't continue to have
> non-backwards-compatible improvements that these stable implementations
> simply don't adopt until some future version of their software is released.
>
> Essentially my point is that there is no reason to view breaking changes to
> the spec as a burden on implementations since we don't *yet* live in a
> world of cross-implementation compatibility where breaking changes become
> important. Until we come close to this vision of the future, breaking
> changes should continue in the DLC specification until it reaches a stable
> *specification* version, that is, a specification version which is intended
> for implementations to view as stable and which is intended for use in
> cross-implementation compatibility. The current specification is not such a
> specification version and as such building on top of unfinished
> specifications comes with some annoyances such as having the responsibility
> of dealing with breaking changes lying with the implementation rather than
> the specification, especially in the current setting where implementations
> that are being released as user-facing aren't even current-specification
> compliant.
>
> 4) As has been stated at length above, I think our path forward to
> cross-compatibility does not come from immediately trying to be compatible
> with our implementations current versions' (which would be paradoxical
> since we all have different, non-compatible implementations), but rather by
> continuing to improve and finish up v0 of the DLC specification (which will
> involve multiple breaking changes) and once this version is reached it then
> becomes reasonable to attempt cross-implementation compatibility according
> to that finalized specification version and that specification version
> should be resistant to backwards-incompatible changes. On a more pragmatic
> note, once this version is completed, I think test vectors for each
> specification document should be prioritized in order to facilitate
> cross-implementation compatibility and correctness.
>
> Looking forward to hearing what others have to say :)
>
> Best,
> Nadav
>
> On Sun, Sep 19, 2021 at 2:37 PM Chris Stewart <chris at suredbits.com> wrote:
>
> >
> > 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/20210928/8ae0e6f3/attachment-0001.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
>
> dlc-dev mailing list
> dlc-dev at mailmanlists.org
> https://mailmanlists.org/mailman/listinfo/dlc-dev
>
>
> ------------------------------
>
> End of dlc-dev Digest, Vol 8, Issue 4
> *************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20211004/69ea5191/attachment-0001.htm>
More information about the dlc-dev
mailing list