Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 92EE9C002D for ; Mon, 9 Jan 2023 19:32:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 661C8405C6 for ; Mon, 9 Jan 2023 19:32:06 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 661C8405C6 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=Rw0J1fMi X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 Ew_KiKoNqlY5 for ; Mon, 9 Jan 2023 19:32:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org CAF44405C2 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by smtp2.osuosl.org (Postfix) with ESMTPS id CAF44405C2 for ; Mon, 9 Jan 2023 19:32:04 +0000 (UTC) Received: by mail-ed1-x535.google.com with SMTP id c34so14208516edf.0 for ; Mon, 09 Jan 2023 11:32:04 -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=asVVN25ySMzLpKpaJSbPVNdlsmLN2cKQ3cYRLoJVlNA=; b=Rw0J1fMiJ5pMzBhM7QRKN/aBpXpkzlhPjwXOxwnVnsl3jO25ylJvhZJC7UOKnSK0rT YJzc/u2J0YOHaYrU7HMDVCZv3p+nwMMvIRziksdPJCtrl2U6jOHriFyBg9mxCrolZyUL KYhQYhucMs65fbAKx6nexVyUspxYCBAvjMyxv7C+DAuw84hmLlHrUOB9ygqwPpo6aZXT m1tiQSb3S7ZdaEXwAP+XC91atk5xuARZv/lqzGZ8KmISekViJbR69sryy1j7Qfiufkoq akpoIn/v0iU5m2lI12CK4iOqjxX5m1f6m7N3/pZ86AO90dWYG8cloaN+wr7YU3xtOzvL Pi0g== 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=asVVN25ySMzLpKpaJSbPVNdlsmLN2cKQ3cYRLoJVlNA=; b=jlmln1QbK1M3im1DL2d0rz7zkiCG8+kGUso2ZI55rpoJ/1a8e750nWlZSsDeJpO3qJ eUWKs3GZNnydpNP+2bu1VvvlwNryW5/Lw5KTKchcnVyoqvfAHoky6BM4Ujl0vn72V7cD gOMhZksTmlrjSfDWis4zE73Nl5wO43FoLC1OmGpPJxzcbGI+QsVJiM+8D5xMubKNI/CT RcOTlTB/ghjjUreUJrASGjfz0j73ne8X4QDYEk8BPqI9SuoidpY9vzFsAqgWZkuCgqFN iTKOKCvPRl9GmxuodmKXkBMdmrgomSIVtEeJPaSZP7JVAqTfjFs+6S1jmUJXgsdXY6/G seYQ== X-Gm-Message-State: AFqh2kp+DyrnGqvBkAFO0RxxKxVRr7T8pL0LSHm8Gy5DCG7h7LwR1Eig P3IREctL+KFMzYYc23YyObp8lY9w1UGRzoG+5kchI6caLAk= X-Google-Smtp-Source: AMrXdXt7f6hY3cyDnO/HnZ62cswUDUpsoEOT5FMn5k8B68p+trGXmiKoVSRh0XNWqJBaHgrlWRfi99uQCwk7tiSTUDc= X-Received: by 2002:aa7:c913:0:b0:498:5096:2415 with SMTP id b19-20020aa7c913000000b0049850962415mr686783edt.364.1673292722632; Mon, 09 Jan 2023 11:32:02 -0800 (PST) MIME-Version: 1.0 References: <8Uq3KNRWS_WV393lP9wq820PE8KNK0bhQ7u7hMJhIfdfV3-ZhSI-4q9Mw5P_TXivKtyePE2Exha4rso2yi3iNnLJpUpBQ38lAuwG-lQPVUE=@protonmail.com> In-Reply-To: <8Uq3KNRWS_WV393lP9wq820PE8KNK0bhQ7u7hMJhIfdfV3-ZhSI-4q9Mw5P_TXivKtyePE2Exha4rso2yi3iNnLJpUpBQ38lAuwG-lQPVUE=@protonmail.com> From: Greg Sanders Date: Mon, 9 Jan 2023 14:31:51 -0500 Message-ID: To: rot13maxi , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000567b1205f1d9d2d6" 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: Mon, 09 Jan 2023 19:32:06 -0000 --000000000000567b1205f1d9d2d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi James and co, Currently there is no way to make this compatible with scripthashes of any 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 to be included in the witness stack as an input to OP_VAULT opcode, and transaction introspection then checks to make sure the 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 scrip= t 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 multisig > to spend=E2=80=9D schemes, you have the problem of needing to =E2=80=9Cre= fresh=E2=80=9D all of your > coins when the timelock is close to maturation. In a lot of the =E2=80=9C= use > multisig with ephemeral keys to emulate covenants=E2=80=9D schemes, you h= ave 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 a= nd > availability of *those* keys. In other words, you either have to have > unbound destinations but a timer that needs resetting, or you have unboun= d > time but fixed destinations. This design gets you the best of both becaus= e > the destination SPKs aren=E2=80=99t committed to until the unvaulting pro= cess > 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 DoS= , 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 th= at > if recovery is triggered, you probably do want it for all of your infligh= t > 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 that > 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 covenant > mechanism, to implement a "minimum-viable" vault design. I found that the > 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 > --000000000000567b1205f1d9d2d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi James and co,

Currently there is no = way to make this compatible=C2=A0with scripthashes=C2=A0of any kind, since = the script interpreter has no insight into the OP_UNVAULT outputs' &quo= t;execution script", and one of the arguments of OP_UNVAULT is freefor= m, 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-outp= uts-hash> to be included in the witness stack as an input to OP_VAULT op= code, and transaction introspection then checks to make sure the witness it= em and the corresponding output script template matches the expected.
=

This would only be necessary for the unvaulting path, a= nd not for the recovery path.

Cheers,
Gr= eg

On Mon, Jan 9, 2023 at 2:10 PM rot13maxi via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.org> wrote:
Hey James,

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. This (or something like this= with destination binding at unvault-time) would be an incredibly useful to= ol for inheritance designs in wallets.=C2=A0

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

Looking forward to reading this a fe= w more times and talking more about it.=C2=A0

Thanks!rijndael


On Mon, Jan 9, 2023 at 11:07 AM, Jam= es 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 deri= sk custodying Bitcoin, both at personal and commercial
scales. Instead o= f 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 vau= lts, it's been pretty clear that
some kind of covenant-enabling cons= ensus functionality is necessary to
provide the feature set necessary to= make vault use practical.

Earlier last year I experimented with usi= ng OP_CTV[1], a limited covenant
mechanism, to implement a "minimum= -viable" vault design. I found that the
inherent limitations of a p= recomputed covenant scheme left the resulting
vault implementation wanti= ng, 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
unsuitabl= e for this use. The bloated scriptPubKeys, both in size and
complexity, = that would result when implementing something like a vault
weren't e= ncouraging. Also importantly, the social-consensus quagmire
regarding wh= ich covenant proposal to actually deploy feels at times
intractable.
=
As a result, I wanted to explore a middle way: a design solely concerne= d
with making the best vault use possible, with covenant functionality a= s a
secondary consideration. In other words, a proposal that would deliv= er
the safety benefits of vaults to users without getting hung up on
= trying to solve the general problem of covenants.

At first this desi= gn, 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 i= sn'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://jame= so.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/mail= man/listinfo/bitcoin-dev
--000000000000567b1205f1d9d2d6--