[dlc-dev] dlc-dev Digest, Vol 8, Issue 4
Chris Stewart
chris at suredbits.com
Tue Oct 5 17:06:57 CEST 2021
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-0001.htm>
More information about the dlc-dev
mailing list