Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 63C17C0029 for ; Sat, 3 Jun 2023 07:50:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3E6F3844B4 for ; Sat, 3 Jun 2023 07:50:16 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3E6F3844B4 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=sIcbOkHQ 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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdyipzRSzhhQ for ; Sat, 3 Jun 2023 07:50:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org F2E70844AC Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by smtp1.osuosl.org (Postfix) with ESMTPS id F2E70844AC for ; Sat, 3 Jun 2023 07:50:14 +0000 (UTC) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-9768fd99c0cso164653466b.0 for ; Sat, 03 Jun 2023 00:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685778612; x=1688370612; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=p+PNlPBs9GTQ2LTa+q4SamwEYydRRQboImkOTMl9Hxs=; b=sIcbOkHQSSEiGIWRdpFz8AUXTs+wsj0xob70gMGGzXhKaJiBi4/ZPKQRvsJT8e1Yrr sYAb0fN/SaSUdE5iO7/Yk+gifxonkuqDEadQe9ahD6GUTakzQ6oKaEn9YwrgG5Gr5xNF IGDEHdBLOsMLmBNQmdUeZK1i9OuXKMz8b37DFDYH3g1BiKA6WZhDLpEl3fjeoyqpF6z3 crcgvRV0xZppwfmBwRYh62prJb/DXn2UChFaBUCPjBxbpEhV5xUe4dsoemhvrEspYgIe LjnxLST9xMTjV9zXTTQ75Nw8u7szae8TwA/orgNmei82ouEr/ri074odGczWrjPo3rYe wMHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685778612; x=1688370612; 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=p+PNlPBs9GTQ2LTa+q4SamwEYydRRQboImkOTMl9Hxs=; b=fzDCJ8aqIMKHIkqWsxCSdUlLeFrHYZ7x+3gvr+a0s0IwJngQswvwQdDKcOpK2VdX88 e3lBlxcMqy9PUNHItkMN06H6Zj7ifN4NV5bL5VQyzr7ldsYtWE+HBE5BzdjV/FXpFYsT RKG3brSzUQLcMmapFLErSzN2UHOn5zA5e+SHr7As1v/KtKzYhobT8m6iLSmlDjfx2xRJ hJ9aKr+Eko6j3fUPDf6XKOXNEQ09bXWH4wlKR4Ooud1DjFNRyJ2a2Lix7ct95OWVmZRY etz+akO2B+nNeeNG3+62sFYlq/1hGH2TM6zOQufgaycQJs8iOEILoUeXtSqjq+fOJaOi UC2Q== X-Gm-Message-State: AC+VfDzsx3V06CHki5kho6kVQBDjmw8dmiyNQSAsjIZu6rGXdHQoCzf1 Sy27o5XKkUryAdyyNJCFel6/N+rN+h8Rxvs09+I= X-Google-Smtp-Source: ACHHUZ607kz2bNKJjMhviOOEiRILEjzZbPvkSSYEbtG5j6iebQ+VSstSXVJzn31O9wV//6itucXtwEqeI25SSPH/qk0= X-Received: by 2002:a17:907:9623:b0:96f:7636:65ca with SMTP id gb35-20020a170907962300b0096f763665camr833769ejc.3.1685778612402; Sat, 03 Jun 2023 00:50:12 -0700 (PDT) MIME-Version: 1.0 References: <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org> In-Reply-To: <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org> From: Joost Jager Date: Sat, 3 Jun 2023 09:49:36 +0200 Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="0000000000005cc11b05fd34ebfd" X-Mailman-Approved-At: Sat, 03 Jun 2023 07:53:59 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex 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: Sat, 03 Jun 2023 07:50:16 -0000 --0000000000005cc11b05fd34ebfd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi David, On Sat, Jun 3, 2023 at 3:08=E2=80=AFAM David A. Harding wro= te: > Out of curiosity, what features and benefits are available today? I > know Greg Sanders wants to use annex data with LN-Symmetry[1], but > that's dependent on a soft fork of SIGHASH_ANYPREVOUT. I also heard you > mention that it could allow putting arbitrary data into a witness > without having to commit to that data beforehand, but that would only > increase the efficiency of witness stuffing like ordinal inscriptions by > only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be > required to create an output in order to spend it. > Indeed, there's a minor efficiency gain in the reveal transaction witness, but I think the real advantage is that it eliminates the need to publish and pay for the commit transaction in the first place. Any spend of a taproot UTXO can be supplemented with arbitrary data in just a single transaction. > Is there some other way to use the annex today that would be beneficial > to users of Bitcoin? The removal of the need for a commitment transaction also enables the inclusion of data within a single transaction that relies on its own transaction identifier (txid). This is possible because the txid calculation does not incorporate the annex, where the data would be housed. This feature can be beneficial in scenarios that require the emulation of covenants through the use of presigned transactions involving an ephemeral signer. For instance, one can establish a time-locked vault using 2-of-2 multisig presigned transactions in which one of the signers is ephemeral [1]. After signing, the private key is discarded, leaving only the signature. To ensure the signature is never lost, it can be stored as a backup in the annex of the transaction that the presigned transaction spends. Such an operation would not be possible with a commit/reveal inscription. [1] https://github.com/LedgerHQ/app-bitcoin-new/issues/153 --0000000000005cc11b05fd34ebfd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,

On Sat, Jun 3, 2023 at 3:08=E2=80=AFAM David= A. Harding <dave@dtrt.org> wrot= e:
Out of curiosity, what features and benefits are available today?=C2=A0 I <= br> know Greg Sanders wants to use annex data with LN-Symmetry[1], but
that's dependent on a soft fork of SIGHASH_ANYPREVOUT.=C2=A0 I also hea= rd you
mention that it could allow putting arbitrary data into a witness
without having to commit to that data beforehand, but that would only
increase the efficiency of witness stuffing like ordinal inscriptions by only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be
required to create an output in order to spend it.
Indeed, there's a minor efficiency gain in the reveal trans= action witness, but I think the real advantage is that it eliminates the ne= ed to publish and pay for the commit transaction in the first place. Any sp= end of a taproot UTXO can be supplemented with arbitrary data in just a sin= gle transaction.
=C2=A0
Is there some other way to use the annex today that would be beneficial to users of Bitcoin?

The removal of the nee= d for a commitment transaction also enables the inclusion of data within a = single transaction that relies on its own transaction identifier (txid). Th= is is possible because the txid calculation does not incorporate the annex,= where the data would be housed. This feature can be beneficial in scenario= s that require the emulation of covenants through the use of presigned tran= sactions involving an ephemeral signer.

For instance, one can establ= ish a time-locked vault using 2-of-2 multisig presigned transactions in whi= ch one of the signers is ephemeral=C2=A0[1]. After signing, the private key= is discarded, leaving only the signature. To ensure the signature is never= lost, it can be stored as a backup in the annex of the transaction that th= e presigned transaction spends. Such an operation would not be possible wit= h a commit/reveal inscription.

--0000000000005cc11b05fd34ebfd--