[dlc-dev] Off-Chain DLC Market Maker
Matthew Black
matthew at atomic.finance
Thu Nov 30 20:06:50 CET 2023
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 --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20231130/039623a4/attachment-0001.htm>
More information about the dlc-dev
mailing list