TheKayman

https://apps.apple.com/au/app/putt-putt-pool-3d-8-ball-golf/id6496864922

Software developer by day. Bitcoiner also by day…
🇦🇺

Public Key

npub1dagr25zv0sucfxmcxmw69xr2reh2nj72emw2jw9a9w82cvsyghtsdlc25u

Profile Code

nprofile1qqsx75p42px8cwvyndurdhdznp4pum4fe09vah9f8z7jhr4vxgzyt4cprpmhxue69uhk5upwwp6hyurvv4ex2mrp0yhxxmmdqyf8wumn8ghj7ur4wfcxcetsv9njuetnqydhwumn8ghj7mn0wd68ytnfd4cx2unkd9hh2uewd35hvegpr9mhxue69uhhyetvv9ujumtfde5kymmvwshxjmnxduqs6amnwvaz7tmwdaejumr0dsq3vamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet5ee4sc3

Publishing to

jp.purplerelay.com

purplepag.es

nostr.impervious.live

relay.minibolt.info

nos.lol

relay.primal.net

Author Public Key

npub1dagr25zv0sucfxmcxmw69xr2reh2nj72emw2jw9a9w82cvsyghtsdlc25u

Show more details

Last Notes

2026-08-04 08:19:30 UTC

- reply

I’m genuinely curious about the issue with dice rolls. Are you saying it’s an opsec issue or an entropy issue? Assuming the goal is to generate a minimum of 128 bits worth of entropy.

2026-07-19 09:53:56 UTC

- reply

I think you’re missing my point. I’m saying, regardless of what the hashers of foundry do or don’t vote for, foundry have made it clear that they are willing to run bip110 (with the caveat that this info is true)
Ultimately if the hashes decide against bip110 the decision still rests with foundry, who to reiterate are obviously neutral on bip110 for them to be giving the courtesy to their hashes.

2026-07-18 22:36:24 UTC

- reply

If foundry were against it, wouldn’t it make sense for them to not offer the option at all? Foundry ultimately gets to choose.
Assuming this is real, the fact that they have offered the choice to its hashers means they are willing to run bip110. This means they must have tested a node implementation that enforces bip110. To me this doesn’t sound like opposition, it sounds like neutrality. A neutral party to bip110 will always run bip110 if it becomes clear that opposing it is becoming increasingly riskier.

2026-07-18 22:25:06 UTC

- reply

This is a ~100kb image, give or take the extra metadata added by iPhotos. 100kb seems sufficient to get a high enough level of detail.
https://blossom.primal.net/5b3c441edb4224dd3cfa9592b0a0151a3254c24e7da97c1b4e28d053e50b8bc7.jpg

2026-07-16 10:52:45 UTC

@nprofile…a36f in a recent podcast I noted that you touched on bip110 but did not elaborate to much on it.
Just wondering seeing as though we are getting close to the mandatory signally period, whether you have evaluated the proposal any further.
I note that your caveat for bitcoin’s success is that it stays decentralised and secure. My opinion is that the successful activation of bip110 would enhance the decentralisation of the network. Curious to whether you share a similar sentiment?

2026-07-13 21:36:44 UTC

- reply

Has core lost your support as well?

2026-06-21 01:42:18 UTC

- reply

Yeah so he was right about the sync time using assumevalid as 0.
However most users probably won’t go to the terminal and manually set this to 0. Conversely, by skipping validation of some scripts I guess there is very small but nonetheless present risk your node accepts a script relating to a historically invalid transaction. I can’t testify as to how much of an issue this is, but is probably one of those things where if you set assumeValid to 0 you can never be 100% sure the synced chain is completely accurate.
Either way I’d still say he’s missing the bigger picture.

2026-06-21 00:23:18 UTC

- reply

I’m going to assume he’s being honest, but he’s missing the bigger picture, which is, clearly people are pointing out that IBD greatly slows when it gets to about 2023. His argument seems to be it “it was fine for me so it’s not a problem”.
From my point of view I know that the 2 times I attempted to IBD on my older laptop, the first took about a month and the second time I had to give up on, because it completely stalled, (had to resync cause I accidentally corrupted the data).
It’s pretty clear to me that from my experience and from hearing other people’s experiences that IBD on older or less powerful machines is an issue especially for node adoption.
Maybe other factors such as internet bandwidth and proximity to the nodes bootstrapping yours has a great effect on IBD. However on the more powerful machine I bought, with the same internet bandwidth and proximity other nodes it took just over 2 days. This is obviously greatly reduced from 1 month, suggesting in my case at least, hardware was the greater bottle neck.

2026-06-20 22:16:12 UTC

- reply

