path: root/60/cfab0d20667d7c49bdcf46d94b1e53b0812057

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5B277C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Jan 2023 22:43:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 3026E41149
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Jan 2023 22:43:04 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3026E41149
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=Nl/6ck8d
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HV2cc1_a5Bu0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Jan 2023 22:43:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9BFB241145
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [IPv6:2a00:1450:4864:20::633])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 9BFB241145
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Jan 2023 22:43:02 +0000 (UTC)
Received: by mail-ej1-x633.google.com with SMTP id rl14so6289695ejb.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Jan 2023 14:43:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=UfjCdOws2s10HgNU0Bfz+49ypnRWvBN7529ESrGB6oU=;
 b=Nl/6ck8dkHWGnyGwsm3A9JFpivkZ9XJ0Qejv9UIm9RcEzO7hOZ/zTYG5gOsYAY4/lj
 MMtYaYiD/R7X46EAU7xGl1NpUktfDeYx9GR2BMjCxfLs532boIhgyPV+r2Egtt4IsR3Z
 rheAPNpFoE4Zp9y77LsKhaSVfdMm4lYrgeyQschJIgepy7X6C212NpqmpYC2mIVB5xHz
 d2zvUjyaoBYLFNVFy1aZn6xidnd/Ae9OGhUhhsHGiRI6jU27Q4sabwFaU2iHVoLDWwMk
 IWFJqcSRRJ/BYne4gBQoS4IloBKpZ86ELlzoo0NFG9kMhmJ+28RKxiDIWz6TfNECiNtF
 j0aA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc: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=UfjCdOws2s10HgNU0Bfz+49ypnRWvBN7529ESrGB6oU=;
 b=g2RJip9QF84ZpMgWR6w33lgWCGSFbOixyKWBzaNwYrPvFVziursMT8Htoa4Fpup8OG
 L546a1qZSPYMqUqvJ+rTFupDX37NHu++Tbjli6caSDV+8kXDHn2Qq4PjSKIBHHeLEzU+
 4na/AaN7/WyQOYtB+aofUf82d68CEkzD2IdqObkSB2t4zE26BVat6fZ7uNskXOEjtfRR
 bNOMx0UdhkRLgkcHMScoegGTY56GnvunzoUyMeMzhkEz9Z3Sftflr/XAOs/d23G2ocpm
 5DZkHyXZUAvcKoifvz2n9tRHTyyXFDFgyMJbRTT9yuVUyyWAVqiVBnoyYR0V+eoMxrjM
 V9bg==
X-Gm-Message-State: AFqh2krbZEZM3jqOU8l0wI9JfKKkkLgK8kbbI7sx36iW+oxIrBvm3HhF
 JwCTdE1Wf8YWS9OKs+HlqhCNGFlj3DDrIHBfZFazm1D+4iU=
X-Google-Smtp-Source: AMrXdXtf5Um5yBagfHemMmU3/vez5Mhd8nhsCtf0/Xxr/sU9uxY60tsYrr8TVMjaHgnZcI+bsrH91W/jBE0xgBjJisk=
X-Received: by 2002:a17:906:4a50:b0:7c1:6b1f:e131 with SMTP id
 a16-20020a1709064a5000b007c16b1fe131mr923045ejv.557.1674168180057; Thu, 19
 Jan 2023 14:43:00 -0800 (PST)
MIME-Version: 1.0
References: <SJ1P223MB0531F7DDDFEB49DCF8E92CE9A1FD9@SJ1P223MB0531.NAMP223.PROD.OUTLOOK.COM>
In-Reply-To: <SJ1P223MB0531F7DDDFEB49DCF8E92CE9A1FD9@SJ1P223MB0531.NAMP223.PROD.OUTLOOK.COM>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 19 Jan 2023 16:42:43 -0600
Message-ID: <CAGpPWDZNHLpdmN=T_J8pJ2v1+RpekMeOQLY-wLjf5rRHTiXbNA@mail.gmail.com>
To: Ben Carman <benthecarman@live.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000aaac7005f2a5a78d"
X-Mailman-Approved-At: Thu, 19 Jan 2023 23:22:08 +0000
Cc: "dlc-dev@mailmanlists.org" <dlc-dev@mailmanlists.org>
Subject: Re: [bitcoin-dev] Using OP_VAULT to improve DLCs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2023 22:43:04 -0000

