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

[conduition]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20230427/f3a848b4/attachment.sig>