[dlc-dev] Off-Chain DLC Maker/Taker Network

Thibaut Le Guilly thibaut at cryptogarage.co.jp
Thu Apr 27 10:55:27 CEST 2023


Hi Conduition,

I believe what you are describing was discussed on the DLC telegram by
Ruben Somsen (at least it looks very similar to me, correct me if I'm
wrong): https://t.me/BitcoinDLCs/3125

However I don't think anyone has fleshed out a concrete proposal, so it
would certainly be interesting to see one. In particular I don't think
anybody has put much thought in how to make the establishment atomic over
multiple hops.

I guess one of the main drawbacks is that every intermediate node needs to
establish two DLCs and thus locking up two collateral for the duration of
the contract, but assuming a good enough premium it might still be valuable
to node operators.

Note that (as discussed in a previous thread:
https://mailmanlists.org/pipermail/dlc-dev/2021-November/000091.html)
assuming a different type of payment channel (Donner), it would be possible
to do routed DLCs without the drawback mentioned above.

Cheers,

Thibaut



On Thu, Apr 27, 2023 at 10:29 AM conduition via dlc-dev <
dlc-dev at mailmanlists.org> wrote:

> Hi all, I'm new to this mailing list so go easy on me =)
>
> On the subject of routing off-chain DLCs between peers, has anyone
> investigated the opportunity to create a network effect by chaining DLC
> offers?
>
> # Concept
>
> Let's say Alice, Bob, and Carol have off-chain channels set up between
> each other like so:
>
> Alice <------> Bob <-----> Carol
>
> These channels are capable of supporting DLCs. Alice offers Bob a DLC on
> some Oracle's outcome. For simplicity, we'll say it is a binary outcome
> with 1:1 odds, like a coin toss: If the coin lands heads, Alice wins and
> she gets 1 BTC from Bob. If the coin lands tails, Bob gets 1 BTC from Alice.
>
> Bob isn't interested in accepting this DLC himself, but maybe Carol is.
> Bob turns around to Carol and offers her the same DLC which Alice offered
> to Bob, except Bob adjusts the DLC payouts to be just slightly in his favor
> on both outcomes: If the coin lands heads, Carol gives Bob 1.001 BTC. If
> tails, Bob gives Carol 0.999 BTC. The outcomes would look like this:
>
> ## Heads
>
>         < +1 BTC <        < +1.001 BTC <
> Alice <------------- Bob <--------------- Carol
>
>
> ## Tails
>
>         > +1 BTC >        > +0.999 BTC >
> Alice -------------> Bob ---------------> Carol
>
>
> # Incentives and Privacy
>
> Alice and Carol don't need to know about each others' channels with Bob.
> Actually, they don't even need to know of each other's existence at all,
> unless they wish to make channels with each other in the future. Their
> channels with Bob could be private, hidden from everyone except Bob. For
> Alice and Carol, their main incentive to offer or accept a DLC isn't WHO
> they're betting with; it's the outcome and the potential payout derived
> therefrom. If they wanted to bet with each other directly for some reason,
> they could create their own direct channel, or construct an on-chain DLC.
>
> Bob's incentive is that he'll gain 0.001 BTC on one of his channels, no
> matter which outcome is signed. Bob can determine the fee he levies from
> the DLC as a function of the amount of liquidity he would lock into the
> DLC, multiplied by the expected DLC lifetime. As a result, his fee would
> get lower and lower as the potential DLC approaches its expected maturation
> date.
>
> From Carol's perspective, Bob is offering her a slightly unfair DLC, but
> even an unfair DLC is worthwhile if Carol is confident enough in the odds
> and the payout is worth it.
>
> The trick is that Bob must ensure neither Alice nor Carol can lock him
> into the DLC, thus exposing him to a contract he doesn't want any part in.
> It gets more complicated when you think about this constraint in the domain
> of 2 or more intermediary 'DLC routing' nodes place of Bob. In theory it
> should be doable, because both the DLC maker (Alice) and the taker (Carol)
> are willing to accept either state being broadcast (DLC or no-DLC). I
> worked out the signature/revocation key exchange timeline on paper and
> found at least one protocol where this is workable (will discuss in more
> detail later once i've formalized the procedure a bit more).
>
> # Scale
>
> Scale this protocol up and you'd have a network of nodes gossiping DLC
> offers to one-another, who are also able to accept any one of them,
> provided enough bidirectional channel liquidity along the whole routing
> path. The more well connected your node is, the more offers you'd see and
> the better the payouts would be.
>
> Conversely, the offers would be increasingly crummy the further you get
> from the DLC maker. The more hops between Alice and Carol, the worse the
> payouts become for Carol. If Carol has channels with multiple DLC nodes,
> she should expect to receive different offers on the same outcome, which
> might stem from the same original DLC maker (Alice). Imagine the same
> example, but with a channel graph like this:
>
> Alice <-----> Bob <-----> Charlie <-----> Chris
>                ^                            ^
>                |                            |
>                '------->  Carol <-----------'
>
> Carol would learn about Alice's DLC offer indirectly through Bob, but also
> indirectly again through Chris, by way of Charlie. The version of the DLC
> offer which Chris gives to Carol would likely have strictly worse payouts
> than Bob's ('strictly worse' meaning worse or identical, for every possible
> outcome). Chris' DLC offer would also be contingent on the same underlying
> Oracle outcome as Bob's offer. Carol could thus ignore Chris' offer because
> no rational actor would ever prefer Chris' offer. If Carol wanted to turn
> around and advertise this DLC offer to another node with whom she has a
> channel, she would base her offer on Bob's offer, not on Chris'.
>
> Nodes would naturally ignore any DLC offers from channel peers who lack
> the necessary liquidity to fund such a DLC. Honest nodes would avoid
> gossiping DLC offers to channel peers if their channel lacks the liquidity
> necessary for that DLC.
>
> # Other Work
>
> I recently learned about 10101 [0]. They are offering a product which is
> apparently similar to what I described in that they are (or appear to be)
> routing off-chain DLCs, but I can't be sure because I can't find any
> documentation on the protocols they use.
>
>
> Has anyone heard of any such concepts before?
>
> -Conduition
>
> [0] https://10101.finance/
> 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/20230427/0ae71f1f/attachment.htm>


More information about the dlc-dev mailing list