[dlc-dev] Off-Chain DLC Market Maker

[conduition]

Hi Matt, thanks for the message. I think you came up with
roughly the same concept I had for the off-chain settlement
path of a ticketed DLC.

Just one thing: There's no need for the ticket secret to
involve the off-chain cooperative settlement. If the
market maker wasn't able to reveal the ticket secret by
that point, the player would not have been able to pay for
the ticket in the first place.

Instead, the cooperative transaction would pay to
the market maker's pubkey, additionally encumbered by some
player-chosen secret which can be sold to the market maker.
That secret does not necessarily need to be fixed before
the contract starts. It can be generated on demand.

Whether done via an HTLC or PTLC, the idea is for
the market maker to have the option of buying back their
funds from the winner(s) of the DLC off-chain, hence the
relative timelocks on `tx_winner_i_j` and `tx_reclaim_i_j`.

I made a diagram which might help to visualize the flow.
Check out my post here:

https://delvingbitcoin.org/t/off-chain-dlc-ticketing-systems/214/3

> Unfortunately this would reduce capital efficiency even
> further, because it would require for the market maker
> to not only have on-chain funds for this, but also funds
> in lightning to pay for off-chain settlement.

Very true, but as long as the market maker earns enough to make
up for the capital commitment, I don't suppose they'd mind.

The more significant problem is how to effectively insure
the market maker against spam (people claiming interest,
but never buying tickets) from locking up their capital.
The up-front deposit was one idea. Another is fidelity bonds.
Would love to hear any suggestions on this subject.

-conduition

On Thursday, November 30th, 2023 at 7:06 PM, Matthew Black via dlc-dev <dlc-dev at mailmanlists.org> wrote:


> Hey conduition,
> 

> I'm wondering if it would be possible to enable smoother off-chain settlement by using a CET that requires both the ticket secret and a new secret created by the participant before entering.
> 

> This way, upon expiry, the participant could provide a lightning invoice using that secret, and by claiming the funds, they would also reveal this new secret.
> 

> The CET could be set up in a manner, such that the market maker can claim the funds with both secrets before 2 * delta, otherwise the user can claim it after 2 * delta using the ticket secret.
> 

> That way, if the user doesn't come back and create the lightning invoice, they can still claim the funds after a timeout.
> 

> Unfortunately this would reduce capital efficiency even further, because it would require for the market maker to not only have on-chain funds for this, but also funds in lightning to pay for off-chain settlement.
> 

> 

> Cheers,Matt
> 

> On Mon, Nov 20, 2023 at 6:00 AM <dlc-dev-request at mailmanlists.org> wrote:
> 

> > Send dlc-dev mailing list submissions to
> > dlc-dev at mailmanlists.org
> > 

> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://mailmanlists.org/mailman/listinfo/dlc-dev
> > or, via email, send a message with subject or body 'help' to
> > dlc-dev-request at mailmanlists.org
> > 

> > You can reach the person managing the list at
> > dlc-dev-owner at mailmanlists.org
> > 

> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of dlc-dev digest..."
> > 

> > 

> > Today's Topics:
> > 

> > 1. Off-Chain DLC Market Maker (conduition)
> > 

> > 

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

> > Message: 1
> > Date: Sun, 19 Nov 2023 19:47:39 +0000
> > From: conduition <conduition at proton.me>
> > To: "dlc-dev at mailmanlists.org" <dlc-dev at mailmanlists.org>
> > Subject: [dlc-dev] Off-Chain DLC Market Maker
> > Message-ID:
> > <RRbrLa6Opjr41dpxRJXt5Tc2Vj0mj20Qg_43qg0KddcQl_ByIqMRmrF9AN2PDBR8D3c92TMrhBdiFzu5quDfh6Qol-8XUomHGvJkbTvc2lg=@proton.me>
> > 

> > Content-Type: text/plain; charset="utf-8"
> > 

> > Hi dlc-devs. I had an idea which I think might enable better scaling
> > and privacy for DLCs which have lots of participants. The concept was
> > originally geared towards provably fair lotteries. I made a more
> > detailed blog post about it here:
> > 

> > - https://github.com/conduition/conduition.io/pull/4
> > - https://conduition.io/scriptless/lottery/
> > - http://conduit4u4zsimbgvcatj6lyy36ot6k7w7bvbvivgwhbgzs7gfds7qad.onion/scriptless/lottery/
> > - https://stacker.news/items/321995
> > 

> > At the end of that article, I briefly note how the strategy could be
> > generalized beyond simple lotteries to DLCs. Let me summarize the concept
> > here so you don't have to read the whole article above.
> > 

