Miners wanting higher fee blocks is not an issue and is in fact important for the security of the network as the block subsidy decreases and the industry becomes more competitive. The issue is that a very small number of entities have control over block template construction. How does Datum fix this? It allows for any hasher not just the pools to be in charge of block template construction. This of course addresses block template construction centralisation as now you have millions of individual hashers responsible for what goes into a block. This means it will be extremely impractical to go direct to a miner as even the largest miner Mara only has ~5% of the hash rate, meaning it would/could take a long time before your submission was mined. “All you need is one pool attracting all the miners who want maximum revenue”. Wouldn’t this large pool also attract all the miners that don’t include spam as well and therefore the rewards would be distributed among miners who do and don’t mine spam? We must assume miners will always prioritise profit and so the nodes need to disincentivise miners from including spam. How do the nodes do this? If a majority of nodes filter large op_return transactions (over 80 bytes) the block filled with large op_return will propagate slower and the risk of that block going stale is higher. This disincentivises miners from mining spam filled blocks as they may lose the whole block entirely. This is a realistic possibility and why Mara charges 2x for slipstream. “The current filters at issue don’t facilitate censorship because they aren’t actually doing much.”. If this is the case, why does removing them improve the network in anyway if they don’t do much? Why not just leave them if they aren’t doing anything? It’s funny that you say they don’t do much when 99% of all op_return transactions since the addition of op_return have been under 80 bytes meaning they are extremely effective at what they were designed to do. Just because they can be bypassed by a determined spammer doesn’t mean they don’t do anything. The fact they have to be bypassed means they do their job very well. The current filters issue relates to datacarriersize. This DOES NOT filter regular transactions because regular transactions do not use op_return. Op_return was designed for arbitrary data and so this the filter of 42/80 bytes related to how much arbitrary data will be relayed. Opening op_return to 100kb signals that the storage and sending of arbitrary data is a native feature of bitcoin, basically meaning that spam is accepted. I assume we both want bitcoin to be a monetary only protocol, the changes to op_return take bitcoin in the opposite direction. “We have rules about what a valid transaction is. A mempool policy should not override that. “. The rules regard to consensus which are the rules we all agree on and hence will be looser. When I run a node, I have my own mempool that is not shared with anyone. Should I be able to decide what data my own hardware stores in plain text in RAM, and relays? Mempool policy does not ‘override’ a valid transaction because everything in a mempool must be adhering to consensus rules otherwise nodes won’t accept it.

One of the reasons core say they are making this change is to address mining centralisation by disincentivising direct submission services. Funnily enough Datum does fix this. If a large majority of pools use Datum then it’s the individual miner responsible for the block template construction, not the pool. This then makes it significantly harder to directly submit your transaction and see it included as there is much more variation in who is mining the block. The issue with mining centralisation today is that there are a small number of pools with majority of the hash power responsible for block template construction. This can lead to out of band transactions becoming more centralising for the large pools. But why not support a solution that gives the block template construction back to the hashers which would solve this entire block template construction centralisation issue? If Mara’s slipstream is not in demand why even rush to make this change. What you’re saying is, it’s not in demand now but we guess it will in demand in the future. It seems very premature. There is currently a lot of demand for spam on bitcoin, so it’s interesting that this service is not also in demand. The cat and mouse game is always worth playing if you don’t want to facilitate spam on bitcoin. It signals a hostility towards spammers, which will push a large majority of spammers away (it pushed vitalik buterin away in 2014), because the only way to spam is to pioneer a new method which is beyond the ability of a majority of people, and even if this new method can be made easier for regular people, it will be able to be filtered out by nodes as well. If bitcoin is very unchanging, there are only so many possible ways spammers can hack spam in. And it’s a game that the anti-spammers will win because filters more dynamic and easier to implement than the creation of new methods of spam. I’m interested to understand how filters facilitate censorship. Currently 99% of all nodes have filters, does that mean bitcoin today and since it’s creation has been a censoring platform? Also, filters do not filter out monetary transactions, for example, even if on knots you set the datacarriersize=0 (which is the filter relevant to op_return), all native monetary transaction will not be filtered. It’s a similar story with filtering inscriptions as inscriptions have to use a pattern that is identifiable. What do you propose when you say “I’d rather we deal with spam” because doesn’t opening the op_return limits actively facilitate spam?

