[dlc-dev] DLC Factories
conduition
conduition at proton.me
Wed Jan 15 22:14:14 CET 2025
Hi Philipp & Kulpreet, thanks for your replies :)
I've been talking about this idea with the devs at lava.xyz and they had similar questions:
---------------------
1. How is it different from DLC Channels? [1]
A DLC channel requires active management and participation from both parties to keep it updated as time passes. You need to actively revoke each DLC by revealing a revocation key.
>From the paper [1]:
> A party can revoke a transaction by revealing the private key for the first spending path. If this transaction was to be broadcast on-chain in the future, the counter party has a certain amount of time to use the revocation key to claim the funds from the output.
For each DLC channel, only one DLC can be safely "queued up", so to speak, for unilateral closure. That DLC will generally have a fixed expiration date. If your counterparty goes offline before then, it means you have no unilateral option to settle the contract early, nor to extend it beyond that date.
But for a DLC factory, the participants can "queue up" an unlimited number of DLCs, and each will be unilaterally enforceable without any further interaction after setup time. The only time the two parties NEED to interact again is if they want to sign new DLCs to extend the lifetime of their factory, or to do a cooperative settlement.
The unique idea which makes this property of DLC Factories possible is changing the revocation (punishment) encumbrance to be non-interactive: Either a timelock and/or an oracle attestation unlocks the counterparty's punishment (revocation) path. Once the oracle releases the attestation for a specific DLC, that DLC can no longer be locked-in safely by either party.
This means both parties can safely pre-sign a whole bunch of DLCs which originate from the funding output, and further negotiation is optional. The parties no longer have to interact, but both parties have unilateral exit options for EVERY DLC they pre-signed. With proper use of timelocks, they can enforce that at most one of those DLCs can be safely locked-in at any given time.
Compare this to a DLC channel: You set up the channel, sign a single DLC, and now you have a unilateral exit option but ONLY for that specific DLC. Even if you did pre-sign a whole bunch of DLCs, you need your channel partner to actively revoke those DLCs after they mature - Otherwise they could publish an outdated commitment TX and defraud you. You're forced to go on-chain early to head off that possibility. Compare this to a DLC factory, where your counterparty's commitment TXs are automatically "revoked" (by oracle attestation, or by timelock), whether they cooperate or not, so you don't need to care if they're online or not.
Like with DLC channels, participants still need to passively monitor the chain for punishment, and they can outsource that to a watchtower.
------------------------
2. Can we remove the settlement TX?
If we remove the settlement TX, this would make the contract unsafe.
To demo, let's say we remove the settlement TX, and add a relative-timelock of Delta blocks to the CETs (via nSequence). Those CETs spend directly from the commitment TX, as you suggested:
[funding_tx] -> [commitment_tx_alice] --> [cet_1]
|-> [cet_2]
|-> [...]
|-> <punishment>
Assume Alice publishes this commitment TX to lock-in one specific set of CETs. She does this well in advance of the oracle attestation, so that the timelocks on the CETs can mature. What happens after Delta blocks?
Now Alice's CETs and the punishment path are BOTH usable. The instant the oracle publishes the attestation, Bob can race against Alice's CETs, using the punishment path (recall the attestation unlocks the punishment path for the counterparty) to sweep the DLC's entire value.
The 2nd-stage settlement TX is a requirement to allow Alice to lock in the DLC without having to race Bob once the attestation is published. After the settlement TX confirms, Alice can relax, as the contract is exactly the same as a normal DLC at that point.
----------------------
I'll try to find some time soon to update my post with this comparison to DLC channels, it's certainly not immediately clear!
-c
[1]: https://medium.com/crypto-garage/dlc-on-lightning-cb5d191f6e64
On Sunday, January 12th, 2025 at 2:29 AM, Philipp Hoenisch via dlc-dev <dlc-dev at mailmanlists.org> wrote:
> Hi Conduition,
>
> thank you for sharing this idea. The core concept sounds very similar to
> what we have built with ItchySats in the library Maia [1] and later on
> in 10101 [2] which was implemented in rust-dlc and spearheaded by Tibo.
> We wrote about it in [4] called DLC-channels. Tibo wrote about it in the
> great article about how to bring DLCs to Lightning [5].
>
> The core idea was to be able to update/renew/settle DLCs off-chain -
> we've implemented it to achieve perpetual CFDs and on top of it,
> synthetic stable coins aka stablesats.
>
> This sounds different to what DLC Markets proposed which is on-chain
> renewals and require an on-chain transaction.
>
>
> Anyways, to your work :D
>
> Can you elaborate the motivation for the `Settlement` TX.
>
> If you were to remove it and add the timeout to the CETs you get the
> same functionality? The commitment transaction already locks in DLC and
> both parties can go offline until the attestation happens.
>
>
>
> Cheers,
> Philipp
>
>
> [1] https://github.com/comit-network/maia
> [2] https://github.com/get10101/10101/
> [3] https://github.com/p2pderivatives/rust-dlc
> [4] https://10101.finance/blog/dlc-channels-demystified/
> [5] https://medium.com/crypto-garage/dlc-on-lightning-cb5d191f6e64
>
> On 12/1/2025 5:25 pm, Kulpreet Singh via dlc-dev wrote:
>
> > Hi,
> >
> > Nice write up there. Similar approaches have been suggested by Kuwahara et.al. [1, 2] and are in use by DLC Markets [3].
> >
> > I am using those approaches in Radpool's payout mechanism as well [4].
> >
> > Will be nice to add a section on how your approach compares to those approaches.
> >
> > Best regards
> >
> > -kp
> >
> > [1] - https://ieeexplore.ieee.org/document/9805512
> > [2] - https://github.com/p2pderivatives/offchain-dlc-paper/blob/master/offchaindlc.pdf
> > [3] - https://dlcmarkets.com/whitepaper.pdf
> > [4] - https://www.radpool.xyz/1/payout-mechanism.html#_roll_over_contract_transactions
> >
> > On Sunday, January 12th, 2025 at 3:24 AM, conduition via dlc-dev dlc-dev at mailmanlists.org wrote:
> >
> > > Hey DLC devs,
> > >
> > > I have an interesting concept I concocted recently which I call DLC Factories.
> > >
> > > I'm curious to know if you've seen anything like it before or if you have any
> > >
> > > feedback.
> > >
> > > https://conduition.io/scriptless/dlc-factory/
> > >
> > > This is a way to create a kind of "rolling" DLC which can be endlessly renewed,
> > >
> > > as long as both parties can come online to sign new CETs before a certain deadline.
> > >
> > > Technically, it's more like a series of DLCs which can be funded only at specific
> > >
> > > times and by specific parties.
> > >
> > > It uses a punishment mechanism similar to lightning to deprecate outdated CETs,
> > >
> > > and so requires participants to be always online (or have a watchtower handle it
> > >
> > > for them).
> > >
> > > There's also the potential for a factory to enter a deadlocked state if neither
> > >
> > > participant publishes their commitment TX in time.
> > >
> > > These drawbacks aside, it seems like a neat and relatively straightforward way
> > >
> > > to create things like american-style options, or flexible CFDs, which can be
> > >
> > > exercised or settled at arbitrary times. I wonder if there are new financial
> > >
> > > instruments we could implement on bitcoin using something like this, tailored
> > >
> > > to specific use-cases.
> > >
> > > Feedback appreciated and thanks in advance for any constructive improvement suggestions :)
> > >
> > > -c
> > > dlc-dev mailing list
> > > dlc-dev at mailmanlists.org
> > > https://mailmanlists.org/mailman/listinfo/dlc-dev
> > > dlc-dev mailing list
> > > dlc-dev at mailmanlists.org
> > > https://mailmanlists.org/mailman/listinfo/dlc-dev
>
>
>
> dlc-dev mailing list
> dlc-dev at mailmanlists.org
> https://mailmanlists.org/mailman/listinfo/dlc-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - conduition at proton.me - 0x474891AD.asc
Type: application/pgp-keys
Size: 649 bytes
Desc: not available
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20250115/e8c39d28/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20250115/e8c39d28/attachment.sig>
More information about the dlc-dev
mailing list