diff options
| author | Anthony Towns <aj@erisian.com.au> | 2023-01-17 17:46:38 +1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-01-17 07:46:49 +0000 |
| commit | eda43bc0d819789746351ec62018da96eb121df7 (patch) | |
| tree | 3f9409a1d8ec4acaf65c7c9f0b19f54eb32f02f9 | |
| parent | 5015b6678248a5b97d21c9fcab7b46c3249428f2 (diff) | |
| download | pi-bitcoindev-eda43bc0d819789746351ec62018da96eb121df7.tar.gz pi-bitcoindev-eda43bc0d819789746351ec62018da96eb121df7.zip | |
Re: [bitcoin-dev] OP_VAULT: a new vault proposal
| -rw-r--r-- | b4/e0cb3788e9fbea61cf5f1cca0ee5a65df0c9db | 116 |
1 files changed, 116 insertions, 0 deletions
diff --git a/b4/e0cb3788e9fbea61cf5f1cca0ee5a65df0c9db b/b4/e0cb3788e9fbea61cf5f1cca0ee5a65df0c9db new file mode 100644 index 000000000..febc3defa --- /dev/null +++ b/b4/e0cb3788e9fbea61cf5f1cca0ee5a65df0c9db @@ -0,0 +1,116 @@ +Return-Path: <aj@erisian.com.au> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 3AC5BC002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 17 Jan 2023 07:46:49 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 0F91840128 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 17 Jan 2023 07:46:49 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0F91840128 +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.901 +X-Spam-Level: +X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, + UNPARSEABLE_RELAY=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 jfbe0HuMXlgk + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 17 Jan 2023 07:46:48 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 04FC140022 +Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 04FC140022 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 17 Jan 2023 07:46:47 +0000 (UTC) +Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) + by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) + id 1pHgg7-0005St-D3; Tue, 17 Jan 2023 17:46:44 +1000 +Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); + Tue, 17 Jan 2023 17:46:38 +1000 +Date: Tue, 17 Jan 2023 17:46:38 +1000 +From: Anthony Towns <aj@erisian.com.au> +To: Andrew Chow <lists@achow101.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <Y8ZSXrxfR8HrB8zD@erisian.com.au> +References: <afde051e-4e63-368c-3251-70f829a51c4e@achow101.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <afde051e-4e63-368c-3251-70f829a51c4e@achow101.com> +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: Tue, 17 Jan 2023 07:46:49 -0000 + +On Mon, Jan 16, 2023 at 11:47:09PM +0000, Andrew Chow via bitcoin-dev wrote: +> It seems like this proposal will encourage address reuse for vaults, + +(That is listed as an explicit goal: "A single vault scriptPubKey should +be able to "receive" multiple deposits") + +> However the current construction makes it impossible to spend these +> vaults together. Since OP_VAULT requires the recovery script of the +> unvault output to match what's provided in the input, + +I don't think this part is a big problem -- the recovery path requires +revealing a secret, but if you separate that secret from the recovery +path sPK, you could vary the secret. ie: + + unvault1 delay recovery1 VAULT + unvault2 delay recovery2 VAULT + +where recovery1 = SHA256(SHA256(secret1), rSPK) and recovery2 = +SHA256(SHA256(secret2), rSPK), and both are spendable when the top stack +element is secretN and the first output pays at least the sum of all +the OP_VAULT using inputs to rSPK. So batched recovery could work fine, +I think. + +(If you're using the same "recovery" parameter to each VAULT, then +you're revealing which txs are in your vault at spend time, rather than +at receive time, which doesn't seem all that much better to me) + +But the problem with this is it prevents you from combining vaults when +spending normally: so if you've got a bunch of vaults with 1 BTC each, +and want to spend 10 BTC on a house, you'll need to make 11 separate +transactions: + + * 10 txs each spending a single vault utxo, satisfying + <uN> <delay> <rN> OP_VAULT + via the uN path, creating an output of + <outhash> <delay> <rN> OP_UNVAULT + + * 1 tx spending all the OP_UNVAULT outputs to a common set of outputs + <uN>, with nSequence set to a relative timelock of at least <delay> + +Whereas if you use an identical OP_VAULT script for all the utxos in +your vault, that can look like: + + * 1 tx, spending all the vault utxos, to a single OP_UNVAULT output, + with the same <delay> <rN> that all the inputs share. + + * 1 tx spending the OP_UNVAULT output after a delay + +But maybe you can get the best of both worlds just by having the unvault +path for OP_VAULT require you to put the vout number for its corresponding +OP_UNVAULT output on the stack? Then if you're doing address reuse, you +use a single vout for multiple inputs; and if you're avoiding address +reuse, you use multiple outputs, and provide the mapping between inputs +and outputs explicitly. + +Cheers, +aj + + |