📅 Original date posted:2022-01-28
📝 Original message:> CTV DLCs are non-interactive asynchronously third-party unilaterally
creatable.
This is super interesting. I think that would make it easier to do
multi-party DLCs. With a "normal" DLC, you need to have N parties
exchanging and signing CETs and you end up with a combinatorial explosion
of signing operations to perform. It sounds like if you did it with CTV,
then each party could compute all the outcomes on their own in parallel (to
be able to generate commitments for each tapleaf) and then just exchange
and sign the single opening transaction for the DLC. Or for devices with
limited resources, you could have a coordinator compute the whole TR tree
and publish a ZKP to the other signers.
Cheers,
Alex
On Fri, Jan 28, 2022 at 12:21 PM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Lloyd,
>
> This is an excellent write up, the idea and benefits are clear.
>
> Is it correct that in the case of a 3/5th threshold it is a total 10x *
> 30x = 300x improvement? Quite impressive.
>
> I have a few notes of possible added benefits / features of DLCs with CTV:
>
> 1) CTV also enables a "trustless timeout" branch, whereby you can have a
> failover claim that returns funds to both sides.
>
> There are a few ways to do this:
>
> A) The simplest is just an oracle-free <STH(timeout tx)> CTV whereby the
> timeout transaction has an absolute/relative timelock after the creation of
> the DLC in question.
>
> B) An alternative approach I like is to have the base DLC have a branch
> `<STH(begin timeout)> CTV` which pays into a DLC that is the exact same
> except it removes the just-used branch and replaces it with `<STH(timeout
> tx)> CTV` which contains a relative timelock R for the desired amount of
> time to resolve. This has the advantage of always guaranteeing at least R
> amount of time since the Oracles have been claimed to be non-live to
> "return funds" to parties participating
>
>
> 2) CTV DLCs are non-interactive asynchronously third-party unilaterally
> creatable.
>
> What I mean by this is that it is possible for a single party to create a
> DLC on behalf of another user since there is no required per-instance
> pre-signing or randomly generated state. E.g., if Alice wants to create a
> DLC with Bob, and knows the contract details, oracles, and a key for Bob,
> she can create the contract and pay to it unilaterally as a payment to Bob.
>
> This enables use cases like pay-to-DLC addresses. Pay-to-DLC addresses can
> also be constructed and then sent (along with a specific amount) to a third
> party service (such as an exchange or Lightning node) to create DLCs
> without requiring the third party service to do anything other than make
> the payment as requested.
>
>
> 3) CTV DLCs can be composed in interesting ways
>
> Options over DLCs open up many exciting types of instrument where Alice
> can do things like:
> A) Create a Option expiring in 1 week where Bob can add funds to pay a
> premium and "Open" a DLC on an outcome closing in 1 year
> B) Create an Option expiring in 1 week where one-of-many Bobs can pay the
> premium (on-chain DEX?).
>
> See https://rubin.io/bitcoin/2021/12/20/advent-23/ for more concrete
> stuff around this.
>
> There are also opportunities for perpetual-like contracts where you could
> combine into one logical DLC 12 DLCs closing 1 per month that can either be
> payed out all at once at the end of the year, or profit pulled out
> partially at any time earlier.
>
> 4) This satisfies (I think?) my request to make DLCs expressible as Sapio
> contracts in https://rubin.io/bitcoin/2021/12/20/advent-23/
>
> 5) An additional performance improvement can be had for iterative DLCs in
> Lightning where you might trade over a fixed set of attestation points with
> variable payout curves (e.g., just modifying some set of the CTV points).
> Defer to you on performance, but this could help enable some more HFT-y
> experiences for DLCs in LN
>
> Best,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
> On Mon, Jan 24, 2022 at 3:04 AM Lloyd Fournier via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi dlc-dev and bitcoin-dev,
>>
>> tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a lot*.
>>
>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220128/95d5f0c6/attachment-0001.html>;
Alex Schoof [ARCHIVE] /
npub1l2…t6swn
2023-06-07 23:02:42
in reply to nevent1q…xegg
Author Public Key
npub1l2nulj0wpjdkjj2t6ajqcsxjvm8u4c42qzdgnsa7x6p9hzgqan7q9t6swnPublished at
2023-06-07 23:02:42Event JSON
{
"id": "035753e83408d91d4c931f1801b7f8c9cc32224be2c1d7f804c4d6867635ab04",
"pubkey": "faa7cfc9ee0c9b69494bd7640c40d266cfcae2aa009a89c3be36825b8900ecfc",
"created_at": 1686178962,
"kind": 1,
"tags": [
[
"e",
"6df28059a2a8982db89a60b80e88df97c2717e5e22bca761749cb90c544f80f0",
"",
"root"
],
[
"e",
"759979d9e9c4c2f853d563b42ac5a1681616b446e7ca3db1336694c10c1e8185",
"",
"reply"
],
[
"p",
"372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a"
]
],
"content": "📅 Original date posted:2022-01-28\n📝 Original message:\u003e CTV DLCs are non-interactive asynchronously third-party unilaterally\ncreatable.\n\nThis is super interesting. I think that would make it easier to do\nmulti-party DLCs. With a \"normal\" DLC, you need to have N parties\nexchanging and signing CETs and you end up with a combinatorial explosion\nof signing operations to perform. It sounds like if you did it with CTV,\nthen each party could compute all the outcomes on their own in parallel (to\nbe able to generate commitments for each tapleaf) and then just exchange\nand sign the single opening transaction for the DLC. Or for devices with\nlimited resources, you could have a coordinator compute the whole TR tree\nand publish a ZKP to the other signers.\n\nCheers,\n\nAlex\n\n\nOn Fri, Jan 28, 2022 at 12:21 PM Jeremy via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Lloyd,\n\u003e\n\u003e This is an excellent write up, the idea and benefits are clear.\n\u003e\n\u003e Is it correct that in the case of a 3/5th threshold it is a total 10x *\n\u003e 30x = 300x improvement? Quite impressive.\n\u003e\n\u003e I have a few notes of possible added benefits / features of DLCs with CTV:\n\u003e\n\u003e 1) CTV also enables a \"trustless timeout\" branch, whereby you can have a\n\u003e failover claim that returns funds to both sides.\n\u003e\n\u003e There are a few ways to do this:\n\u003e\n\u003e A) The simplest is just an oracle-free \u003cSTH(timeout tx)\u003e CTV whereby the\n\u003e timeout transaction has an absolute/relative timelock after the creation of\n\u003e the DLC in question.\n\u003e\n\u003e B) An alternative approach I like is to have the base DLC have a branch\n\u003e `\u003cSTH(begin timeout)\u003e CTV` which pays into a DLC that is the exact same\n\u003e except it removes the just-used branch and replaces it with `\u003cSTH(timeout\n\u003e tx)\u003e CTV` which contains a relative timelock R for the desired amount of\n\u003e time to resolve. This has the advantage of always guaranteeing at least R\n\u003e amount of time since the Oracles have been claimed to be non-live to\n\u003e \"return funds\" to parties participating\n\u003e\n\u003e\n\u003e 2) CTV DLCs are non-interactive asynchronously third-party unilaterally\n\u003e creatable.\n\u003e\n\u003e What I mean by this is that it is possible for a single party to create a\n\u003e DLC on behalf of another user since there is no required per-instance\n\u003e pre-signing or randomly generated state. E.g., if Alice wants to create a\n\u003e DLC with Bob, and knows the contract details, oracles, and a key for Bob,\n\u003e she can create the contract and pay to it unilaterally as a payment to Bob.\n\u003e\n\u003e This enables use cases like pay-to-DLC addresses. Pay-to-DLC addresses can\n\u003e also be constructed and then sent (along with a specific amount) to a third\n\u003e party service (such as an exchange or Lightning node) to create DLCs\n\u003e without requiring the third party service to do anything other than make\n\u003e the payment as requested.\n\u003e\n\u003e\n\u003e 3) CTV DLCs can be composed in interesting ways\n\u003e\n\u003e Options over DLCs open up many exciting types of instrument where Alice\n\u003e can do things like:\n\u003e A) Create a Option expiring in 1 week where Bob can add funds to pay a\n\u003e premium and \"Open\" a DLC on an outcome closing in 1 year\n\u003e B) Create an Option expiring in 1 week where one-of-many Bobs can pay the\n\u003e premium (on-chain DEX?).\n\u003e\n\u003e See https://rubin.io/bitcoin/2021/12/20/advent-23/ for more concrete\n\u003e stuff around this.\n\u003e\n\u003e There are also opportunities for perpetual-like contracts where you could\n\u003e combine into one logical DLC 12 DLCs closing 1 per month that can either be\n\u003e payed out all at once at the end of the year, or profit pulled out\n\u003e partially at any time earlier.\n\u003e\n\u003e 4) This satisfies (I think?) my request to make DLCs expressible as Sapio\n\u003e contracts in https://rubin.io/bitcoin/2021/12/20/advent-23/\n\u003e\n\u003e 5) An additional performance improvement can be had for iterative DLCs in\n\u003e Lightning where you might trade over a fixed set of attestation points with\n\u003e variable payout curves (e.g., just modifying some set of the CTV points).\n\u003e Defer to you on performance, but this could help enable some more HFT-y\n\u003e experiences for DLCs in LN\n\u003e\n\u003e Best,\n\u003e\n\u003e Jeremy\n\u003e --\n\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e\n\u003e\n\u003e On Mon, Jan 24, 2022 at 3:04 AM Lloyd Fournier via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Hi dlc-dev and bitcoin-dev,\n\u003e\u003e\n\u003e\u003e tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a lot*.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\n\n-- \n\n\nAlex Schoof\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220128/95d5f0c6/attachment-0001.html\u003e",
"sig": "9002509569226c2be6c585761d56368436c8518ae6712c4c18ffe26ad4221411158c66d7fca0f77f8a7b3ea4221cea64ab71f135f529cb070b164d7e56a79a79"
}