diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2023-06-19 02:14:10 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-06-19 01:14:24 +0000 |
| commit | bc8d93420ee151b86fd8927325c999471478aea9 (patch) | |
| tree | 93b278e1cfb6f1957f7aa6feb370b466c0f1112e | |
| parent | 0f805fa2bea41b1a9e686dc95c4128c4c9757304 (diff) | |
| download | pi-bitcoindev-bc8d93420ee151b86fd8927325c999471478aea9.tar.gz pi-bitcoindev-bc8d93420ee151b86fd8927325c999471478aea9.zip | |
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
| -rw-r--r-- | 24/759e87005d4743929860505f1d5e96e56c917c | 422 |
1 files changed, 422 insertions, 0 deletions
diff --git a/24/759e87005d4743929860505f1d5e96e56c917c b/24/759e87005d4743929860505f1d5e96e56c917c new file mode 100644 index 000000000..fc9eda48b --- /dev/null +++ b/24/759e87005d4743929860505f1d5e96e56c917c @@ -0,0 +1,422 @@ +Return-Path: <antoine.riard@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id A3012C0029 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 19 Jun 2023 01:14:24 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 7703F81C58 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 19 Jun 2023 01:14:24 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7703F81C58 +Authentication-Results: smtp1.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20221208 header.b=A4HxkNVW +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 smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 8FVAZ-u1UGUZ + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 19 Jun 2023 01:14:23 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C90B681448 +Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com + [IPv6:2607:f8b0:4864:20::731]) + by smtp1.osuosl.org (Postfix) with ESMTPS id C90B681448 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 19 Jun 2023 01:14:22 +0000 (UTC) +Received: by mail-qk1-x731.google.com with SMTP id + af79cd13be357-7623a6c24f2so284885085a.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 18 Jun 2023 18:14:22 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20221208; t=1687137261; x=1689729261; + h=cc:to:subject:message-id:date:from:in-reply-to:references + :mime-version:from:to:cc:subject:date:message-id:reply-to; + bh=FtHGf5ukD7EalhB32daT0jSIe1h6FHYvHOYVsX8FQWY=; + b=A4HxkNVWrUDidYfWROpQ7G+zf6tHVtsnSHqGpXMfm/Cn17W7C57Y36u8qQVprT/A+m + lx8gTo7bx92DW19PVP2RlbsWg01BnPLK1o15viFIBbIkO25apKG3yToh78ILditMyfQ+ + 5Zw2ja2sP9n1ffYLZFVeFBZSPJqXmNpHZUyantuEw/3CKexWVX12X90nzM0E+m1b0JmT + +OVWO0HEN2leAT3B836XRC9/FvMXIyHSJdWggU4fZX2JBWha8WoEG1RFxRohj+MmNauM + UM4CddOa+3TL+vAAC5qlMVh0fHtRMXMVqQ/E1isrr5pnjTWIEqgDFaawETvdkXSdi9YF + pL2g== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20221208; t=1687137261; x=1689729261; + 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=FtHGf5ukD7EalhB32daT0jSIe1h6FHYvHOYVsX8FQWY=; + b=JTwWUjdwyyTo2XhxNjssh/w9XizZnMSENkvqFTifzp+91c1bp9cUUGqpzJK7JvuLPI + xF1qTsl0lhD1KK8/ttiHoFJz0njLT3Eiun1iJ3ZBBnoPZojLQ8ZeMQrxSD7rEks49gh2 + A1PvBx5V6JUZtQy45IUT/QOmVVsUyV9g0+vxMzDLXJ7KXjNF8qqfx14B4O8sh/7Dhvxs + PW7MCghFLCAchmwFvsoZ8A4bbXsPUxFVn+BP7U/SWkup9pGk4r14pwklnQUjMlNRvvzN + rl9PmDZ/FPt5a4zq98l7BnG38gagD0wc3+bj4bM/Re5FYNVUswSm4nMbZXc/5lekrk73 + JJGA== +X-Gm-Message-State: AC+VfDwMGnIz/kJu3eot31+JdlOSvLV7n9QNJkt7e2IlBtb6PXPjLsi9 + oKMabX4He0UPyTN0tHKyoyaVoWXZzCs9UD4AqNc20KI4CH0= +X-Google-Smtp-Source: ACHHUZ6m1i2ascmNZBHkyLj7/1w/LBy8j3lOEXldTjJjLdbDtSR9YOUzJXNag/fC8B67u3TBywyq0M4mVS4m2b5r3FI= +X-Received: by 2002:a05:620a:424d:b0:75b:23a1:3606 with SMTP id + w13-20020a05620a424d00b0075b23a13606mr9752461qko.23.1687137261397; Sun, 18 + Jun 2023 18:14:21 -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> + <CAB3F3DszC3ZDDYrN_jzoU+hZ021TfmCRoVTZWCpzOmH4F_anwg@mail.gmail.com> + <CALZpt+FUzpr=3jUfQmqs=LFBjOU=0Ah-snipf-_j1PQKuC4seQ@mail.gmail.com> + <CAB3F3DvyC33UZkioW_JV7U9qc4+VKFEMt51T6XuUmoX5x+BRsw@mail.gmail.com> +In-Reply-To: <CAB3F3DvyC33UZkioW_JV7U9qc4+VKFEMt51T6XuUmoX5x+BRsw@mail.gmail.com> +From: Antoine Riard <antoine.riard@gmail.com> +Date: Mon, 19 Jun 2023 02:14:10 +0100 +Message-ID: <CALZpt+EKC840oQkL_Jd_BaKTJRsZzsZkPKHA32E+7i=gbwOmSQ@mail.gmail.com> +To: Greg Sanders <gsanders87@gmail.com> +Content-Type: multipart/alternative; boundary="000000000000272c8a05fe7141c0" +X-Mailman-Approved-At: Mon, 19 Jun 2023 08:39:05 +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: Mon, 19 Jun 2023 01:14:24 -0000 + +--000000000000272c8a05fe7141c0 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Greg, + +> Going to need a citation for this. + +Sorry for the confusion, this was in reply to Joost's point on "Opt-in +annex (every input must commit to an annex even if its is empty) -> make +sure existing multi-party protocols remain unaffected" + +What is unclear to me is if we're talking about opt-in of non-deployed-yet +protocols like the pre-signed vaults or deployed protocols like +coinjoin/lightning spending P2TR outputs, where a counterparty script spend +path can inflate the witness, and we would like to commit *now* to avoid +future interferences. E.g 0-conf dual-funding and we loosened the limit +from 126 bytes to 256, the worst-case liquidity griefing is not the same +anymore. + +If the opt-in mechanism we're talking about is just adding an annex for +non-deployed-yet protocols as a script spend path of a currently deployed +protocol could always be opted-in to the new annex policy through script +spend path in the context of collaborative added inputs, no ? + +> People should really not be building protocols that are meant to go into +production on top of undeveloped upgrade hooks, +and we should not be encumbered by these premature choices if so. + +> People should really not be building protocols that are meant to go into +production on top of undeveloped upgrade hooks, +> and we should not be encumbered by these premature choices if so. Maybe +I'm misunderstanding, which is why a citation +> would be handy. + +Yes ideally we should not be encumbered by these premature choices. Still +if those use-cases catched up in terms of economic weight, the coordination +cost of deploying a new policy might be prohibitive, or require very long +periods, somehow like we're seeing with mempoolfullrbf. And I don't think +we can say the use-cases would be illegitimate, or that base-layer policy +should always have the last word. In the example of lightning, we're doing +major re-work of the mempool, partially to improve lightning operations. +Personally, I think we should care more about sound and "firewalled" +signaling and upgrading mechanisms that let us deploy new policy rules for +new use-cases more smoothly. + +Best, +Antoine + +Le dim. 18 juin 2023 =C3=A0 21:41, Greg Sanders <gsanders87@gmail.com> a = +=C3=A9crit : + +> Hi Antoine, +> +> > If I understand correctly, this would require modifying current Taproot +> support on the Lightning-side, where all P2TR spends must add an annex an= +d +> commit to it in the BIP341 signature digest. +> +> huh? +> +> Going to need a citation for this. +> +> People should really not be building protocols that are meant to go into +> production on top of undeveloped upgrade hooks, +> and we should not be encumbered by these premature choices if so. Maybe +> I'm misunderstanding, which is why a citation +> would be handy. +> +> Best, +> Greg +> +> On Sun, Jun 18, 2023 at 4:32=E2=80=AFPM Antoine Riard <antoine.riard@gmai= +l.com> +> wrote: +> +>> Hi all, +>> +>> > * Opt-in annex (every input must commit to an annex even if its is +>> empty) -> make sure existing multi-party protocols remain unaffected +>> +>> By requiring every input to commit to an annex even if it is empty, do +>> you mean rejecting a transaction where the minimal annex with its 0x50 t= +ag +>> is absent ? +>> +>> If I understand correctly, this would require modifying current Taproot +>> support on the Lightning-side, where all P2TR spends must add an annex a= +nd +>> commit to it in the BIP341 signature digest. This would be quite a +>> mandatory upgrade for Lightning nodes, as failure to do so would break +>> propagations of their `option_taproot` channel transactions. +>> +>> > * Limit maximum size of the value to 256 bytes -> protect opt-in users +>> +>> There is another approach where the maximum size/weight of the +>> witness/transaction is introduced as a TLV record itself: +>> https://github.com/bitcoin-inquisition/bitcoin/pull/28 +>> +>> Note this branch also implements the "only allow tlv record 0" with the +>> TLV format from bips #1381. +>> +>> Best, +>> Antoine +>> +>> Le ven. 16 juin 2023 =C3=A0 14:31, Greg Sanders via bitcoin-dev < +>> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : +>> +>>> 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@gmai= +l.com> +>>>> 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 ca= +n +>>>>> also be used for other anti-pinning efforts(though clearly not suffic= +ient +>>>>> 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 bitcoi= +n +>>>> 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 itse= +lf as +>>>> the key can't be reconstructed from the schnorr signature. The remaini= +ng +>>>> 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 +>>>> +>>>>> _______________________________________________ +>>> bitcoin-dev mailing list +>>> bitcoin-dev@lists.linuxfoundation.org +>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>> +>> + +--000000000000272c8a05fe7141c0 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi Greg,<div><br></div><div>> Going to need a citation = +for this.=C2=A0</div><div><br></div><div>Sorry for the confusion, this was = +in reply to Joost's point on "Opt-in annex (every input must commi= +t to an annex even if its is empty) -> make sure existing multi-party pr= +otocols remain unaffected"</div><div><br></div><div>What is unclear to= + me is if we're talking about opt-in of non-deployed-yet protocols like= + the pre-signed vaults or deployed protocols like coinjoin/lightning spendi= +ng P2TR outputs, where a counterparty script spend path can inflate the wit= +ness, and we would like to commit *now* to avoid future interferences. E.g = +0-conf dual-funding and we loosened the limit from 126 bytes=C2=A0to 256, t= +he worst-case liquidity griefing is not the same anymore.</div><div><br></d= +iv><div>If the opt-in mechanism we're talking about is just adding an a= +nnex for non-deployed-yet protocols as a script spend path of a currently d= +eployed protocol could always be opted-in to the new annex policy through s= +cript spend path in the context of collaborative added inputs, no ?</div><d= +iv><br></div><div>> People should really not be building protocols that = +are meant to go into production on top of undeveloped upgrade hooks,</div><= +div>and we should not be encumbered by these premature choices if so.</div>= +<div><br></div><div><div>> People should really not be building protocol= +s that are meant to go into production on top of undeveloped upgrade hooks,= +</div><div>> and we should not be encumbered by these premature choices = +if so. Maybe I'm misunderstanding, which is why a citation</div><div>&g= +t; would be handy.</div></div><div><br></div><div>Yes ideally we should not= + be encumbered by these premature choices. Still if those use-cases catched= + up in terms of economic weight, the coordination cost of deploying a new p= +olicy might be prohibitive, or require very long periods, somehow like we&#= +39;re seeing with mempoolfullrbf. And I don't think we can say the use-= +cases would be illegitimate, or that base-layer policy should always have t= +he last word. In the example of lightning, we're doing major re-work of= + the mempool, partially to improve lightning operations. Personally, I thin= +k we should care more about sound and "firewalled" signaling and = +upgrading mechanisms that let us deploy new policy rules for new use-cases = +more smoothly.</div><div><br></div><div>Best,</div><div>Antoine</div></div>= +<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2= +=A0dim. 18 juin 2023 =C3=A0=C2=A021:41, Greg Sanders <<a href=3D"mailto:= +gsanders87@gmail.com">gsanders87@gmail.com</a>> a =C3=A9crit=C2=A0:<br><= +/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= +rder-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,2= +04);padding-left:1ex"><div dir=3D"ltr"><div>Hi Antoine,</div><div><br></div= +>> If I understand correctly, this would require modifying current Tapro= +ot support on the Lightning-side, where all P2TR spends must add an annex a= +nd commit to it in the BIP341 signature digest.=C2=A0<div><br></div><div>hu= +h?</div><div><br></div><div>Going to need a citation for this.=C2=A0</div><= +div><br></div><div>People should really not be building protocols that are = +meant to go into production on top of undeveloped upgrade hooks,</div><div>= +and we should not be encumbered by these premature choices if so. Maybe I&#= +39;m misunderstanding, which is why a citation</div><div>would be handy.</d= +iv><div><br></div><div>Best,</div><div>Greg</div></div><br><div class=3D"gm= +ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 18, 2023 at 4:= +32=E2=80=AFPM Antoine Riard <<a href=3D"mailto:antoine.riard@gmail.com" = +target=3D"_blank">antoine.riard@gmail.com</a>> wrote:<br></div><blockquo= +te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt= +h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-le= +ft:1ex"><div dir=3D"ltr">Hi all,<div><br></div><div>> * Opt-in annex (ev= +ery input must commit to an annex even if its is empty) -> make sure exi= +sting multi-party protocols remain unaffected</div><br><div>By requiring=C2= +=A0every input to commit to an annex even if it is empty, do you mean rejec= +ting a transaction where the minimal annex with its 0x50 tag is absent ?</d= +iv><div><br></div><div>If I understand correctly, this would require modify= +ing current Taproot support on the Lightning-side, where all P2TR spends mu= +st add an annex and commit to it in the BIP341 signature digest. This would= + be quite a mandatory upgrade for Lightning nodes, as failure to do so woul= +d break propagations of their `option_taproot` channel transactions.</div><= +div><br></div><div>> * Limit maximum size of the value to 256 bytes ->= +; protect opt-in users</div><div><br></div><div>There is another approach w= +here the maximum size/weight of the witness/transaction is introduced as a = +TLV record itself:</div><div><a href=3D"https://github.com/bitcoin-inquisit= +ion/bitcoin/pull/28" target=3D"_blank">https://github.com/bitcoin-inquisiti= +on/bitcoin/pull/28</a></div><div><br></div><div>Note this branch also imple= +ments the "only allow tlv record 0" with the TLV format from bips= +=C2=A0#1381.</div><div><br></div><div>Best,</div><div>Antoine</div></div><b= +r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0= +ven. 16 juin 2023 =C3=A0=C2=A014:31, Greg Sanders via bitcoin-dev <<a hr= +ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco= +in-dev@lists.linuxfoundation.org</a>> a =C3=A9crit=C2=A0:<br></div><bloc= +kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-= +width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddin= +g-left:1ex"><div dir=3D"ltr">Hi Joost,<div><br></div><div>I haven't tho= +ught a ton about the specific TLV format, but that seems like a reasonable = +place to start as it shouldn't unduly</div><div>impact current users, a= +nd is pretty simple from an accounting perspective.</div><div>It also can b= +e further relaxed in the future if we so decide by using max tx size policy= + "hints" in an annex field.</div><div><br></div><div>I'll let= + others chime 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"gm= +ail_attr">On Fri, Jun 16, 2023 at 7:27=E2=80=AFAM Joost Jager <<a href= +=3D"mailto:joost.jager@gmail.com" target=3D"_blank">joost.jager@gmail.com</= +a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p= +x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c= +olor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Greg,</div= +><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Th= +u, Jun 15, 2023 at 12:39=E2=80=AFPM Greg Sanders <<a href=3D"mailto:gsan= +ders87@gmail.com" target=3D"_blank">gsanders87@gmail.com</a>> wrote:<br>= +</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= +order-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,= +204);padding-left:1ex"><div dir=3D"ltr"><div>> Would it then still be ne= +cessary to restrict the annex to a maximum size?<br></div><div><br></div><d= +iv>I think it's worth thinking about to protect the opt-in users, and c= +an also be used for other anti-pinning efforts(though clearly not sufficien= +t by itself for the many many pinning vectors we have :) )</div></div></blo= +ckquote><div><br></div><div>Thinking about the most restrictive policy that= + would still enable annex-vaults (which I believe has great potential for i= +mproving 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 anne= +x even if its is empty) -> make sure existing multi-party protocols rema= +in unaffected</div><div>* Tlv format as defined in=C2=A0<a href=3D"https://= +github.com/bitcoin/bips/pull/1381" target=3D"_blank">https://github.com/bit= +coin/bips/pull/1381</a> -> future extensibility<br>* Only allow tlv reco= +rd 0 - unstructured data -> future extensibility</div><div>* Limit maxim= +um size of the value to 256 bytes -> protect 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/pull/22" target=3D"_blank">https://g= +ithub.com/bitcoin-inquisition/bitcoin/pull/22</a> isn't sufficient for = +these types of vaults. If there are two presigned txes (unvault and emergen= +cy), 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 b= +e reconstructed from the schnorr signature. The remaining bytes could be us= +ed for a third presigned tx and/or additional vault parameters.</div><div><= +br></div><div>Can you think of remaining practical objections to making the= + annex standard under the conditions listed above?</div><div><br></div><div= +>Joost</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= +.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20= +4,204,204);padding-left:1ex"><div class=3D"gmail_quote"><blockquote class= +=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo= +rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> +</blockquote></div> +</blockquote></div></div> +</blockquote></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> +</blockquote></div> +</blockquote></div> + +--000000000000272c8a05fe7141c0-- + |