Bitcoin Core developers: Neither individuals nor the OCEAN team have any intention to filter CoinJoin transactions and are willing to utilize all resources to develop a solution.

On December 9th, Luke Dashjr, a Bitcoin Core developer, posted on social media that the OP_RETURN discussion is not new and can be traced back to 2014 when Bitcoin Core 0.9.0 was released. At that time, the OP_RETURN policy was included in order to prevent more malicious forms of spam. The default maximum data carrier size limit implemented by all nodes at that time was 40 bytes, which was sufficient for binding data with transactions both then and now (hash value 32 bytes, unique identifier 8 bytes). The Core later voluntarily increased the default value to 80 bytes, and this decision was not contradictory to the design goal of creating OP_RETURN to create provable and trimmable outputs to minimize the damage caused by data storage schemes, which have always been considered abusive behavior. There are also other good technical reasons why Luke Dashjr chooses to keep the lower default value of Bitcoin Knot and sees no reason to increase it. Luke Dashjr also stated that he and the OCEAN team have no intention of filtering out coinjoin transactions. These provide an innovative tool to enhance Bitcoin privacy and, when constructed correctly, coinjoins can easily stay within the OP_RETURN limit (in fact, they have no reason to have any OP_RETURN data at all). He has some ideas on how to mitigate the recent issue, namely that some coinjoin transactions are being marked as spam by Knots v25, and is willing to use his and his team's resources to sincerely collaborate on developing a solution.