Hi vjudeu,
> 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.
This 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
/dev/fd0
Sent with [ProtonMail](https://protonmail.com/) secure email.
------- Original Message -------
On Saturday, May 7th, 2022 at 9:22 AM, vjudeu via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
>> 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.
>
> 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.
>
>> 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 ...
>
> 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.
>
>> It was considered unfair that the sender is paying for the security of the
>> receiver.
>
> 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.
>
> On 2022-05-07 05:06:46 user ZmnSCPxj via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
>> Good morning Jorge,
>
>> 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.
>
> 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:
>
> 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 ...
>
> 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).
>
> OP_CAT was removed long before covenants were even expressed as a possibility.
>
> Covenants were first expressed as a possibility, I believe, during
> discussions around P2SH.
> Basically, at the time, the problem was this:
>
> * Some receivers wanted to use k-of-n multisignature for improved security.
> * The only way to implement this, pre-P2SH, was by putting in the
> scriptPubKey all the public keys.
> * The sender is the one paying for the size of the scriptPubKey.
> * It was considered unfair that the sender is paying for the security of the
> receiver.
>
> Thus, OP_EVAL and the P2SH concept was conceived.
> 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.
> By symmetry with the P2PKH template:
>
> OP_DUP OP_HASH160 <hash160(pubkey)> OP_EQUALVERIFY OP_CHECKSIG
>
> The P2SH template would be:
>
> OP_DUP OP_HASH160 <hash160(redeemScript)> OP_EQUALVERIFY OP_EVAL
>
> OP_EVAL would take the stack top vector and treat it as a Bitcoin SCRIPT.
>
> It was then pointed out that OP_EVAL could be used to create recursive
> SCRIPTs by quining using OP_CAT.
> 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.
>
> 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).
> 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.
>
> 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.
>
> (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.)
>
>> 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.
>
> If you are willing to work in Taproot the same OP-code can be enabled in a
> softfork by using a new Tapscript version.
>
> 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.
>
>> 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.
>
> No, it was OP_EVAL, not OP_CAT.
> In particular if OP_EVAL was allowed in the redeemScript then it would enable
> covenants as well.
> It was just pointed out that OP_CAT enables recursive covenenats in
> combination with OP_EVAL-in-redeemScript.
>
> 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.
> Thus, OP_EVAL is simply not going to fly, at all.
>
>> 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.
>>
>> What are the main arguments against speedy covenants (aka op_cat2) and
>> against deploying simplicity in bitcoin respectively?
>> Sorry if this was discussed before.
>
> OP_CAT, by itself, does not implement any covenants --- instead, it creates
> recursive covenants when combined with almost all covenant opcodes.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
