Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Hi Joost, > Hopefully this further raises awareness of the on-chain ephemeral signature backup functionality that the annex uniquely enables. >From my perspective, if vault applications can be made more robust by on-chain backing up of ephemeral signatures, this can be rational to make the annex standard. There is the observation that other critical elements of vault's application state could be backed up in this way (e.g pubkeys and amounts of the destination output) to rebuild from scratch a pre-signed withdrawal. The unstructured data could be even marked by an application-level "tag" or "signaling" to identify all the backup annexes composing your vault application state. Of course, such backing up of more critical elements comes with its own drawbacks in terms of confidentiality, as you would leak your vault policy on-chain, so they would need to be ciphered first, I think. It sounds to me another economically rational set of use-cases can be to simplify protocols using the chain as a publication space for collectibles. Using the annex as a publication space enables a clear chain of collectible ownership thanks to the key signing the annex, which is not permissible with op_return outputs today. Best, Antoine Le mar. 20 juin 2023 à 13:30, Joost Jager a écrit : > Hi all, > > On Sat, Jun 10, 2023 at 9:43 AM Joost Jager wrote: > >> However, the primary advantage I see in the annex is that its data isn't >> included in the calculation of the txid or a potential parent commit >> transaction's txid (for inscriptions). I've explained this at [1]. This >> feature makes the annex a powerful tool for applications that would ideally >> use covenants. >> >> The most critical application in this category, for me, involves >> time-locked vaults. Given the positive reception to proposals such as >> OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probably >> a bit further out, but pre-signed transactions signed using an ephemeral >> key can fill the gap and improve the safeguarding of Bitcoin in the short >> term. >> >> Backing up the ephemeral signatures of the pre-signed transactions on the >> blockchain itself is an excellent way to ensure that the vault can always >> be 'opened'. However, without the annex, this is not as safe as it could >> be. Due to the described circular reference problem, the vault creation and >> signature backup can't be executed in one atomic operation. For example, >> you can store the backup in a child commit/reveal transaction set, but the >> vault itself can be confirmed independently and the backup may never >> confirm. If you create a vault and lose the ephemeral signatures, the funds >> will be lost. >> >> This use case for the annex has been labeled 'speculative' elsewhere. To >> me, every use case appears speculative at this point because the annex >> isn't available. However, if you believe that time-locked vaults are >> important for Bitcoin and also acknowledge that soft forks, such as the one >> required for OP_VAULT, aren't easy to implement, I'd argue that the >> intermediate solution described above is very relevant. >> > > To support this use case of the taproot annex, I've create a simple demo > application here: https://github.com/joostjager/annex-covenants > > This demo shows how a coin can be spent to a special address from which it > can - at a later stage - only move to a pre-defined final destination. It > makes use of the annex to store the ephemeral signature for the presigned > transaction so that the coin cannot get lost. This is assuming that nodes > do not prune witness data en masse and also that the destination address > itself is known. > > The application may not be the most practically useful, but more advanced > covenants such as time-locked vaults can be implemented similarly. > > Hopefully this further raises awareness of the on-chain ephemeral > signature backup functionality that the annex uniquely enables. > > Joost > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Hi all, On Sat, Jun 10, 2023 at 9:43 AM Joost Jager wrote: > However, the primary advantage I see in the annex is that its data isn't > included in the calculation of the txid or a potential parent commit > transaction's txid (for inscriptions). I've explained this at [1]. This > feature makes the annex a powerful tool for applications that would ideally > use covenants. > > The most critical application in this category, for me, involves > time-locked vaults. Given the positive reception to proposals such as > OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probably > a bit further out, but pre-signed transactions signed using an ephemeral > key can fill the gap and improve the safeguarding of Bitcoin in the short > term. > > Backing up the ephemeral signatures of the pre-signed transactions on the > blockchain itself is an excellent way to ensure that the vault can always > be 'opened'. However, without the annex, this is not as safe as it could > be. Due to the described circular reference problem, the vault creation and > signature backup can't be executed in one atomic operation. For example, > you can store the backup in a child commit/reveal transaction set, but the > vault itself can be confirmed independently and the backup may never > confirm. If you create a vault and lose the ephemeral signatures, the funds > will be lost. > > This use case for the annex has been labeled 'speculative' elsewhere. To > me, every use case appears speculative at this point because the annex > isn't available. However, if you believe that time-locked vaults are > important for Bitcoin and also acknowledge that soft forks, such as the one > required for OP_VAULT, aren't easy to implement, I'd argue that the > intermediate solution described above is very relevant. > To support this use case of the taproot annex, I've create a simple demo application here: https://github.com/joostjager/annex-covenants This demo shows how a coin can be spent to a special address from which it can - at a later stage - only move to a pre-defined final destination. It makes use of the annex to store the ephemeral signature for the presigned transaction so that the coin cannot get lost. This is assuming that nodes do not prune witness data en masse and also that the destination address itself is known. The application may not be the most practically useful, but more advanced covenants such as time-locked vaults can be implemented similarly. Hopefully this further raises awareness of the on-chain ephemeral signature backup functionality that the annex uniquely enables. Joost ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Hi Antoine, On Sun, Jun 18, 2023 at 10:32 PM Antoine Riard wrote: > > * 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 ? > No what I meant, and what was mentioned by Greg in a previous email, is that either none of the inputs have an annex, or all of them have one. So if you're part of a multi-party transaction and you don't commit to an annex, you can be sure that no version of that tx will appear where another signer surprises you with a potentially large annex. For future protocols that rely on the annex, everyone would need to opt-in by committing to an annex (which can be empty just to signal opt-in). Joost ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
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 à 21:41, Greg Sanders a écrit : > 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 and > 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 PM Antoine Riard > 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 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 >>> wrote: >>> Hi Greg, On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders 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
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
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 wrote: > >> Hi Greg, >> >> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders >> 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
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
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 and 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 PM Antoine Riard 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 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 >> wrote: >> >>> Hi Greg, >>> >>> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders >>> 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
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
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 wrote: > Hi Greg, > > On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders > 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
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Hi Greg, On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders 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
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
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 the last signer presenting an unexpected annex. The downside is just that extra empty annex byte per input, if there are other inputs involved. To me that 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
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 AM Joost Jager 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 the > last signer presenting an unexpected annex. The downside is just that extra > empty annex byte per input, if there are other inputs involved. To me that > 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. > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
On Tue, Jun 13, 2023 at 10:51 AM David A. Harding wrote: > > I am really looking for a bitcoin-native solution to leverage > > bitcoin's robustness and security properties. > > I understand. I would briefly point out that there are other advantages > to not storing a signature for an ephemeral key in the annex. For > example, if you want to generate multiple different potential spending > transactions, you need to store one signature for each potential > transaction. The more data you store in the annex, the less scalable > the vault protocol becomes; by comparison, it's possible to cheaply > store a very large amount of data offchain with high robustness. > Each byte on-chain indeed has a cost. Though for practical vault usage, you may only need two spend paths - one for the unvaulting transaction and another for an emergency transaction. Also, depending on construction of the vault, a possible advantage of a > presigned vault (without using the annex) over a solution like OP_VAULT > is that all actions might be able to use keypath spends. That would be > highly efficient, increasing the usability of vaults. It would also be > more private, which may be important to certain classes of vault users. > Even if OP_VAULT was added to Bitcoin, it would be interesting to have > an alternative vault protocol that offered different tradeoffs. > It would indeed be interesting to compare the on-chain footprint of both vault protocols. The main downside of presigned transactions of course is the requirement for an ephemeral signer and key deletion. I am not sure if a potentially smaller on-chain footprint is able to compensate for that. But the landscape of tradeoffs is complicated, and hard to say what users prefer if both options would be available to them. > > That years-long timeline that you sketch for witness replacement (or > > any other policy change I presume?) to become effective is perhaps > > indicative of the need to have an alternative way to relay > > transactions to miners besides the p2p network? > > The speed depends on the policy change. In this case, I think there's a > reasonable argument to be made that a mitigation for the problems of > annex relay should be widely deployed before we enable annex relay. > On the other hand, maybe we are inside a window of opportunity where the annex can still be enabled without mitigating this problem fully. Taproot is still young and you could argue that there are not that many applications that would be affected by this yet. By clearly communicating the lack of witness replacement by commonly used node software now, developers may want to hold off on implementing these applications, rather than giving them a false sense of security offered by policy. But we've covered that in this thread before. > To be specific towards this proposal, if an alternative relay network > naively implemented annex relay, any miners who used that network could > receive a coinjoin-style transaction with a large annex that > significantly reduced the transaction's feerate. By comparison, any > miners who continued to only receive transactions from the P2P network > of Bitcoin Core (or similar) nodes would have received the transaction > without an annex at its original (higher) feerate, allowing them to to > receive greater revenue if they mined it. If, instead, the alternative > relay network implemented the witness replacement proposal you've linked > to, those miners could still receive up to 4.99% less revenue than > Bitcoin Core-based miners Perhaps way to fix this is to combine the 5% (or whatever constant is chosen) with Greg's proposal above to also always allow replacement by an empty annex? That way it's always possible to put in an annex-less transaction that is part of an annex-less protocol, regardless of how few extra bytes the annex was inflated with in a previous version of that tx. > and the operators of the alternative relay > network might have had to pay extra costs for the replacement relays. > You can tweak the proposal to tweak those ratios, but I'm not sure > there's a case where an alternative relay network comes up as a clear > winner over the existing network for general purpose transactions. > Instead, like many things, it's a matter of tradeoffs. > It is the question whether those 5% replacement DoS attacks are powerful enough to make it worthwhile for an attacker. And in the case for example the nostr proposal, there could be anti DoS on a different level as well. > > I agree though that it would be ideal if there is a good solution that > > doesn't require any protocol changes or upgrade path. > > Apologies for the salt, but there is a good solution: don't use the > block chain to store backup data. > Any auxiliary system that is required for operating a vault adds risk. Whether it is still good enough is debatable, but I expect some users to hold the opinion that it isn't. Joost
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
On 2023-06-11 09:25, Joost Jager wrote: Isn't it the case that that op-dropped partial signature for the ephemeral key isn't committed to and thus can be modified by anyone before it is mined That's correct; I hadn't thought of that, sorry. I am really looking for a bitcoin-native solution to leverage bitcoin's robustness and security properties. I understand. I would briefly point out that there are other advantages to not storing a signature for an ephemeral key in the annex. For example, if you want to generate multiple different potential spending transactions, you need to store one signature for each potential transaction. The more data you store in the annex, the less scalable the vault protocol becomes; by comparison, it's possible to cheaply store a very large amount of data offchain with high robustness. Also, depending on construction of the vault, a possible advantage of a presigned vault (without using the annex) over a solution like OP_VAULT is that all actions might be able to use keypath spends. That would be highly efficient, increasing the usability of vaults. It would also be more private, which may be important to certain classes of vault users. Even if OP_VAULT was added to Bitcoin, it would be interesting to have an alternative vault protocol that offered different tradeoffs. That years-long timeline that you sketch for witness replacement (or any other policy change I presume?) to become effective is perhaps indicative of the need to have an alternative way to relay transactions to miners besides the p2p network? The speed depends on the policy change. In this case, I think there's a reasonable argument to be made that a mitigation for the problems of annex relay should be widely deployed before we enable annex relay. Bitcoin Core's policy is designed to both prevent the abuse of relay node resources and also serve the transaction selection needs of miners. Any alternative relay system will need to solve the same general problems: how to prevent abuse of the relayers and help miners choose the best transactions. Ideas for alternative relay like those previously proposed on this list[1] avoid certain problems but also (AFAICT) create new problems. To be specific towards this proposal, if an alternative relay network naively implemented annex relay, any miners who used that network could receive a coinjoin-style transaction with a large annex that significantly reduced the transaction's feerate. By comparison, any miners who continued to only receive transactions from the P2P network of Bitcoin Core (or similar) nodes would have received the transaction without an annex at its original (higher) feerate, allowing them to to receive greater revenue if they mined it. If, instead, the alternative relay network implemented the witness replacement proposal you've linked to, those miners could still receive up to 4.99% less revenue than Bitcoin Core-based miners and the operators of the alternative relay network might have had to pay extra costs for the replacement relays. You can tweak the proposal to tweak those ratios, but I'm not sure there's a case where an alternative relay network comes up as a clear winner over the existing network for general purpose transactions. Instead, like many things, it's a matter of tradeoffs. I agree though that it would be ideal if there is a good solution that doesn't require any protocol changes or upgrade path. Apologies for the salt, but there is a good solution: don't use the block chain to store backup data. -Dave [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021700.html ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
> Regarding the potential payload extension attack, I believe that the changes proposed in the [3] to allow tx replacement by smaller witness would provide a viable solution? The only plausible case I could see moving forward is replacing the transaction to a form that has *no* annex or scriptpath spends, ala https://github.com/bitcoin/bitcoin/pull/24007#issuecomment-1308104119 . It's much easier to think about one-off replacements from an anti-DoS perspective. We would have to think a lot harder if that actually solves the problem and maintains the prospective use-cases before diving into analysis, regardless. Cheers, Greg On Sat, Jun 10, 2023 at 5:02 AM Joost Jager via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Antoine, > > On Sat, Jun 10, 2023 at 2:23 AM Antoine Riard > wrote: > >> From a taproot annex design perspective, I think this could be very >> valuable if you have a list of unstructured data use-cases you're thinking >> about ? >> > > The annex's list of unstructured data use-cases includes existing data > storage uses that utilize OP_RETURN or inscriptions. Consider ordinals, > timestamps, and any other data already stored on the chain. These > applications would immediately benefit from the annex's improved space > efficiency. > > However, the primary advantage I see in the annex is that its data isn't > included in the calculation of the txid or a potential parent commit > transaction's txid (for inscriptions). I've explained this at [1]. This > feature makes the annex a powerful tool for applications that would ideally > use covenants. > > The most critical application in this category, for me, involves > time-locked vaults. Given the positive reception to proposals such as > OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probably > a bit further out, but pre-signed transactions signed using an ephemeral > key can fill the gap and improve the safeguarding of Bitcoin in the short > term. > > Backing up the ephemeral signatures of the pre-signed transactions on the > blockchain itself is an excellent way to ensure that the vault can always > be 'opened'. However, without the annex, this is not as safe as it could > be. Due to the described circular reference problem, the vault creation and > signature backup can't be executed in one atomic operation. For example, > you can store the backup in a child commit/reveal transaction set, but the > vault itself can be confirmed independently and the backup may never > confirm. If you create a vault and lose the ephemeral signatures, the funds > will be lost. > > This use case for the annex has been labeled 'speculative' elsewhere. To > me, every use case appears speculative at this point because the annex > isn't available. However, if you believe that time-locked vaults are > important for Bitcoin and also acknowledge that soft forks, such as the one > required for OP_VAULT, aren't easy to implement, I'd argue that the > intermediate solution described above is very relevant. > > >> As raised on the BIP proposal, those unstructured data use-cases could >> use annex tags with the benefit to combine multiple "types" of unstructured >> data in a single annex payload. As you're raising smaller bits of >> unstructured data might not afford the overhead though my answer with this >> observation would be to move this traffic towards some L2 systems ? In my >> mind, the default of adding a version byte for the usage of unstructured >> data comes with the downside of having future consensus enabled use-cases >> encumbering by the extended witness economic cost. >> > > When it comes to the trade-offs associated with various encodings, I fully > acknowledge their existence. The primary motivation behind my proposal to > adopt a simple approach to the Taproot annex is to avoid a potentially long > standardization process. While I am not entirely familiar with the > decision-making process of Bitcoin Core, my experience with other projects > suggests that simpler changes often encounter less resistance and can be > implemented more swiftly. Perhaps I am being overly cautious here, though. > > >> About the annex payload extension attack described by Greg. If my >> understanding of this transaction-relay jamming griefing issue is correct, >> we can have an annex tag in the future where the signer is committing to >> the total weight of the transaction, or even the max per-input annex size ? >> This should prevent a coinjoin or aggregated commitment transaction >> counterparty to inflate its annex space to downgrade the overall >> transaction feerate, I guess. And I think this could benefit unstructured >> data use-cases too. >> > > Regarding the potential payload extension attack, I believe that the > changes proposed in the [3] to allow tx replacement by smaller witness > would provide a viable solution? > > Joost > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021737.html > [2]
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Hi Joost, > However, the primary advantage I see in the annex is that its data isn't included in the calculation of the txid or a potential parent commit transaction's txid (for inscriptions). I've explained this at [1]. This > feature makes the annex a powerful tool for applications that would ideally use covenants. I share the observation that the annex data not being committed in the parent txid is very powerful for use-cases that would use covenants. E.g there could be an alternative design of CoinPool based on Grafroot, where the signed surrogate scripts authorized withdrawal abilities [0]. Once consumed the signed surrogate shouldn't be replayable against the clawback pool output, and the signature of the surrogate added as "toxic" in a cryptographic accumulator. Efficient set test membership can be realized to refuse pool output spend attempts with consumed surrogate scripts. The annex is a perfect emplacement to locate such an accumulator in the future as the state of the accumulator cannot be predicted as pool setup time and is a function of the effective order withdrawal. Note with Taproot-based design, the replay protection is achieved by the removal from the taproot tree as edited by any contracting primitive during the withdrawal phase (e.g TLUV). > When it comes to the trade-offs associated with various encodings, I fully acknowledge their existence. The primary motivation behind my proposal to adopt a simple approach to the Taproot annex is to > avoid a potentially long standardization process. While I am not entirely familiar with the decision-making process of Bitcoin Core, my experience with other projects suggests that simpler changes often > encounter less resistance and can be implemented more swiftly. Perhaps I am being overly cautious here, though. I fully understand the motivation to avoid a lengthy standardization process, which can be a source of frustration for everyone, including the standard champions themselves. Indeed, no one lacks the bureaucratic-style of standardization process for their own sake. Long standardization processes in Bitcoin consensus are better explained by the number of technical dimensions to weigh in terms of designs (e.g full-nodes ressources scalability, fee economic costs, confidentiality, composability with other changes). And due to the asynchronous nature of FOSS development, every domain expert is constantly jungling between different engineering contributions priorities (e.g for myself currently package relay and mempool for L2s). All that said, to make the conversation of annex standardization more practical, and aiming to compose with all technical interest expressed, I can think about a 2 phase process, at least. Such standardization process reflects only my opinion, and is based on the experience of recent mempool fullrbf partial deployment experience, the Core's trends to have tracking issues for substantial changes, bitcoin-inquisition and the bitcoin contracting primitives WG experiences. Phase 1: - a BIP proposal for the TLV records + code (almost done with #9 in bitcoin-inquisition and #1421 in the bips repository) - a BIP proposal to reserve "tag 0" for unstructured data + code (let's say in bitcoin-inquisition) - anti-DoS mempool/transaction-relay/replacement code (same) - bonus point: documenting the new mempool/replacement rules like in Core's `doc/policy` - preferential peering logic working code (there is already some code with Core's #25600) - opt-in activation of the annex validation rules - engage Bitcoin devs appreciated by the community as domain experts in the covered areas to collect more relevant technical feedbacks Phase 2: - submit the annex branch with all the features on the Bitcoin Core repository - communicate to the Bitcoin technical community at large the existence of the proposal e.g dev mail list, technical newsletters - communicate to the second-layers and unstructured data application maintainers the existence of the proposal - integrate the feedback from Bitcoin Core, Bitcoin users and second-layers communities in a "staging code branch" - if there is a deep technical objection, go back to phase 1 (e.g a competing serializing proposal for the annex) - otherwise, split the annex reference branch core in logical chunks for optimal review process This is what an efficient-yet-decentralized standardization process of the annex would look like to me, I don't know. About when we can expect a deployment of new policy rules for the annex, as Dave made me the (grounded) reprimand on the list a while back, I don't think mentioning a date or software version release is appropriate. And this to avoid creating a sense of commitment on all the contributors involved in the projects above mentioned. I'm still interested in championing the "base" TLV serialization annex code and BIP. To move faster, I think it would be better to have another champion on the "tag 0" and BIP, especially as the unstructured data
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Hi Dave, On Sun, Jun 11, 2023 at 12:10 AM David A. Harding wrote: > 3. When paying the script in #2, Alice chooses the scriptpath spend from > #1 and pushes a serialized partial signature for the ephemeral key > from #2 onto the stack, where it's immediately dropped by the > interpreter (but is permanently stored on the block chain). She also > attaches a regular signature for the OP_CHECKSIG opcode. > Isn't it the case that that op-dropped partial signature for the ephemeral key isn't committed to and thus can be modified by anyone before it is mined, effectively deleting the keys to the vault? If not, this would be a great alternative! Even better, I think you can achieve nearly the same safety without > putting any data on the chain. All you need is a widely used > decentralized protocol that allows anyone who can prove ownership of a > UTXO to store some data. > I appreciate the suggestion, but I am really looking for a bitcoin-native solution to leverage bitcoin's robustness and security properties. By comparison, rolling > out relay of the annex and witness replacement may take months of review > and years for >90% deployment among nodes, would allow an attacker to > lower the feerate of coinjoin-style transactions by up to 4.99%, would > allow an attacker to waste 8 million bytes of bandwidth per relay node > for the same cost they'd have to pay to today to waste 400 thousand > bytes, and might limit the flexibility and efficiency of future > consensus changes that want to use the annex. That years-long timeline that you sketch for witness replacement (or any other policy change I presume?) to become effective is perhaps indicative of the need to have an alternative way to relay transactions to miners besides the p2p network? I agree though that it would be ideal if there is a good solution that doesn't require any protocol changes or upgrade path. Joost ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
On 2023-06-09 21:43, Joost Jager via bitcoin-dev wrote: The most critical application in this category, for me, involves time-locked vaults. [...] Backing up the ephemeral signatures of the pre-signed transactions on the blockchain itself is an excellent way to ensure that the vault can always be 'opened'. However, without the annex, this is not as safe as it could be. Due to the described circular reference problem, the vault creation and signature backup can't be executed in one atomic operation. Hi Joost, For the purpose of experimenting with vaults, I don't think you need the most efficient construction---instead, anything that works without too much overhead is probably ok. In that case, I don't think you need the annex at all: 1. Alice can receive new payments to tr(, raw(OP_DROP OP_CHECKSIG)) 2. Later, Alice creates tr(MuSig2(, )) 3. When paying the script in #2, Alice chooses the scriptpath spend from #1 and pushes a serialized partial signature for the ephemeral key from #2 onto the stack, where it's immediately dropped by the interpreter (but is permanently stored on the block chain). She also attaches a regular signature for the OP_CHECKSIG opcode. Alternatively, if Alice decides she doesn't want to pay into a vault, she uses the keypath spend from #1 with no loss in efficiency. The scriptpath solution requires some extra preparation on Alice's part and costs about a dozen vbytes extra over using the annex, which feels acceptable to me to avoid the problems identified with using the annex. Even better, I think you can achieve nearly the same safety without putting any data on the chain. All you need is a widely used decentralized protocol that allows anyone who can prove ownership of a UTXO to store some data. You can think of LN gossip as being a version of this: anyone who proves ownership of a P2WSH 2-of-2 script is allowed to store data in a certain format on every LN routing node. Rusty Russell's v2 gossip proposal makes this a bit more generic, but I think you could make it even more generic by creating a simple server that stores and forwards a single BIP322 signed message up to size x for any entry in the current UTXO set, with periodic replacement of the signed message allowed. The signed data could be LN routing information or it could be arbitrary data like a signature from an ephemeral key (or it could even be a JPEG or other data irrelevant to processing payments). Any full node (including pruned and utreexo nodes) can trustlessly provide UTXO lookup for such a server and a decentralized network of such servers could be useful by a large number of protocols, encouraging hundreds or thousands of servers to be operated---providing similar data availability guarantees to committing data on the block chain, but without the permanent footprint (i.e., once a UTXO is spent, the associated data can be deleted). Many vault designs already effectively require watchtowers, so it'd be easy to make this simple server part of the watchtower. Regarding the potential payload extension attack, I believe that the changes proposed in the [3] to allow tx replacement by smaller witness would provide a viable solution? [...] [3] https://github.com/bitcoin/bitcoin/pull/24007 The two solutions identified above (OP_DROP and decentralized storage for UTXO owners) can be implemented immediately. By comparison, rolling out relay of the annex and witness replacement may take months of review and years for >90% deployment among nodes, would allow an attacker to lower the feerate of coinjoin-style transactions by up to 4.99%, would allow an attacker to waste 8 million bytes of bandwidth per relay node for the same cost they'd have to pay to today to waste 400 thousand bytes, and might limit the flexibility and efficiency of future consensus changes that want to use the annex. -Dave ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Hi Antoine, On Sat, Jun 10, 2023 at 2:23 AM Antoine Riard wrote: > From a taproot annex design perspective, I think this could be very > valuable if you have a list of unstructured data use-cases you're thinking > about ? > The annex's list of unstructured data use-cases includes existing data storage uses that utilize OP_RETURN or inscriptions. Consider ordinals, timestamps, and any other data already stored on the chain. These applications would immediately benefit from the annex's improved space efficiency. However, the primary advantage I see in the annex is that its data isn't included in the calculation of the txid or a potential parent commit transaction's txid (for inscriptions). I've explained this at [1]. This feature makes the annex a powerful tool for applications that would ideally use covenants. The most critical application in this category, for me, involves time-locked vaults. Given the positive reception to proposals such as OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probably a bit further out, but pre-signed transactions signed using an ephemeral key can fill the gap and improve the safeguarding of Bitcoin in the short term. Backing up the ephemeral signatures of the pre-signed transactions on the blockchain itself is an excellent way to ensure that the vault can always be 'opened'. However, without the annex, this is not as safe as it could be. Due to the described circular reference problem, the vault creation and signature backup can't be executed in one atomic operation. For example, you can store the backup in a child commit/reveal transaction set, but the vault itself can be confirmed independently and the backup may never confirm. If you create a vault and lose the ephemeral signatures, the funds will be lost. This use case for the annex has been labeled 'speculative' elsewhere. To me, every use case appears speculative at this point because the annex isn't available. However, if you believe that time-locked vaults are important for Bitcoin and also acknowledge that soft forks, such as the one required for OP_VAULT, aren't easy to implement, I'd argue that the intermediate solution described above is very relevant. > As raised on the BIP proposal, those unstructured data use-cases could use > annex tags with the benefit to combine multiple "types" of unstructured > data in a single annex payload. As you're raising smaller bits of > unstructured data might not afford the overhead though my answer with this > observation would be to move this traffic towards some L2 systems ? In my > mind, the default of adding a version byte for the usage of unstructured > data comes with the downside of having future consensus enabled use-cases > encumbering by the extended witness economic cost. > When it comes to the trade-offs associated with various encodings, I fully acknowledge their existence. The primary motivation behind my proposal to adopt a simple approach to the Taproot annex is to avoid a potentially long standardization process. While I am not entirely familiar with the decision-making process of Bitcoin Core, my experience with other projects suggests that simpler changes often encounter less resistance and can be implemented more swiftly. Perhaps I am being overly cautious here, though. > About the annex payload extension attack described by Greg. If my > understanding of this transaction-relay jamming griefing issue is correct, > we can have an annex tag in the future where the signer is committing to > the total weight of the transaction, or even the max per-input annex size ? > This should prevent a coinjoin or aggregated commitment transaction > counterparty to inflate its annex space to downgrade the overall > transaction feerate, I guess. And I think this could benefit unstructured > data use-cases too. > Regarding the potential payload extension attack, I believe that the changes proposed in the [3] to allow tx replacement by smaller witness would provide a viable solution? Joost [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021737.html [2] https://github.com/bitcoin/bips/pull/1421 [3] https://github.com/bitcoin/bitcoin/pull/24007 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Hi Joost, Thanks for detailing why a '0' as free-form, without any additional constraints offers valuable engineering properties as of today. >From a taproot annex design perspective, I think this could be very valuable if you have a list of unstructured data use-cases you're thinking about ? As raised on the BIP proposal, those unstructured data use-cases could use annex tags with the benefit to combine multiple "types" of unstructured data in a single annex payload. As you're raising smaller bits of unstructured data might not afford the overhead though my answer with this observation would be to move this traffic towards some L2 systems ? In my mind, the default of adding a version byte for the usage of unstructured data comes with the downside of having future consensus enabled use-cases encumbering by the extended witness economic cost. About the annex payload extension attack described by Greg. If my understanding of this transaction-relay jamming griefing issue is correct, we can have an annex tag in the future where the signer is committing to the total weight of the transaction, or even the max per-input annex size ? This should prevent a coinjoin or aggregated commitment transaction counterparty to inflate its annex space to downgrade the overall transaction feerate, I guess. And I think this could benefit unstructured data use-cases too. Best, Antoine Le ven. 2 juin 2023 à 22:18, Joost Jager via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > Hi, > > As it stands, the taproot annex is consensus valid but non-standard. The > conversations around standardization seem to be leaning towards the > adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt > that this approach has considerable potential. However, settling on an > exact format may require a significant amount of time. > > In the interim, the benefits of making the annex available in a > non-structured form are both evident and immediate. By allowing developers > to utilize the taproot annex without delay, we can take advantage of its > features today, without the need to wait for the finalization of a more > lengthy standardization process. > > With this in view, I am proposing that we define any annex that begins > with '0' as free-form, without any additional constraints. This strategy > offers several distinct benefits: > > Immediate utilization: This opens the door for developers to make use of > the taproot annex for a variety of applications straight away, thus > eliminating the need to wait for the implementation of TLV or any other > structured format. > > Future flexibility: Assigning '0'-beginning annexes as free-form keeps our > options open for future developments and structure improvements. As we > forge ahead in determining the best way to standardize the annex, this > strategy ensures we do not limit ourselves by setting its structure in > stone prematurely. > > Chainspace efficiency: Non-structured data may require fewer bytes > compared to a probable TLV format, which would necessitate the encoding of > length even when there's only a single field. > > In conclusion, adopting this approach will immediately broaden the > utilization scope of the taproot annex while preserving the possibility of > transitioning to a more structured format in the future. I believe this is > a pragmatic and efficient route, one that can yield substantial benefits in > both the short and long term. > > Joost > > [1] https://github.com/bitcoin/bips/pull/1381 > ___ > 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
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Hi, In the proposal below, any annex that begins with `0x00` is defined as free-form. This isn't the most efficient format though because there is always one byte lost on signalling. In a future where unstructured annex data turns out to be the predominant use case, this may be relevant. Also for very short annexes, the lost byte may weigh relatively heavy. Without sacrificing future extensions to structured annex data, one could also store the annex data as is except for the case where the data starts with `0x21` (or any other 'uncommon' byte). If the data starts with `0x21`, this byte needs to be repeated first and then followed by the remainder of the data. Examples: Data: [01 02 03] Encoding [01 02 03] Data: [21 22 23] Encoding: [21 21 22 23] The prefixes [21 (not 21)] are available for future upgrades. Joost On Fri, Jun 2, 2023 at 5:00 PM Joost Jager wrote: > Hi, > > As it stands, the taproot annex is consensus valid but non-standard. The > conversations around standardization seem to be leaning towards the > adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt > that this approach has considerable potential. However, settling on an > exact format may require a significant amount of time. > > In the interim, the benefits of making the annex available in a > non-structured form are both evident and immediate. By allowing developers > to utilize the taproot annex without delay, we can take advantage of its > features today, without the need to wait for the finalization of a more > lengthy standardization process. > > With this in view, I am proposing that we define any annex that begins > with '0' as free-form, without any additional constraints. This strategy > offers several distinct benefits: > > Immediate utilization: This opens the door for developers to make use of > the taproot annex for a variety of applications straight away, thus > eliminating the need to wait for the implementation of TLV or any other > structured format. > > Future flexibility: Assigning '0'-beginning annexes as free-form keeps our > options open for future developments and structure improvements. As we > forge ahead in determining the best way to standardize the annex, this > strategy ensures we do not limit ourselves by setting its structure in > stone prematurely. > > Chainspace efficiency: Non-structured data may require fewer bytes > compared to a probable TLV format, which would necessitate the encoding of > length even when there's only a single field. > > In conclusion, adopting this approach will immediately broaden the > utilization scope of the taproot annex while preserving the possibility of > transitioning to a more structured format in the future. I believe this is > a pragmatic and efficient route, one that can yield substantial benefits in > both the short and long term. > > Joost > > [1] https://github.com/bitcoin/bips/pull/1381 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
On Sat, Jun 03, 2023 at 11:14:27AM +0200, Joost Jager via bitcoin-dev wrote: > 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? In the specific case of annex replacement leading to larger transactions, in almost all cases you only care about the annex malleability causing the transaction to take longer to get mined, due to it being larger. The fact the transaction has become larger does not matter if the transaction does in fact get mined, eg due to an out-of-band payment by the "attacker". The only exception is the rare cases where some transaction processing software/hardware has actual limits on transaction size. Eg you could imagine a hardware wallet that simply *can't* process a transaction larger than a certain size due to a lack of RAM. I don't think this is a good rational to make use of the annex standard. Quite the contrary: we should be thinking about if and how to fix annex malleability in a future soft fork. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
On Sat, Jun 3, 2023 at 2:43 PM Greg Sanders wrote: > No in this case the txid is identical. Only the wtxid is malleated, with > annex data stuffed to max transaction size. > This doesn't sound incentive compatible? While gathering context, I did find https://github.com/bitcoin/bitcoin/pull/24007. Apparently closed because of a lack of use case. But perhaps the desire to not limit the annex can revive that proposal? Joost > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
> > > 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. > > The issue I'm talking about is where someone's transaction is denied entry > into the mempool entirely because a counter-party decided to put in a > strictly worse transaction for miners by bloating the weight of it, not > adding fees. A strictly worse "API" for paying miners for no gain seems > like a bad trade to me, especially when there are reasonable methods for > mitigating this. > Just to expand this, an example would be a transaction with inputs A' and B' signed by two parties A and B. A has a fully signed transaction in hands, but can't publish it because B created and published an alternative version of it with a large annex for input B'. Wouldn't miners just accept A's version because it's fee rate is higher? I am looking at this case assuming the user has a direct connection to a miner, ignoring any potential concerns related to p2p transport. Joost ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
No in this case the txid is identical. Only the wtxid is malleated, with annex data stuffed to max transaction size. Cheers, Greg On Sat, Jun 3, 2023, 8:36 AM Joost Jager wrote: > > 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. >> >> The issue I'm talking about is where someone's transaction is denied >> entry into the mempool entirely because a counter-party decided to put in a >> strictly worse transaction for miners by bloating the weight of it, not >> adding fees. A strictly worse "API" for paying miners for no gain seems >> like a bad trade to me, especially when there are reasonable methods for >> mitigating this. >> > > Just to expand this, an example would be a transaction with inputs A' and > B' signed by two parties A and B. A has a fully signed transaction in > hands, but can't publish it because B created and published an alternative > version of it with a large annex for input B'. Wouldn't miners just accept > A's version because it's fee rate is higher? I am looking at this case > assuming the user has a direct connection to a miner, ignoring any > potential concerns related to p2p transport. > > Joost > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
> I think this avoidance of a circular reference is also why LN-Symmetry uses the annex? The annex trick specifically is used to force the publication of the missing piece of the control block corresponding to the new taproot output. This is to maintain the node's O(1) state while also keeping 0.5RTT channel updates. Could have also been done with a dangling OP_RETURN, with the associated restrictions on which sighashes you can use since you now have to commit to multiple outputs(disallows SIGHASH_SINGLE). There's also a fair exchange protocol that obviates the need for it using signature adapters, but the requisite APIs don't exist yet, and doesn't lend itself naturally to 3+ party scenarios. > 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. The issue I'm talking about is where someone's transaction is denied entry into the mempool entirely because a counter-party decided to put in a strictly worse transaction for miners by bloating the weight of it, not adding fees. A strictly worse "API" for paying miners for no gain seems like a bad trade to me, especially when there are reasonable methods for mitigating this. > 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? Mempool policy should be an attempt to bridge the gap between node anti-DoS and an entity's ability to pay miners more via feerate-ordered queue. I don't think the answer to this problem is to zero out all ability to limit the sizes of multi-party, multi-input transactions for speculative use cases. Greg On Sat, Jun 3, 2023 at 7:31 AM Joost Jager via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Jun 3, 2023 at 9:49 AM Joost Jager wrote: > >> The removal of the need for a commitment transaction also enables the >> inclusion of data within a single transaction that relies on its own >> transaction identifier (txid). This is possible because the txid >> calculation does not incorporate the annex, where the data would be housed. >> This feature can be beneficial in scenarios that require the emulation of >> covenants through the use of presigned transactions involving an ephemeral >> signer. >> > > I think this avoidance of a circular reference is also why LN-Symmetry > uses the annex? > > 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
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
HI Greg, On Sat, Jun 3, 2023 at 3:14 AM Greg Sanders 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_r1143382264 > . > > 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 into > 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 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. > 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
On Sat, Jun 3, 2023 at 9:49 AM Joost Jager wrote: > The removal of the need for a commitment transaction also enables the > inclusion of data within a single transaction that relies on its own > transaction identifier (txid). This is possible because the txid > calculation does not incorporate the annex, where the data would be housed. > This feature can be beneficial in scenarios that require the emulation of > covenants through the use of presigned transactions involving an ephemeral > signer. > I think this avoidance of a circular reference is also why LN-Symmetry uses the annex? Joost ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Hi David, On Sat, Jun 3, 2023 at 3:08 AM David A. Harding wrote: > Out of curiosity, what features and benefits are available today? I > know Greg Sanders wants to use annex data with LN-Symmetry[1], but > that's dependent on a soft fork of SIGHASH_ANYPREVOUT. I also heard you > mention that it could allow putting arbitrary data into a witness > without having to commit to that data beforehand, but that would only > increase the efficiency of witness stuffing like ordinal inscriptions by > only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be > required to create an output in order to spend it. > Indeed, there's a minor efficiency gain in the reveal transaction witness, but I think the real advantage is that it eliminates the need to publish and pay for the commit transaction in the first place. Any spend of a taproot UTXO can be supplemented with arbitrary data in just a single transaction. > Is there some other way to use the annex today that would be beneficial > to users of Bitcoin? The removal of the need for a commitment transaction also enables the inclusion of data within a single transaction that relies on its own transaction identifier (txid). This is possible because the txid calculation does not incorporate the annex, where the data would be housed. This feature can be beneficial in scenarios that require the emulation of covenants through the use of presigned transactions involving an ephemeral signer. For instance, one can establish a time-locked vault using 2-of-2 multisig presigned transactions in which one of the signers is ephemeral [1]. After signing, the private key is discarded, leaving only the signature. To ensure the signature is never lost, it can be stored as a backup in the annex of the transaction that the presigned transaction spends. Such an operation would not be possible with a commit/reveal inscription. [1] https://github.com/LedgerHQ/app-bitcoin-new/issues/153 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Hello Joost, David, Thanks for the link to my ln-symmetry draft David. I'd also be curious as to the usage you have in mind Joost. It's probably helpful to cite the most recent discussions on the topic, which is probably https://github.com/bitcoin-inquisition/bitcoin/pull/22 , where bitcoin-inquisition has included the `annexcarrier` option. I have a particular use for APO-enabled payment channel designs that doesn't require consensus meaning, so some effort was put in to try something out there. 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_r1143382264 . 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 into 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 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. 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 Anyways, curious to hear what people think and want to make sure everyone is on the same page. Best, Greg On Fri, Jun 2, 2023 at 9:08 PM David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote: > > the benefits of making the annex available in a > > non-structured form are both evident and immediate. By allowing > > developers to utilize the taproot annex without delay, we can take > > advantage of its features today, > > Hi Joost, > > Out of curiosity, what features and benefits are available today? I > know Greg Sanders wants to use annex data with LN-Symmetry[1], but > that's dependent on a soft fork of SIGHASH_ANYPREVOUT. I also heard you > mention that it could allow putting arbitrary data into a witness > without having to commit to that data beforehand, but that would only > increase the efficiency of witness stuffing like ordinal inscriptions by > only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be > required to create an output in order to spend it. > > Is there some other way to use the annex today that would be beneficial > to users of Bitcoin? > > -Dave > > [1] > > https://github.com/lightning/bolts/compare/master...instagibbs:bolts:eltoo_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800ae2R119 > ___ > 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
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote: the benefits of making the annex available in a non-structured form are both evident and immediate. By allowing developers to utilize the taproot annex without delay, we can take advantage of its features today, Hi Joost, Out of curiosity, what features and benefits are available today? I know Greg Sanders wants to use annex data with LN-Symmetry[1], but that's dependent on a soft fork of SIGHASH_ANYPREVOUT. I also heard you mention that it could allow putting arbitrary data into a witness without having to commit to that data beforehand, but that would only increase the efficiency of witness stuffing like ordinal inscriptions by only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be required to create an output in order to spend it. Is there some other way to use the annex today that would be beneficial to users of Bitcoin? -Dave [1] https://github.com/lightning/bolts/compare/master...instagibbs:bolts:eltoo_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800ae2R119 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Standardisation of an unstructured taproot annex
Hi, As it stands, the taproot annex is consensus valid but non-standard. The conversations around standardization seem to be leaning towards the adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt that this approach has considerable potential. However, settling on an exact format may require a significant amount of time. In the interim, the benefits of making the annex available in a non-structured form are both evident and immediate. By allowing developers to utilize the taproot annex without delay, we can take advantage of its features today, without the need to wait for the finalization of a more lengthy standardization process. With this in view, I am proposing that we define any annex that begins with '0' as free-form, without any additional constraints. This strategy offers several distinct benefits: Immediate utilization: This opens the door for developers to make use of the taproot annex for a variety of applications straight away, thus eliminating the need to wait for the implementation of TLV or any other structured format. Future flexibility: Assigning '0'-beginning annexes as free-form keeps our options open for future developments and structure improvements. As we forge ahead in determining the best way to standardize the annex, this strategy ensures we do not limit ourselves by setting its structure in stone prematurely. Chainspace efficiency: Non-structured data may require fewer bytes compared to a probable TLV format, which would necessitate the encoding of length even when there's only a single field. In conclusion, adopting this approach will immediately broaden the utilization scope of the taproot annex while preserving the possibility of transitioning to a more structured format in the future. I believe this is a pragmatic and efficient route, one that can yield substantial benefits in both the short and long term. Joost [1] https://github.com/bitcoin/bips/pull/1381 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