Your response tacitly acknowledges that you think there should be no more forks / updates / fixes, and that bitcoin should ossify.
Arbitrary data has definitely disrupted the usage of bitcoin as money over the last 3 years. Have you tried syncing a node recently on an older but still fairly capable laptop. Syncs very fast until about 70%, then completely hits a wall, with an estimated time to finish of over a year. This forced me to spend $800 on a more powerful machine.
I suspect that most people will turn away from that and therefore a lesser ratio of people using bitcoin will run nodes. This does not just disrupt bitcoin as money, but also disrupts bitcoin as a decentralised network.

2026-06-19 11:16:55 UTC

- reply

Maybe the state does have jurisdiction of the child’s rights and property? Maybe upon mother and father signing the birth certificate, this transfers the child’s rights and property into estate administered by the state, where the state acts as the lawfully appointed trustee who acts to “benefit” the beneficiary (child).
We assume the birth certificate is the record of the birth of a new born, but maybe it’s recording the birth of an estate under name of the surname.
In this case the parents do have a limited authority over the child only because the state grants it. The state as the lawful administer / trustee appoints mother and father to look after the new born under the name “parents”, but parents must follow the rules the state sets.
I would argue parents are different and distinct from mother and father.
Just a thought experiment.

2026-05-28 10:50:31 UTC

- reply

Yeah fair enough. I guess whether it depends on Luke isn’t as relevant anymore as bip 110 is out there now and can be ran and audited.
To the point of it being temporary, I can see that if it worked flawlessly then yes it doesn’t make sense for it to be temporary, but because of the unseen issues in past soft forks I do see the value in it being temporary. Only time will tell if there are any unseen issues with it.
From my point of view I accept that maybe bip 110 isn’t perfect in its design or release schedule, but I agree with the direction it takes bitcoin if it succeeds, and since currently I can see no better alternative I give it my support.

2026-05-28 10:23:56 UTC

- reply

I guess my question to you is, do you not support bip 110 because you oppose what it proposes, or do you not support it because you don’t think it will succeed? I believe there is an important difference.

2026-05-14 01:41:23 UTC

- reply

Spam metrics such as the bloating of the UTXO set and a large increase in dust outputs from taproot transactions since 2023 suggest there has been demand for it. If you have any metrics to suggest that the demand for spam is reducing, I would be interested to see them.
Here we have ord.io a company founded in 2023 that has been in operation up until the moment where plebs’ hostility to spam has increased shown in the release of bip110 and the adoption of knots. Coincidence that ord.io has shut down as hostility to spam has increased? Maybe, but I think not.

2026-05-14 01:07:42 UTC

- reply

You’re right, knots didn’t do it… but plebs’ increasing hostility to spam did.

2025-10-30 20:42:17 UTC

- reply

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

2025-10-29 22:36:43 UTC

- reply

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.

2025-10-29 20:53:37 UTC

- reply

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.

2025-10-29 08:21:10 UTC

- reply

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.

2025-10-28 21:01:28 UTC

- reply

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.

2025-10-16 22:29:35 UTC

- reply

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

2025-10-16 22:28:29 UTC

- reply

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.

2025-10-16 21:40:13 UTC

- reply

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…

2025-10-16 21:26:50 UTC

- reply

Relay policy does and has sufficed since inception. That’s why 99% of op_returns are under the 83 byte default relay limit, and so no consensus change was necessary.
Now the reference implementation has uncapped those limits, meaning that version of node software now supports the relaying of large continuous chunks of arbitrary data by default. We can expect to see more large op_returns being mined because of the changes in core 30, and so a consensus change may be necessary if we do not want bitcoin to become an arbitrary file storage system…

2025-10-09 00:31:00 UTC

- reply

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.

2025-10-08 21:33:57 UTC

- reply

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?

2025-10-08 08:17:33 UTC

- reply

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.

2025-10-04 01:45:01 UTC

- reply

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

2025-10-03 22:59:02 UTC

- reply

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.

2025-10-03 22:08:00 UTC

- reply

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

2025-10-03 21:47:02 UTC

- reply

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.

2025-09-30 11:35:29 UTC

- reply

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.

2025-09-29 21:14:41 UTC

- reply

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.

2025-09-29 10:37:20 UTC

- reply

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

2025-09-29 10:09:26 UTC

- reply

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.

2025-09-29 07:41:20 UTC

- reply

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.

2025-09-29 00:43:56 UTC

- reply

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

2025-09-28 23:44:55 UTC

- reply

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.

2025-09-28 22:06:28 UTC

- reply

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…

2025-09-28 21:51:40 UTC

- reply

Yes I agree fees do serve as a filter, however the issue with saying this is that fees are also a filter to regular bitcoin transactions. I think it’s a bit naive to assume spam will get priced out and monetary transactions will not. If companies / spammers can find a way to make money from their spam, suddenly fees just become a business expense. Now you have spammers who are making money from their transactions competing with regular people just wanting to send a monetary transaction and not be making a profit. I wonder who the fees will filter out in this case…

2025-09-28 05:11:27 UTC

- reply

