From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 67214C0032 for ; Mon, 30 Oct 2023 16:20:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 41EBC4159D for ; Mon, 30 Oct 2023 16:20:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 41EBC4159D Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=Xr6PmTN+ 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 IAJ-kVRQ9ent for ; Mon, 30 Oct 2023 16:20:46 +0000 (UTC) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by smtp4.osuosl.org (Postfix) with ESMTPS id 73B4E41591 for ; Mon, 30 Oct 2023 16:20:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 73B4E41591 Received: by mail-ot1-x32f.google.com with SMTP id 46e09a7af769-6ce2eaf7c2bso3225050a34.0 for ; Mon, 30 Oct 2023 09:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698682845; x=1699287645; darn=lists.linuxfoundation.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=6ih9aw0JbVsSxMz8rnP6vJd/TS3OY51Nr6Th00mQiV0=; b=Xr6PmTN++n8K9bglFkz0yd6lrfb4m6N1tQFrRPiJJzDo1SZLYMsOlL5jcdQKKjS4tj Nw6Oc5pbTkENnHsomtjrMiZO/+zIiqIdP8jVKELOU3U/WeacR56y9AgltnLH69Uzxvom 05yaW3XxMyj/58OLnyOW0oZTk8LcbkNwyJ+huiT7kkT4eU00REWaEUowawixlZrrLo98 A9Ll6Gv5STP1tVjUAkQ9eoQbZChxfmdN63OtT0V7VQDrU626ztaB4Q4mnMyHWqil//7O CIqlS35nEhhNni9nG6ZgtU2K0wgxxEqPxZ0eHPVyk5jk08n9g36vruiMB+UgkZVd4CO2 ciiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698682845; x=1699287645; 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=6ih9aw0JbVsSxMz8rnP6vJd/TS3OY51Nr6Th00mQiV0=; b=pvtiWeW/bzbsmcb+vsbMVhZUoWsFMPHMB9fV7AD1ueua6lGzcD0f97SLeQ4eOOEf86 1fncSn6FtSURt5TofRcA1lIetre9zAwuJAfCwABsiMWDOyhTr5/SWgkhWTxNxjZZeDL0 o25dTdkk+fHMn1092C0Gz5GSOcIunvS6jblMiooLgbO7eP+dwhDjshyiBxWwGm/TICqy 6uUHVOK1tGFbMZOA3oJP170kO9XfATPM2oyx4N9LW6H8BCdnkDgAXnH1rqvlR/uD3nMn s+sr76yIOypkpq0mty2z0QpJ3bpdLVnKboVC0ALTyANaE3NYmBSKpMOga7cWj12R5yUb YzlA== X-Gm-Message-State: AOJu0YxqgK3h6NFZK8Q+Cja5QAbJUAk8A53AkwS01NYGffLthqYDmhvh AMbFkrAeYoCPx6gmIuX4BwsfqZee5JOayfzRarPl7uUl4k8= X-Google-Smtp-Source: AGHT+IHf9pFLvWjYoPcgeNKRXu0zQRc2leWyWIgITX2LAQidB/FmabjDeCHp98ANqRn3Qt8IY75axEvsLlKxOQ6v0dw= X-Received: by 2002:a05:6870:f210:b0:1d7:1533:6869 with SMTP id t16-20020a056870f21000b001d715336869mr12478869oao.31.1698682843887; Mon, 30 Oct 2023 09:20:43 -0700 (PDT) MIME-Version: 1.0 References: <87r0lfz6zp.fsf@rustcorp.com.au> In-Reply-To: <87r0lfz6zp.fsf@rustcorp.com.au> From: "James O'Beirne" Date: Mon, 30 Oct 2023 12:20:32 -0400 Message-ID: To: Rusty Russell , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000007efce40608f16b1b" X-Mailman-Approved-At: Mon, 30 Oct 2023 16:22:18 +0000 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: Mon, 30 Oct 2023 16:20:47 -0000 --0000000000007efce40608f16b1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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." That said, I'm sure some VAULT patterns could be abstracted into the miniscript/descriptor layer to good effect. --0000000000007efce40608f16b1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Oct 28, 2023 at 12:51=E2=80=AFAM = Rusty Russell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
<= div class=3D"gmail_quote">
But AFAICT there are multiple perfectly reasonable variants of vaults,
too.=C2=A0 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 pre= tty sure that BIP-345 VAULT handles the cases that you're outlining, th= ough I don't understand your terminology -- "master" vs. &qu= ot;normal", and why we are caring about P2WPKH vs. anything else. Usin= g the OP_VAULT* codes can be done in an arbitrary arrangement of tapleaves,= facilitating any number of vaultish spending conditions, alongside other n= on-VAULT leaves.

Well, I found the vault BIP really hard to understand.=C2=A0 I think it wan= ts
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."
That said, I'm sure some VAULT patterns could be abstracted= into the miniscript/descriptor layer to good effect.
--0000000000007efce40608f16b1b--