path: root/92/bc1f8f6e57699c817192c77a7a95e70274372c

Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 52484C0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Jun 2023 13:31:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 2652E60BFF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Jun 2023 13:31:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2652E60BFF
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=Mf9g/y3R
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wCdDj7VSF99n
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Jun 2023 13:31:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D9CEB60A6A
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [IPv6:2a00:1450:4864:20::62b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id D9CEB60A6A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Jun 2023 13:31:00 +0000 (UTC)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-986d871a9beso9812966b.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Jun 2023 06:31:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1686922259; x=1689514259;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=saCFrP/Xt/o3NDB8K3NjNEdxDDo2YHCiJhuQp1ww0c0=;
 b=Mf9g/y3ROYy3CsAFtbSKhKSvEwecYgBqRfE/qdc7SgoLqhexo+TtXg6zpgTnsskbOr
 05hxCYNNRoWkeLXCDbI8lFMIX2pPxvtK1HEqYwIO2uCZKCb2Tll2DrGR29gs9FK4GySI
 bgMPUDjNJ23eWFtz+cpKnnJCNSfg4aJmXn3IYRVgTBPFm6wT/sbC6B7JthWy3m3pGceV
 yh08iBe9nPM7uKMOuJyp7R11JucGYLtG6hTTJeDJwPEvhSmHtAv9ay9souTXyu3golNL
 NyT07OyzTCHCXXYnHzF35Gy4CK95QMg+PunUMYKrD1PD7V0VPbJuuYj+pAAYeDU5wAup
 592w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1686922259; x=1689514259;
 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=saCFrP/Xt/o3NDB8K3NjNEdxDDo2YHCiJhuQp1ww0c0=;
 b=KDRb3DaXQyDRElyiNFxK39d8AyXJ09gPXK740QOI8QhHjlP9lIqHz17nOAWde0zpX6
 hAJekiDl4aPCzY52lQkkvGPTdqGvDfKZi+IDM2bwslIbumnJ++O1YZu+5HB9CZlT8Bpi
 zKFX/pFSWh5wqEKJU1XFP3YFTaqp5+KQxs7Ep5weOifdJgedT+aj6+lpF4hyeUW547Bm
 pfwbRrOkhPOQXi+Ab4RL3ZXQ8eE2vS0oMXc4vETOohaJMbmuGbt0wl8GEjrbFmHv9QVV
 TrMEqkG2RMRU9Gm2SM29ZXOnjU7Ruv78jJats7Edep8luLAdQLZhRXSZW1Lz2cxZk+G+
 Qrng==
X-Gm-Message-State: AC+VfDwx9GIyO1wKBJ7X2R+p40xKlrJAExtTg1wLzprjIM2iIwYdQOoW
 0vYC+qCLMmtvMGnVaqkCQzjOZzzNVCyXVyZ/3VbtsyZ/
X-Google-Smtp-Source: ACHHUZ4wUohztKqgSrHdwS/XHkA+z7m/jJGTihrnX4KMo3ECrcRvNBJxTKOFpzlxI2QUS3r+A4Xvyscskev4C7i5jak=
X-Received: by 2002:a17:907:3f29:b0:973:8cb7:4d81 with SMTP id
 hq41-20020a1709073f2900b009738cb74d81mr2682174ejc.49.1686922258436; Fri, 16
 Jun 2023 06:30:58 -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>
 <CAB3F3DtLzemnNqj6skRcK22qGYVwuo5YCPhUXQDCUcEe3yKr7Q@mail.gmail.com>
 <CAJBJmV_vPW1vBSfTeDOU_FecHk1sX2=uGUFYS9enC=hwvLpVQA@mail.gmail.com>
In-Reply-To: <CAJBJmV_vPW1vBSfTeDOU_FecHk1sX2=uGUFYS9enC=hwvLpVQA@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Fri, 16 Jun 2023 09:30:46 -0400
Message-ID: <CAB3F3DszC3ZDDYrN_jzoU+hZ021TfmCRoVTZWCpzOmH4F_anwg@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000fa594c05fe3f3127"
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: Fri, 16 Jun 2023 13:31:02 -0000

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

Hi Joost,

I haven't thought a ton about the specific TLV format, but that seems like
a reasonable place to start as it shouldn't unduly
impact current users, and is pretty simple from an accounting perspective.
It also can be further relaxed in the future if we so decide by using max
tx size policy "hints" in an annex field.

I'll let others chime in at this point!

Cheers,
Greg

On Fri, Jun 16, 2023 at 7:27=E2=80=AFAM Joost Jager <joost.jager@gmail.com>=
 wrote:

> Hi Greg,
>
> On Thu, Jun 15, 2023 at 12:39=E2=80=AFPM Greg Sanders <gsanders87@gmail.c=
om>
> wrote:
>
>> > 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 sufficien=
t
>> by itself for the many many pinning vectors we have :) )
>>
>
> Thinking about the most restrictive policy that would still enable
> annex-vaults (which I believe has great potential for improving bitcoin
> custody) and is in line with work already done, I get to:
>
> * Opt-in annex (every input must commit to an annex even if its is empty)
> -> make sure existing multi-party protocols remain unaffected
> * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381 ->
> future extensibility
> * Only allow tlv record 0 - unstructured data -> future extensibility
> * Limit maximum size of the value to 256 bytes -> protect opt-in users
>
> Unfortunately the limit of 126 bytes in
> https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient
> for these types of vaults. If there are two presigned txes (unvault and
> emergency), those signatures would already take up 2*64=3D128 bytes. Then=
 you
