{"type":"rich","version":"1.0","author_name":"npub1w30zwgl8947760cd62fawy9hqmxnq24cga5c8s5j6j7m07w96dnqzjzhn2","author_url":"https://nostr.ae/npub1w30zwgl8947760cd62fawy9hqmxnq24cga5c8s5j6j7m07w96dnqzjzhn2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-05-11\n📝 Original message:Hi vjudeu,\n\n\u003e It can be changed by using different sighashes, for example, it is possible to create a \"negative fee transaction\", where all transaction costs are paid by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher amount in outputs than inputs is enough to do that, see testnet3 transaction 495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40.\n\nThis transaction has 2 inputs: 0.00074 tBTC and 0.00073 tBTC (0.00074 + 0.00073 = 0.00147) which is more than output amount 0.001 tBTC\n\n/dev/fd0\n\nSent with [ProtonMail](https://protonmail.com/) secure email.\n------- Original Message -------\nOn Saturday, May 7th, 2022 at 9:22 AM, vjudeu via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:\n\n\u003e\u003e Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating a new OP_CAT2 that does the same would be a softfork.\n\u003e\n\u003e We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be re-enabled in a soft-fork way. For now, OP_CAT in TapScript simply means \"anyone can move those coins\", so adding some restrictions is all we need to re-enable this opcode. Introducing OP_CAT2 is not needed at all, unless it will be totally different, but then it should not be named as OP_CAT2, but rather as OP_SOMETHING_ELSE, it depends how different it will be from OP_CAT.\n\u003e\n\u003e\u003e OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT ...\n\u003e\n\u003e So we can use OP_SUBSTR instead. Maybe even OP_SPLIT will be enough, if data expansion is the only problem, then we can focus on getting it smaller. Or better, we could use OP_FIND that would return true/false answer if element A is a part of element B, when we do byte-to-byte comparison. In general, we can use many different string-based functions to do the same things, we can choose something that will not exponentially explode as OP_CAT.\n\u003e\n\u003e\u003e It was considered unfair that the sender is paying for the security of the receiver.\n\u003e\n\u003e It can be changed by using different sighashes, for example, it is possible to create a \"negative fee transaction\", where all transaction costs are paid by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher amount in outputs than inputs is enough to do that, see testnet3 transaction 495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40.\n\u003e\n\u003e On 2022-05-07 05:06:46 user ZmnSCPxj via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:\n\u003e\n\u003e\u003e Good morning Jorge,\n\u003e\n\u003e\u003e OP_CAT was removed. If I remember correctly, some speculated that perhaps it was removed because it could allow covenants.I don't remember any technical concern about the OP besides enabling covenants.Before it was a common opinion that covenants shouldn't be enabled in bitcoin because, despite having good use case, there are some nasty attacks that are enabled with them too. These days it seems the opinion of the benefits being worth the dangers is quite generalized. Which is quite understandable given that 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 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 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 similar behavior (consider that multiplying two 32-bit numbers results in a 64-bit number, similar to OP_CATting a vector to itself).\n\u003e\n\u003e OP_CAT was removed long before covenants were even expressed as a possibility.\n\u003e\n\u003e Covenants were first expressed as a possibility, I believe, during 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 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 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 create a separate script containing the public keys, then hash it, and the 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 SCRIPTs by quining using OP_CAT.\n\u003e OP_CAT was already disabled by then, but people were talking about re-enabling it somehow by restricting the output size of OP_CAT to limit the O(2^N) behavior.\n\u003e\n\u003e Thus, since then, OP_CAT has been associated with recursive covenants (and people are now reluctant to re-enable it even with a limit on its output size, because recursive covenants).\n\u003e In particular, OP_CAT in combination with OP_CHECKSIGFROMSTACK and OP_CHECKSIG, you could get a deferred OP_EVAL and then use OP_CAT too to quine.\n\u003e\n\u003e Because of those concerns, the modern P2SH is now \"just a template\" with an implicit OP_EVAL of the redeemScript, but without any OP_EVAL being actually enabled.\n\u003e\n\u003e (OP_EVAL cannot replace an OP_NOP in a softfork, but it is helpful to remember that P2SH was pretty much what codified the difference between softfork and hardfork, and the community at the time was small enough (or 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 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 softfork by using a new Tapscript version.\n\u003e\n\u003e If you worry about quantum-computing-break, a new SegWit version (which is more limited than Tapscript versions, unfortunately) can also be used, 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 implemented for the longest time, if that's to be used as a selection criteria.And as always, this is not incompatible with deploying other 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 enable covenants as well.\n\u003e It was just pointed out that OP_CAT enables recursive covenenats in combination with OP_EVAL-in-redeemScript.\n\u003e\n\u003e In particular, in combination with OP_CAT, OP_EVAL not only allows recursive covenants, but also recursion within a SCRIPT i.e. unbounded 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 covenant proposals by far, including this one.But I understand that despite the name, the proposal is harder to review and test than other proposals, for it wouldn't simply add covenants, but a complete new scripting language that is better in many senses.Speedy covenants, on the other hand, is much simpler and has been implemented for longer, so in principle, it should be 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 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 creates recursive covenants when combined with almost all covenant opcodes.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220511/40c774ba/attachment-0001.html\u003e"}