--000000000000aaac7005f2a5a78d
Content-Type: text/plain; charset="UTF-8"

That's an interesting mechanism. Since the goal of OP_VAULT was to avoid
being another general covenant proposal, that avenue could be blocked by
requiring that for a transaction spending a utxo with a script using
OP_UNVAULT, the script (or taproot tree) must *only* contain that one
opcode call (perhaps with an escape hatch that OP_UNVAULT turns into a NOOP
if that constraint isn't satisfied). If no other conditions can be placed
on the utxo, then the only relevant condition is the delay (and the
prescribed output targets).

Even with this restriction, it could be used for Jeremy Rubin's congestion
control transactions, which just commits to a list of future outputs, to be
sent when the fee environment is cheaper.

However, James mentioned adding <recovery-params> that includes a
scriptPubKey for authorizing recovery. With that addition, OP_UNVAULT can
be used to do more general covenants by making `unvault-target-hash`
unsatisfiable (set to some random number that isn't derived from a hash)
the delay wouldn't matter, but arbitrary conditions can be set on spending
the utxo to the "recovery address" which could be another OP_UNVAULT. It
seems like that could be used as a general CTV-like covenant.

On Fri, Jan 13, 2023 at 2:04 PM Ben Carman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi list,
>
> After reading through James's OP_VAULT proposal this week, I had a realization that this can be used for more than a deep cold storage wallet.
>
> Instead of vaulting and unvaulting, we can just send to a OP_UNVAULT output.
> When using OP_UNVAULT if we set the `recovery-spk-hash` to a burn address (ie OP_RETURN `<random value>`)
> and the `delay-period` to `0` we can use it as a not-so simple covenant with the `unvault-target-hash` being
> set to whatever output restrictions you want to create.
>
> Given this we can recreate a lot of what CTV promises, one of my favorites being
> [Lloyd's improvement to DLCs](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html)
> (I recommend reading that first)
>
> A similiar construction could be done by creating a taproot tree similiar to LLoyd's construction with each leaf looking like:
>
> `<hash-of-burn-spk> 0 <CET-hash_i> OP_UNVAULT <CET_i> CHECKSIG`
>
> In the same as Lloyd's proposal: when the oracle(s) reveals their attestations either party can combine them to get the secret key corresponding to `CET_i` and spend the coins to the CET (whose `unvault-target-hash`
> hash is `CET-hash`) which distributes the funds according to the contract.
>
> ## Comparison
>
> Compared to the original CTV proposal, this *should *get all the same computational savings. However, it would use more blockchain space.
>
> The main downside I see is our final spending script will be slightly larger.
> Instead of just having `<hash> OP_CTV` it will be replaced with `<hash> 0 <hash> OP_UNVAULT` (34 bytes extra, not including the witness discount).
> However, this may be negligible in the case of a DLC with many outcomes as a lot of the input size will be coming from the control block.
> This also can always be skipped by doing a cooperative close of the DLC if the internal-key of the taproot tree can be spent using something like MuSig.
>
> I imagine a lot of the other applications for CTV can be recreated with OP_VAULT using this same trick.
>
> # Credits
>
> - Lloyd Fournier for the original proposal
> - James O'Beirne for the OP_VAULT proposal and giving me the idea to skip the intial OP_VAULT and just use OP_UNVAULT
>
>
>
> Best,
>
> benthecarman
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000aaac7005f2a5a78d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That&#39;s an interesting mechanism. Since the goal of OP_=
VAULT was to avoid being another general covenant proposal, that avenue cou=
ld be blocked by requiring that for a transaction spending a utxo with a sc=
ript using OP_UNVAULT, the script (or taproot tree) must *only* contain tha=
t one opcode call (perhaps with an escape hatch that OP_UNVAULT turns into =
a NOOP if that constraint isn&#39;t satisfied). If no other conditions can =
be placed on the utxo, then the only relevant condition is the delay (and t=
he prescribed output targets).=C2=A0<div><br></div><div>Even with this rest=
riction, it could be used for Jeremy Rubin&#39;s congestion control transac=
tions, which just commits to a list of future outputs, to be sent when the =
fee environment is cheaper.=C2=A0<div><br></div><div>However, James mention=
ed adding &lt;recovery-params&gt; that includes a scriptPubKey for authoriz=
ing recovery. With that addition,=C2=A0OP_UNVAULT can be used to do more ge=
neral covenants by making=C2=A0<span style=3D"color:rgb(0,0,0);white-space:=
pre-wrap">`unvault-target-hash` unsatisfiable (set to some random number th=
at isn&#39;t derived from a hash) the delay wouldn&#39;t matter, but arbitr=
ary conditions can be set on spending the utxo to the &quot;recovery addres=
s&quot; which could be another OP_UNVAULT. It seems like that could be used=
 as a general CTV-like covenant. </span></div></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jan 13, 2023 at=
 2:04 PM Ben Carman via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o=
rg</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">



<div dir=3D"auto">
<div dir=3D"ltr">
<pre style=3D"color:rgb(0,0,0)">Hi list,

After reading through James&#39;s OP_VAULT proposal this week, I had a real=
ization that this can be used for more than a deep cold storage wallet.

Instead of vaulting and unvaulting, we can just send to a OP_UNVAULT output=
.
When using OP_UNVAULT if we set the `recovery-spk-hash` to a burn address (=
ie OP_RETURN `&lt;random value&gt;`)
and the `delay-period` to `0` we can use it as a not-so simple covenant wit=
h the `unvault-target-hash` being
set to whatever output restrictions you want to create.

Given this we can recreate a lot of what CTV promises, one of my favorites =
being
[Lloyd&#39;s improvement to DLCs](<a href=3D"https://lists.linuxfoundation.=
org/pipermail/bitcoin-dev/2022-January/019808.html" target=3D"_blank">https=
://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html=
</a>)
(I recommend reading that first)

A similiar construction could be done by creating a taproot tree similiar t=
o LLoyd&#39;s construction with each leaf looking like:

`&lt;hash-of-burn-spk&gt; 0 &lt;CET-hash_i&gt; OP_UNVAULT &lt;CET_i&gt; CHE=
CKSIG`

In the same as Lloyd&#39;s proposal: when the oracle(s) reveals their attes=
tations either party can combine them to get the secret key corresponding t=
o `CET_i` and spend the coins to the CET (whose `unvault-target-hash`
hash is `CET-hash`) which distributes the funds according to the contract.

## Comparison

Compared to the original CTV proposal, this <i>should </i>get all the same =
computational savings. However, it would use more blockchain space.=20

The main downside I see is our final spending script will be slightly large=
r.
Instead of just having `&lt;hash&gt; OP_CTV` it will be replaced with `&lt;=
hash&gt; 0 &lt;hash&gt; OP_UNVAULT` (34 bytes extra, not including the witn=
ess discount).
However, this may be negligible in the case of a DLC with many outcomes as =
a lot of the input size will be coming from the control block.
This also can always be skipped by doing a cooperative close of the DLC if =
the internal-key of the taproot tree can be spent using something like MuSi=
g.

I imagine a lot of the other applications for CTV can be recreated with OP_=
VAULT using this same trick.

# Credits

- Lloyd Fournier for the original proposal
- James O&#39;Beirne for the OP_VAULT proposal and giving me the idea to sk=
ip the intial OP_VAULT and just use OP_UNVAULT</pre>
<pre style=3D"color:rgb(0,0,0)"><br></pre>
<pre style=3D"color:rgb(0,0,0)"><br></pre>
<pre style=3D"color:rgb(0,0,0)">Best,</pre>
<pre style=3D"color:rgb(0,0,0)">benthecarman</pre>
<div dir=3D"ltr"></div>
</div>
</div>

_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000aaac7005f2a5a78d--