path: root/ad/ee353e058ac67acfdfdc28c70f44bb0a8f346b

Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 50BDCC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Mar 2023 14:44:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 180FA60E57
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Mar 2023 14:44:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 180FA60E57
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=j2TdyKn+
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id aQn5FqMuuz2y
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Mar 2023 14:44:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 61D7D60BE8
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [IPv6:2a00:1450:4864:20::531])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 61D7D60BE8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Mar 2023 14:44:46 +0000 (UTC)
Received: by mail-ed1-x531.google.com with SMTP id x3so8572247edb.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Mar 2023 07:44:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20210112; t=1678977884;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=6w2rw4S4IvVgRMxROTQd5jtnlAVOEOTip1vFXZ3NTYY=;
 b=j2TdyKn+7aIw2Lh/PasVCT8wnzbKH8bFqPNhmNTnF0C/lI8xc5HQ8QrnvKwfAwfIkD
 SgIHEGzv3FUV7w4ndgFlqeK1VfiA+N/TFxvb1z6pUVU7b9LahsOEqQa/7qtbLAD/SNfv
 Lm6Xpx4uDcj7iPIVlUD2AQBLzLmjNH32wIgoQPb+E45L40ImF+SFjXg2kW4jCU3pPEar
 vFitTf/gml0EelDvLnEf/czH03bpfi/qiHY9apV7DNa54vwAzgVnQx99JOe3klfVmo0Z
 Heq5ZMSamjjnhKiUJMNaE/2mPcyk7+WBvWcxw/CJVwrs0EcUGznhDJQc6Dgql8ti7SwM
 XaKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112; t=1678977884;
 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=6w2rw4S4IvVgRMxROTQd5jtnlAVOEOTip1vFXZ3NTYY=;
 b=F9W2Kmsa+TYbSgo7npyKnK2avm1qSDwT5U7hHzroH2lcbT3Ia9Pd7amCVUbucFOw1V
 wQ+PmQ0D9eMUNSnoFDxPklXj7N3s7DkGX6x4tZNka1lbXy5vajqAS/Bhtf1h/9OOECCJ
 yz+QE+2dsvyfXR11zRNTSB7vELzk0IoA7VLWQP08tDb5xSw4gfwiZIgbC3WmpvkEdJvG
 RukYsxITzOfJjlOyi4YoHBOpwJWMOcF8FBPR2YVx7ZQgJWq9n9IGkYHWHHPaE0WdSbOM
 fUXoD9wGXo4MKbuv3cjd6ojh22MIgCeFmMhe5x8UUFkb6O50IqNX46BM+GtmwEsNtR4D
 1zSQ==
X-Gm-Message-State: AO0yUKWrMefXINoDzUyVPndXY+k8vX6eUGl91yVzOmzn3shPzGm752iR
 0i83M+jXYyAeLMLcLA/zlR3gRxWM+/BnKv6liqrwGjT3hn4=
X-Google-Smtp-Source: AK7set/R7dICvVyPsIY3qpkIlcUtckZG+MMT/8OBt9CNV3nsXBnK/V6NHI1sU16lvEQ6HJT6zIeMOesP1MnsqUB2Ra8=
X-Received: by 2002:a17:907:728f:b0:92f:7c42:863d with SMTP id
 dt15-20020a170907728f00b0092f7c42863dmr2614295ejc.2.1678977884146; Thu, 16
 Mar 2023 07:44:44 -0700 (PDT)
MIME-Version: 1.0
References: <CAPfvXfJQKb7i8GBvTEvTTz-3dU_5mH8jOv8Nm4Q8gPt=KxrqLQ@mail.gmail.com>
 <4652dbe8-6647-20f2-358e-be0ef2e52c47@dashjr.org>
 <CAB3F3DtitOkV=KGGJjtet=YHJYbfj0KWVYRNKDWwyecRCBC=2w@mail.gmail.com>
 <CAB3F3DtTD4DeY33UCArRq-iNEt7D8tuT+daA5H-8aCVHz9FP4g@mail.gmail.com>
 <f2dba06f-6230-1093-32a5-8a426821ed8e@dashjr.org>
