Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 63199C002D for ; Wed, 18 Jan 2023 23:38:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 32A7141908 for ; Wed, 18 Jan 2023 23:38:04 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 32A7141908 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=GCQTQTLr 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHyX-SskgSIy for ; Wed, 18 Jan 2023 23:38:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AB8A941903 Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by smtp4.osuosl.org (Postfix) with ESMTPS id AB8A941903 for ; Wed, 18 Jan 2023 23:38:01 +0000 (UTC) Received: by mail-oi1-x22c.google.com with SMTP id p133so360178oig.8 for ; Wed, 18 Jan 2023 15:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=eWx0SGzKxJ0KEF7/QZXzy8b1e/dzeHRdpHQIP4aK9nI=; b=GCQTQTLrnRjX46UVd1IAvgy61eA+Si7jxycdX7IOl9NZnDksGNUkPH4PpxMUUBJjrL tvb6rC1RaRYZk148tH/aWj7ULQTFGX7EVRHpOybO8aClXaXfhXaKHFVkW49O2MnPukHN bk5n+4HgBx1KGOkDt6Iq03xXbg8NNW/psL1ckgz/DMVEeKrMXzh6HjvBgCKXHir2Pmfi bXqb3uqkv8wOhGdOdmjwdXvH3OLFeU/jSdPYYewskAIDt0p+F8e2g9Ng/ejnddm05Qvf pz9vh95pabc4GOwaCJtshV+rcPx+5PP6Yo7kSazkr8U781xZ9NBkvDNL6tScjuGnRqdq ip1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=eWx0SGzKxJ0KEF7/QZXzy8b1e/dzeHRdpHQIP4aK9nI=; b=o7xZoZ+Br0GyO8zif6XHdwDZQvIvLMFJoSr+BSATBE/8aT+vCZRSEKAHhwYmK3gJuD neRnqa9S5hbyepMKslyZ1lajVJBsFOHAaB6hPmHvXpmQFyVFbDVOnsgUlGx+GZdBs7bv sAbohxPS9wg4ANrvM85E19f4OYsmgTuVJt2GPPNA+/GbsEdd9KmjColuhjSWwDfJRUMq OIvOhJf8TGcoeTUuB0L4a2AYWNWjUhZ5eopKlJ4S+Tmr0SUf5vNiVlwOmcTR+5dvA2sn Jf1FQz/rR67tUBnxV8MndF64XQgFZCjhYWBWpbjMh1YGykuusm9tP0UOj/ornrc8C3Lt PsAw== X-Gm-Message-State: AFqh2kpbcvNcrWRFTArVgsFIbgTMYkKJv5cCwR8FKozhBYYmN8DEo3qR azAvu4wNVE92zoPq1LqB1+xVfskEPhwlA/EV1Vs= X-Google-Smtp-Source: AMrXdXt+P0DmIr9nqj4n8/FLdCE51jEtHU58doqPNUHqTPBz+xK9aRNMjcWQAH5j2ehAbDT3ZVk+7QiLxpcCQS7xXfA= X-Received: by 2002:aca:b708:0:b0:35a:774e:d352 with SMTP id h8-20020acab708000000b0035a774ed352mr525294oif.193.1674085080366; Wed, 18 Jan 2023 15:38:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "James O'Beirne" Date: Wed, 18 Jan 2023 18:37:51 -0500 Message-ID: To: Billy Tetrud , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000008a02db05f2924ef4" 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: Wed, 18 Jan 2023 23:38:04 -0000 --0000000000008a02db05f2924ef4 Content-Type: text/plain; charset="UTF-8" > I don't see in the write up how a node verifies that the destination > of a spend using an OP_VAULT output uses an appropriate OP_UNVAULT > script. It's probably quicker for you to just read through the implementation that I reference in the last section of the paper. https://github.com/bitcoin/bitcoin/blob/fdfd5e93f96856fbb41243441177a40ebbac6085/src/script/interpreter.cpp#L1419-L1456 > It would usually be prudent to store this recovery address with every > key to the vault, ... I'm not sure I really follow here. Worth noting now that in OP_VAULT the recovery path can be optionally gated by an arbitrary scriptPubKey. > This is rather limiting isn't it? Losing the key required to sign > loses your recovery option. This functionality is optional in OP_VAULT as of today. You can specify OP_TRUE (or maybe I should allow empty?) in the to disable any signing necessary for recovery. > Wouldn't it be reasonably possible to allow recovery outputs with any > recovery address to be batched, and the amount sums sent to each to be > added up and verified? I think the space savings from this is pretty negligible, since you're just saving on the transaction overhead, and it makes the implementation decently more complicated. One benefit might be sharing a common fee-management output (e.g. ephemeral anchor) across the separate vaults being recovered. > If someday wallet vaults are the standard wallet construct, people > might not even want to have a non-vault wallet just for use in > unvaulting. If you truly lacked any non-vaulted UTXOs and couldn't get any at a reasonable price (?), I can imagine there might be a mechanism where you include a payout output to some third party in a drafted unvault trigger transaction, and they provide a spend of the ephemeral output. Though you do raise a good point that this construction as written may not be compatible with SIGHASH_GROUP... I'd have to think about that one. > Hmm, it seems inaccurate to say that step is "skipped". While there > isn't a warm wallet step, its replaced with an OP_UNVAULT script step. It is "skipped" in the sense that your bitcoin can't be stolen by having to pass through some intermediate wallet during an authorized withdrawal to a given target, in the way that they could if you had to prespecify an unvault target when creating the vault. --- > My proposal for efficient wallet vaults was designed to meet all of > those criteria, and allows batching as well. Probably a discussion of your proposal merits a different thread, but some thoughts that occur: > [from the README] > > OP_BEFOREBLOCKVERIFY - Verifies that the block the transaction is > within has a block height below a particular number. This allows a > spend-path to expire. I think this breaks fundamental reorgability of transactions. I think some of the other opcodes, e.g the one that limits fee contribution on the basis of historical feerate, are going to be similarly controversial. > This is done by using a static intermediate address that has no values > that are unique to the particular wallet vault address. Does mean either that (i) this proposal doesn't have dynamic unvaulting targets or, (ii) if you do, in order to be batch unvaulted, vaulted coins need to first be spent into this intermediate output? It sounds like (ii) is the case, given that your unvault target specification lives in (I think?) the witness for the spend creating the intermediate output. If the intermediate address doesn't have any values which are unique to a particular vault, how do you authorize recoveries from it? --- Personally I think if you'd like to pursue your proposal, it'd be valuable to see a full implementation. Might also make it easier to assess the viability of the proposal. --0000000000008a02db05f2924ef4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I don't see in the write up how = a node verifies that the destination
> of a spend using an OP_VAULT o= utput uses an appropriate OP_UNVAULT
> script.

