Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C8273C002D for ; Tue, 10 Jan 2023 14:18:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id A384D6101A for ; Tue, 10 Jan 2023 14:18:01 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A384D6101A Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=fBY0HjvH X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0f5SBqYJE8A for ; Tue, 10 Jan 2023 14:18:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8B3D561011 Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) by smtp3.osuosl.org (Postfix) with ESMTPS id 8B3D561011 for ; Tue, 10 Jan 2023 14:18:00 +0000 (UTC) Received: by mail-ot1-x333.google.com with SMTP id k44-20020a9d19af000000b00683e176ab01so7022902otk.13 for ; Tue, 10 Jan 2023 06:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=an42uXi+na1cMU7Hrr5IbDeOB3rQyHTL0GUJ1eDzHCg=; b=fBY0HjvHUqI1IH9z+Qnq/8/N+c81YgQucg8vneShlRqrgE2iZsPBC/UDjpjUK2AySm kT8xJp4R16iTFhu+4bz18cFAT/C3St7y0SGkYNb390dsPbFvrRRe3Bt0sLPOc8TJHNU3 5CS7CxtAZY5Zzjct1t6v8gOI+3PlkHDmJpqdfyyDvKMdZpCzaMlsoftGGqnSSqIJGe4R 9rHt4ykZaoEXhMGnAT3K/hScehUKPFUJJz6j1sKSBEI9n6Szu5psi6vg4idemkJNLFUe 4JtH56LKBuuNGZa9Cws50591oKOQB70AhAmMlsWXtPXTI7wq8Q5o2E9NHkwVQ27zc/3y zNmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=an42uXi+na1cMU7Hrr5IbDeOB3rQyHTL0GUJ1eDzHCg=; b=b7LrRvYcKGnO9vNcXKwWm1JV6s5CUgtzPV1+kb+EG8GjBOgYRCtpOtdf8C8wK7R4t5 0L3O9RYLpgWSF+Kh0VVgHCcD335UlsMKzpHrTEdmPRwyOH195Etr8Q1ZEu54loIFhqaC 1Vo5zaoLfP1y3KmjIDKNzobqmBs92fNvoQ3ODoMx5ozwFcFFah+5wjE5A0VRsGFiXzBK XERhveXf+bSLTBDxI7lfeAXAVKGAhHHJucyrx4E2KdjWpW8J9+YRpy7ceV4HawsO3P7w YChT7lgtgA5RoH4FDix0WUTCcN17eqd/oy5ljmJGpCPhDm/rLjnJD/r8P6xgthS7bOk5 PC/w== X-Gm-Message-State: AFqh2kqTUPWcqcM/OYwoyYqUhE+NI3BxxgOvcT6vEawMVJCBg1t683kC suE9Cp345LY7zkHAVM0CRjR/4AmJ8JmMiDfQvr6Ztb3troQ= X-Google-Smtp-Source: AMrXdXuK0hDy/nD1y3gjuIbM4La2Z6pGzoYE4pA9tS/iFBYhOTyBoDEUqbkYJnel4+iF//8Qd+5DhKysyE+/TOWWE8Y= X-Received: by 2002:a9d:6a48:0:b0:678:23c0:5f3e with SMTP id h8-20020a9d6a48000000b0067823c05f3emr4346289otn.347.1673360279159; Tue, 10 Jan 2023 06:17:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "James O'Beirne" Date: Tue, 10 Jan 2023 09:17:49 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000000562d705f1e98d5e" Subject: Re: [bitcoin-dev] OP_VAULT: a new vault proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2023 14:18:01 -0000 --0000000000000562d705f1e98d5e Content-Type: text/plain; charset="UTF-8" Forwarding in some conceptual feedback from the pull request. From ariard: > I've few open questions, like if the recovery path should be committed with a signature rather than protected by a simple scriptpubkey preimage. That's something I've wondered about too. I have to ruminate on AJ's good post about this, but a pretty straightforward way of enabling this (at the expense of some complexity) is to do something like "if is 32 bytes, treat it as it's currently used. If it's 33 bytes, use the first byte as a parameter for how to interpret it." To start with, an extra prefix byte of 0x00 could mean "require a witness satisfying the scriptPubKey that hashes to the remaining 32 bytes" in the same way we do the unvault signing. This would enable a "sign-to-recover" flow at the option of the user, specified during vault creation. > The current OP_VAULT implementation is using OP_NOP repurposing but this doesn't seem compatible with Taproot-only extensions (e.g ANYPREVOUT) and maybe a OP_SUCCESS could be used. Yes, with Greg's suggestion of putting on the witness stack during OP_VAULT (-> OP_UNVAULT) spend, we could conceivably move OP_VAULT/OP_UNVAULT into Taproot-only OP_SUCCESSx opcodes. I haven't thought hard about how worthwhile it is to preserve the ability to use OP_VAULT in pre-Taproot contexts. > There is a conceptual wonder, if a CTV and template malleability approach wouldn't better suit the vault use-case and allow other ones, as such better re-usability of primitives. I dedicated a whole section of the paper ("Precomputed vaults with covenants") to explaining why precomputed covenant mechanisms have big shortcomings for vaults. That said, a number of people have commented about OP_VAULT's ability to (inefficiently) emulate CTV. I'm still very supportive of CTV, I just don't really have any uses I personally understand inside and out aside from vaults... so if others do, they should really post about it on this list and we should resume working on an activation for CTV! --- From naumenkogs: > I'm personally not sure batching withdrawals is that compelling... It's a nice-to-have, but I'd think about the benefits dropping this feature would provide. Having familiarity with a few large-scale custodial operations, I think batching is a really big deal. And if you're going to support multiple deposits to the same vault, no support for batching is going to result in a lot of unnecessary output creation even as a small user if you're, e.g., doing weekly automated deposits from an exchange to a vault you've configured. Darosior comments: > On the contrary i think the batching feature is very compelling. The impossibility to batch Unvaults in Revault is a major drawback: it significantly increases the cost of any realistic operation (you need one whole additional transaction per input, and each have likely more than one output). It also potentially increases the cost on the network (you'd likely want some sort of anchor output on each Unvault tx, that you might not spend, so that's 2*n outputs created with n the number of coins spent): we definitely don't want to prevent batching. The ability to batch the recovery transactions (what we called Emergency tx in Revault) is also very compelling but i think your comment was only about batched withdrawals. --0000000000000562d705f1e98d5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forwarding in some conceptual feedback from the pull reque= st.

