coinjoin

Bitcoin Core developers: No intention to filter coin mixing transactions "coinjoin", willing to utilize all team resources to formulate a solution

ChainCatcher news, Bitcoin Core developer Luke Dashjr posted on social media, "The discussion about OP_RETURN is not new; it dates back to 2014 when Bitcoin Core 0.9.0 was released, which included the OP_RETURN policy aimed at preventing more severe forms of spam. At that time, the default maximum data carrier size limit implemented by all nodes was 40 bytes; this has always been and remains sufficiently large for binding data to transactions (32 bytes for a hash, 8 bytes for a unique identifier). The subsequent increase of the default value to 80 bytes was a completely voluntary decision and in no way contradicts the design goal of OP_RETURN to create provably prunable outputs to minimize the damage caused by data storage schemes, which have always been considered abusive. There are also other good technical reasons why I choose to retain the lower default value of Bitcoin Knot, and there is no reason to increase it."Luke Dashjr stated that he and the OCEAN team have no intention of filtering coinjoin transactions. These provide an innovative tool for enhancing 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 personal ideas on how to mitigate the recent issues, namely that some coinjoin transactions were flagged as spam by Knots v25, and he is willing to leverage all his and his team's resources to sincerely collaborate on developing solutions.
ChainCatcher Building the Web3 world with innovators