[dlc-dev] DLC Factories

conduition conduition at proton.me
Sat Jan 18 08:50:18 CET 2025 

Thanks for your reply Philipp, 


> The idea was actually to allow multiple DLCs in parallel by having multiple outputs of the commitment transaction, each leading to its own DLC output. Updating a single contract though meant to update all contracts which was sub-optimal.



I think i remember reading about this when I was trying - and failing - to figure out how to do routed DLCs. 

Key difference in your case, each DLC output in the channel is enforceable concurrently, whereas in a DLC factory, every DLC is mutually exclusive because it spends the same common funding UTXO. I wonder if there is a benefit to embedding a DLC Factory inside a DLC Channel output. More mathcha diagrams needed...


> Very interesting, so the spending part in the diagram of `B + attestation (or A+attestation)` from `commitment tx` is the punishment mechanism. Which means, that if the attestation is available at the time of publishing `commitment tx` or before the expiry `Δ`, the counterparty can punish you.


That's exactly right. I added some further clarification to my original article:


-   https://github.com/conduition/conduition.io/pull/9
    

-   https://conduition.io/scriptless/dlc-factory/#Comparison-to-DLC-Channels
    




> The challenge though is to have "many" multiple CETs for different events, e.g. a set of CETs for every hour of the day for the next x days. That would be quite computational expensive.


I agree, that's the major bottleneck. OP_CTV would alleviate this [1] but who knows if/when that might happen. The nice thing about factories' performance is, unlike with a DLC channel, you have a lot more flexibility with spreading the signature CPU cycles out over time.


In a DLC channel, you typically only have one, max 2, valid commitment TXs at a time. You might try pre-signing some timelocked commitment transactions in-advance and sign CETs to spend from them, but those pre-signed TXs aren't helpful if your channel peer doesn't revoke the prior commitment TXs in time.


In a DLC Factory, you can have as many valid (timelocked) commitment TXs as you want, extending arbitrarily far into the future. You and your peer can pre-sign new DLCs at any time, as long as you've both agreed on the terms of the contract. Those commitment TXs & CETs will be fully valid/enforceable once your peer goes offline.


I'm not well acquainted with the inner workings of ItchySats and 10101, but your description of "rolling CETs" suggests those are exactly the kind of situations for which DLC Factories are best suited. Imagine every time you and your counterparty are online, the software can passively coordinate to extend the lifetime of your contract, without locking your money into a contract for that full duration. 


For instance you start with a CFD DLC Factory between Alice and Bob which expires in 1 week, and when both Alice & Bob come online, their software clients automatically start exchanging DLC CET signatures for the next week, then for the week after that, and so on. Meanwhile the DLC for week 1 is still fully enforceable so either party can close early if they want. As long as they can both agree on the terms of the DLCs involved, they can theoretically extend the factory like this indefinitely.


The catch is that at least one of them must come online before the final DLC expires - Otherwise, they hit a deadlock.


Weird idea: You could game-ify this. My contracts all have "health bars" which drain over time, and i gotta open The App once in a while to heal them. Low-health contracts need to be executed on-chain. 


Sounds kinda dark. Food for thought.

Thanks!
-conduition

[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html


On Wednesday, January 15th, 2025 at 5:09 PM, Philipp Hoenisch via dlc-dev <dlc-dev at mailmanlists.org> wrote:

> Hi conduition,
> 

> thank you for taking your time to respond in such detail.
> 

> Please find some comments in line below.
> 

> On 16/1/2025 8:14 am, conduition wrote:
> 

> > 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. 

> 

> The idea was actually to allow multiple DLCs in parallel by having multiple outputs of the commitment transaction, each leading to its own DLC output. Updating a single contract though meant to update all contracts which was sub-optimal. In the use case of 10101, we wanted to allow users to have a stable positions (aka stable sats) as well as use funds to trade.
> 

> 

> 

> > 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.
> 

> Thank you for the clarification, I believe I get it now.
> 

> It's mentioned in this part of your article
> 

> > This structure allows Alice and Bob to engage with each other in multiple mutually exclusive DLCs, where either party is allowed to settle any DLC from the factory, as long as the attestation for that DLC has not been published yet, and won’t be published for at least the relative timelock duration after the commitment TX confirms. If the attestation were to be published before that time, the counterparty would be able to sweep all the money from the commitment transaction.
> 

> Very interesting, so the spending part in the diagram of `B + attestation (or A+attestation)` from `commitment tx` is the punishment mechanism. Which means, that if the attestation is available at the time of publishing `commitment tx` or before the expiry `Δ`, the counterparty can punish you.
> 

> Nice :)
> 

> > 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.
> 

> Yea, this sounds correct.
> 

> The challenge though is to have "many" multiple CETs for different events, e.g. a set of CETs for every hour of the day for the next x days. That would be quite computational expensive.
> 

> Did you do some analysis on this? We indeed had a similar challenge but decided to have fixed maturity dates for each contract with multiple liquidation points in between, i.e. have a single DLC with multiple attestation points where if the price drops below (or exceeds) a certain value any time before maturity you can get liquidated and get the current price but if the contract runs normally you have to wait until maturity.
> 

> As a reference, in ItchySats we had 24h rolling CETs, i.e. whenever you come online you extended your contract for another 24h. In 10101 we had 7 days rolling contracts, i.e. you always extended your contract for the next 7 days.
> 

> Cheers,
> Philipp
> 

> p.s. We've spend quite a bit of time on DLCs, DLC-channels and DLCs on Lightning. If you ever want to chat in sync, let me know :) I'm reachable on matrix under @bonomat:matrix.org
> 

> 

> 

> > 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.
> 

> Thank you for the clarification, I get it now.
> 

> Cheers,
> Philipp
> 

> 

> 

> > ----------------------
> > 

> > 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 --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20250118/08b8d12c/attachment-0001.htm>
-------------- 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/20250118/08b8d12c/attachment-0001.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/20250118/08b8d12c/attachment-0001.sig>

More information about the dlc-dev mailing list