path: root/f0/0d9531564f5e043b49645353be8dd8dfe301c6

Return-Path: <gsanders87@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 54C24C0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Jun 2023 13:04:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 2F7DB404B4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Jun 2023 13:04:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2F7DB404B4
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=SXDXy8fo
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 0DBDOSagL-bR
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Jun 2023 13:04:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8B19040462
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [IPv6:2a00:1450:4864:20::530])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 8B19040462
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Jun 2023 13:04:00 +0000 (UTC)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-510d6b939bfso7687503a12.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Jun 2023 06:04:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1686575038; x=1689167038;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=5Zx2fg3LAkjFMieA3ilVOWgo+0h6ajdvVzK0mFxMDnQ=;
 b=SXDXy8foxkGmi04l9HXRdC4+1ItXfxDwY4uGPiXiufI1jbgFLEhbtaMVMHWYsMId+O
 mA0qWmB+OVopGtapQYDpTpUVUyEniV4oOa8oqzxeQAhI3Quq7BtfqtSNueiRgsP2sYth
 ZkI3QhM4pV3h7xQYD6/8s0YCjR4LvLxbx/jkWyQ8Q7fqf1WDtbQETOqEWXacENNuE2pE
 hVXmcXbrseq31dulT+48ijlh/RvJlGlrzwcN6RRGMuOA20hF2lHc8GeGSWiXve3vWDVy
 LkSRo5+bVU/FQUPC8X5eyJDJPk114afkuTpyBMHSvAA4LPxcsjUrMTr8n9+1x2BZPKgO
 EvNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1686575038; x=1689167038;
 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=5Zx2fg3LAkjFMieA3ilVOWgo+0h6ajdvVzK0mFxMDnQ=;
 b=S/WB4JXyrfc5XHRo8E7VPJ7H6W8w/CCnEmihPeVNY+DL2pV/F9hQG0uzW+n298TaIE
 IuUfXHx+21u2sTVuSHggHNscf4TPUSM07BKgy7cBZI3MmoBPBjS+8sfddO3FHgfPbzjb
 En/EeUYGuFiJ+wO0R4YX6Y0EzCX5cAResL2PU3BDVUyNH8IK48zsS/o/R/L8pvCzOVre
 hn0BB8H1u+hr9dxK39ebTiCYUtkMdGGwBKNSC2WKwpNcO8+YaQ4Rjq3GCWAYiNJV0gl4
 0TjLlzVfBoRNhgJ6xMt5fIRv8rH6hZpm8Bpksnj9owM8O9chS27AhYoRj6AQccXtrZQW
 CECQ==
X-Gm-Message-State: AC+VfDySncwzV+baZTFJ7Spxu2bkV8r1Zhx9NJemPRICmlLI33zGZcw+
 zHRZ+Jp7jWdZCG1d0TODGuWZ4S0v9grWwhemVwo=
X-Google-Smtp-Source: ACHHUZ4cuUpg0SzkLoBhF4LApd3C/Abw8pT3WomJ59pEQr4oKyhin0kXHPhQh8g8kb/DCuv+KLL4XVSxoyPSwdWHBQc=
X-Received: by 2002:a17:907:928a:b0:973:940e:a01d with SMTP id
 bw10-20020a170907928a00b00973940ea01dmr11097633ejc.67.1686575038272; Mon, 12
 Jun 2023 06:03:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <CALZpt+FyVQpMAf-gPmUgh6ORqa2K59iKZKsa3Qm2Fw_U+GHC3Q@mail.gmail.com>
 <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
In-Reply-To: <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Mon, 12 Jun 2023 09:03:47 -0400
Message-ID: <CAB3F3Ds4aZ7fqqNUBGW3vzvUhsJ7ABvbGaAaEhWimyLosxwVmg@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000b182c05fdee5aaa"
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 <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: Mon, 12 Jun 2023 13:04:02 -0000

--0000000000000b182c05fdee5aaa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Regarding the potential payload extension attack, I believe that the
changes proposed in the [3] to allow tx replacement by smaller witness
would provide a viable solution?

The only plausible case I could see moving forward is replacing the
transaction to a form that has *no* annex or scriptpath spends, ala
https://github.com/bitcoin/bitcoin/pull/24007#issuecomment-1308104119 .
It's much easier to think about one-off replacements from an anti-DoS
perspective.

We would have to think a lot harder if that actually solves the problem and
maintains the prospective use-cases before diving into analysis, regardless=
.

Cheers,
Greg


