[dlc-dev] SIGHASH_ANYPREVOUT allows significant improvement in DLC transferability

Nadav Kohen nadavk25 at gmail.com
Thu Feb 24 23:19:44 CET 2022


Oops, I forgot to add the links I meant to:

[1] https://suredbits.com/transferring-discreet-log-contracts/
[2] https://zmnscpxj.github.io/bitcoin/unchained.html

On Thu, Feb 24, 2022 at 5:14 PM Nadav Kohen <nadavk25 at gmail.com> wrote:

> Hi Swetark!
>
> Thanks for the proposal, I'm always happy to see people thinking about
> ways to improve DLC transferability, especially in the realm of reducing
> the interactivity necessary! Here are my thoughts on your proposal.
>
> The first thing I noticed is that you are using the old
> Pay to `(Person j + Oracle) || (Person i & OP_CLTV)`
> scheme which we've replaced with adaptor signatures to reduce complexity
> and remove asymmetry between transactions signed by the parties involved, I
> believe that this optimization also applies here and that the
> implementation complexity of this scheme would be reduced through the use
> of adaptor signatures.
>
> My other concrete thought is that as it is currently proposed, it is
> assumed that the party transferring into the DLC is always going to be
> providing inputs and paying a premium but this should not be assumed, since
> often times one would like to sell out of a DLC position after it has
> become less valuable and one is willing to pay someone else to take the
> position. In particular something more than simply making who adds an input
> a variable is needed as is mentioned in security concern #1, if the person
> currently in the DLC is paying to leave then they can extract a free option
> (as it currently stands) from the person they are allegedly paying to take
> their position. This likely requires that the handshake for transfers (in
> terms of signatures) always ends with the person who has a new input on the
> transformation transaction, which shouldn't be too hard to implement but is
> important.
>
> As for less concrete concerns, my current understanding is that the
> proposal is essentially a big pre-computation scheme where every party that
> might ever be involved in a DLC has to do a full setup of the DLC (in terms
> of how much computation is needed) with every other party that might be in
> the DLC, along with pre-signing every possible transfer between every
> possible other two parties (the third being themselves). Assuming my
> understanding is correct, then I think there are a few places where this
> scheme really is interesting, namely if a single person wishes to enter
> into a DLC, they don't care who with, and there exists some fixed group of
> counterparty market makers. In this case this scheme could be practical for
> sufficiently small contracts, or sufficiently patient users. But at the end
> of the day, I am not seeing how this scheme can be used practically for P2P
> novation, simply because the communication and computational complexity
> seem quite large, the parties must all be known in advance, and the DLC
> must remain static between transfers which likely leads to quite a bit of
> capital inefficiency relative to other proposals for DLC transfers [1]
> (although these require the static party to be online to authorize
> transfers). As such, I think that this proposal has many interesting
> applications for B2B interactions between DLC service entities, but that
> the costs outweigh the non-interactivity benefits for generic P2P DLC
> applications relative to the existing interactive transfer scheme (but who
> knows, P2P may only constitute a minority of DLCs in the future).
>
> One last higher level concern I have is that, as it is currently
> constructed, I worry that the primary benefit of using DLCs over federated
> escrows [2], privacy (especially from the oracle), is at risk of being lost
> in the presence of such transfers; and it should be noted that in escrow
> schemes transfers of the kind being achieved here are trivially
> accomplished using the escrows to enforce contract rules if the static
> party is offline. This privacy loss comes in two main forms (as far as I
> can tell), one is that the transformation transactions form a chain of
> easily recognizable transactions which can leak a lot of information since
> they come with an obviously distinguishable output representing a premium
> paid for the transfer, and if there are multiple transfers this along with
> the final payout (and its timestamp, and all timelocks) can leak a lot of
> information about the contract terms. Furthermore, aside from the public
> footprint, all parties which may participate in the future are privy to the
> entire contract details from the beginning which allows oracles and
> surveillance organizations to simply be a member of these large pools (or
> buy data from any single participant) in order to gain full access to the
> DLC terms. This seems like a pretty major drawback which might be able to
> at least be partially mitigated, at least enough to make the use of the
> proposal preferable to simply using escrows in place of DLCs.
>
> Please do let me know if I've misinterpreted your proposal in any part,
> and I'm excited to follow your future work!
>
> Best,
> Nadav
>
> On Mon, Feb 14, 2022 at 5:48 PM Shwetark Patel via dlc-dev <
> dlc-dev at mailmanlists.org> wrote:
>
>> # Intro to Transformable Discreet Log Contracts
>>
>> ## Introduction
>>
>> Discreet Log contracts are interesting, but one of the key issues is that
>> they lock the two participants into the contract and do not allow for
>> mutability, unless both participants are online, agree, and are willing to
>> allow another participant into the contract. One of our key goals is to
>> allow transferability of DLCs only requiring the person swapping in and the
>> person swapping out to be online.
>>
>> ## Goals and Assumptions
>> The assumption is very simple: There is a set of `N` participants whose
>> public keys are known.
>>
>>
>> The goal is essentially to simulate futures contract trading on Bitcoin;
>> at the beginning, the DLC will be between two predetermined participants
>> (WLOG say participants `0` and `1`). After that, the futures contract can
>> be constantly traded between participants by one person swapping out and
>> another swapping in, without interaction of the person staying in the
>> contract. It is even possible to create cycles where we come back to the
>> original two participants; for example, the following interaction is
>> possible:
>>
>> 1. Persons [0, 1] are the original two participants.
>>
>> 2. Person 0 swaps out and Person 2 swaps in (In exchange for some amount
>> of monetary transfer from Person 2 to Person 0), leading to Persons [1, 2]
>> being the new participants.
>>
>> 3. Person 1 swaps out and Person 0 swaps in (In exchange for some amount
>> of monetary transfer from Person 0 to Person 1), leading to Persons [0, 2]
>> being the new participants.
>>
>> 4. Person 2 swaps out and Person 1 swaps in (In exchange for some amount
>> of monetary transfer from Person 1 to Person 2), leading to Persons [0, 1]
>> being the new participants. Notice that they were also the original
>> participants in the contract.
>>
>> It is important to note that the contract does not have to end with the
>> original two participants having control of the contract; in fact, in the
>> above, if we just ended the process after step 3 where Persons [0, 2] have
>> control over the contract, they would still be able to settle and get their
>> money out.
>>
>> Another important detail is that the contract must have some type of
>> expiration date (like a futures contract does) so that the DLC can be
>> settled at some point.
>>
>>
>> ## Signing
>> We need to do some signing initially (just like regular DLCs require us
>> to sign CETs before we put the funding transaction on chain). We have to
>> sign two types of transactions here:
>>
>> ### Transformation Transactions
>>
>> For this part, we use `SIGHASH_ANYPREVOUT | ANYONECANPAY | SINGLE` to
>> sign off on the spending condition and amount of the 0th input and the
>> entire 0th output.
>>
>>
>> For every pairwise distinct, unordered triple of people `(i, j, k)`,
>> person `i` must sign the following transaction using `SIGHASH_ANYPREVOUT |
>> ANYONECANPAY | SINGLE`:
>>
>> ---------------------------------------------------------------
>>
>> Input 0 script pubKey (well it's the script pubKey of the previous output
>> to be more precise..): (Person `i & j` multi-sig)
>>
>> Input 0 amount: Same as funding TX amount
>>
>> ---------------------------------------------------------------
>>
>> Output 0 script pubKey: (Person `i & k` multi-sig)
>>
>> Output 0 amount: Same as funding TX amount
>>
>> ---------------------------------------------------------------
>>
>> The total number of transactions created here is `O(N^3)` (where `N` is
>> the number of people).
>>
>> ### CETs
>>
>> For every pairwise distinct, unordered pair of people `(i, j)` and every
>> oracle outcome, person `i` must sign the following transaction using
>> `SIGHASH_ANYPREVOUT`:
>>
>> ---------------------------------------------------------------
>>
>> Input 0 script pubKey: (Person `i & j` multi-sig)
>>
>> Input 0 amount: Same as funding TX amount
>>
>> ---------------------------------------------------------------
>>
>> Output 0: Pay to Person `i`'s PKH (amount based on oracle outcome)
>>
>> ---------------------------------------------------------------
>>
>> Output 1: Pay to `(Person j + Oracle) || (Person i & OP_CLTV)` (amount
>> based on oracle outcome)
>>
>> ---------------------------------------------------------------
>>
>> A minor detail here is that these CETs should have timelocks on them so
>> they are only valid after the expiration date (this prevents someone from
>> just putting a CET on chain if they are sure of the oracle outcome and
>> preventing future transformation transactions).
>>
>> The total number of transactions created here is `O(N^2 * O)` (where `N`
>> is the number of people and `O` is the number of outcomes).
>>
>> ## Put Funding TX on chain
>>
>> The next step is to create a single initial DLC funding transaction
>> between two arbitrary parties (WLOG let's say Persons `0` and `1`) and put
>> it on chain.
>>
>> ## Creating Transformation Transactions
>>
>> Let's say Persons `i` and `j` are currently in the contract (which
>> implies a multisig between two exists at the moment). Let's say that person
>> `j` wants to swap out and person `k` wants to swap in; in this case, both
>> person `j` and `k` need to be online and interact, but person `i` does not
>> need to be there. Person `j` and `k` will construct the following
>> transaction:
>>
>> ---------------------------------------------------------------
>>
>> Input 0 script pubKey: (Person `i & j` multi-sig)
>>
>> Input 0 amount: Same as funding TX amount
>>
>> ---------------------------------------------------------------
>>
>> Input 1: Any UTXO spendable by Person `k`
>>
>> ---------------------------------------------------------------
>>
>> Output 0 script pubKey: (Person `i & k` multi-sig)
>>
>> Output 0 amount: Same as funding TX amount
>>
>> ---------------------------------------------------------------
>>
>> Output 1: Some agreed upon amount is sent to Person `j`'s PKH.
>>
>> ---------------------------------------------------------------
>>
>>
>> Person `k` will then insert in Person `i`'s relevant Transformation
>> Transaction signature (during the signing phase, Person `i` already created
>> and published this signature) and sign themselves. They will then send the
>> signed transaction to Person `j`, who can then sign and send the
>> transaction into the mempool.
>>
>> Any number of these transformation transactions can be put on chain, one
>> after another. As a result, ownership of the contract can constantly change.
>>
>> ## Final CET
>>
>> Once the final expiration time is reached, the oracle publishes the
>> outcome and a CET can be put on chain by either party. WLOG assume that
>> persons `i` and `j` are currently in the contract. Let's say that person
>> `j` wants to be the one to publish the final settlement transaction. Person
>> `j` will create and sign the following transaction:
>>
>> ---------------------------------------------------------------
>>
>> Input 0 script pubKey: (Person `i & j` multi-sig)
>>
>> Input 0 amount: Same as funding TX amount
>>
>> ---------------------------------------------------------------
>>
>> Output 0: Pay to Person `i`'s PKH (amount based on oracle outcome)
>>
>> Output 1: Pay to `(Person j + Oracle) || (Person i & OP_CLTV)` (amount
>> based on oracle outcome)
>>
>> ---------------------------------------------------------------
>>
>> They will use Person `i`'s signature which already exists from the
>> signing phase to complete the transaction. They will then send this to the
>> mempool.
>>
>> ## Security Considerations
>>
>>
>> There exist at least two interesting security considerations:
>>
>> 1. Say Person `i` and `j` are currently in the contract, and `k` wants to
>> swap in for `j`. Person `k` signs a transformation transaction and sends it
>> to `j`. Person `j` can now wait a while before they send the transaction
>> into the mempool (to see if it is advantageous to do so). Person `k` has
>> the option to respond to this by spending the UTXO they are using as an
>> input,  but it could become some type of priority gas auction if they try
>> to do this simultaneously.
>>
>> 2. Say the expiration time has passed, and someone wants to be a sore
>> loser. They can keep sending transformation transactions to prevent a CET
>> from being put on chain. The deterrent here is that they literally have to
>> do this every single block and they lose the transaction fee, which adds up
>> to pretty significant sums of money. This only delays the inevitable,
>> however, because at some point the CET will be put on chain and everything
>> will be settled.
>>
>> Would be interested if anyone has thoughts on this.
>>
>> 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/20220224/89ea10be/attachment-0001.htm>


More information about the dlc-dev mailing list