path: root/93/e0570e6d384717f9a27c364a94cb400259a06d

Return-Path: <joost.jager@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8D1ECC0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 09:15:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 4C38360864
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 09:15:07 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4C38360864
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=WUuHH6/t
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 Ldnhsfb0YCW6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 09:15:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E9CEC6101E
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [IPv6:2a00:1450:4864:20::632])
 by smtp3.osuosl.org (Postfix) with ESMTPS id E9CEC6101E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 09:15:05 +0000 (UTC)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-96fbe7fbdd4so430806266b.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 03 Jun 2023 02:15:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1685783704; x=1688375704;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=De2rbY8KxntOKSu908eNu3y682GewLGHGcsCWQpVJu0=;
 b=WUuHH6/t6ELzg/FDzjsPFPd5aXuVwUoRD1jRuvEEinZ97Gj0xxdR9A+HFO0+XRnL7g
 UegL2KzbkQpx7PdVpLiCD53nfjENmBNcef/bmP2UkczsfUmXI+SxmcAsJLuNiy1zXPEr
 FWjfgEU0Ux4oxAg4hX2+2miPJQi8cMm29+YXPxzXFKZM7qSgp6DMyv+lidyuKFxIyXKl
 Bezdm+0sq0YckRansnlyp3TO8w3PYckuVi/u6mKXkNB7+Ibj1cA3qWor7bWwk8Ls7dav
 3Jp04ewOCmSyhFytaxv7i1F2C2P3XnPq0V5G5L/Zoa920pKU1BH+iP+W+becJuvdWei2
 gDdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1685783704; x=1688375704;
 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=De2rbY8KxntOKSu908eNu3y682GewLGHGcsCWQpVJu0=;
 b=LyllsvIxmKXp4mohCZTEeFpco67vj0j8xPwcMrOh4NGVihxrLWj2TmPLHjm1qXdU7t
 vlUSHMEENe5dyTSJvf2p+euFFfgA/QdZmVvPvlpEQJHr0jOjM4Fgj82oTA92eW9l8/ht
 x8saqHA69/Z+zX90+zHQ23h8QO70jIKuP2PxnHDxqeJ5+qZfnE5Kpvwo0FIny2T9iSg6
 1ZyGIaijZ8TH1AIea/Vwxy1w+hhG0TYTPN57jSwXroil7Yv6eKEMCP29dYqknsv6bg7Q
 xXtTSWDYggU/zvRpekQq1NBBnBZ3Q46jfIGL+v0ypyeq5STCJBBhIYbfVvY43vCfMrAN
 9cog==
X-Gm-Message-State: AC+VfDytTOuHZShZS1uS3/9DAKiKrVMfJ/x9SVK5ykNVemVeAB4vIgD8
 MdWZq22n/EBhb4QsQPJ0CqHGztvFUgrpr5fyvCU=
X-Google-Smtp-Source: ACHHUZ6p+AkiT5crcvpLTSAA8fIgKRuKBE8q/ll/Rt0rn1cjrCz7nfQN5WtO/0HUHMI4rYT+JRWlOAooAn1k4mcW8YY=
X-Received: by 2002:a17:906:5d0a:b0:974:1e0e:9bd4 with SMTP id
 g10-20020a1709065d0a00b009741e0e9bd4mr1155238ejt.16.1685783703457; Sat, 03
 Jun 2023 02:15:03 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
 <CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
In-Reply-To: <CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Sat, 3 Jun 2023 11:14:27 +0200
Message-ID: <CAJBJmV8Vt_LLH-AEo-fCCs+S6uSy9UwC6QBakWY5tzn9Utwb8w@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d0149e05fd361aa3"
X-Mailman-Approved-At: Sat, 03 Jun 2023 11:30:48 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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, 03 Jun 2023 09:15:07 -0000

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

HI Greg,

On Sat, Jun 3, 2023 at 3:14=E2=80=AFAM Greg Sanders <gsanders87@gmail.com> =
wrote:

> Attempting to summarize the linked PR:
>
> I think the biggest remaining issue to this kind of idea, which is why I
> didn't propose it for mainnet,
> is the fact that BIP341/342 signature hashes do not cover *other* inputs'
> annex fields, which we
> briefly discussed here
> https://github.com/bitcoin-inquisition/bitcoin/pull/22#discussion_r114338=
2264
> .
>
> This means that in a coinjoin like scenario, even if the other joining
> parties prove they don't have any
> crazy script paths, a malicious party can make the signed transaction int=
o
> a maximum sized transaction
> package, causing griefing. The mitigation in the PR I linked was to limit
> it to 126 bytes, basically punting
> on the problem by making the grief vector small. Another solution could b=
e
> to make annex usage "opt-in"
> by requiring all inputs to commit to an annex to be relay-standard. In
> this case, you've opted into a possible
> vector, but at least current usage patterns wouldn't be unduly affected.
> For those who opt-in, perhaps the first
> order of business would be to have a field that limits the total
> transaction weight, by policy only?
>
> Some logs related to that here:
> https://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7bb
>
> Related discussion on possible BIP118 modifications to mitigate this in
> tapscript-spending circumstances:
> https://github.com/bitcoin-inquisition/bitcoin/issues/19
>

While solutions such as making annex usage opt-in or imposing size
limitations may initially appear effective, they may also inadvertently
foster a false sense of security, as they lack alignment with economic
incentives.

