path: root/9e/a307e44733056bd89a9390723594389dd97a7d

Return-Path: <james.obeirne@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 200CAC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Jan 2023 20:31:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id DAB3C81E4E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Jan 2023 20:31:20 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DAB3C81E4E
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=QU7zpTxA
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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id m6QWKJ3zvMt4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Jan 2023 20:31:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6794481E46
Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com
 [IPv6:2001:4860:4864:20::30])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 6794481E46
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Jan 2023 20:31:19 +0000 (UTC)
Received: by mail-oa1-x30.google.com with SMTP id
 586e51a60fabf-1441d7d40c6so9984109fac.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 09 Jan 2023 12:31:19 -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=q7PAT/O5XR+W8KvG2LKTcw/HrloqGn2cgjpByKX5zm8=;
 b=QU7zpTxA1nmHQLlzyp86OTZ9K3LNVNx1Yw7Fd50ak7xcjIuDnPWa/87aigprsuzz3U
 mOlzbCvW8BvwdXw5wnUY5e1kswPtR1yuID2zt6/rK/fU6cxUKD5O1BuLgQEr+dBSNmVe
 Vf6LORherPojMbYHqowzpm8JOKOpfxLtUBFXR7kbbTfgqw4Gj6C9rnWyDmKJRfsq3k7s
 e5iMk/McQooipxr7wYZUcuVQyFAky9+RTz8nhm8RAKPpVn7vNUGH6VZXEWE4I8Zqew8r
 VdBkHFUFfRuKos18rV1vRbJTQBE5SgE2Mhwpd/fLJE5S8W8mAKi0K/pLulGvEUmYCKHS
 SG0Q==
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=q7PAT/O5XR+W8KvG2LKTcw/HrloqGn2cgjpByKX5zm8=;
 b=Ye8nhwE20K57uQG5/Glti9qMYGXCCx1NHH2VS87n4Xr3vj7cJeg+LBM9pZTw40JMyW
 y99iD4DV2ZgUP4/pg7RElVAMDQNc6zKq7YSt3vxlXC9panESNCdcbwj5mGeJAjfpJHOi
 GIZL6uJI2xmSEuNtZWWgHghbjsDBab0jFemYpOW+OdQshGL2XE92Q/ZaJclPMaA6n6L/
 GBy4xkF7cLBtRHNFihWe1MdkMO6N2jUT+Ddou2b3CnjdlXlHmIgM7kvszFqhKZaMPL+j
 fmTmNwOEQjebgjfA4CoLBgFju15pm1/MWJbS0ldYqYV1b+ptX6bTSE1pIqTOMz1YQxG+
 Q/ew==
X-Gm-Message-State: AFqh2kpk0kpZ+R8ctx6GxD1yoLA3PqpCoH3uIGNwPgVKBHKATNEGG2VU
 sXxj6mo8epVjLMO8Mlu9P5HUakccW1DDG8P1x1M=
X-Google-Smtp-Source: AMrXdXs8jFDO179Zgkuqol6EqqTEquWrfoN1vPi/mXz4CXPj3EAENpBXESqLHz0roQQ/S4vLA3DAZ9mjXGNIOb9u60M=
X-Received: by 2002:a05:6870:4b8d:b0:14f:d35e:b7fa with SMTP id
 lx13-20020a0568704b8d00b0014fd35eb7famr4315259oab.222.1673296278205; Mon, 09
 Jan 2023 12:31:18 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfL65cneOabmxfOzTZq14xN4vXNaGboq_g15-frM14RqGA@mail.gmail.com>
 <8Uq3KNRWS_WV393lP9wq820PE8KNK0bhQ7u7hMJhIfdfV3-ZhSI-4q9Mw5P_TXivKtyePE2Exha4rso2yi3iNnLJpUpBQ38lAuwG-lQPVUE=@protonmail.com>
 <CAB3F3DsyN_Nj0Fs4LseiwxUE96tFt079qbb0hKBnTBZdyaPcSQ@mail.gmail.com>
In-Reply-To: <CAB3F3DsyN_Nj0Fs4LseiwxUE96tFt079qbb0hKBnTBZdyaPcSQ@mail.gmail.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Mon, 9 Jan 2023 15:32:34 -0500
Message-ID: <CAPfvXfK=ykkFWEpRruudLBMt-DaUprFcF=XCJvQ65AFEbo0zpg@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000443a8005f1daa63c"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: Mon, 09 Jan 2023 20:31:21 -0000

