[dlc-dev] dlc-dev Digest, Vol 9, Issue 2
Matthew Black
matthew at atomic.finance
Wed Oct 6 00:00:56 CEST 2021
I think allocating some time to ensuring compatibility between the two
libraries makes sense. I've added DLC Spec compliance section to both
Node-DLC <https://github.com/AtomicFinance/node-dlc#dlc-spec-compliance>
and CAL-Finance
<https://github.com/AtomicFinance/chainabstractionlayer-finance#dlc-spec-compliance>
to
help get a better sense of the purpose of each library and which features
have been implemented and which are missing.
>From a messaging serialization and deserialization perspective, I
believe everything in the current spec is currently implemented into
Node-DLC <https://github.com/AtomicFinance/node-dlc#dlc-spec-compliance> (other
than proposals that haven't been merged yet). This should include
everything required to build a front-end interface for an existing back-end
wallet.
It is the wallet implementation in CAL-Finance
<https://github.com/AtomicFinance/chainabstractionlayer-finance#dlc-spec-compliance>
that
is missing some features however it sounds like that's not necessary for
this specific Umbrel application.
Cheers,
Matt
On Tue, Oct 5, 2021 at 11:08 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: dlc-dev Digest, Vol 8, Issue 4 (Chris Stewart)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 Oct 2021 10:06:57 -0500
> From: Chris Stewart <chris at suredbits.com>
> To: Matthew Black <matthew at atomic.finance>
> Cc: dlc-dev at mailmanlists.org
> Subject: Re: [dlc-dev] dlc-dev Digest, Vol 8, Issue 4
> Message-ID:
> <CAFQwNuzBpYcUDnMB_P3eGVjp65BT3rt=
> JS39FkJ7bFdd-j4Dtw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Perhaps we can allocate some time this month to try and start checking
> compatibility between the two libraries.
>
> On the Suredbits front, I think this will be increasingly important to us
> as we have started using node-dlc as the library for supporting RPC clients
> to our backend services. We will need the middleware layer (powered by
> node-dlc) and the backend services to speak the same protocol.
>
> We are looking at launching Krystal Bull (our oracle project) on umbrel in
> the next week or so (https://github.com/getumbrel/umbrel/pull/984), and
> then after that we will start working on getting the full fledged wallet
> shipped to the umbrel platform.
>
> This requires us to make sure the node dlc library is protocol compliant
> with our backend services in the wallet.
>
> >From a cursory glance, it doesn't seem there is a list of implemented
> features and known limitations on the repo. It would be very helpful if you
> could dedicate some time to enumerating that.
>
> https://github.com/atomicfinance/node-dlc
>
> -Chris
>
> On Mon, Oct 4, 2021 at 6:58 PM Matthew Black via dlc-dev <
> dlc-dev at mailmanlists.org> wrote:
>
> > 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
> >> *************************************
> >>
> >
> > 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/20211005/42df2a4e/attachment.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 9, Issue 2
> *************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20211005/8928fa13/attachment-0001.htm>
More information about the dlc-dev
mailing list