I think it’s important to distinguish that the article Satoshi included in the genesis block was included in the Coinbase part of the transaction (nothing to do with the exchange).
Each block must have one and only one coinbase transaction which is the transaction that distributes the block reward to the miner.
The coinbase transaction is part of what is used to generate the hash for the block, and so if satoshi did not include the article the hash of the genesis block would be different. Technically this does not affect the bitcoin protocol but served as a neat way to alter the hash of the genesis block as well as adding a human readable timestamp in the form of an article.
Just about all mining pools add their name (for example Foundry) to the coinbase transaction as a common practice but is not technically necessary.
From my understanding, there is no limit to size of the coinbase transaction besides the block weight (4mb). This incentivises miners to include less in the coinbase transaction as a larger coinbase transaction leaves less room for regular transactions (less fees earned) and may cause that block to propagate the network slower.

2025-09-27 10:22:46 UTC

- reply

Please remind me how people choosing what they want to filter out of their OWN mempool and OWN hardware undermines bitcoin’s core principles?

2025-09-27 09:58:55 UTC

- reply

If enough people run nodes that filter out op_return larger than 80 bytes then miners will have less incentive to include that arbitrary data in blocks.
In the case of a miner mining a block with arbitrary data that most nodes do not have in their mempools because of filters, that block’s propagation will be slower meaning the miner has a higher risk of the block going ‘stale’. This is a real risk and is why Mara Slipstream cost 2x the fees of the normal p2p network.

2025-09-23 08:24:04 UTC

- reply

Why does knots filtering suck from an engineering perspective?

2025-09-09 21:35:18 UTC

- reply

- Increasing the amount in which people’s nodes store in their mempool and relay to other people’s nodes by 1250x is major. Changes do not have to be just to the consensus level . If the default data carrier size is increased by 1250x on 80% of the nodes (I understand that 80% represents all of core’s software versions, so v30 may end up looking a lot less) then spam will end up at a miners node more often than not.
- Yes people are already able to store arbitrary data on chain. You either have to A mine a block yourself, B go directly to a miner (Mara Slipstream), C use the inscriptions exploit. With 100kb of op return, it allows people to store arbitrary data not just on chain but also in nodes mempools for a lower cost than option A and B in one whole contiguous chunk unlike C which must be broken into chunks. It’s one thing to say “oh people are already putting arbitrary data on chain”, and then not do anything about it. It’s another thing to say that and then actively make it easier for people to upload spam, for the sake of block propagation and fee estimation.
- Making the p2p network relay spam which is valid by consensus, but that makes it harder to run a node due to computational costs of processing these larger stores of data, plus any sort of data that is illegal / immoral, makes it more difficult / more undesirable to run a node and hence less people will do it leading to centralisation. Please note this illicit data does not even have to be mined for nodes to store it, it just has to be relayed to them…
- Arguably the social consensus layer to bitcoin is the most important as it is the one steering the ship and advocating for changes / decisions and pointing out problems . Bitcoin is not a conscious being and so it will head where we want it to head. It’s almost certain that social consensus (ie the large majority of bitcoiners) would be up for the idea of quantum resistant addresses because it serves their best interests. The op return change only serves the interests of those who wish to spam the chain and miners who are focused on short term profit rather than preservation.
- It’s true just run another client which approx 20% of the network is doing. The issue is core had approx 99% of the market share before this change and were / are the reference implementation and so any change they make even to mempool policy has its effects
- I don’t think considering potential threats and attacks is FUD, I think it’s more about being vigilant and not complacent
- Maybe Luke is using this as a power grab / portraying himself as the hero. He must have been planning this since 2023 because that’s when he released knots. So maybe he initiated core to make the op return change so that people would switch to knots and herald him as the hero. It’s definitely quite the plan. Maybe he was also behind the inscriptions hack because that was one of the reasons he created knots. Wow this goes deep…

2025-09-09 10:31:58 UTC

- reply

The large and important difference between these 2 situations is that on one occasion you have a side trying to push a major change (big blockers who lost on the social consensus front) and on the other, a major change that has already been pushed regardless of any social consensus. There’s no power grab, it’s just people against this change to op_return pointing out the issues involved with the relaxation of filters. Because core has already pushed this change and it looks as though it will be released in v30, the only way people thinking this change is reckless can voice their opinion is by running knots with customisable mempool policies.
What Luke is saying in that post you linked is that either:
- Core with this change and/or potentially future changes made in a similarly rash fashion could/will destroy bitcoin or at least make running nodes unfavourable for the average Bitcoiner leading to centralisation
- Or the bitcoin community will push back against core, diminishing core’s reputation and credibility to potentially nothing.
Personally I think the latter, as I think there are more bitcoiners who wish for it to remain as a monetary protocol rather than a JPEG database / cloud storage…

2025-09-07 22:33:13 UTC

- reply

It’s completely different because Core (the reference implementation) initiated this and so likening the push back from people against spam to the big blockers, who were trying to push something new (larger blocks) doesn’t make sense.