> > ## Concept
> > 

> > A bunch of players with pubkeys `[P_1, P_2, ... P_n]` want to participate in
> > a DLC together.
> > 

> > Let `delta` be some block delay within with a transaction could reasonably be
> > mined, e.g. 144 blocks.
> > 

> > The outcome of the DLC will be signed by an oracle who promises to sign one of
> > a set of outcome messages `[m_1, m_2, ...]` using nonce `R`. A message `m_i`
> > if signed would unlock the point `S_i = R + H(R, D, m_i) * D`, where `D` is
> > the oracle's pubkey. WLOG we can also support multiple oracles.
> > 

> > If there are many players, and buy-in costs are low, then setting up an n-of-n
> > contract with deposits paid from all `n` players would be expensive and
> > inefficient. Instead, as long as there is an available 'market maker' with
> > enough capital to cover the cost of the whole DLC up-front, the players can
> > use the market maker's capital on-chain, and each buy into the DLC using
> > off-chain HTLCs or PTLCs paid to the market maker.
> > 

> > 

> > The market maker could be a contestant in the DLC himself, or he could be an
> > independent bystander seeking to profit by leasing his on-chain capital to
> > 

> > serve others.
> > 

> > ## Example
> > 

> > Here's a simple example of a DLC with 3 players, and a fourth market maker
> > who isn't participating in the DLC. We assume the oracle signs one of two
> > possible messages, which dictates the outcome.
> > 

> > 1. The market maker sets up `tx_init`, which deposits the whole DLC value into a
> > 4-of-4 multisig address.
> > 

> > 2. The market maker sets up `[tx_outcome_1, tx_outcome_2]` - one
> > for every possible outcome.
> > - Each `tx_outcome_i` distributes the value of the DLC, paying to a specific set
> > of winners depending on the outcome.
> > - For each player (a 'winner') who receives money from the DLC outcome, we add
> > an output to `tx_outcome_i`.
> > - Each output in `tx_outcome_i` pays to a 2-of-2 escrow contract jointly owned
> > by a winning player and the market maker.
> > - Spending from each output in `tx_outcome_i`, the market maker sets up two
> > mutually exclusive transactions:
> > - `tx_winner_i_j`, which pays to the sole control of player `j` after a
> > relative timelock of `delta` blocks.
> > - `tx_reclaim_i_j`, which pays to the sole control of the market maker after
> > a relative timelock of `2 * delta` blocks.
> > 

> > 3. The market maker sends these transactions to the players, who reply with partial
> > signatures. The players take no issue with signing, because so far the players
> > haven't invested any money into the DLC; The market maker is frollicking about
> > with their own capital at this stage.
> > 

