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.
Luke is worse than Udi right now. Breaking #Bitcoin network protocol and giving the wizards their civil war.
News flash: you can't ban arbitrary data om #Bitcoin. There are a dozem ways to accomplish the same thing. It's going to be a destructive game of cat and mouse that hurts #Bitcoin more than shitcoiners ever could.
nostr:note1z03wsa48vwgm3m4vpckgq40yy68mchfzztwvdyndq9a6jkvke40qeux255
I'm not seeing the civil war here - those who wish to implement knots rules can, those who wish to support ordinals can. They won't cause a crash in the Blockchain, just some nodes will fill with data and become unmanageable eventually and some will keep the excess data out and remain more manageable. What excess data miners choose to include, or not, in a block, is up to them.
1. Wizards campaign that maxis are censoring them.
2. Luke breaks with 10yrold standard protocol to "kick them out"; breaks whirlpool.
3. Whirlpool is about to release a Knots-proof workaround.
4. Prediction: wizards will follow suite.
Thus begins a cat and mouse game of incrementally dismantling critical #Bitcoin features.
It's right there.
This is just Luke’s Bitcoin client and Luke’s mining pool, both of which are a tiny minority of users.
Aye, and this expose of his bullshit is going to ensure we don't go too far down this road with blinders on.
You lost me at Luke is worse than Udi. Even the biggest Luke hater knows that's BS.