On Sat, Jun 10, 2023 at 5:02=E2=80=AFAM Joost Jager via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Antoine,
>
> On Sat, Jun 10, 2023 at 2:23=E2=80=AFAM Antoine Riard <antoine.riard@gmai=
l.com>
> wrote:
>
>> From a taproot annex design perspective, I think this could be very
>> valuable if you have a list of unstructured data use-cases you're thinki=
ng
>> about ?
>>
>
> The annex's list of unstructured data use-cases includes existing data
> storage uses that utilize OP_RETURN or inscriptions. Consider ordinals,
> timestamps, and any other data already stored on the chain. These
> applications would immediately benefit from the annex's improved space
> efficiency.
>
> However, the primary advantage I see in the annex is that its data isn't
> included in the calculation of the txid or a potential parent commit
> transaction's txid (for inscriptions). I've explained this at [1]. This
> feature makes the annex a powerful tool for applications that would ideal=
ly
> use covenants.
>
> The most critical application in this category, for me, involves
> time-locked vaults. Given the positive reception to proposals such as
> OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probabl=
y
> a bit further out, but pre-signed transactions signed using an ephemeral
> key can fill the gap and improve the safeguarding of Bitcoin in the short
> term.
>
> Backing up the ephemeral signatures of the pre-signed transactions on the
> blockchain itself is an excellent way to ensure that the vault can always
> be 'opened'. However, without the annex, this is not as safe as it could
> be. Due to the described circular reference problem, the vault creation a=
nd
> signature backup can't be executed in one atomic operation. For example,
> you can store the backup in a child commit/reveal transaction set, but th=
e
> vault itself can be confirmed independently and the backup may never
> confirm. If you create a vault and lose the ephemeral signatures, the fun=
ds
> will be lost.
>
> This use case for the annex has been labeled 'speculative' elsewhere. To
> me, every use case appears speculative at this point because the annex
> isn't available. However, if you believe that time-locked vaults are
> important for Bitcoin and also acknowledge that soft forks, such as the o=
ne
> required for OP_VAULT, aren't easy to implement, I'd argue that the
> intermediate solution described above is very relevant.
>
>
>> As raised on the BIP proposal, those unstructured data use-cases could
>> use annex tags with the benefit to combine multiple "types" of unstructu=
red
>> data in a single annex payload. As you're raising smaller bits of
>> unstructured data might not afford the overhead though my answer with th=
is
>> observation would be to move this traffic towards some L2 systems ? In m=
y
>> mind, the default of adding a version byte for the usage of unstructured
>> data comes with the downside of having future consensus enabled use-case=
s
>> encumbering by the extended witness economic cost.
>>
>
> When it comes to the trade-offs associated with various encodings, I full=
y
> acknowledge their existence. The primary motivation behind my proposal to
> adopt a simple approach to the Taproot annex is to avoid a potentially lo=
ng
> standardization process. While I am not entirely familiar with the
> decision-making process of Bitcoin Core, my experience with other project=
s
> suggests that simpler changes often encounter less resistance and can be
> implemented more swiftly. Perhaps I am being overly cautious here, though=
.
>
>
>> About the annex payload extension attack described by Greg. If my
>> understanding of this transaction-relay jamming griefing issue is correc=
t,
>> we can have an annex tag in the future where the signer is committing to
>> the total weight of the transaction, or even the max per-input annex siz=
e ?
>> This should prevent a coinjoin or aggregated commitment transaction
>> counterparty to inflate its annex space to downgrade the overall
>> transaction feerate, I guess. And I think this could benefit unstructure=
d
>> data use-cases too.
>>
>
> Regarding the potential payload extension attack, I believe that the
> changes proposed in the [3] to allow tx replacement by smaller witness
> would provide a viable solution?
>
> Joost
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021737.=
html
> [2] https://github.com/bitcoin/bips/pull/1421
> [3] https://github.com/bitcoin/bitcoin/pull/24007
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000000b182c05fdee5aaa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; Regarding the potential payload extension attack, I b=
elieve that the changes proposed in the [3] to allow tx replacement by smal=
ler witness would provide a viable solution?=C2=A0<div><br></div><div>The o=
nly plausible case I could see moving forward is replacing the transaction =
to a form that has *no* annex or scriptpath spends, ala <a href=3D"https://=
github.com/bitcoin/bitcoin/pull/24007#issuecomment-1308104119">https://gith=
ub.com/bitcoin/bitcoin/pull/24007#issuecomment-1308104119</a> . It&#39;s mu=
ch easier to think about one-off replacements from an anti-DoS perspective.=
=C2=A0</div><div><br></div><div>We would have to think a lot harder if that=
 actually solves the problem and maintains the prospective use-cases before=
 diving into analysis, regardless.</div><div><br></div><div>Cheers,</div><d=
iv>Greg</div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sat, Jun 10, 2023 at 5:02=E2=80=AFAM Joost=
 Jager via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Anto=
