path: root/b6/7908e1e28c767778feb377bd9945d8695473e7

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 05D3CC0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Jun 2023 00:23:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id CE06F60ADD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Jun 2023 00:23:49 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org CE06F60ADD
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=MtABtfIQ
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id gpP7eoBSHbcd
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Jun 2023 00:23:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7876760AC4
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com
 [IPv6:2607:f8b0:4864:20::d2f])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 7876760AC4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Jun 2023 00:23:48 +0000 (UTC)
Received: by mail-io1-xd2f.google.com with SMTP id
 ca18e2360f4ac-777a4926555so73767139f.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 09 Jun 2023 17:23:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1686356627; x=1688948627;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=uFukvdjNDflCh2FV45l1eWjbNDh40MY1dXAUeF1LRHI=;
 b=MtABtfIQ9tccEUwATp6pzlmPZFj2i1+3EHmbp3pytFmJj6L/QbgoOXmcI6fq2ARI2n
 Bj35SRjF9vhegmcU4liukDh6oC+jX3rsabJ/MgbmAAVMW9uomdmbFV7PsbAVjwWfp0I3
 HulXsTMrbg9ZlN0EZKg7DJX+maG3kkqzlfO22JRP70U9CJ9t6GkwwXarAJvvYU95vC1v
 BixCy80jAEEN97pSce+TJq6lSaqIzwo7lTv1c2xuztuMfR9Pp1Vwt9jAWhboyL7rOLaN
 t7cG+m1Q3gi6zpwL2LuG8QhjN3HGE5OjrptzMyzw5KD86qfiEI+SM8XEMEUJ6lldDACS
 /XCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1686356627; x=1688948627;
 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=uFukvdjNDflCh2FV45l1eWjbNDh40MY1dXAUeF1LRHI=;
 b=hrpSU9RvLy+9W4T2oo8Nh/pCwdoedIzl+90suMZThFVh9UtdEQcKF7m9BDRxq/Wz2c
 bNNJPJals3CJzFws2a7TISuyInz1268MerBj+G7F3ZhA2bpcXwg/kQXRc/d4v8hoEMFS
 LHYRJmFyotj3/1crr/c68wH4b6q5bGrqm6EvWuzsIMCtBdqgHS7Js2lG74OiLcRjXUT/
 kvZGB11whdECB9UdpOR/DsET73aqk8vGNQ1vVDe4ISzhnk8YRNMyLfvzNu3SmAGC3nLG
 aKyIILpOobL7eJFh8tz/KEbp/bDEXjooliCa7G/ZFc34/wNnZDsuZcPxVoygDS2u55cV
 oqcw==
X-Gm-Message-State: AC+VfDyooTLeLlekvEK8BS0ZBcqjy3vQmvPi8PKch9Vnw2Z4qjLpTQ4K
 gv3yrfFgzgjYCk9lGHZATLELkwcC/wpET54b13g=
X-Google-Smtp-Source: ACHHUZ4X+7YYjfnWXtB4QZQK/Od9YiE62pTfn1w3M8sANWJ7FrMi+Za4dErSVh6XzY9hc+ZGU9Q+NVR/P/BkBPV93Ys=
X-Received: by 2002:a05:6602:2770:b0:774:7b02:39ac with SMTP id
 l16-20020a056602277000b007747b0239acmr5268503ioe.6.1686356627326; Fri, 09 Jun
 2023 17:23:47 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
In-Reply-To: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sat, 10 Jun 2023 01:23:36 +0100
Message-ID: <CALZpt+FyVQpMAf-gPmUgh6ORqa2K59iKZKsa3Qm2Fw_U+GHC3Q@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bc896205fdbb7fc3"
X-Mailman-Approved-At: Sat, 10 Jun 2023 00:55:59 +0000
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: Sat, 10 Jun 2023 00:23:50 -0000

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

Hi Joost,

Thanks for detailing why a '0' as free-form, without any additional
constraints offers valuable engineering properties as of today.

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 thinking
about ? As raised on the BIP proposal, those unstructured data use-cases
could use annex tags with the benefit to combine multiple "types" of
unstructured data in a single annex payload. As you're raising smaller bits
of unstructured data might not afford the overhead though my answer with
this observation would be to move this traffic towards some L2 systems ? In
my mind, the default of adding a version byte for the usage of unstructured
data comes with the downside of having future consensus enabled use-cases
encumbering by the extended witness economic cost.

About the annex payload extension attack described by Greg. If my
understanding of this transaction-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 transaction, 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 could benefit unstructured
data use-cases too.

Best,
Antoine

