Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6482FC0029 for ; Mon, 12 Jun 2023 03:17:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 2B1A0400C7 for ; Mon, 12 Jun 2023 03:17:00 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2B1A0400C7 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=mr0Z047m 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4e8bW8ieSjs for ; Mon, 12 Jun 2023 03:16:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EB05B400A6 Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) by smtp2.osuosl.org (Postfix) with ESMTPS id EB05B400A6 for ; Mon, 12 Jun 2023 03:16:56 +0000 (UTC) Received: by mail-il1-x136.google.com with SMTP id e9e14a558f8ab-33aa60f4094so14884105ab.1 for ; Sun, 11 Jun 2023 20:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686539816; x=1689131816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+k8k8ZNhjsgq3nAyaUqDFQp8q2Mmn3dQD9A3685nnhs=; b=mr0Z047mjVJ/kPetQvEuoJEF1B3qP1K6UGCsbRzWEEhHI3zME4o25HZXEbZyVRykgY D2sK1mZVxIv8LOwt4MxKOs5ME8Dk1yxssu9RlVXGWbAw8VaUNUgGtyUrW4wkurzYQPvt rU2OOi8dL7curEFHast5uSkbZ8FhxI/K1kdmUQxXrRDR8z8yuuY2hCM7i/t3fWCeK+WS RyGl+5hKT0vcCeSuAFFqEEwzeah8EwSBO1ltDQ74Lk1q9KaHG7MPT/RQumGvYiclSxOI hFwTaJGltr9wsozVaTAdLEYN23xU5Qh21+VgLzZNhmsAI1JHCvzBvyxAvh8zxfhQTN29 vzCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686539816; x=1689131816; 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=+k8k8ZNhjsgq3nAyaUqDFQp8q2Mmn3dQD9A3685nnhs=; b=Wnu3wFwWpL5G7BEH8Ob4V8sRko++4Y5iwkgAo1fg4TAjJBDu+X5vZGYYym6Udm542R KGu8rFPv9MJMTfkai7MqMNCBr9iatp/DHLpuIREl/W9HeFMWrtdywop8j54kAWb4yRIX agGvogMIkT6CGTX286iA5iKs5bsSkh+1B6ngM1u6xiTqjjddGHrnZx8bHSF78dbUJS0d lmsMOtZU3ho0LbMxy1bB6/Nm+yrCBi8tg46OfgaxH+c3vXQ7iWPAobhH7MldYAlN0Z05 0dOo3vKHETpiWvukeDFMcdRmf2W6At19EJShh4arSXGJJYpTGrSyCgBeF0AE37jrRBBj 92hA== X-Gm-Message-State: AC+VfDz3EMYDTuubbAsCI3rTSNfn5ih+r+nO0IVslUmRqirdYOYDRAHv mGTPaCgkc6VZqfns2Asio9UwAlH1gdt15OAqLGJX5HSL+/1o5w== X-Google-Smtp-Source: ACHHUZ7/pEZz0ki9UqHcqGA0srupYYeEgJMt6FCF6Gsgx6OHf19No4dbghLtCU/ayfhpPI+gB0GJWzB5DMtCOHzmD6A= X-Received: by 2002:a05:6e02:12e2:b0:334:fa57:e670 with SMTP id l2-20020a056e0212e200b00334fa57e670mr8654257iln.0.1686539815653; Sun, 11 Jun 2023 20:16:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Mon, 12 Jun 2023 04:16:44 +0100 Message-ID: To: Joost Jager Content-Type: multipart/alternative; boundary="0000000000009c975405fde6267a" X-Mailman-Approved-At: Mon, 12 Jun 2023 09:41:00 +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: Mon, 12 Jun 2023 03:17:00 -0000 --0000000000009c975405fde6267a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joost, > 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 ideally use covenants. I share the observation that the annex data not being committed in the parent txid is very powerful for use-cases that would use covenants. E.g there could be an alternative design of CoinPool based on Grafroot, where the signed surrogate scripts authorized withdrawal abilities [0]. Once consumed the signed surrogate shouldn't be replayable against the clawback pool output, and the signature of the surrogate added as "toxic" in a cryptographic accumulator. Efficient set test membership can be realized to refuse pool output spend attempts with consumed surrogate scripts. The annex is a perfect emplacement to locate such an accumulator in the future as the state of the accumulator cannot be predicted as pool setup time and is a function of the effective order withdrawal. Note with Taproot-based design, the replay protection is achieved by the removal from the taproot tree as edited by any contracting primitive during the withdrawal phase (e.g TLUV). > When it comes to the trade-offs associated with various encodings, I fully acknowledge their existence. The primary motivation behind my proposal to adopt a simple approach to the Taproot annex is to > avoid a potentially long standardization process. While I am not entirely familiar with the decision-making process of Bitcoin Core, my experience with other projects suggests that simpler changes often > encounter less resistance and can be implemented more swiftly. Perhaps I am being overly cautious here, though. I fully understand the motivation to avoid a lengthy standardization process, which can be a source of frustration for everyone, including the standard champions themselves. Indeed, no one lacks the bureaucratic-style of standardization process for their own sake. Long standardization processes in Bitcoin consensus are better explained by the number of technical dimensions to weigh in terms of designs (e.g full-nodes ressources scalability, fee economic costs, confidentiality, composability with other changes). And due to the asynchronous nature of FOSS development, every domain expert is constantly jungling between different engineering contributions priorities (e.g for myself currently package relay and mempool for L2s). All that said, to make the conversation of annex standardization more practical, and aiming to compose with all technical interest expressed, I can think about a 2 phase process, at least. Such standardization process reflects only my opinion, and is based on the experience of recent mempool fullrbf partial deployment experience, the Core's trends to have tracking issues for substantial changes, bitcoin-inquisition and the bitcoin contracting primitives WG experiences. Phase 1: - a BIP proposal for the TLV records + code (almost done with #9 in bitcoin-inquisition and #1421 in the bips repository) - a BIP proposal to reserve "tag 0" for unstructured data + code (let's say in bitcoin-inquisition) - anti-DoS mempool/transaction-relay/replacement code (same) - bonus point: documenting the new mempool/replacement rules like in Core's `doc/policy` - preferential peering logic working code (there is already some code with Core's #25600) - opt-in activation of the annex validation rules - engage Bitcoin devs appreciated by the community as domain experts in the covered areas to collect more relevant technical feedbacks Phase 2: - submit the annex branch with all the features on the Bitcoin Core repository - communicate to the Bitcoin technical community at large the existence of the proposal e.g dev mail list, technical newsletters - communicate to the second-layers and unstructured data application maintainers the existence of the proposal - integrate the feedback from Bitcoin Core, Bitcoin users and second-layers communities in a "staging code branch" - if there is a deep technical objection, go back to phase 1 (e.g a competing serializing proposal for the annex) - otherwise, split the annex reference branch core in logical chunks for optimal review process This is what an efficient-yet-decentralized standardization process of the annex would look like to me, I don't know. About when we can expect a deployment of new policy rules for the annex, as Dave made me the (grounded) reprimand on the list a while back, I don't think mentioning a date or software version release is appropriate. And this to avoid creating a sense of commitment on all the contributors involved in the projects above mentioned. I'm still interested in championing the "base" TLV serialization annex code and BIP. To move faster, I think it would be better to have another champion on the "tag 0" and BIP, especially as the unstructured data use-cases are coming with their own specifics. > Regarding the potential payload extension attack, I believe that the changes proposed in the [3] to allow tx replacement by smaller witnesses would provide a viable solution? To be honest, in terms of DoS, I wouldn't give a strong opinion before better formalization or consensus of the use-case requirements. From experience of Core's mempools PRs, you have few subcomponents that can be involved (replacement, block template, broadcast backend of L2s, etc). > That years-long timeline that you sketch for witness replacement (or any other policy change I presume?) to become effective is perhaps indicative of the need to have an alternative way to relay > transactions to miners besides the p2p network? Assuming an alternative p2p network, I don't think we can avoid some standardization of fundamental data structures between those p2p network. Most of L2s are pre-signing transactions/packages and might not be able to alter the validity of such set of transactions in a unilateral fashion without re-introducing some =E2=80=9Cbad=E2=80=9D malleability. And a L2 no= de has an interest to use multiple p2p networks to mitigate against things like time-dilation attacks. Best, Antoine [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/01570= 0.html Le dim. 11 juin 2023 =C3=A0 20:26, Joost Jager a = =C3=A9crit : > Hi Dave, > > On Sun, Jun 11, 2023 at 12:10=E2=80=AFAM David A. Harding = wrote: > >> 3. When paying the script in #2, Alice chooses the scriptpath spend from >> #1 and pushes a serialized partial signature for the ephemeral key >> from #2 onto the stack, where it's immediately dropped by the >> interpreter (but is permanently stored on the block chain). She als= o >> attaches a regular signature for the OP_CHECKSIG opcode. >> > > Isn't it the case that that op-dropped partial signature for the ephemera= l > key isn't committed to and thus can be modified by anyone before it is > mined, effectively deleting the keys to the vault? If not, this would be = a > great alternative! > > Even better, I think you can achieve nearly the same safety without >> putting any data on the chain. All you need is a widely used >> decentralized protocol that allows anyone who can prove ownership of a >> UTXO to store some data. >> > > I appreciate the suggestion, but I am really looking for a bitcoin-native > solution to leverage bitcoin's robustness and security properties. > > By comparison, rolling >> out relay of the annex and witness replacement may take months of review >> and years for >90% deployment among nodes, would allow an attacker to >> lower the feerate of coinjoin-style transactions by up to 4.99%, would >> allow an attacker to waste 8 million bytes of bandwidth per relay node >> for the same cost they'd have to pay to today to waste 400 thousand >> bytes, and might limit the flexibility and efficiency of future >> consensus changes that want to use the annex. > > > That years-long timeline that you sketch for witness replacement (or any > other policy change I presume?) to become effective is perhaps indicative > of the need to have an alternative way to relay transactions to miners > besides the p2p network? > > I agree though that it would be ideal if there is a good solution that > doesn't require any protocol changes or upgrade path. > > Joost > --0000000000009c975405fde6267a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joost,

> However, the primary adv= antage I see in the annex is that its data isn't included in the calcul= ation 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 ideally use cov= enants.

I share the observation that the annex= data not being committed in the parent txid is very powerful for use-cases= that would use covenants. E.g there could be an alternative design of Coin= Pool based on Grafroot, where the signed surrogate scripts authorized withd= rawal abilities [0]. Once consumed the signed surrogate shouldn't be re= playable against the clawback pool output, and the signature of the surroga= te added as "toxic" in a cryptographic accumulator. Efficient set= test membership can be realized to refuse pool output spend attempts with = consumed surrogate scripts.

The annex is a perfect= emplacement to locate such an accumulator in the future as the state of th= e accumulator cannot be predicted as pool setup time and is a function of t= he effective order withdrawal.

Note with Taproot-b= ased design, the replay protection is achieved by the removal from the tapr= oot tree as edited by any contracting primitive during the withdrawal phase= (e.g TLUV).

> When it comes to the trade-offs = associated with various encodings, I fully acknowledge their existence.=C2= =A0The primary motivation behind my proposal to adopt a simple approach to = the Taproot annex is to
> avoid a potentially long standardiza= tion process. While I am not entirely familiar with the decision-making pro= cess of Bitcoin Core, my experience with other projects suggests that simpl= er changes often
> encounter less resistance and can be implem= ented more swiftly. Perhaps I am being overly cautious here, though.

I fully understand the motivation to avoid a lengthy= standardization process, which can be a source of frustration for everyone= , including the standard champions themselves. Indeed, no one lacks the bur= eaucratic-style of standardization process for their own sake.
Long standardization processes in Bitcoin consensus are better= explained by the number of technical dimensions to weigh in terms of desig= ns (e.g full-nodes ressources scalability, fee economic costs, confidential= ity, composability with other changes). And due to the asynchronous nature = of FOSS development, every domain expert is constantly jungling between dif= ferent engineering contributions priorities (e.g for myself currently packa= ge relay and mempool for L2s).

All that said, to m= ake the conversation of annex standardization more practical, and aiming to= compose with all technical interest expressed, I can think about a 2 phase= process, at least.

Such standardization process r= eflects only my opinion, and is based on the experience of recent mempool f= ullrbf partial deployment experience, the Core's trends to have trackin= g issues for substantial changes, bitcoin-inquisition and the bitcoin contr= acting primitives WG experiences.

Phase 1:
- a BIP proposal for the TLV records=C2=A0+ code (almost done with #9 in= bitcoin-inquisition and #1421 in the bips repository)
- a BIP pr= oposal to reserve "tag 0" for unstructured data=C2=A0+ code (let&= #39;s say in bitcoin-inquisition)
- anti-DoS mempool/transaction-= relay/replacement code (same)
- bonus point: documenting the new = mempool/replacement rules like in Core's `doc/policy`
- prefe= rential peering logic working code (there is already some code with Core= 9;s #25600)
- opt-in activation of the annex validation rules
- engage Bitcoin devs appreciated by the community as domain experts= in the covered areas to collect more relevant technical feedbacks

Phase 2:
- submit the annex branch with all the = features on the Bitcoin Core repository
- communicate to the Bitc= oin technical community at large the existence of the proposal e.g dev mail= list, technical newsletters
- communicate to the second-layers a= nd unstructured data application maintainers the existence of the proposal<= /div>
- integrate the feedback from Bitcoin Core, Bitcoin users and sec= ond-layers communities in a "staging code branch"
- if = there is a deep technical objection, go back to phase 1 (e.g a competing se= rializing proposal for the annex)
- otherwise, split the annex re= ference branch core in logical chunks for optimal review process
=
This is what an efficient-yet-decentralized standardization = process of the annex would look like to me, I don't know. About when we= can expect a deployment of new policy rules for the annex, as Dave made me= the (grounded) reprimand on the list a while back, I don't think menti= oning a date or software version release is appropriate. And this to avoid = creating a sense of commitment on all the contributors involved in the proj= ects above mentioned.

I'm still interested in = championing the "base" TLV serialization annex code and BIP. To m= ove faster, I think it would be better to have another champion on the &quo= t;tag 0" and BIP, especially as the unstructured data use-cases are co= ming with their own specifics.

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

To be honest, in terms of DoS, I wouldn't give a strong opinion befor= e better formalization or consensus of the use-case requirements. From expe= rience of Core's mempools PRs, you have few subcomponents that can be i= nvolved (replacement, block template, broadcast backend of L2s, etc).
=

> That years-long timeline that you sketch for witne= ss replacement (or any other policy change I presume?) to become effective = is perhaps indicative of the need to have an alternative way to relay
=
> transactions to miners besides the p2p network?
Assuming an alternative p2p network, I don't think we can a= void some standardization of fundamental data structures between those p2p = network. Most of L2s are pre-signing transactions/packages and might not be= able to alter the validity of such set of transactions in a unilateral fas= hion without re-introducing some =E2=80=9Cbad=E2=80=9D malleability. And a = L2 node has an interest to use multiple p2p networks to mitigate against th= ings like time-dilation attacks.

Best,
A= ntoine


Le=C2=A0dim. 11 juin 2023 =C3=A0=C2=A020:26, Joost Jager <joost.jager@gmail.com> a =C3=A9crit=C2= =A0:
Hi Dave,

On Sun, Jun 11= , 2023 at 12:10=E2=80=AFAM David A. Harding <dave@dtrt.org> wrote:
= 3. When paying the script in #2, Alice chooses the scriptpath spend from =C2=A0 =C2=A0 #1 and pushes a serialized partial signature for the ephemera= l key
=C2=A0 =C2=A0 from #2 onto the stack, where it's immediately dropped by= the
=C2=A0 =C2=A0 interpreter (but is permanently stored on the block chain).= =C2=A0 She also
=C2=A0 =C2=A0 attaches a regular signature for the OP_CHECKSIG opcode.
<= /blockquote>

Isn't it the case that that op-dropped = partial signature for the ephemeral key isn't committed to and thus can= be modified by anyone before it is mined, effectively deleting the keys to= the vault? If not, this would be a great alternative!

=
Even better, I think you can achieve nearly the same safety without
putting any data on the chain.=C2=A0 All you need is a widely used
decentralized protocol that allows anyone who can prove ownership of a
UTXO to store some data.=C2=A0=C2=A0

I = appreciate the suggestion, but I am really looking for a bitcoin-native sol= ution to leverage bitcoin's robustness and security properties.

By comparison, rolling
out relay of the annex and witness replacement may take months of review and years for >90% deployment among nodes, would allow an attacker to lower the feerate of coinjoin-style transactions by up to 4.99%, would
allow an attacker to waste 8 million bytes of bandwidth per relay node
for the same cost they'd have to pay to today to waste 400 thousand
bytes, and might limit the flexibility and efficiency of future
consensus changes that want to use the annex.

That years-long timeline that you sketch for witness replacement (or any= other policy change I presume?) to become effective is perhaps indicative = of the need to have an alternative way to relay transactions to miners besi= des the p2p network?

I agree though that it would = be ideal if there is a good solution that doesn't require any protocol = changes or upgrade path.

Joost
--0000000000009c975405fde6267a--