Thank you. This is sensible.
The OP_RETURN discussion is not new and dates back to 2014 when Bitcoin Core 0.9.0 was released with the OP_RETURN policy included which was intended to discourage more egregious forms of spam. At that time, 40 bytes was the default max datacarriersize limit across all node implementations; this was and still is sufficiently large for tying data to a transaction (32 bytes for a hash and 8 bytes for a unique identifier). Core subsequently increasing the default to 80 bytes was an entirely voluntary decision and in no way contradicts the design objective that OP_RETURN creates a provably-prunable output to minimise damage caused by data storage schemes, which have always been discouraged as abusive. There are also other good technical reasons which I have chosen to retain the lower default in Bitcoin Knots, and no justification for increasing it.
It is not my intention, nor that of my team at
nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze, to filter coinjoins. These present an innovative tool for increasing Bitcoin’s privacy and, when constructed properly, coinjoins can easily stay within the OP_RETURN limit (indeed, there is no reason for them to have *any* OP_RETURN data at all). I have some ideas on how to alleviate the recent issue where some coinjoin transactions were flagged as spam from Knots v25, and I am willing, with the full resources of my team, to work collaboratively on a solution in good faith.
Bitcoin does and always has allowed nodes to set filters based on multiple sets of criteria and Knots v25’s defaults are IMO what is best for Bitcoin at this time. Others may disagree and that is ok. They are free to (and should) run their own nodes - it is good for Bitcoin to have more people running nodes, including miners, and there should be a natural diversity in node policies. As was stated before, OCEAN is on a path to decentralization and very soon we are going to be in a position where hashers will be able to fully participate as miners and perform the intelligent parts of mining such as deciding which version of node software to run and what filters or other policies to apply to block template construction.
Discussion
Does nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk understands that op_return is not a part of coinjoin txn? This rant is misleading.
You see it’s not a coinjoin ban.
Tx0 is a prep txn NOT a coinjoin txn.
one needs to understand why it is a prep tx? Unlike a payjoin(stowaway) the purpose of a coinjoin is not to hide the nature of the transaction.
It's a bit like encryption: the objective is not to hide the fact that the text is encrypted, but to make it impossible to understand.
Also Tx0 fees are paid to the software publisher, not to the coordinator and no fee is paid during mixing, except fees that paid to miners.
then tx goes to premix/postmix which belongs to your own derivation path your wallet never loses possession of sats.
Therefore op_return contains info allowing the server to verify that the fee was actually paid to an address., because sending to whirlpool means sending to your own hardened derivation path that you control. It's an anti-spoofing mechanism. If the fee is not seen in the blockchain then the inputs are not registered. It also allows to not use a static fee for address collection.
The use of op return in tx0 resilient to potential coordinator failure and enable decentralization - two things a coordinator database can't solve.
You do not need OP_RETURN or a "prep" transaction to coinjoin. Wasabi Wallet, BTCPay Server, Trezor, and JoinMarket all do coinjoin transactions WITHOUT spamming the chain with tx0 transactions.