path: root/9b/4cb8a032a932928ee565e8b4ac72c0a6b56478

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 13A15C0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 15 Jun 2023 10:39:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id E0B1041F92
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 15 Jun 2023 10:39:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E0B1041F92
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=YTRQd0EH
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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id aBOQFTNy0uai
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 15 Jun 2023 10:39:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7443041F7D
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [IPv6:2a00:1450:4864:20::135])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 7443041F7D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 15 Jun 2023 10:39:50 +0000 (UTC)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-4f004cc54f4so10300991e87.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 15 Jun 2023 03:39:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1686825588; x=1689417588;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=BSN6HNqhJWOuMPAOHQJnT9624iIuGaNDsdd6dOTX9f0=;
 b=YTRQd0EHnuvB+gBptP4408lloPAvMbHdMMLOX//qyYzyNyoLAPliY6cEGPqCi0ctcr
 UErQ6vScjVnkgJgDpj4PXy8Gr3IySiENeWbfevam5ZZecUgko+i5Nyntn7IXOQdtkB4G
 LuDW9FIRVWL/BGRYYhqUm+im95Wo/FAtkPBG4ny9kZ/S4uShfu4SWG9vIU4qxwFmdB3c
 5dgkOiLXAPQ5DWb647IxUUIZO0Pw+Osbh1g4zt9mzglTPf1MbfU6qE3sVSZ5HKYCtY14
 VSk/KWbgYuB2NgWCun3xH9oGHDCn4neEWD56dPPanD3IlgrZksReklFUXtaExAUdErhx
 TvlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1686825588; x=1689417588;
 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=BSN6HNqhJWOuMPAOHQJnT9624iIuGaNDsdd6dOTX9f0=;
 b=Fcxc6rp7mnP1dEkoLaWbimq6ujp5myWP+EE8qogXCmPRN4qrOXS7X1P69Pdy0TTG7E
 Yj3x8aBnOky3ApoNFdp1yuWld8BUu/O8YwTOEBSOKiaX3N2Xg+QaU71etDUcn2aN8RE1
 MhAeMkZieFRtjgfWTAuWh/WTp0XEd/DgNTF9OvUjmBj5q2UNaAIboFYH+c5UA9hs3qI3
 xgVd0OewOGGULD7Danj6zds4aipaQ0hqamliwhxlanxgdtLKXeK9TefnOp3ArlFm1U5w
 JxldfR7G/RfWXr6cqmwK2ZQf9f/PeeFklaGXYwklkPkpHVainE3+sUOtK3ZAtevD3fiw
 JEiA==
X-Gm-Message-State: AC+VfDwhZlrqDWsoTiR3Tyw5bnpk8G/ko342ROLUIIXpF3i0+7qFUKGH
 9d9OB8dAP7aqb7kJSSV9SahKkvtF0xewtZfV9/Q=
X-Google-Smtp-Source: ACHHUZ5bCEQ3baw3Xb10+xztGNqavtLpUPEeRgWjkQsub5+xhPL/DmGKTe19KnBrzvsbpin2bgRL8hSYyituVgvcmak=
X-Received: by 2002:a05:6512:459:b0:4f6:2e5f:45cc with SMTP id
 y25-20020a056512045900b004f62e5f45ccmr9503813lfk.3.1686825587750; Thu, 15 Jun
 2023 03:39:47 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
 <CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
 <CAJBJmV88j7i3=uqnU5OwMCKyZaP9v6cx9EKEuK1FYs6aL0r1uw@mail.gmail.com>
In-Reply-To: <CAJBJmV88j7i3=uqnU5OwMCKyZaP9v6cx9EKEuK1FYs6aL0r1uw@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 15 Jun 2023 06:39:36 -0400
Message-ID: <CAB3F3DtLzemnNqj6skRcK22qGYVwuo5YCPhUXQDCUcEe3yKr7Q@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f4bf0305fe28afa6"
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: Thu, 15 Jun 2023 10:39:52 -0000

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

Hi Joost,

> Ignoring the argument that policy may provide a false sense of security

This may take longer form arguments than I'm willing to make on this
thread, but I think this only true in a shallower sense that we cannot know
for sure that anything will be confirmed quickly. When crafting policy, we
are trying to make as reliable-as-possible systems to allow people to pay
miners. That may mean opening up the annex to potential use-cases, but it
certainly means allowing current users of the p2p network to make
reasonable feerate transactions in coinjoin-like scenarios. Ideally we
shoot for as many use cases as we can, to pay these miners.

