Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 50BDCC0032 for ; 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 ; 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 ; 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 ; Thu, 16 Mar 2023 14:44:46 +0000 (UTC) Received: by mail-ed1-x531.google.com with SMTP id x3so8572247edb.10 for ; 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: <4652dbe8-6647-20f2-358e-be0ef2e52c47@dashjr.org> In-Reply-To: From: Greg Sanders Date: Thu, 16 Mar 2023 10:44:33 -0400 Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary="0000000000005ed09705f705801e" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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) 1 " OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG" OP_FORWARD_LEAF_UPDATE The 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 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 > 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
Hi Luke,

I think this works as wi= th=C2=A0OP_FLU based construct, for the simplest single key case.

<= /div>
e.g., single key hot wallet(or MuSig2/FROST wallet)

<= /div>
<hot_pubkey> 1 "<time-delay> OP_CHECKSEQUENCEVER= IFY 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_* o= pcodes, 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 i= nputs looking for this type of leaf.

Unfortu= nately this doesn'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.

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

Cheers,
Greg

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

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:
=20
Didn'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,
among other technical challenges.

On Mon, Mar 13, 2023 at 10:55=E2=80=AFAM Greg Sanders <gsanders87@gmail.com> wrote:
Hi Luke,

Can you elaborate why the current idealized functionality of deposit=C2=A0-> trigger -> withdrawal is too complicated for
everyday use but the above deposit -> withdrawal -> resolve(claim/clawback)=C2=A0 wouldn't be? I admit = at a high level
it's a fine paradigm, but in practice would end=C2=A0<= /div>

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@l= ists.linuxfoundation.org> wrote:
I started rev= iewing 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 of
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
> =C2=A0 anchors for fee management. When using "auth= orized recovery," all
> =C2=A0 vault-related transactions can be bundled with unrelated inputs and
> =C2=A0 outputs, facilitating fee management that is self contained to the
> =C2=A0 transaction. Consequently, the contents of this proposal are in theory
> =C2=A0 usable today.
>
> * Specific output locations are no longer hardcoded in any of the
> =C2=A0 transaction validation algorithms. This means tha= t the proposal is now
> =C2=A0 compatible with future changes like SIGHASH_GROUP= , and
> =C2=A0 transaction shapes for vault operations are more flexible.
>
> ---
>
> I've written a BIP that fully describes the proposal here:
>
> ht= tps://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawi= ki
>
> The corresponding PR is here:
>
> https://github.com/bitcoin/bips/pull/142= 1
>
> 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]:
> h= ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.= html
> [1]: https://github.com/bitcoin/bitc= oin/pull/26857
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linux= foundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfound= ation.org/mailman/listinfo/bitcoin-dev
--0000000000005ed09705f705801e--