ine,</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Sat, Jun 10, 2023 at 2:23=E2=80=AFAM Antoine Riard &lt;<a href=3D"ma=
ilto:antoine.riard@gmail.com" target=3D"_blank">antoine.riard@gmail.com</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr"><div>From a taproot annex design perspective, I think this cou=
ld be very valuable if you have a list of unstructured=C2=A0data use-cases =
you&#39;re thinking about ? </div></div></blockquote><div><br></div>The ann=
ex&#39;s list of unstructured data use-cases includes existing data storage=
 uses that utilize OP_RETURN or inscriptions. Consider ordinals, timestamps=
, and any other data already stored on the chain. These applications would =
immediately benefit from the annex&#39;s improved space efficiency.</div><d=
iv class=3D"gmail_quote"><br>However, the primary advantage I see in the an=
nex is that its data isn&#39;t included in the calculation of the txid or a=
 potential parent commit transaction&#39;s txid (for inscriptions). I&#39;v=
e explained this at [1]. This feature makes the annex a powerful tool for a=
pplications that would ideally use covenants.<br><br>The most critical appl=
ication in this category, for me, involves time-locked vaults. Given the po=
sitive reception to proposals such as OP_VAULT [2], I don&#39;t think I&#39=
;m alone in this belief. OP_VAULT is probably a bit further out, but pre-si=
gned transactions signed using an ephemeral key can fill the gap and improv=
e the safeguarding of Bitcoin in the short term.<br><br>Backing up the ephe=
meral signatures of the pre-signed transactions on the blockchain itself is=
 an excellent way to ensure that the vault can always be &#39;opened&#39;. =
However, without the annex, this is not as safe as it could be. Due to the =
described circular reference problem, the vault creation and signature back=
up can&#39;t be executed in one atomic operation. For example, you can stor=
e the backup in a child commit/reveal transaction set, but the vault itself=
 can be confirmed independently and the backup may never confirm. If you cr=
eate a vault and lose the ephemeral signatures, the funds will be lost.<br>=
<br>This use case for the annex has been labeled &#39;speculative&#39; else=
where. To me, every use case appears speculative at this point because the =
annex isn&#39;t available. However, if you believe that time-locked vaults =
are important for Bitcoin and also acknowledge that soft forks, such as the=
 one required for OP_VAULT, aren&#39;t easy to implement, I&#39;d argue tha=
t the intermediate solution described above is very relevant.<br><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div>As raised on the BIP proposal, those unstructured=C2=A0data use-cases=
 could use annex tags with the benefit to combine multiple &quot;types&quot=
; of unstructured data in a single annex payload. As you&#39;re raising sma=
ller bits of unstructured data might not afford the overhead though my answ=
er with this observation would be to move this traffic towards some L2 syst=
ems ? In my mind, the default of adding a version byte for the usage of uns=
tructured data comes with the downside of having future consensus enabled u=
se-cases encumbering by the extended witness economic cost.</div></div></bl=
ockquote><div><br></div><div>When it comes to the trade-offs associated wit=
h various encodings, I fully acknowledge their existence.=C2=A0The primary =
motivation behind my proposal to adopt a simple approach to the Taproot ann=
ex is to avoid a potentially long standardization process. While I am not e=
ntirely familiar with the decision-making process of Bitcoin Core, my exper=
ience with other projects suggests that simpler changes often encounter les=
s resistance and can be implemented more swiftly. Perhaps I am being overly=
 cautious here, though.<br></div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div>About=C2=A0the annex payload=
 extension attack described by Greg. If my understanding of this transactio=
n-relay jamming griefing issue is correct, we can have an annex tag in the =
future where the signer is committing to the total weight of the transactio=
n, or even the max per-input annex size ? This should prevent a coinjoin or=
 aggregated commitment transaction counterparty to inflate its annex space =
to downgrade the overall transaction feerate, I guess. And I think this cou=
ld benefit unstructured data use-cases too.</div></div></blockquote><div><b=
r></div>Regarding the potential payload extension attack, I believe that th=
e changes proposed in the [3] to allow tx replacement by smaller witness wo=
uld provide a viable solution?=C2=A0<br><div>=C2=A0</div><div>Joost</div><d=
iv><br></div><div>[1] <a href=3D"https://lists.linuxfoundation.org/pipermai=
l/bitcoin-dev/2023-June/021737.html" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2023-June/021737.html</a></div><div>[2]=
=C2=A0<a href=3D"https://github.com/bitcoin/bips/pull/1421" target=3D"_blan=
k">https://github.com/bitcoin/bips/pull/1421</a></div><div>[3]=C2=A0<a href=
=3D"https://github.com/bitcoin/bitcoin/pull/24007" target=3D"_blank">https:=
//github.com/bitcoin/bitcoin/pull/24007</a></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000000b182c05fdee5aaa--