--000000000000443a8005f1daa63c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Greg,

I think what you're trying to get at here is that the OP_UNVAULT
scriptPubKey *must* be a bare script so that the OP_VAULT spend logic can
verify that we're spending an OP_VAULT output into a compatible OP_UNVAULT
output, and that's true. The OP_UNVAULT scriptPubKey also must contain the
target hash because that has is used when validating that spend to ensure
that the final unvault target matches what was advertised when the
OP_UNVAULT output was created.

So I'm not sure what problem you're trying to solve by putting the target
hash  on the OP_VAULT spend witness stack. If it were placed there, it
wouldn't be accessible during OP_UNVAULT spend AFAICT. I agree it would be
nice to figure out a way to allow the OP_UNVAULT scriptPubKey to not be
bare, which may require moving the target hash out of it, but we'd have to
figure out a mechanism to properly forward the target hash for validation.

Best,
James

On Mon, Jan 9, 2023 at 2:32 PM Greg Sanders <gsanders87@gmail.com> wrote:

> Hi James and co,
>
> Currently there is no way to make this compatible with scripthashes of an=
y
> kind, since the script interpreter has no insight into the OP_UNVAULT
> outputs' "execution script", and one of the arguments of OP_UNVAULT is
> freeform, resulting in an unpredictable output scriptpubkey.
>
> I think the fix is just requiring a single additional witness data item
> during OP_VAULT spend(for unvault path), mandating the
> <target-outputs-hash> to be included in the witness stack as an input to
> OP_VAULT opcode, and transaction introspection then checks to make sure t=
he
> witness item and the corresponding output script template matches the
> expected.
>
> This would only be necessary for the unvaulting path, and not for the
> recovery path.
>
> Cheers,
> Greg
>
> On Mon, Jan 9, 2023 at 2:10 PM rot13maxi via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hey James,
>>
>> Really cool proposal. I=E2=80=99ve been thinking a lot lately about scri=
pt paths
>> for inheritance. In a lot of the =E2=80=9Chave a relative time lock that=
 allows a
>> different key to spend coins, or allows a smaller threshold of a multisi=
g
>> to spend=E2=80=9D schemes, you have the problem of needing to =E2=80=9Cr=
efresh=E2=80=9D all of your
>> coins when the timelock is close to maturation. In a lot of the =E2=80=
=9Cuse
>> multisig with ephemeral keys to emulate covenants=E2=80=9D schemes, you =
have to
>> pre-commit to the terminal destination well in advance of the spend-path
>> being used, which leads to all kinds of thorny questions about security =
and
>> availability of *those* keys. In other words, you either have to have
>> unbound destinations but a timer that needs resetting, or you have unbou=
nd
>> time but fixed destinations. This design gets you the best of both becau=
se
>> the destination SPKs aren=E2=80=99t committed to until the unvaulting pr=
ocess
>> starts. This (or something like this with destination binding at
>> unvault-time) would be an incredibly useful tool for inheritance designs=
 in