From ariard:

> I've fe= w open questions, like if the recovery path should be committed with a sign= ature rather than protected by a simple scriptpubkey preimage.
=

That's something I've wondered about too. I = have to ruminate on AJ's good post about this, but a pretty straightfor= ward way of enabling this (at the expense of some complexity) is to do some= thing like "if <recovery-path-hash> is 32 bytes, treat it as it&= #39;s currently used. If it's 33 bytes, use the first byte as a paramet= er for how to interpret it." To start with, an extra prefix byte of 0x= 00 could mean "require a witness satisfying the scriptPubKey that hash= es to the remaining 32 bytes" in the same way we do the unvault signin= g. This would enable a "sign-to-recover" flow at the option of th= e user, specified during vault creation.

>=C2=A0The current=C2=A0OP_VAULT=C2=A0implementation is using OP= _NOP repurposing but this doesn't seem compatible with Taproot-only ext= ensions (e.g=C2=A0ANYPREVOUT) and maybe a=C2=A0OP_SUCCESS=C2=A0could b= e used.=C2=A0

Yes, with Greg's sugge= stion of putting <target-hash> on the witness stack during OP_VAULT (= -> OP_UNVAULT) spend, we could conceivably move OP_VAULT/OP_UNVAULT into= Taproot-only OP_SUCCESSx opcodes. I haven't thought hard about how wor= thwhile it is to preserve the ability to use OP_VAULT in pre-Taproot contex= ts.

>=C2=A0There is a conceptual= wonder, if a=C2=A0CTV=C2=A0and template malleability approach wouldn'= ;t better suit the vault use-case and allow other ones, as such better re-u= sability of primitives.

I dedicated a wh= ole section of the paper=C2=A0("Precomputed vaults with cove= nants")=C2=A0to explaining why precomputed covenant mechanisms ha= ve big shortcomings for vaults.=C2=A0

= Th= at said, a number of people have commented about OP_VAULT's ability to = (inefficiently) emulate CTV. I'm still very supportive of CTV, I just d= on't really have any uses I personally understand inside and out aside = from vaults... so if others do, they should really post about it on this li= st and we should resume working on an activation for CTV!
=
---

From naumenkogs:

>=C2=A0I'm personally not sur= e batching withdrawals is that compelling... It's a nice-to-have, but I= 'd think about the benefits dropping this feature would provide.=

Having familiarity with a few large-scale cust= odial operations, I think batching is a really big deal. And if you're = going to support multiple deposits to the same vault, no support for batchi= ng is going to result in a lot of unnecessary output creation even as a sma= ll user if you're, e.g., doing weekly automated deposits from an exchan= ge to a vault you've configured.

<= font color=3D"#24292f" face=3D"-apple-system, BlinkMacSystemFont, Segoe UI,= Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji= ">Darosior comments:

>=C2=A0On the contrary i think the ba= tching feature is very compelling. The impossibility to batch Unvaults in R= evault is a major drawback: it significantly increases the cost of any real= istic operation (you need one whole additional transaction per input, and e= ach have likely more than one output). It also potentially increases the co= st on the network (you'd likely want some sort of anchor output on each= Unvault tx, that you might not spend, so that's=C2=A02*n=C2=A0output= s created with=C2=A0n=C2=A0the number of coins spent): we definitely don&= #39;t want to prevent batching. The ability to batch the recovery transacti= ons (what we called Emergency tx in Revault) is also very compelling but i = think your comment was only about batched withdrawals.
--0000000000000562d705f1e98d5e--