> also want to store 32 bytes for the ephemeral key itself as the key can't
> be reconstructed from the schnorr signature. The remaining bytes could be
> used for a third presigned tx and/or additional vault parameters.
>
> Can you think of remaining practical objections to making the annex
> standard under the conditions listed above?
>
> Joost
>
>>

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

<div dir=3D"ltr">Hi Joost,<div><br></div><div>I haven&#39;t thought a ton a=
bout the specific TLV format, but that seems like a reasonable place to sta=
rt as it shouldn&#39;t unduly</div><div>impact current users, and is pretty=
 simple from an accounting perspective.</div><div>It also can be further re=
laxed in the future if we so decide by using max tx size policy &quot;hints=
&quot; in an annex field.</div><div><br></div><div>I&#39;ll let others chim=
e in at this point!</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=
 Fri, Jun 16, 2023 at 7:27=E2=80=AFAM Joost Jager &lt;<a href=3D"mailto:joo=
st.jager@gmail.com">joost.jager@gmail.com</a>&gt; wrote:<br></div><blockquo=
te 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 Greg,</di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On T=
hu, Jun 15, 2023 at 12:39=E2=80=AFPM Greg Sanders &lt;<a href=3D"mailto:gsa=
nders87@gmail.com" target=3D"_blank">gsanders87@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>&gt; Would it then still be necessary to restrict the annex to a maximu=
m size?<br></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 ef=
forts(though clearly not sufficient by itself for the many many pinning vec=
tors we have :) )</div></div></blockquote><div><br></div><div>Thinking abou=
t the most restrictive policy that would still enable annex-vaults (which I=
 believe has great potential for improving bitcoin custody) and is in line =
with work already done, I get to:</div><div><br></div><div>* Opt-in annex (=
every input must commit to an annex even if its is empty) -&gt; make sure e=
xisting multi-party protocols remain unaffected</div><div>* Tlv format as d=
efined in=C2=A0<a href=3D"https://github.com/bitcoin/bips/pull/1381" target=
=3D"_blank">https://github.com/bitcoin/bips/pull/1381</a> -&gt; future exte=
nsibility<br>* Only allow tlv record 0 - unstructured data -&gt; future ext=
ensibility</div><div>* Limit maximum size of the value to 256 bytes -&gt; p=
rotect opt-in users</div><div><br></div><div>Unfortunately the limit of 126=
 bytes in=C2=A0<a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pu=
ll/22" target=3D"_blank">https://github.com/bitcoin-inquisition/bitcoin/pul=
l/22</a> isn&#39;t sufficient for these types of vaults. If there are two p=
resigned txes (unvault and emergency), those signatures would already take =
up 2*64=3D128 bytes. Then you also want to store 32 bytes for the ephemeral=
 key itself as the key can&#39;t be reconstructed from the schnorr signatur=
e. The remaining bytes could be used for a third presigned tx and/or additi=
onal vault parameters.</div><div><br></div><div>Can you think of remaining =
practical objections to making the annex standard under the conditions list=
ed above?</div><div><br></div><div>Joost</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">
</blockquote></div>
</blockquote></div></div>
</blockquote></div>

--000000000000fa594c05fe3f3127--