Protocol for closing DLC by mutual consent

[matthewjablack]

The introduction specifies that in a DLC, contract collateral is locked in an output that can only be spent by mutual consent.

However, there is currently no protocol for requesting to close a DLC before cet_locktime with mutual consent.

Additionally, there are some concerns with requesting to close a DLC early. Say Alice wishes to exit her DLC early. Alice could simply provide a mutual close signature to Bob. However, if Bob does not respond this could result in a free option problem where Bob can simply wait for favorable market conditions and sign and broadcast when it is optimal for him.

After chatting with @nkohen it seems the simplest choices to solve this issue are invalidation or revocation (without going into the realm of verifiable encryption).

Invalidation could be solved by having Alice provide her own Input in addition to the DLC Input. If Bob doesn't respond after a certain amount of time, Alice could spend this input, invalidating this close tx.

A close_dlc Message could be formatted as following:

1. type ??? (close_dlc_v0)
2. data:
   • [32*byte:contract_id]
   • [signature:close_signature]
   • [u64:offerPayoutSatoshis]
   • [u64:acceptPayoutSatoshis]
   • [u16:num_funding_inputs]
   • [num_funding_inputs*funding_input:funding_inputs]

payout_spk and payout_serial_id from offer_dlc as well as payout_spk and payout_serial_id from accept_dlc could be used for constructing the close transaction

funding_inputs would be the input(s) provided by Alice that could be invalidated after a timeout.

Curious to hear if folks think this should be added to the spec. I personally think there are quite a few use cases for closing a DLC (such as requesting to close a position where a market maker is the counterparty).

This might also make more sense to add as an optional second layer interaction rather than to the core protocol.

[benthecarman]

I think a PSBT would serve better than a new tlv

[matthewjablack]

PSBT could make more sense, but would still need to be communicated during closing negotiation, meaning a tlv (idk if psbt in a tlv makes sense)

A similar example of closing tlv is closing negotiation in LN #Bolt 2 spec, although this is part of the core protocol.

[ariard]

@matthewjablack What do you think about zero-feerate signature provided by Alice to Bob ?

Let's say at cet_locktime expiration, Alice sends a close_dlc_v0 with her signature to spend the 2-of-2 funding_txo. This signature is committed with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. It should enable Bob to complete the transaction with 0+ input/1+ output to fan out the remaining value from the funding_txo between feerate and his DLC balance ?

[nkohen]

I think a PSBT would serve better than a new tlv

Strong disagree, PSBTs are the worst and shouldn't be used anywhere where we can have a specification instead.

Let's say at cet_locktime expiration, Alice sends a close_dlc_v0 with her signature to spend the 2-of-2 funding_txo. This signature is committed with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. It should enable Bob to complete the transaction with 0+ input/1+ output to fan out the remaining value from the funding_txo between feerate and his DLC balance ?

Would love a quick description of the details here as I haven't spent the time researching how those sighash codes work :)

[nkohen]

Note from May meeting:

Extra input to mutual close to avoid free option, and in the future we will introduce revocation mechanism