Le ven. 2 juin 2023 =C3=A0 22:18, Joost Jager via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> Hi,
>
> As it stands, the taproot annex is consensus valid but non-standard. The
> conversations around standardization seem to be leaning towards the
> adoption of a flexible Type-Length-Value (TLV) format [1]. There's no dou=
bt
> that this approach has considerable potential. However, settling on an
> exact format may require a significant amount of time.
>
> In the interim, the benefits of making the annex available in a
> non-structured form are both evident and immediate. By allowing developer=
s
> to utilize the taproot annex without delay, we can take advantage of its
> features today, without the need to wait for the finalization of a more
> lengthy standardization process.
>
> With this in view, I am proposing that we define any annex that begins
> with '0' as free-form, without any additional constraints. This strategy
> offers several distinct benefits:
>
> Immediate utilization: This opens the door for developers to make use of
> the taproot annex for a variety of applications straight away, thus
> eliminating the need to wait for the implementation of TLV or any other
> structured format.
>
> Future flexibility: Assigning '0'-beginning annexes as free-form keeps ou=
r
> options open for future developments and structure improvements. As we
> forge ahead in determining the best way to standardize the annex, this
> strategy ensures we do not limit ourselves by setting its structure in
> stone prematurely.
>
> Chainspace efficiency: Non-structured data may require fewer bytes
> compared to a probable TLV format, which would necessitate the encoding o=
f
> length even when there's only a single field.
>
> In conclusion, adopting this approach will immediately broaden the
> utilization scope of the taproot annex while preserving the possibility o=
f
> transitioning to a more structured format in the future. I believe this i=
s
> a pragmatic and efficient route, one that can yield substantial benefits =
in
> both the short and long term.
>
> Joost
>
> [1] https://github.com/bitcoin/bips/pull/1381
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi Joost,<div><br></div><div>Thanks for detailing why a &#=
39;0&#39; as free-form, without any additional constraints offers valuable =
engineering=C2=A0properties as of today.</div><div><br></div><div>From a ta=
proot annex design perspective, I think this could be very valuable if you =
have a list of unstructured=C2=A0data use-cases you&#39;re thinking about ?=
 As raised on the BIP proposal, those unstructured=C2=A0data use-cases coul=
d 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 smaller =
bits of unstructured data might not afford the overhead though my answer wi=
th this observation would be to move this traffic towards some L2 systems ?=
 In my mind, the default of adding a version byte for the usage of unstruct=
ured data comes with the downside of having future consensus enabled use-ca=
ses encumbering by the extended witness economic cost.</div><div><br></div>=
<div>About=C2=A0the annex payload extension attack described by Greg. If my=
 understanding of this transaction-relay jamming griefing issue is correct,=
 we can have an annex tag in the future where the signer is committing to t=
he total weight of the transaction, or even the max per-input annex size ? =
This should prevent a coinjoin or aggregated commitment transaction counter=
party to inflate its annex space to downgrade the overall transaction feera=
te, I guess. And I think this could benefit unstructured data use-cases too=
.</div><div><br></div><div>Best,</div><div>Antoine</div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 2 juin=
 2023 =C3=A0=C2=A022:18, Joost Jager via bitcoin-dev &lt;<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:sol=
id;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi=
,<br><br>As it stands, the taproot annex is consensus valid but non-standar=
d. The conversations around standardization seem to be leaning towards the =
adoption of a flexible Type-Length-Value (TLV) format [1]. There&#39;s no d=
oubt that this approach has considerable potential. However, settling on an=
 exact format may require a significant amount of time.<br><br>In the inter=
im, the benefits of making the annex available in a non-structured form are=
 both evident and immediate. By allowing developers to utilize the taproot =
annex without delay, we can take advantage of its features today, without t=
he need to wait for the finalization of a more lengthy standardization proc=
ess.<br><br>With this in view, I am proposing that we define any annex that=
 begins with &#39;0&#39; as free-form, without any additional constraints. =
This strategy offers several distinct benefits:<br><br>Immediate utilizatio=
n: This opens the door for developers to make use of the taproot annex for =
a variety of applications straight away, thus eliminating the need to wait =
for the implementation of TLV or any other structured format.<br><br>Future=
 flexibility: Assigning &#39;0&#39;-beginning annexes as free-form keeps ou=
r options open for future developments and structure improvements. As we fo=
rge ahead in determining the best way to standardize the annex, this strate=
gy ensures we do not limit ourselves by setting its structure in stone prem=
aturely.<br><br>Chainspace efficiency: Non-structured data may require fewe=
r bytes compared to a probable TLV format, which would necessitate the enco=
ding of length even when there&#39;s only a single field. <br><br>In conclu=
sion, adopting this approach will immediately broaden the utilization scope=
 of the taproot annex while preserving the possibility of transitioning to =
a more structured format in the future. I believe this is a pragmatic and e=
fficient route, one that can yield substantial benefits in both the short a=
nd long term.<br><br>Joost<br><br>[1] <a href=3D"https://github.com/bitcoin=
/bips/pull/1381" target=3D"_blank">https://github.com/bitcoin/bips/pull/138=
1</a></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>

--000000000000bc896205fdbb7fc3--