Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id EA062C0032 for ; Mon, 6 Mar 2023 16:07:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id C53CC80E8E for ; Mon, 6 Mar 2023 16:07:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C53CC80E8E Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=CLRZtdU4 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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo8qYAPLoIVO for ; Mon, 6 Mar 2023 16:07:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5095480E78 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5095480E78 for ; Mon, 6 Mar 2023 16:07:51 +0000 (UTC) Received: by mail-ed1-x531.google.com with SMTP id ec29so9920233edb.6 for ; Mon, 06 Mar 2023 08:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678118869; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=O0XFbo02IC/faotjgZfJb21wyoCDhYIls0Oxw3KxrvE=; b=CLRZtdU4zirjVxaODlww2j5qCZbZIAdWn1SL20ojyiykyQqD4Wh6Qdz8FyjXkPRln0 NTyhXHzH58/0apg5TcgRmw3SW3RoaSc4/xGVvprcbssCvBP8eSTIbtMgfadYws5uOqDP j64mZBvjexhhy+GuUnWg5cPQ+X/iwArJFUy4HNvfo2EY7vI4KJ81oCzA8GtRG7vzf16Q XyVvt8z4HCVgLgQbC3SRkY+dh+kQrDyxJoUJopyWH1sYw5VktFnksv7g0+/AmxFLiYXv u2gObzNPT0ijqTSg+CGfeXbJH1xUOgTrbzcSBj2it17Os3px4P1KeQ1SHZlwT8s+kr/m 4ncg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678118869; 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=O0XFbo02IC/faotjgZfJb21wyoCDhYIls0Oxw3KxrvE=; b=6hYdW/oHint8fdLbuEo+adPtPWcsN6vDwrIVl7udHVponED+2CEn89ZChHKaPvDg+w VT67Kqgpc685YX6iw/GBEr2+3YAubQyTc6Fn4vXyqgZiTdARiog6om5f0t9kK7aH0uXY V6YM325JCctVH1/NYTkVJRAR1FVIa7cnNWntIlVWmdkl7DPhpCcF/sEeHWsMsfHz4D2B zKjNWp9sjXoZDRDPePsgGq+esZ4T60v2CKQ77r9KFZVJKCURJXL4tQXsPjhCGLUxFAUU QahXiqnK8Tjw8WAMI6cUH8qtdZtuI0EAs86/yEefhPIk/Dm8rngEFdn3Bh8WVyDeFi/p e8Qw== X-Gm-Message-State: AO0yUKV8F7yC8ts3sDyRlAFntzatzzhBvwcx0GBmNioJ6bsnjCn8qAGV pt9gEZMWJlrcUcrQfRItHXgSvOcsEp6wB6ybrX4= X-Google-Smtp-Source: AK7set9odQ2Q1k2ABmYU48hBDmq7bAn5ROPITx8qy6/hRjwKvoLmLZ8fPoOXwhH5SNyaNmMn9qRF1R7Z/+ol7AnupkU= X-Received: by 2002:a17:907:724f:b0:8b1:3c31:efe6 with SMTP id ds15-20020a170907724f00b008b13c31efe6mr9024655ejc.3.1678118869312; Mon, 06 Mar 2023 08:07:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Mon, 6 Mar 2023 11:07:38 -0500 Message-ID: To: "James O'Beirne" Content-Type: multipart/alternative; boundary="00000000000018a8c405f63d7f78" Cc: Bitcoin Protocol Discussion , Anthony Towns 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: Mon, 06 Mar 2023 16:07:53 -0000 --00000000000018a8c405f63d7f78 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi James, I think everything except the hinted "withdrawal authorization" is spot on. For withdrawal authorization, I think we'll have to go deeper into the TLUV direction as AJ suggested for at least a couple reasons: 1) You need the withdrawal authorization committed at deposit time 2) You need to make sure cheeky opcodes cannot be prepended to the script at spend time OP_FORWARD_LEAF_UPDATE(OP_FLU) seems to fit the bill, at the cost of maybe adding another opcode for "refunds" as he notes. Cheers, Greg On Mon, Mar 6, 2023 at 10:25=E2=80=AFAM James O'Beirne wrote: > I'm glad to see that Greg and AJ are forming a habit of hammering > this proposal into shape. Nice work fellas. > > To summarize: > > What Greg is proposing above is to in essence TLUV-ify this proposal. > > I.e. instead of relying on hashed commitments and recursive script > execution (e.g. + later presentation of preimage > script for execution), OP_VAULT would instead move through its > withdrawal process by swapping out tapleaf contents according to > specialized rules. If this is opaque (as it was to me), don't fret - > I'll describe it below in the "mechanics" section. > > > The benefits of this TLUVification are > > - we can avoid any nested/recursive script execution. I know the > recursive stuff rankles some greybeards even in spite of it being > bounded to a single call. I'm not sure I share the concern but > maintaining the status quo seems good. > > - the spec is easier to reason about, more or less. The opcodes > introduced don't have variadic witness requirements, and each opcode > is only consumed in a single way. > > - there's less general indirection. Instead of saying "okay, here's the > hash of the script I'm going to use to authorize trigger > transactions," we're just outright including the trigger auth script > in the tapleaf at the birth of the vault as regular 'ol script that is > evaluated before execution of the OP_VAULT instruction. > > Similarly, instead of relying on an implicit rule that an OP_VAULT can > be claimed by a recovery flow, we're relying on a specific tapleaf that > facilitates that recovery with OP_VAULT_RECOVER, described below. > > Basically, OP_VAULT would just be implemented in a way that feels > more native to Taproot primitives. > > Greg also introduces different opcodes to facilitate consistent > witness structure, rather than the variable ones we have now > since OP_VAULT and OP_UNVAULT can each be spent in two different > contexts. I've changed those a little here; instead of the three general > ones Greg gave, we whittled it down to two: OP_VAULT and > OP_VAULT_RECOVER. > > > So I think that, barring significant implementation complexity - which > I'll find out about soon and don't expect - this is a good change to the > proposal. As Greg noted, it doesn't really change anything about the > usage or expressiveness... other than the fact that, as a bonus, it > might allow an optional withdrawal authorization script (i.e. trigger > output =3D> final target), which could be useful if e.g. some kind of > size-limiting opcode (e.g. OP_TX_MAXSIZE or something) came around in > the future as a kind of pinning fix. > > If that last bit lost you, don't worry - that is speculative, but the > point is that this rework composes well with other stuff. > > > # CTV use > > Another thing that has dawned on us is that we might as well just reuse > OP_CHECKTEMPLATEVERIFY for withdrawal target spends. Ben Carmen and > others realized early on that you can synthesize CTV-like behavior by > spending to a 0-delay OP_UNVAULT output, so something CTVish has always > implicitly been a part of the proposal. But CTV is better studied and > basically as simple as the OP_UNVAULT spend semantics, so the thought is > that we might as well reuse all the existing work (and scrutiny) from > CTV. > > As a concrete example, an issue with the existing proposal is that the > existing CTVish OP_UNVAULT behavior has txid malleability, since it > doesn't commit to nVersion or nLockTime or the input sequences. Using > CTV solves this issue. Otherwise we'd basically reinvent it - "something > something convergent evolution." > > I think this is a satisfying development, because there's clearly demand > for CTV use in other contexts (DLC efficiency, e.g.), and if it's > required behavior for practical vaults, I think pulling in the existing > BIP-119 that's been worked over for years reduces the conceptual > surface area added by OP_VAULT. > > > # New mechanics of the proposal > > So here I'm going to describe my rendering of Greg and AJ's suggestions. > > > ## Required opcodes > > - OP_VAULT: spent to trigger withdrawal > - OP_VAULT_RECOVER: spent to recover > - OP_CHECKTEMPLATEVERIFY: spent into final withdrawal target > > > Creating an initial deposit > --------------------------- > > For each vault, vaulted coins are spent to an output with the taproot > structure > > taproot(internal_key, {$recovery_leaf, $trigger_leaf, ...}) > > where > > internal_key =3D > unchanged from original proposal (some very safe recovery key) > > $recovery_leaf =3D > [ ] OP_VAULT_RECOVER > > $trigger_leaf =3D >