It's probab= ly quicker for you to just read through the
implementation that I refere= nce in the last section of the paper.

https://github.com/bitcoin/bitcoin/blob/fdfd5e93= f96856fbb41243441177a40ebbac6085/src/script/interpreter.cpp#L1419-L1456=

> It would usually be prudent to store this recovery address wit= h every
> key to the vault, ...

I'm not sure I really foll= ow here. Worth noting now that in OP_VAULT the
recovery path can be opti= onally gated by an arbitrary scriptPubKey.

> This is rather limit= ing isn't it? Losing the key required to sign
> loses your recove= ry option.

This functionality is optional in OP_VAULT as of today. = You can specify
OP_TRUE (or maybe I should allow empty?) in the <reco= very-params> to
disable any signing necessary for recovery.

&g= t; Wouldn't it be reasonably possible to allow recovery outputs with an= y
> recovery address to be batched, and the amount sums sent to each = to be
> added up and verified?

I think the space savings from = this is pretty negligible, since you're
just saving on the transacti= on overhead, and it makes the implementation
decently more complicated. = One benefit might be sharing a common
fee-management output (e.g. epheme= ral anchor) across the separate vaults
being recovered.

> If s= omeday wallet vaults are the standard wallet construct, people
> migh= t not even want to have a non-vault wallet just for use in
> unvaulti= ng.

If you truly lacked any non-vaulted UTXOs and couldn't get = any at a
reasonable price (?), I can imagine there might be a mechanism = where you
include a payout output to some third party in a drafted unvau= lt trigger
transaction, and they provide a spend of the ephemeral output= .

Though you do raise a good point that this construction as written= may
not be compatible with SIGHASH_GROUP... I'd have to think about= that
one.

> Hmm, it seems inaccurate to say that step is &quo= t;skipped". While there
> isn't a warm wallet step, its repl= aced with an OP_UNVAULT script step.

It is "skipped" in t= he sense that your bitcoin can't be stolen by having
to pass through= some intermediate wallet during an authorized withdrawal
to a given tar= get, in the way that they could if you had to prespecify
an unvault targ= et when creating the vault.


---


> My proposal for = efficient wallet vaults was designed to meet all of
> those criteria,= and allows batching as well.

Probably a discussion of your proposal= merits a different thread, but
some thoughts that occur:


>= ; [from the README]
>
> OP_BEFOREBLOCKVERIFY - Verifies that t= he block the transaction is
> within has a block height below a parti= cular number. This allows a
> spend-path to expire.

I think th= is breaks fundamental reorgability of transactions. I think
some of the = other opcodes, e.g the one that limits fee contribution on
the basis of = historical feerate, are going to be similarly
controversial.

>= This is done by using a static intermediate address that has no values
= > that are unique to the particular wallet vault address.

Does m= ean either that (i) this proposal doesn't have dynamic unvaulting
ta= rgets or, (ii) if you do, in order to be batch unvaulted, vaulted
coins = need to first be spent into this intermediate output?

It sounds like= (ii) is the case, given that your unvault target
specification lives in= (I think?) the witness for the spend creating the
intermediate output.<= br>
If the intermediate address doesn't have any values which are un= ique to
a particular vault, how do you authorize recoveries from it?
---

Personally I think if you'd like to pursue your proposa= l, it'd be
valuable to see a full implementation. Might also make it= easier to
assess the viability of the proposal.
--0000000000008a02db05f2924ef4--