[dlc-dev] DLC Factories
conduition
conduition at proton.me
Mon Jan 20 02:26:01 CET 2025
Hey Dave, thanks for asking. Let me dissect your example a little and hopefully things will start making sense.
Your example, starting from "Alice and Bob open a factory", all the way to "the oracle publishes their attestation to the BTCUSD price for t_0" makes perfect sense. I believe this sentence belies your confusion:
> Either party can now now spend from the original commitment transaction.
Actually at this point, neither Bob nor Alice can safely publish the commitment transaction for the t_0 DLC. They MAY be able to publish the commitment TX for the later t_1 DLC, but that depends on its locktime.
The punishment (AKA revocation) spending paths on the outputs of the t_0 commitment transactions are typically unlocked by the oracle attestation issued at or around t_0. Alice's commitment transaction can be swept if Bob has the attestation. Likewise Bob's commitment TX can be swept if Alice has the attestation. This means if either party were to publish the commitment TX for the first DLC at time t_0, as in your example, they'd forfeit the money to their counterparty. Any DLC Factory commitment TX thus has a natural "expiration-date", which occurs shortly before the attestation is released.
In order to safely publish a DLC Factory commitment transaction, you have to publish it BEFORE the expected attestation time for the child DLC. How long before, exactly? That's determined by the relative timelock parameter Δ, by how long you expect it takes on average to mine a transaction, and by how much wiggle room you need in case the oracle publishes early. To settle the DLC Factory on-chain, you publish the commitment TX first, and wait out the relative timelock. Then you publish the settlement TX. Once the settlement TX is mined, you've locked-in the DLC and your counterparty can no longer punish you when the attestation is released. From here on, it's a normal DLC through and through.
This all makes DLC Factories behave very differently from DLC Channels. If your example were using a DLC Channel, the peers could wait until after the attestation at t_0, and then negotiate a new DLC based on the outcome of the previous one, and then revoke the old DLC, or they could force-close on-chain if their peer is uncooperative.
Contrastingly with a DLC Factory, you must negotiate at least one new DLC BEFORE the last commitment TX expires, lest you end up without an on-chain exit path. If that becomes impossible, you MUST force-close before the last commitment TX expires.
> it would seem to me that DLC factories must be settled onchain before the earliest maturation date of any DLC contained within them.
You're very close here. Actually the DLC must be settled on-chain before the FINAL DLC's maturation date - the DLC which matures last. If participants wait beyond that time, all commitment TXs will expire, and there is no longer a safe unilateral exit path available to either participant. Participants must come online occasionally to sign new DLCs from the factory, extending its lifetime.
Think of a DLC Factory as a device with infinite battery density, but with some non-zero energy leakage rate. The participants can charge it as much as they want (by signing new DLCs) at any time they're both available. But over enough time, it will eventually leak enough energy to become completely drained (deadlocked because all commitment TXs expired). It is crucial to ensure that this metaphorical device never completely runs out of battery, but if you have enough power and time, you could charge it so much it outlasts even your grandchildren.
I hope this helps :)
conduition
On Saturday, January 18th, 2025 at 9:37 AM, David A. Harding <dave at dtrt.org> wrote:
> On 2025-01-11 16:24, conduition via dlc-dev wrote:
>
> > 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.
>
>
> Hi conduition,
>
> I'm having trouble understanding how DLC factories can be both
> "endlessly extended without any onchain transaction" but also spendable
> by either party at the time any attestation is published. Imagine:
>
> - Alice and Bob open a factory with a commitment transaction to a DLC
> for the BTCUSD price at time t_0.
>
> - Well before time t_0, they reuse the same funds and sign alternative
> commitment transactions for a DLC for the price at a much later time
> t_1.
>
> - Nothing (besides the funding transaction) has been published onchain
> so far.
>
> - Shortly after time t_0 (but long before time t_1), the oracle
> publishes their attestation to the BTCUSD price for t_0. Either party
> can now now spend from the original commitment transaction. If they're
> a miner or have miner assistance, they can spend without going through
> public transaction relay, so the their counterparty doesn't learn of the
> intended theft until after the spend has been confirmed.
>
> I suspect I'm missing something, but it would seem to me that DLC
> factories must be settled onchain before the earliest maturation date of
> any DLC contained within them.
>
> Sorry for my confusion and thanks for the interesting proposal!,
>
> -Dave
-------------- 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/20250120/13a04571/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/20250120/13a04571/attachment.sig>
More information about the dlc-dev
mailing list