I don’t think we are going to agree on your first point so let’s agree to disagree.

The issue with the garbage can analogy is that the garbage can is 4x more expensive. There is no economic incentive for spammers to use op_return. However, it still allows bad actors to relay illicit data through an officially supported method. Even if everyone still uses inscriptions, this change still widens the attack surface.

The issue with pruned nodes is that if I ran a pruned node I can’t run a transaction indexer such as an electrum indexer which is important for running an electrum server. Without this it makes it very hard to connect my sparrow wallet to my node. If 99% of people run pruned nodes then anyone doing an IBD would have to get the blockchain data from the 1%.

Tbh I don’t really have problem with criminals using bitcoin as money. Money should be neutral and if that means criminals will use it for monetary purposes, so be it.

I think it will always be possible for people to store and relay arbitrary data using the bitcoin network through exploits or unintended use cases but as long as bitcoin’s only intended function remains as neutral money then I think a lot of the social, moral, legal potential issues to do with arbitrary data will subside. In the case of the expansion of op_return, it is expanding bitcoins use case from just neutral money to also arbitrary data relay and storage.

Touching on the case where basically any data can be compressed into 20 bytes, this sort of tech would affect not just bitcoin but basically everything else, and so cp could be encoded in basically any transfer of data.

The page is the blockchain, the letters are the data, your brain is the decoder. The paper doesn’t allow for the decoding of that data, you need an external decoder. That’s why I cant get the meaning when it’s Chinese characters written on the paper without the use of an external decoder (translator). I guess your point is because there is no file viewer included in a blockchain explorer, until that data is decoded in an external decoder, that data is just 1s and 0s. In reality that data IS its correct interpretation, whether it needs a standard decoder for that data format or not. If I have some illicit message written in Chinese on a piece of paper which I technically can’t decode myself doesn’t mean it’s just random characters.

Maybe I have been relaying 80byte cp op_return data forever, but that was clearly not the intended use case. The intended use case was obviously 80 bytes of arbitrary data. If someone wants to exploit that by splitting up cp into tiny chunks across many transitions, fine, yes it’s pretty hard to stop that, but it is clearly not a supported and/or facilitated use case of the protocol. And then if that data ever gets into chain, the correct way (supported by btc network) to decode that data is individually decoding them as if they were each whole chunks. So yes, from a technical standpoint 1 vs 100 split up op_return transactions are very similar. The difference is that one is the correct way to store and send arbitrary data, whereas the other is using an exploit. There are huge social, moral and legal differences between people relaying around cp split up into chunks because it has to use an exploit that’s certainly not supported by the network, vs people relaying around whole data in a field of a transaction specifically designed for arbitrary data which is clearly the intended use case.

Technically everything you’re saying is correct, but the important distinction for this whole debate is what the bitcoin network supports. Because of the removal of op_return bitcoin now supports large 100kb files, simple as that, but that opens a can of worms and is why there is push back.

Whether you think the p2p network is good for relaying cp or not doesn’t really matter. The point is this change has widened the avenue for these sorts of activities and actually now facilitates them.

The all data is 1s and 0s argument is flawed because it implies that all data is equal. Whilst this is true from a technical standpoint it is not true from any other standpoint (moral, legal, social, etc). Just like you can see letters on a page, there is a correct and intended way to interpret those letters, and whilst you can technically interpret them differently, there is a correct meaning that everyone else will see them as.

For argument’s sake, let’s just say that you’re correct in that there is no legal problem for node runners if cp starts getting relayed around, many people are still going to have a problem contributing to the relaying and storing of this cp from a moral point of view, meaning fewer people will run nodes. There is no reality where cp has a positive impact on bitcoin, only negative. Which means any change that widens the avenue / facilitation of cp should not be undertaken.

I would argue that bitcoin could potentially be the best cp distribution protocol in the world. Anonymous upload of arbitrary data, to thousands of people all around the world in seconds without having to pay anything because this distribution can happen only at the mempool level and does not have to get mined. When 99%+ of nodes filtered out these large op_returns the p2p network was not efficient at distributing large data files because 999 in 1000 nodes were not going to relay it. As less and less nodes filter, suddenly the p2p network becomes much more effective at relaying around these large data blobs.

“The fact that you need a special software to piece together the cp vs just an image program is irrelevant.”

This is relevant because in the case of inscriptions etc, bitcoin clearly interprets them as native bitcoin data and is why there has been large increase in utxos recently. Whereas op_return’s only purpose is as a place to store arbitrary data, meaning any data put there bitcoin sees as the correct way to interpret that data.

It requires software to decode the data on external hard drives as well, does that mean cp sitting on people’s hard drives should be seen as just random 1s and 0s?

The important point is, what the network views as the correct way to interpret that data. If that data can simply be dragged and dropped into image software to present cp, then the network is supporting cp.

In the case of fake pub keys etc, the bitcoin network interprets that cp (thats been split up to look like native bitcoin data) as native bitcoin data, and so the network interprets that as a standard transaction. To then view that cp you must purposely use software that then interprets those 1s and 0s differently to what the bitcoin network does.

Edit: a fork to remove the illegal data is not necessary. A softfork to prevent it being put in op_return may be warranted.

Idk, possibly. Maybe if you piece together lots of chunks of data hidden in the witness section of a transaction, you might be able to interpret an illegal image etc, but because it would have had to have been hacked in in multiple chunks, it is neither obvious nor supported and so a fork is not necessary.

The fact that you have to ask if there is any illegal data on chain says that even if there is it’s not obvious and not natively supported by the network. Any illegal data mined in the op_return part of the transaction will be known about because:

1. It is a full contiguous string of data that can potentially be dragged and dropped into video playing software without any complex reformation of data

2. The reason op_return was created in the first place was for a way to include a very small amount of arbitrary data in a transaction, meaning arbitrary data is op_returns purpose. Therefore increasing the default op_return limit 1250x signals that bitcoin now supports and facilitates the relaying and storage of arbitrary data which must include illegal data as well.

As soon as illegal data was mined in bsv using op_return it was known about…

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.

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

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

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.

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.

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.

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”.

It’s a good point and yes retail transactions will/have migrate to higher layers, but the point is I don’t think you can say fees are the filter and assume fees will filter out spam and not native transactions. Fees will not be a deterrant for bad actors with vested interests in the fiat system. I think you know who that refers to.

If a bad actor wants to imbed 100kb blob of illicit data they can go straight to a miner. In this case the blame will be put on the miner and the bad actor for voluntarily putting this illicit data on chain forever.

If a bad actor can get a 100kb blob of illicit data imbedded anonymously using other people’s nodes (the p2p network) suddenly the blame will be put on the bitcoin network for supporting and facilitating this activity as a feature. You’ve got to remember op_return is a native feature of bitcoin and so by opening up the data carrier size to 100kb you are saying “hey this is a legitimate and supported use case for bitcoin”.

There’s a blinding difference between the two…

Why does knots filtering suck from an engineering perspective?