Swambo, Jacob [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-29 📝 Original message:Hi, While I agree with the ...
📅 Original date posted:2022-04-29
📝 Original message:Hi,
While I agree with the arguments in favour of (optional ANYONECANPAY) APOAS in lieu of CTV in the short-term (given the additional benefit of enabling Eltoo), there's a point to add in favour of CTV (or similar) in the long-term beyond as an optimisation.
With APOAS-based covenants, the signature message algorithm is tied to both the covenant commitment and transaction validation. Coupling these things introduces a trade-off between safety and flexibility with covenant-based applications. E.g. the maximally safe and restricted covenant commits to all inputs and outputs of the transaction (using SIGHASH ALL). However, a less restricted covenant commits to, for example, a single input and a single output (using ANYONECANPAY|SINGLE) but opens itself up to attacks making use of transaction malleability and signature replay. If instead we separate the covenant commitment from the signatures to validate transactions (as with CTV and TXHASH + CHECKSIGFROMSTACK) then we by-pass this trade-off. The flexibility of additional templates with new CTV versions or with the TXHASH primitive seems to me to enable significantly more utility for covenant-based applications.
Best regards,
Jacob Swambo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220429/942ba6fa/attachment.html>;
📝 Original message:Hi,
While I agree with the arguments in favour of (optional ANYONECANPAY) APOAS in lieu of CTV in the short-term (given the additional benefit of enabling Eltoo), there's a point to add in favour of CTV (or similar) in the long-term beyond as an optimisation.
With APOAS-based covenants, the signature message algorithm is tied to both the covenant commitment and transaction validation. Coupling these things introduces a trade-off between safety and flexibility with covenant-based applications. E.g. the maximally safe and restricted covenant commits to all inputs and outputs of the transaction (using SIGHASH ALL). However, a less restricted covenant commits to, for example, a single input and a single output (using ANYONECANPAY|SINGLE) but opens itself up to attacks making use of transaction malleability and signature replay. If instead we separate the covenant commitment from the signatures to validate transactions (as with CTV and TXHASH + CHECKSIGFROMSTACK) then we by-pass this trade-off. The flexibility of additional templates with new CTV versions or with the TXHASH primitive seems to me to enable significantly more utility for covenant-based applications.
Best regards,
Jacob Swambo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220429/942ba6fa/attachment.html>;