0

With all the recent developments of the spammers and those who want to filter them. I have a few things I don't get. They mention the bug that wasn't fixed (CVE-2023-50428). As I understand, this "bug" is that Bitcoin Core developers did not implement a filter for the jpegs on the policy side of things after the taproot has merged, and if they would, like Bitcoin Knots did, it could still get into the block with a help of a miner because it still would be within the consensus. That's the first one. Another one is about op_cat and other covenant proposals. For example the bip 420 is for the reintroduction of op_cat. As Satoshi removed it, is it forbidden on the consensus side or on the policy side. If it was removed from the consensus, if it will be merged, how will it be backwards compatible? But if it is a policy, op_cat can appear today with a help of a miner?

Thanks

1
  • 3
    there is too many questions in one there. Could you try and ask each question separately? Mind subjective questions aren't a good fit for this site so try to phrase it so it's more focused on some objective technical aspects of it. Commented May 10 at 9:02

1 Answer 1

0

You might be thinking of valid yet non-standard transactions. From the point of view of the node software:

Standardness is what type of transactions should be included.

Validity is what type of transactions could be included.

If a node sees a prospective transaction as non-standard it will not share it on the P2P network and will not include it in candidate blocks for mining, even if it is valid. However, if it sees non-standard yet valid transaction has been confirmed on the chain, it will accept it.

Bitcoin Core and and Bitcoin Knots have a slightly different point of view (policy) on standardness, but agree on validity. If nodes were to disagree on validity, there would likely be a fork.

...how will it be backwards compatible?

It might be worth looking at OP_CHECKSIGADD for an example opcode only used in Tapscript.

case OP_CHECKSIGADD:
    {
        // OP_CHECKSIGADD is only available in Tapscript
        if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);

But if it is a policy, op_cat can appear today with a help of a miner?

No, the script would be invalid. Such a transaction, and its block, would be rejected as invalid by all nodes running a Bitcoin Core version, or derivation, released since OP_CAT was removed (i.e. ~all of them).

2
  • Thanks for the answer, how are they planning on adding the op_cat then, if it will be rejected by for example core 27.0?
    – user151596
    Commented May 10 at 12:25
  • I found out, they are adding it as a new opcode in tapscript, not reenabling the old one
    – user151596
    Commented May 10 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.