>> wallets.
>>
>> I need to think a bit more about the recovery path not having any real
>> encumbrances on it. Maybe in practice if you=E2=80=99re worried about Do=
S, you have
>> UTXOs that commit to multiple vault paths that have tweaked recovery
>> destinations or something, or maybe it really is the right move to say t=
hat
>> if recovery is triggered, you probably do want it for all of your inflig=
ht
>> unvaultings.
>>
>> Looking forward to reading this a few more times and talking more about
>> it.
>>
>> Thanks!
>> rijndael
>>
>>
>> On Mon, Jan 9, 2023 at 11:07 AM, James O'Beirne via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> For the last few years, I've been interested in vaults as a way to
>> substantially derisk custodying Bitcoin, both at personal and commercial
>> scales. Instead of abating with familiarity, as enthusiasm sometimes
>> does, my conviction that vaults are an almost necessary part of bitcoin'=
s
>> viability has only grown over the years.
>>
>> Since people first started discussing vaults, it's been pretty clear tha=
t
>> some kind of covenant-enabling consensus functionality is necessary to
>> provide the feature set necessary to make vault use practical.
>>
>> Earlier last year I experimented with using OP_CTV[1], a limited covenan=
t
>> mechanism, to implement a "minimum-viable" vault design. I found that th=
e
>> inherent limitations of a precomputed covenant scheme left the resulting
>> vault implementation wanting, even though it was an improvement over
>> existing strategies that rely on presigned transactions and (hopefully)
>> ephemeral keys.
>>
>> But I also found proposed "general" covenant schemes to be
>> unsuitable for this use. The bloated scriptPubKeys, both in size and
>> complexity, that would result when implementing something like a vault
>> weren't encouraging. Also importantly, the social-consensus quagmire
>> regarding which covenant proposal to actually deploy feels at times
>> intractable.
>>
>> As a result, I wanted to explore a middle way: a design solely concerned
>> with making the best vault use possible, with covenant functionality as =
a
>> secondary consideration. In other words, a proposal that would deliver
>> the safety benefits of vaults to users without getting hung up on
>> trying to solve the general problem of covenants.
>>
>> At first this design, OP_VAULT, was just sort of a pipe dream. But as I
>> did more thinking (and eventually implementing) I became more convinced
>> that, even if it isn't considered for soft-fork, it is a worthwhile
>> device to serve as a standard benchmark against which other proposals
>> might be judged.
>>
>> I wrote a paper that summarizes my findings and the resulting proposal:
>> https://jameso.be/vaults.pdf
>>
>> along with an accompanying draft implementation:
>> https://github.com/bitcoin/bitcoin/pull/26857
>>
>> I might work on a BIP if there's interest.
>>
>> James
>>
>> [1]: https://github.com/jamesob/simple-ctv-vault
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<div dir=3D"ltr"><div>Hey Greg,</div><div><br></div><div>I think what you&#=
39;re trying to get at here is that the OP_UNVAULT scriptPubKey *must* be a=
 bare script so that the OP_VAULT spend logic can verify that we&#39;re spe=
nding an OP_VAULT output into a compatible OP_UNVAULT output, and that&#39;=
s true. The OP_UNVAULT scriptPubKey also must contain the target hash becau=
se that has is used when validating that spend to ensure that the final unv=
ault target matches what was advertised when the OP_UNVAULT output was crea=
ted.</div><div><br></div><div>So I&#39;m not sure what problem you&#39;re t=
rying to solve by putting the target hash=C2=A0 on the OP_VAULT spend witne=
ss stack. If it were placed there, it wouldn&#39;t be accessible during OP_=
UNVAULT spend AFAICT. I agree it would be nice to figure out a way to allow=
 the OP_UNVAULT scriptPubKey to not be bare, which may require moving the t=
arget hash out of it, but we&#39;d have to figure out a mechanism to proper=
ly forward the target hash for validation.</div><div><br></div><div>Best,</=
div><div>James<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Mon, Jan 9, 2023 at 2:32 PM Greg Sanders &lt;<a =
href=3D"mailto:gsanders87@gmail.com">gsanders87@gmail.com</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">H=
i James and co,<div><br></div><div>Currently there is no way to make this c=
ompatible=C2=A0with scripthashes=C2=A0of any kind, since the script interpr=
eter has no insight into the OP_UNVAULT outputs&#39; &quot;execution script=
&quot;, and one of the arguments of OP_UNVAULT is freeform, resulting in an=
 unpredictable output scriptpubkey.<br></div><div><br></div><div>I think th=
e fix is just requiring a single additional witness data item during OP_VAU=
LT spend(for unvault path), mandating the &lt;target-outputs-hash&gt; to be=
 included in the witness stack as an input to OP_VAULT opcode, and transact=
ion introspection then checks to make sure the witness item and the corresp=
onding output script template matches the expected.</div><div><br></div><di=
v>This would only be necessary for the unvaulting path, and not for the rec=
overy path.</div><div><br></div><div>Cheers,</div><div>Greg</div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Ja=
n 9, 2023 at 2:10 PM rot13maxi via bitcoin-dev &lt;<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxf=
oundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div>Hey James,<div><br></div><div>Really cool proposal. I=E2=
=80=99ve been thinking a lot lately=C2=A0about script paths for inheritance=
. In a lot of the =E2=80=9Chave a relative time lock that allows a differen=
t key to spend coins, or allows a smaller threshold of a multisig to spend=
=E2=80=9D schemes, you have the problem of needing to =E2=80=9Crefresh=E2=
=80=9D all of your coins when the timelock is close to maturation. In a lot=
 of the =E2=80=9Cuse multisig with ephemeral keys to emulate covenants=E2=