In-Reply-To: <f2dba06f-6230-1093-32a5-8a426821ed8e@dashjr.org>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 16 Mar 2023 10:44:33 -0400
Message-ID: <CAB3F3DsDefXiHsGxOsqHQHPEgHcjVi6QrvUVenCW2HwQJBr9Ng@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary="0000000000005ed09705f705801e"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP for OP_VAULT
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, 16 Mar 2023 14:44:48 -0000

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

Hi Luke,

I think this works as with OP_FLU based construct, for the simplest single
key case.

e.g., single key hot wallet(or MuSig2/FROST wallet)

<hot_pubkey> 1 "<time-delay> OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG"
OP_FORWARD_LEAF_UPDATE

The <hot_pubkey> is appended at spending time.

This allows the utxo to go to $recover cold storage at any point like
before, otherwise the time matures and the funds can be spent by a single
key. Rate-limiting like usual can be bolted on as well using OP_FORWARD_*
opcodes, I'm pretty sure. This would as you note require wallet support,
where the hot wallet would have to be aware of the vault, or be scanning
inputs looking for this type of leaf.

Unfortunately this doesn't extend to things like OP_CHECKSIGADD, since the
pubkeys are all pushed first, then the opcodes run. OP_CHECKMULTISIG would
have worked probably.

To generalize I think you'd need recursive taproot, or a proper replacement
for Bitcoin script :)

Cheers,
Greg

On Mon, Mar 13, 2023 at 4:55=E2=80=AFPM Luke Dashjr <luke@dashjr.org> wrote=
:

> In ordinary use cases, you wouldn't clawback; that would only be in the
> extreme case of the wallet being compromised. So typical usage would just
> be receive -> send, like wallets currently do.
>
> Luke
>
>
> On 3/13/23 10:56, Greg Sanders wrote:
>
> Didn't finish sentence: but in practice would end up with pretty similar
> usage flows imho, and as noted in PR, would take a different wallet
> paradigm,
> among other technical challenges.
>
> On Mon, Mar 13, 2023 at 10:55=E2=80=AFAM Greg Sanders <gsanders87@gmail.c=
om>
> wrote:
>
>> Hi Luke,
>>
>> Can you elaborate why the current idealized functionality of deposit ->
>> trigger -> withdrawal is too complicated for
>> everyday use but the above deposit -> withdrawal ->
>> resolve(claim/clawback)  wouldn't be? I admit at a high level
>> it's a fine paradigm, but in practice would end
>>
>> Let's ignore implementation for the discussion, since that's in flux.
>>
>> Cheers,
>> Greg
>>
>> On Sat, Mar 11, 2023 at 3:53=E2=80=AFPM Luke Dashjr via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> I started reviewing the BIP, but stopped part way through, as it seems
>>> to have a number of conceptual issues.
>>>
>>> I left several comments on the PR
>>> (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575=
),
>>>
>>> but ultimately I think it isn't simplified enough for day-to-day use,
>>> and would harm privacy quite a bit.
>>>
>>> Instead, I would suggest a new approach where:
>>>
>>> 1) Joe receives funds with a taproot output like normal.
>>> 2) Joe sends funds to Fred, but Fred cannot spend them until N blocks
>>> later (covenant-enforced relative locktime). Ideally, this should
>>> use/support a taproot keypath spend somehow. It would be nice to blind
>>> the particular relative locktime somehow too, but that may be too
>>> expensive.
>>> 2b) If Joe's funds were stolen, Joe can spend Fred's UTXO within the N
>>> block window to a recovery output.
>>>
>>> Unfortunately, the implementation details for this kind of setup are
>>> non-obvious and will likely require yet another address format (or at
>>> least recipient-wallet changes), but certainly seems within the scope o=
f
>>> possibility.
>>>
>>> Thoughts?
>>>
>>> Luke
>>>
>>>
>>> On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote:
>>> > Since the last related correspondence on this list [0], a number of
>>> > improvements have been made to the OP_VAULT draft [1]:
>>> >
>>> > * There is no longer a hard dependence on package relay/ephemeral
>>> >   anchors for fee management. When using "authorized recovery," all
>>> >   vault-related transactions can be bundled with unrelated inputs and
>>> >   outputs, facilitating fee management that is self contained to the
>>> >   transaction. Consequently, the contents of this proposal are in
>>> theory
>>> >   usable today.
>>> >
>>> > * Specific output locations are no longer hardcoded in any of the
>>> >   transaction validation algorithms. This means that the proposal is
>>> now
>>> >   compatible with future changes like SIGHASH_GROUP, and
>>> >   transaction shapes for vault operations are more flexible.
>>> >
>>> > ---
>>> >
>>> > I've written a BIP that fully describes the proposal here:
>>> >
>>> >
>>> https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.m=
ediawiki
>>> >
>>> > The corresponding PR is here:
>>> >
>>> > https://github.com/bitcoin/bips/pull/1421
>>> >
>>> > My next steps will be to try for a merge to the inquisition repo.
>>> >
>>> > Thanks to everyone who has participated so far, but especially to AJ
>>> and
>>> > Greg for all the advice.
>>> >
>>> > James
>>> >
>>> > [0]:
>>> >
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/02=
1318.html
>>> > [1]: https://github.com/bitcoin/bitcoin/pull/26857
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>

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