Relying solely on policy enforcement merely transfers responsibility to the
miners, without necessarily aligning their incentives with the broader
network health. This situation is reminiscent of the challenges encountered
with opt-in rbf. Despite signaling for non-replaceability, miners began
accepting replacements probably due to the enticing higher fee incentives.
At least that's how I picked up this development. Businesses that relied on
zero-confirmation payments were unexpectedly affected, leading to
undesirable outcomes.

While we can define policy rules, miners will ultimately operate in a
manner that maximizes their profits. Consequently, if a miner identifies an
opportunity to bolster their fees by replacing an annex transaction,
they're likely to seize it, regardless of any policy rules. This might not
be readily apparent currently with a limited number of pools dominating
block production, but it is my hope that mining will be more decentralized
in the future.

Depending on policy to mitigate this annex malleability vector could
mislead developers into believing their transactions are immune to
replacement, when in fact they might not be. This potential misalignment
could result in developers and businesses constructing systems based on
assumptions that could be compromised in the future, mirroring the
situation that unfolded with zero-confirmation payments and rbf.

It may thus be more prudent to permit the utilization of the annex without
restrictions, inform developers of its inherent risks, and acknowledge that
Bitcoin, in its present state, might not be ideally suited for certain
types of applications?

Joost

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

<div dir=3D"ltr"><div dir=3D"ltr">HI Greg,<div><br></div></div><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 3, 2023 =
at 3:14=E2=80=AFAM Greg Sanders &lt;<a href=3D"mailto:gsanders87@gmail.com"=
>gsanders87@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div id=3D"m_-811107207189304988gmail-:3h=
l" aria-label=3D"Message Body" role=3D"textbox" aria-multiline=3D"true" sty=
le=3D"direction:ltr;min-height:85px" aria-controls=3D":3k2"><div>Attempting=
 to summarize the linked PR:</div><div><br></div><div>I think the biggest r=
emaining issue to this kind of idea, which is why I didn&#39;t propose it f=
or mainnet,</div><div>is the fact that BIP341/342 signature hashes do not c=
over *other* inputs&#39; annex fields, which we</div><div>briefly discussed=
 here=C2=A0<a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pull/2=
2#discussion_r1143382264" target=3D"_blank">https://github.com/bitcoin-inqu=
isition/bitcoin/pull/22#discussion_r1143382264</a> .=C2=A0</div><div><br></=
div><div>This means that in a coinjoin like scenario, even if the other joi=
ning parties prove they don&#39;t have any</div><div>crazy script paths, a =
malicious party can make the signed transaction into a maximum sized transa=
ction</div><div>package, causing griefing. The mitigation in the PR I linke=
d was to limit it to 126 bytes, basically punting</div><div>on the problem =
by making the grief vector small. Another solution could be to make annex u=
sage &quot;opt-in&quot;</div><div>by requiring all inputs to commit to an a=
nnex to be relay-standard. In this case, you&#39;ve opted into a possible</=
div><div>vector, but at least current usage patterns wouldn&#39;t be unduly=
 affected. For those who opt-in, perhaps the first</div><div>order of busin=
ess would be to have a field that limits the total transaction weight, by p=
olicy only?</div><div><br></div><div>Some logs related to that here:=C2=A0<=
a href=3D"https://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7=
bb" target=3D"_blank">https://gist.github.com/instagibbs/7406931d953fd96fea=
28f85be50fc7bb</a></div><div><br></div><div>Related discussion on possible =
BIP118 modifications to mitigate this in tapscript-spending circumstances:=
=C2=A0<a href=3D"https://github.com/bitcoin-inquisition/bitcoin/issues/19" =
target=3D"_blank">https://github.com/bitcoin-inquisition/bitcoin/issues/19<=
/a></div></div></div></blockquote><div><br></div>While solutions such as ma=
king annex usage opt-in or imposing size limitations may initially appear e=
ffective, they may also inadvertently foster a false sense of security, as =
they lack alignment with economic incentives.<br><br>Relying solely on poli=
cy enforcement merely transfers responsibility to the miners, without neces=
sarily aligning their incentives with the broader network health. This situ=
ation is reminiscent of the challenges encountered with opt-in rbf. Despite=
 signaling for non-replaceability, miners began accepting replacements prob=
ably due to the enticing higher fee incentives. At least that&#39;s how I p=
icked up this development. Businesses that relied on zero-confirmation paym=
ents were unexpectedly affected, leading to undesirable outcomes.<br><br>Wh=
ile we can define policy rules, miners will ultimately operate in a manner =
that maximizes their profits. Consequently, if a miner identifies an opport=
unity to bolster their fees by replacing an annex transaction, they&#39;re =
likely to seize it, regardless of any policy rules. This might not be readi=
ly apparent currently with a limited number of pools dominating block produ=
ction, but it is my hope that mining will be more decentralized in the futu=
re.<br><br>Depending on policy to mitigate this annex malleability vector c=
ould mislead developers into believing their transactions are immune to rep=
lacement, when in fact they might not be. This potential misalignment could=
 result in developers and businesses constructing systems based on assumpti=
ons that could be compromised in the future, mirroring the situation that u=
nfolded with zero-confirmation payments and rbf.<br><br><div>It may thus be=
 more prudent to permit the utilization of the annex without restrictions, =
inform developers of its inherent risks, and acknowledge that Bitcoin, in i=
ts present state, might not be ideally suited for certain types of applicat=
ions?</div><div><br></div><div>Joost=C2=A0</div></div></div>

--000000000000d0149e05fd361aa3--