=80=9D schemes, you have to pre-commit to the terminal destination well in =
advance of the spend-path being used, which leads to all kinds of thorny qu=
estions about security and availability of *those* keys. In other words, yo=
u either have to have unbound destinations but a timer that needs resetting=
, or you have unbound time but fixed destinations. This design gets you the=
 best of both because the destination SPKs aren=E2=80=99t committed to unti=
l the unvaulting process starts. T<u></u><u></u>his (or something like this=
 with destination binding at unvault-time) would be an incredibly useful to=
ol for inheritance designs in wallets.=C2=A0</div><div><br></div><div>I nee=
d to think a bit more about the recovery path not having any real encumbran=
ces on it. Maybe in practice if you=E2=80=99re worried about DoS, you have =
UTXOs that commit to multiple vault paths that have tweaked recovery destin=
ations or something, or maybe it really is the right move to say that if re=
covery is triggered, you probably do want it for all of your inflight unvau=
ltings.=C2=A0</div><div><br></div><div>Looking forward to reading this a fe=
w more times and talking more about it.=C2=A0</div><div><br></div>Thanks!<d=
iv>rijndael<br><div><br><div><br></div>On Mon, Jan 9, 2023 at 11:07 AM, Jam=
es O&#39;Beirne via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; wrote:<blockquote type=3D"cite">  <div dir=3D"ltr">For the last few =
years, I&#39;ve been interested in vaults as a way to<br>substantially deri=
sk custodying Bitcoin, both at personal and commercial<br>scales. Instead o=
f abating with familiarity, as enthusiasm sometimes<br>does, my conviction =
that vaults are an almost necessary part of bitcoin&#39;s<br>viability has =
only grown over the years.<br><br>Since people first started discussing vau=
lts, it&#39;s been pretty clear that<br>some kind of covenant-enabling cons=
ensus functionality is necessary to<br>provide the feature set necessary to=
 make vault use practical.<br><br>Earlier last year I experimented with usi=
ng OP_CTV[1], a limited covenant<br>mechanism, to implement a &quot;minimum=
-viable&quot; vault design. I found that the<br>inherent limitations of a p=
recomputed covenant scheme left the resulting<br>vault implementation wanti=
ng, even though it was an improvement over<br>existing strategies that rely=
 on presigned transactions and (hopefully)<br>ephemeral keys.<br><br>But I =
also found proposed &quot;general&quot; covenant schemes to be<br>unsuitabl=
e for this use. The bloated scriptPubKeys, both in size and<br>complexity, =
that would result when implementing something like a vault<br>weren&#39;t e=
ncouraging. Also importantly, the social-consensus quagmire<br>regarding wh=
ich covenant proposal to actually deploy feels at times<br>intractable.<br>=
<br>As a result, I wanted to explore a middle way: a design solely concerne=
d<br>with making the best vault use possible, with covenant functionality a=
s a<br>secondary consideration. In other words, a proposal that would deliv=
er<br>the safety benefits of vaults to users without getting hung up on<br>=
trying to solve the general problem of covenants.<br><br>At first this desi=
gn, OP_VAULT, was just sort of a pipe dream. But as I<br>did more thinking =
(and eventually implementing) I became more convinced<br>that, even if it i=
sn&#39;t considered for soft-fork, it is a worthwhile<br>device to serve as=
 a standard benchmark against which other proposals<br>might be judged.<br>=
<br>I wrote a paper that summarizes my findings and the resulting proposal:=
<br><a href=3D"https://jameso.be/vaults.pdf" target=3D"_blank">https://jame=
so.be/vaults.pdf</a><br><br>along with an accompanying draft implementation=
:<br><a href=3D"https://github.com/bitcoin/bitcoin/pull/26857" target=3D"_b=
lank">https://github.com/bitcoin/bitcoin/pull/26857</a><br><br>I might work=
 on a BIP if there&#39;s interest.<br><div><br></div><div>James<br></div><b=
r>[1]: <a href=3D"https://github.com/jamesob/simple-ctv-vault" target=3D"_b=
lank">https://github.com/jamesob/simple-ctv-vault</a><br></div>
</blockquote></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>
</blockquote></div>

--000000000000443a8005f1daa63c--