<div dir=3D"ltr"><div>Hi Luke,</div><div><br></div>I think this works as wi=
th=C2=A0OP_FLU based construct, for the simplest single key case.<div><br><=
/div><div>e.g., single key hot wallet(or MuSig2/FROST wallet)<br><div><br><=
/div><div>&lt;hot_pubkey&gt; 1 &quot;&lt;time-delay&gt; OP_CHECKSEQUENCEVER=
IFY OP_DROP OP_CHECKSIG&quot; OP_FORWARD_LEAF_UPDATE</div><div><br></div><d=
iv>The &lt;hot_pubkey&gt; is appended at spending time.</div><div><br></div=
><div>This allows the utxo to go to $recover cold storage at any point like=
 before, otherwise the time matures and the funds can be spent by a single =
key. Rate-limiting like usual can be bolted on as well using OP_FORWARD_* o=
pcodes, I&#39;m pretty sure. This would as you note require wallet support,=
 where the hot wallet would have to be aware of the vault, or be scanning i=
nputs looking for this type of leaf.</div></div><div><br></div><div>Unfortu=
nately this doesn&#39;t extend to things like OP_CHECKSIGADD, since the pub=
keys are all pushed first, then the opcodes run. OP_CHECKMULTISIG would hav=
e worked probably.</div><div><br></div><div>To generalize I think you&#39;d=
 need recursive taproot, or a proper replacement for Bitcoin script :)=C2=
=A0</div><div><br></div><div>Cheers,</div><div>Greg</div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 13, 20=
23 at 4:55=E2=80=AFPM Luke Dashjr &lt;<a href=3D"mailto:luke@dashjr.org" ta=
rget=3D"_blank">luke@dashjr.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div>
    <p>In ordinary use cases, you wouldn&#39;t clawback; that would only be
      in the extreme case of the wallet being compromised. So typical
      usage would just be receive -&gt; send, like wallets currently do.</p=
>
    <p>Luke</p>
    <p><br>
    </p>
    <div>On 3/13/23 10:56, Greg Sanders wrote:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">Didn&#39;t finish sentence: but in practice would en=
d
        up with pretty similar usage flows imho, and as noted in PR,
        would take a different wallet paradigm,
        <div>among other technical challenges.</div>
      </div>
      <br>
      <div class=3D"gmail_quote">
        <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 13, 2023 at
          10:55=E2=80=AFAM Greg Sanders &lt;<a href=3D"mailto:gsanders87@gm=
ail.com" target=3D"_blank">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">
            <div>Hi Luke,</div>
            <div><br>
            </div>
            Can you elaborate why the current idealized functionality of
            deposit=C2=A0-&gt; trigger -&gt; withdrawal is too complicated
            for
            <div>everyday use but the above deposit -&gt; withdrawal
              -&gt; resolve(claim/clawback)=C2=A0 wouldn&#39;t be? I admit =
at a
              high level</div>
            <div>it&#39;s a fine paradigm, but in practice would end=C2=A0<=
/div>
            <div><br>
            </div>
            <div>Let&#39;s ignore implementation for the discussion, since
              that&#39;s in flux.</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 Sat, Mar 11, 2023 at
              3:53=E2=80=AFPM Luke Dashjr via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l=