Yes if spammers can use op_return instead of direct submission to miners, it helps to prevent mining centralisation from getting worse. However, the only pool I could find that publicly offers this service is Mara with slipstream. Doesn’t it seem a bit premature to remove op_return limits with the intent of reducing mining centralisation by making a service that a pool with only 5% of the hash rate offers, obsolete? I understand that other pools may implement this service later down the line, but that means this change does not reduce mining centralisation from its current levels, it only helps to prevent it getting worse. We can agree mining centralisation is a problem today, so wouldn’t it make more sense to support solutions that actually reduce mining centralisation like Ocean and DATUM instead of pushing contentious changes that only help prevent this issue from getting worse? Removing op_return does give spammers a less technically harmful alternative solution for uploading spam, but are many spammers actually going to use it if the op_return solution is 4x more expensive? I hear the “fees are the filter” argument a lot , but this contradicts the point that with the removal of op_return spammers can spam in a less harmful way because wouldn’t they choose the cheaper alternative (witness data)? We both agree that inscriptions are bad for bitcoin and so isn’t the most logical choice to provide a solution to this bug, such as the one knots has already implemented (inscriptions filtering at the mempool level) and the one core refused to implement in 2023.

I haven’t twisted any argument. I simply responded to your argument that ‘the number of knots nodes is irrelevant because miners will just mine the spam anyway’. It’s actually knots + core prior v30, and the ratio between that sum and core 30 nodes will dictate whether miners can just ‘ignore filters’. It’s important to address this point. An argument I see against knots a lot is that it’s a losing game because miners will just mine spam because they are economically incentivised to. Well if enough nodes filter spam they are not economically incentivised to. The more core 30 nodes the more incentive to mine spam. Core 30 is bad because it facilitates and supports the transfer and relay of arbitrary data anonymously for free anywhere around the globe. That data doesn’t even have to be mined to relayed to the other side of the world. This is an unnecessary attack vector. Granted, the severity of core 30’s impacts is dependent on its adoption.

Bitcoin: peer to peer electronic CASH system Wokecoiners: - we do not discriminate against any transaction - All transactions are equal - People will use bitcoin for whatever they want and stopping them is censorship and authoritarian - You’re a knotzie!!! - How dare you filter your own mempool, that’s distributed authoritarianism - It’s unfair to want only experienced maintainers, we should want a diverse group with differing ideologies

There is no size increase for the total transaction (still 100k vbytes), and so there is no size increase to the inputs. The change is changing how much data in the op_return part of the transaction nodes will relay. The change means your op_return data can take up the entire 100k vbytes and core 30 nodes will still relay it by default. Prior to core 30 nodes would only relay transactions with a max of 80 bytes op_return data by default. The change basically means the bitcoin p2p network supports transactions that are completely arbitrary data or spam. The concern comes from whether you think nodes relaying 100kb files, uploaded anonymously for free could be an attack vector for bad actors.

“OP_RETURN was always just bound by the maximum transaction size. We are not opening up anything now at the consensus level.” - I assume you are referring to the fact that nodes can change their data carrier size to allow for 100kb. By default all core nodes prior v30 only allow for 80 + 3 bytes of op_return. The defaults are very important because most people run the defaults. This means that it is very hard to have your larger than 80 byte op_return file relayed across the p2p network, as most nodes do not relay this transaction. This also disincentives miners not to include this transaction as there is a higher risk of their block going “stale” if they do. Regarding “the blame would be on the protocol either way” I’d say there’s a difference. If a bad actor must bypass the default P2P path by submitting directly to a cooperating miner or mining the block themselves, responsibility is clearly on the actor and the cooperating miner. If Core’s default changes so that most nodes relay large OP_RETURNs, that plausible-deniability vanishes because the network defaults now support large data relay, and the perception shifts toward the protocol. The anonymity of the miner/bad actor does not really matter in this case because whether the miner is known or not, it’s the perception of how that illicit data was included on chain and whether it was supported by the p2p network, or the network had to be bypassed because it did not support it.

