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 tag 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 and 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 à 14:31, Greg Sanders via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > 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 AM Joost Jager <joost.ja...@gmail.com> wrote: > >> Hi Greg, >> >> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders <gsander...@gmail.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 can >>> also be used for other anti-pinning efforts(though clearly not sufficient >>> 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=128 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 >> >>> _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