ists.linuxfoundation.org</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">I started rev=
iewing the
              BIP, but stopped part way through, as it seems <br>
              to have a number of conceptual issues.<br>
              <br>
              I left several comments on the PR <br>
              (<a href=3D"https://github.com/bitcoin/bips/pull/1421#pullreq=
uestreview-1335925575" rel=3D"noreferrer" target=3D"_blank">https://github.=
com/bitcoin/bips/pull/1421#pullrequestreview-1335925575</a>),
              <br>
              but ultimately I think it isn&#39;t simplified enough for
              day-to-day use, <br>
              and would harm privacy quite a bit.<br>
              <br>
              Instead, I would suggest a new approach where:<br>
              <br>
              1) Joe receives funds with a taproot output like normal.<br>
              2) Joe sends funds to Fred, but Fred cannot spend them
              until N blocks <br>
              later (covenant-enforced relative locktime). Ideally, this
              should <br>
              use/support a taproot keypath spend somehow. It would be
              nice to blind <br>
              the particular relative locktime somehow too, but that may
              be too expensive.<br>
              2b) If Joe&#39;s funds were stolen, Joe can spend Fred&#39;s =
UTXO
              within the N <br>
              block window to a recovery output.<br>
              <br>
              Unfortunately, the implementation details for this kind of
              setup are <br>
              non-obvious and will likely require yet another address
              format (or at <br>
              least recipient-wallet changes), but certainly seems
              within the scope of <br>
              possibility.<br>
              <br>
              Thoughts?<br>
              <br>
              Luke<br>
              <br>
              <br>
              On 2/13/23 16:09, James O&#39;Beirne via bitcoin-dev wrote:<b=
r>
              &gt; Since the last related correspondence on this list
              [0], a number of<br>
              &gt; improvements have been made to the OP_VAULT draft
              [1]:<br>
              &gt;<br>
              &gt; * There is no longer a hard dependence on package
              relay/ephemeral<br>
              &gt; =C2=A0 anchors for fee management. When using &quot;auth=
orized
              recovery,&quot; all<br>
              &gt; =C2=A0 vault-related transactions can be bundled with
              unrelated inputs and<br>
              &gt; =C2=A0 outputs, facilitating fee management that is self
              contained to the<br>
              &gt; =C2=A0 transaction. Consequently, the contents of this
              proposal are in theory<br>
              &gt; =C2=A0 usable today.<br>
              &gt;<br>
              &gt; * Specific output locations are no longer hardcoded
              in any of the<br>
              &gt; =C2=A0 transaction validation algorithms. This means tha=
t
              the proposal is now<br>
              &gt; =C2=A0 compatible with future changes like SIGHASH_GROUP=
,
              and<br>
              &gt; =C2=A0 transaction shapes for vault operations are more
              flexible.<br>
              &gt;<br>
              &gt; ---<br>
              &gt;<br>
              &gt; I&#39;ve written a BIP that fully describes the proposal
              here:<br>
              &gt;<br>
              &gt; <a href=3D"https://github.com/jamesob/bips/blob/jamesob-=
23-02-opvault/bip-vaults.mediawiki" rel=3D"noreferrer" target=3D"_blank">ht=
tps://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawi=
ki</a><br>
              &gt;<br>
              &gt; The corresponding PR is here:<br>
              &gt;<br>
              &gt; <a href=3D"https://github.com/bitcoin/bips/pull/1421" re=
l=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/pull/142=
1</a><br>
              &gt;<br>
              &gt; My next steps will be to try for a merge to the
              inquisition repo.<br>
              &gt;<br>
              &gt; Thanks to everyone who has participated so far, but
              especially to AJ and<br>
              &gt; Greg for all the advice.<br>
              &gt;<br>
              &gt; James<br>
              &gt;<br>
              &gt; [0]: <br>
              &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/b=
itcoin-dev/2023-January/021318.html" rel=3D"noreferrer" target=3D"_blank">h=
ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.=
html</a><br>
              &gt; [1]: <a href=3D"https://github.com/bitcoin/bitcoin/pull/=
26857" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitc=
oin/pull/26857</a><br>
              &gt;<br>
              &gt; _______________________________________________<br>
              &gt; bitcoin-dev mailing list<br>
              &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
              &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/lis=
tinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/mailman/listinfo/bitcoin-dev</a><br>
              _______________________________________________<br>
              bitcoin-dev mailing list<br>
              <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=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.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev</a><br>
            </blockquote>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </div>

</blockquote></div>

--0000000000005ed09705f705801e--