> > 4. The market maker verifiably encrypts the signatures on each `tx_outcome_i` with
> > the point `S_i` (the oracle's locking point for outcome `i`)
> > 

> > 5. The market maker generates a set of secret tickets `[t_1, t_2, t_3]`, one for
> > each player. Each ticket has a public point `T_i = t_i * G`.
> > 

> > 6. The market maker verifiably encrypts the signatures on each `tx_winner_i_j` with
> > the point `T_j`, so that the ticket for player `j` is needed to decrypt
> > `tx_winner_i_j` (the TX which pays out to player `j`).
> > 

> > 7. The market maker sends the encrypted signatures on all `tx_outcome_i` and
> > `tx_winner_i_j` transactions to the players.
> > 

> > 8. The players verify and ACK the adaptor signatures.
> > 

> > 9. (optional) All players pay a small anti-spam deposit to the market maker.
> > 

> > 10. The market maker signs and publishes `tx_init`.
> > 

> > 11. Once `tx_init` is confirmed, each player `j` has an incentive to learn the
> > ticket secret `t_j` that encrypts `tx_winner_i_j`. The market maker can now
> > sell each ticket secret `t_j` to player `j` using an off-chain point time
> > lock contract. The price of the earlier deposit can be factored into this
> > ticket price.
> > 

> > 12. Once all tickets have been purchased, and the outcome signature `s_i` is
> > published by the oracle, then the market maker has several options to settle
> > the on-chain contract with each winning player:
> > 

> > a. (cooperative, off-chain) The winner can claim the money in her outcome
> > transaction output, but only after `delta` blocks. She can adaptor-sign a
> > settlement transaction with no locktime returning the output of `tx_outcome_i`
> > to the market maker, and then sell the adaptor secret key to the market
> > maker. This TX would supercede `tx_winner_i_j`.
> > 

> > b. (cooperative, on-chain) If the winner wishes to receive their DLC winnings
> > on-chain, she can cooperate with the market maker to sign a version of
> > `tx_winner_i_j` which has no relative locktime, and broadcast it. The two
> > 

> > could even arrange a CoinSwap [1], where the winner is paid out from a
> > completely unrelated UTXO, owned by the market maker.
> > 

> > c. (forceful, on-chain) If the market maker is not cooperative, the winning player
> > simply waits for the relative locktime on `tx_winner_i_j` to mature and
> > broadcasts it.
> > 

> > ## Discussion
> > 

> > Assuming a player can learn `s_i` (the discrete log of `S_i`) from the oracle, then
> > they can decrypt and publish `tx_outcome_i` independently without the market maker's
> > cooperation. However, by itself this is not useful to the player, because the market
> > 

> > maker will use `tx_reclaim_i_j` to return the money to himself after its relative
> > 

> > locktime of `2 * delta` blocks matures.
> > 

> > However, if player `j` knows their ticket `t_j` as well, they can decrypt and publish
> > `tx_winner_i_j` to claim their winnings independently (under outcome `i`). This
> > is what creates the incentive to buy tickets.
> > 

> > As described, nothing forces players to buy a ticket. A player could feign interest
> > but abstain from actually purchasing a ticket. Players who abstain in this way
> > will force the market maker into assuming their position in the DLC, creating
> > counterparty risk.
> > 

> > If the market maker is unwilling to expose themselves to any counterparty risk,
> > they can use HODL invoices to accept deposits and ticket payments, only revealing
> > ticket secrets once all players have active PTLC/HTLC offers for their tickets. If
> > a player paid a deposit but did not buy a ticket, then the market maker can take
> > 

> > their deposit as payment for wasting their time and locking up their capital for
> > 

> > no reason. (Is there a better system there? more investigation needed)
> > 

> > It would also be nice if there were a way to make an even smoother off-chain
> > settlement flow. Perhaps in a situation where all DLC winners cooperate with
> > the market maker, there could be some kind of cooperative atomic off-chain
> > payment which pays out to all the winners at once, and returns the whole DLC
> > output to the market maker somehow.
> > 

> > 

> > ## Benefits
> > 

> > - No on-chain association between DLC contestants
> > - On-chain footprint does not indicate how many participants; only reveals
> > number of winners paid out.
> > - Minimal on-chain footprint (one TXO in, one TXO back out) might be achievable
> > - Market maker is not trusted with custody of funds
> > - Market maker can be incentivized by charging fees (e.g. keeping deposits)
> > - If using PTLCs, the contract's happy path consists entirely of taproot key
> > spending (great for fungibility).
> > - If using HTLCs, this protocol could be executed via LN today, no new BOLTs,
> > 

> > opcodes, or sighash types required.
> > 

> > ## Diagram
> > 

> > Although not exactly the same as the DLC generalization i just described,
> > 

> > the diagram in this section of the lottery protocol blog post might help
> > 

> > to visualize the flow of on-chain transactions.
> > 

> > https://conduition.io/scriptless/lottery/#Lottery-Signing
> > 

> > ## HTLCs instead of PTLCs
> > 

> > To suppor classic lightning HTLCs, we simply rephrase the protocol such that the
> > ticket secret `t_j` is a preimage, and `T_j = H(t_j)`. Instead of adaptor signatures
> > on each `tx_winner_i_j`, we instead encumber the relevant output of `tx_outcome_i`
> > 

> > with an HTLC script or tapscript tree like this:
> > 

> > ```
> > <market_maker && P_j> OR
> > <P_j && preimage(T_j) && delay(delta)> OR
> > <market_maker && delay(2*delta)>
> > ```
> > 

> > Off-chain payouts to winners can also be trivially converted to HTLCs.
> > 

> > Keen to hear your thoughts,
> > -conduition
> > 

> > [1] https://bitcoinops.org/en/topics/coinswap/
> > -------------- 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/20231119/ee3f6969/attachment-0001.asc>
> > -------------- 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/20231119/ee3f6969/attachment-0001.sig>
> > 

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

> > Subject: Digest Footer
> > 

> > 

> > dlc-dev mailing list
> > dlc-dev at mailmanlists.org
> > https://mailmanlists.org/mailman/listinfo/dlc-dev
> > 

> > 

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

> > End of dlc-dev Digest, Vol 27, Issue 1
> > **************************************
-------------- 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/20231209/e39c66da/attachment.asc>
-------------- 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/20231209/e39c66da/attachment.sig>