> Would it then still be necessary to restrict the annex to a maximum size?

I think it's worth thinking about to protect the opt-in users, and can also
be used for other anti-pinning efforts(though clearly not sufficient by
itself for the many many pinning vectors we have :) )

Cheers,
Greg

On Thu, Jun 15, 2023 at 5:36=E2=80=AFAM Joost Jager <joost.jager@gmail.com>=
 wrote:

> Hi Greg,
>
> Getting back to this:
>
> Another solution could be 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.
>>
>
> Ignoring the argument that policy may provide a false sense of security, =
I
> think this is an interesting idea. Opt-in would enable convenants through
> presigned txes with atomic on-chain signature backup, without needing to
> worry about non-annex multi-party protocols (coinjoin and dual funded
> lightning mentioned previously) that may suffer from annex inflation or t=
he
> last signer presenting an unexpected annex. The downside is just that ext=
ra
> empty annex byte per input, if there are other inputs involved. To me tha=
t
> would be a reasonable trade-off.
>
> Would it then still be necessary to restrict the annex to a maximum size?
> Perhaps not opting into annex for multi-party protocols is sufficient. Or
> otherwise, #24007 may be helpful. It is hard to pick a constant usually.
>
> Joost.
>

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

<div dir=3D"ltr">Hi Joost,<div><br></div><div>&gt; Ignoring the argument th=
at policy may provide a false sense of security</div><div><br></div><div>Th=
is may take longer form arguments than I&#39;m willing to make on this thre=
ad, but I think this only true in a shallower sense that we cannot know for=
 sure that anything will be confirmed quickly. When crafting policy, we are=
 trying to make as reliable-as-possible systems to allow people to pay mine=
rs. That may mean opening up the annex to potential use-cases, but it certa=
inly means allowing current users of the p2p network to make reasonable fee=
rate transactions=C2=A0in coinjoin-like scenarios. Ideally we shoot for as =
many use cases as we can, to pay these miners.</div><div><br></div><div>&gt=
; Would it then still be necessary to restrict the annex to a maximum size?=
</div><div><br></div><div>I think it&#39;s worth thinking about to protect =
the opt-in users, and can also be used for other anti-pinning efforts(thoug=
h clearly not sufficient by itself for the many many pinning vectors we hav=
e :) )</div><div><br></div><div>Cheers,</div><div>Greg</div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 15,=
 2023 at 5:36=E2=80=AFAM Joost Jager &lt;<a href=3D"mailto:joost.jager@gmai=
l.com">joost.jager@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_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 Greg,</div><div><br></=
div><div>Getting back to this:</div><div><br></div><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div =
id=3D"m_-6262746064179201819m_-3252546504006912555gmail-:3hl" aria-label=3D=
"Message Body" role=3D"textbox" aria-multiline=3D"true" style=3D"direction:=
ltr;min-height:85px" aria-controls=3D":3k2"><div>Another solution could be =
to make annex usage &quot;opt-in&quot;</div><div>by requiring all inputs to=
 commit to an annex to be relay-standard. In this case, you&#39;ve opted in=
to a possible</div><div>vector, but at least current usage patterns wouldn&=
#39;t be unduly affected.=C2=A0</div></div></div></blockquote><div>=C2=A0</=
div><div>Ignoring the argument that policy may provide a false sense of sec=
urity, I think this is an interesting idea. Opt-in would enable convenants =
through presigned txes with atomic on-chain signature backup, without needi=
ng to worry about non-annex multi-party protocols (coinjoin and dual funded=
 lightning mentioned previously) that may suffer from annex inflation or th=
e last signer presenting an unexpected annex. The downside is just that ext=
ra empty annex byte per input, if there are other inputs involved. To me th=
at would be a reasonable trade-off.</div><div><br></div><div>Would it then =
still be necessary to restrict the annex to a maximum size? Perhaps not opt=
ing into annex for multi-party protocols is sufficient. Or otherwise, #2400=
7 may be helpful. It is hard to pick a constant usually.</div><div><br></di=
v><div>Joost.</div></div></div>
</blockquote></div>

--000000000000f4bf0305fe28afa6--