Thanks for the support Davo. It’s important us Karens look out for one another.

The 100k vbytes refers to the total size of the transaction including witness data, headers, the inputs and outputs, etc. For inscriptions spammers use the witness data aspect of the transaction. From my understanding, each input has its own witness field, which can carry only a limited amount of data. To include larger files, the data must be split across multiple inputs and/or multiple transactions. The total transaction size cannot exceed100k vbytes.

That’s true, but there’s a difference between people using an exploit that is not natively supported vs using op_return which is a feature with the purpose to allow arbitrary data. By increasing the op_return limit you are now signalling that relaying large blobs of continuous data is a feature supported by the network. In contrast, shoving split up chunks of data into the witness section where it is not designed to be is not an intended use of the network. The argument is that: now relaying large continuous chunks of data is natively supported, any legal/regulatory plausible deniability is gone. From a technical standpoint this change also makes it easier for bad actors / criminals as they don’t have to split their files into multiple chunks.

I think it’s incorrect to say mempool policy is flimsy. As of today, 99% of all op_return transactions are under the 80 byte default max relay limit. Policy is very effective at filtering out transactions on individual nodes’ mempools. In my opinion a consensus change is not necessary because filters in their current state disincentivise spammers to the point where they have to use exploits or bypass the p2p network. Because of this, its clear bitcoin in its current state is for monetary transactions only. If someone wants to put illegal data on chain by using an exploit or bypassing the p2p network, or in other words “jump the fence”, technically nothing is stopping them, but I don’t think the fault and legal responsibility lies with bitcoin in this instance. However, if nodes start to relay large continuous data chunks by default (ie, this behaviour is now supported by the network), I think some fault can and will be put on bitcoin. And yes the risk of miners having their block orphaned is important and is a reminder that the miners serve the nodes, not the other way around.

The fees are the filter argument does not address the mempool issue that this change to op_return brings. Because core 30 nodes will accept and relay 100kb files by default, this allows for files to be sent across the p2p network without having to get this transaction mined. Criminals / bad actors can exploit this by relaying illegal data to their buddy on the other side of the world, anonymously and for free because this is all happening at the mempool level. Yes, eventually after a period of time of this transaction not being mined it will be dropped from the node’s mempool, but by this point that illegal file has already been relayed to other bad actors. In short: the removal of op_return filters in core 30 software creates infrastructure for an extremely effective, anonymous and free data relay / sharing service that will be exploited by criminals with illegal files. This is not me being a purist saying “this is immoral”. This is me saying “this introduces a legitimate attack vector that governments and the powers at be who want to see bitcoin fail WILL use”.

Why does knots filtering suck from an engineering perspective?

The question is not how many knots nodes, but how many core 30 nodes. Knots and core prior to v30 all filter op_return greater than 80 bytes. The more nodes that filter the more miners have to respect those filters. If a miner includes a large or_return transaction that most nodes have not seen because it has been filtered out of mempools, that block will propagate across the network slower and there will be a greater risk of that miners block going ‘stale’. This is a realistic risk and is the reason Mara charges 2x for their slipstream service.

Knots. I don’t see why you would want to relay anyone’s arbitrary data with your own hardware and trust that people won’t exploit that. So not V30. Knots also does a better job of filtering out inscriptions, whereas Core has done nothing to prevent them despite being provided with solutions. This means that previous Core implementations won’t filter out inscriptions either.