From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id F17BAC0032 for ; Wed, 1 Nov 2023 12:06:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id C718C7034D for ; Wed, 1 Nov 2023 12:06:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C718C7034D Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=rustcorp.com.au header.i=@rustcorp.com.au header.a=rsa-sha256 header.s=202305 header.b=TffyOaUR X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 QWvaVo4gJeK9 for ; Wed, 1 Nov 2023 12:06:48 +0000 (UTC) Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by smtp3.osuosl.org (Postfix) with ESMTPS id 2C92B6FCDD for ; Wed, 1 Nov 2023 12:06:48 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2C92B6FCDD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rustcorp.com.au; s=202305; t=1698840401; bh=K+hh5mlLwvNVvJNuMWsKwYlZpgi57Z/Wl4bM0LBjj4M=; h=From:To:Subject:In-Reply-To:References:Date:From; b=TffyOaUR+P8RbWMLqdmJ8dCVdMlugtN50iQ8bZfZMtyxXx5swDxv1OdvSiZT2ZudC 77pPR1DZJ/LTbzb/0L+CMf4+2mIpGr/bGHb1keE4lM5IBFe4avsFv6SPFUL8DKkgxe kBZleDH3qp3lfcmLUVwNEmIn6eyEepCybVyQDazPKEtkQo5EeYcGB5YJaa/wd0Cylp m2tIJ/GWBTnxA+knWrfn10wYFl5bBNoCgWlMgFE9+GVLL6MtHeCZyRgofYMqVPGH9i NhTycNJEhNu8sAHsLwB31xTbIkiDtrZPT6n9TQkDIB/o955ZOc1x6HKf9BLqlZCw8b uHaLAQkt3dBiw== Received: by gandalf.ozlabs.org (Postfix, from userid 1011) id 4SL5Mj1CzZz4x5w; Wed, 1 Nov 2023 23:06:41 +1100 (AEDT) From: Rusty Russell To: James O'Beirne , Bitcoin Protocol Discussion In-Reply-To: References: <87r0lfz6zp.fsf@rustcorp.com.au> Date: Tue, 31 Oct 2023 12:54:27 +1030 Message-ID: <87v8anr0kk.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script 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, 01 Nov 2023 12:06:53 -0000 "James O'Beirne" writes: > On Sat, Oct 28, 2023 at 12:51=E2=80=AFAM Rusty Russell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> But AFAICT there are multiple perfectly reasonable variants of vaults, >> too. One would be: >> >> 1. master key can do anything >> 2. OR normal key can send back to vault addr without delay >> 3. OR normal key can do anything else after a delay. >> >> Another would be: >> 1. normal key can send to P2WPKH(master) >> 2. OR normal key can send to P2WPKH(normal key) after a delay. >> > > I'm confused by what you mean here. I'm pretty sure that BIP-345 VAULT > handles the cases that you're outlining, though I don't understand your > terminology -- "master" vs. "normal", and why we are caring about P2WPKH > vs. anything else. Using the OP_VAULT* codes can be done in an arbitrary > arrangement of tapleaves, facilitating any number of vaultish spending > conditions, alongside other non-VAULT leaves. I was thinking from a user POV: the "master" key is the one they keep super safe in case of emergencies, the "normal" is the delayed spend key. OP_VAULT certainly can encapsulate this, but I have yet to do the kind of thorough review that I'd need to evaluate the various design decisions. > Well, I found the vault BIP really hard to understand. I think it wants >> to be a new address format, not script opcodes. >> > > Again confused here. This is like saying "CHECKLOCKTIMEVERIFY wants to be= a > new address format, not a script opcode." I mean in an ideal world, Bitcoin Script would be powerful enough to implement vaults, and once a popular use pattern emerged we'd introduce a new address type, defined to expand to that template. Like P2WPK or P2PKH. Sadly, we're not in that world! BIP 345 introduces a number of separate mechanisms, such as limited script delegation, iteration and amount arithmetic which are not expressible in Script (ok, amount arithmetic kind of is, but ick!). To form a real opinion, I need to consider all these elements, and whether they should exist inside OP_VAULT, or as separate things. That's a slow process, sorry :( > That said, I'm sure some VAULT patterns could be abstracted into the > miniscript/descriptor layer to good effect. That would be very interesting, but hard. Volunteers? :) Cheers, Rusty.