{"type":"rich","version":"1.0","author_name":"npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","author_url":"https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-05-07\n📝 Original message:Thanks a lot for the many clarifications.\nYeah, I forgot it wasn't OP_CAT alone, but in combination with other things.\nI guess this wouldn't be a covenants proposal then.\nBut simplicity would enable covenants too indeed, no?\nOr did I get that wrong too?\n\nOn Sat, May 7, 2022 at 5:06 AM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Jorge,\n\u003e\n\u003e \u003e OP_CAT was removed. If I remember correctly, some speculated that\n\u003e perhaps it was removed because it could allow covenants.I don't remember\n\u003e any technical concern about the OP besides enabling covenants.Before it was\n\u003e a common opinion that covenants shouldn't be enabled in bitcoin because,\n\u003e despite having good use case, there are some nasty attacks that are enabled\n\u003e with them too. These days it seems the opinion of the benefits being worth\n\u003e the dangers is quite generalized. Which is quite understandable given that\n\u003e more use cases have been thought since then.\n\u003e\n\u003e I think the more accurate reason for why it was removed is because the\n\u003e following SCRIPT of N size would lead to 2^N memory usage:\n\u003e\n\u003e     OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP\n\u003e OP_CAT OP_DUP OP_CAT ...\n\u003e\n\u003e In particular it was removed at about the same time as `OP_MUL`, which has\n\u003e similar behavior (consider that multiplying two 32-bit numbers results in a\n\u003e 64-bit number, similar to `OP_CAT`ting a vector to itself).\n\u003e\n\u003e `OP_CAT` was removed long before covenants were even expressed as a\n\u003e possibility.\n\u003e\n\u003e Covenants were first expressed as a possibility, I believe, during\n\u003e discussions around P2SH.\n\u003e Basically, at the time, the problem was this:\n\u003e\n\u003e * Some receivers wanted to use k-of-n multisignature for improved security.\n\u003e * The only way to implement this, pre-P2SH, was by putting in the\n\u003e `scriptPubKey` all the public keys.\n\u003e * The sender is the one paying for the size of the `scriptPubKey`.\n\u003e * It was considered unfair that the sender is paying for the security of\n\u003e the receiver.\n\u003e\n\u003e Thus, `OP_EVAL` and the P2SH concept was conceived.\n\u003e Instead of the `scriptPubKey` containing the k-of-n multisignature, you\n\u003e create a separate script containing the public keys, then hash it, and the\n\u003e `scriptPubKey` would contain the hash of the script.\n\u003e By symmetry with the P2PKH template:\n\u003e\n\u003e     OP_DUP OP_HASH160 \u003chash160(pubkey)\u003e OP_EQUALVERIFY OP_CHECKSIG\n\u003e\n\u003e The P2SH template would be:\n\u003e\n\u003e     OP_DUP OP_HASH160 \u003chash160(redeemScript)\u003e OP_EQUALVERIFY OP_EVAL\n\u003e\n\u003e `OP_EVAL` would take the stack top vector and treat it as a Bitcoin SCRIPT.\n\u003e\n\u003e It was then pointed out that `OP_EVAL` could be used to create recursive\n\u003e SCRIPTs by quining using `OP_CAT`.\n\u003e `OP_CAT` was already disabled by then, but people were talking about\n\u003e re-enabling it somehow by restricting the output size of `OP_CAT` to limit\n\u003e the O(2^N) behavior.\n\u003e\n\u003e Thus, since then, `OP_CAT` has been associated with ***recursive***\n\u003e covenants (and people are now reluctant to re-enable it even with a limit\n\u003e on its output size, because recursive covenants).\n\u003e In particular, `OP_CAT` in combination with `OP_CHECKSIGFROMSTACK` and\n\u003e `OP_CHECKSIG`, you could get a deferred `OP_EVAL` and then use `OP_CAT` too\n\u003e to quine.\n\u003e\n\u003e Because of those concerns, the modern P2SH is now \"just a template\" with\n\u003e an implicit `OP_EVAL` of the `redeemScript`, but without any `OP_EVAL`\n\u003e being actually enabled.\n\u003e\n\u003e (`OP_EVAL` cannot replace an `OP_NOP` in a softfork, but it is helpful to\n\u003e remember that P2SH was pretty much what codified the difference between\n\u003e softfork and hardfork, and the community at the time was small enough (or\n\u003e so it seemed) that a hardfork might not have been disruptive.)\n\u003e\n\u003e \u003e Re-enabling OP_CAT with the exact same OP would be a hardfork, but\n\u003e creating a new OP_CAT2 that does the same would be a softfork.\n\u003e\n\u003e If you are willing to work in Taproot the same OP-code can be enabled in a\n\u003e softfork by using a new Tapscript version.\n\u003e\n\u003e If you worry about quantum-computing-break, a new SegWit version (which is\n\u003e more limited than Tapscript versions, unfortunately) can also be used,\n\u003e creating a new P2WSHv2 (or whatever version) that enables these opcodes.\n\u003e\n\u003e \u003e As far a I know, this is the covenants proposal that has been\n\u003e implemented for the longest time, if that's to be used as a selection\n\u003e criteria.And as always, this is not incompatible with deploying other\n\u003e convenant proposals later.\n\u003e\n\u003e No, it was `OP_EVAL`, not `OP_CAT`.\n\u003e In particular if `OP_EVAL` was allowed in the `redeemScript` then it would\n\u003e enable covenants as well.\n\u003e It was just pointed out that `OP_CAT` enables recursive covenenats in\n\u003e combination with `OP_EVAL`-in-`redeemScript`.\n\u003e\n\u003e In particular, in combination with `OP_CAT`, `OP_EVAL` not only allows\n\u003e recursive covenants, but also recursion *within* a SCRIPT i.e. unbounded\n\u003e SCRIPT execution.\n\u003e Thus, `OP_EVAL` is simply not going to fly, at all.\n\u003e\n\u003e \u003e Personally I find the simplicity proposal the best one among all the\n\u003e covenant proposals by far, including this one.But I understand that despite\n\u003e the name, the proposal is harder to review and test than other proposals,\n\u003e for it wouldn't simply add covenants, but a complete new scripting language\n\u003e that is better in many senses.Speedy covenants, on the other hand, is much\n\u003e simpler and has been implemented for longer, so in principle, it should be\n\u003e easier to deploy in a speedy manner.\n\u003e \u003e\n\u003e \u003e What are the main arguments against speedy covenants (aka op_cat2) and\n\u003e against deploying simplicity in bitcoin respectively?\n\u003e \u003e Sorry if this was discussed before.\n\u003e\n\u003e `OP_CAT`, by itself, does not implement any covenants --- instead, it\n\u003e creates recursive covenants when combined with almost all covenant opcodes.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220507/a95bab51/attachment-0001.html\u003e"}