Thread

Here is an updated version of my email to the bitcoindev ML, which fixes a typo: Hi list - I was hoping to post this on the PR, but it's still locked so I will post it here. I don't really have any other methods of addressing the public as my X account has also been suspended due to trolls reporting it. I did create a Nostr account, but Nostr doesn't seem to have many users. There is a wild misconception floating around that the BIP I am proposing is a "legal threat from Ocean Mining". This could not be further from the truth, and I suspect this nonsense is being pushed by people who would love to see Bitcoin become a data storage service. I would like to take this opportunity to correct the record. Though I am in direct communication with some Ocean employees (and the BIP was originally drafted by one of them), I am not affiliated with Ocean in any way. I am just a Bitcoin dev who is concerned about the implications of Core 30 having been released and gaining adoption. The references to "legal risks" in the BIP are not "threats". They are warnings about a major legal and moral threat that has been created by Bitcoin Core 30's officially designating Bitcoin as a storage service for files up to 100kB. Specifically, there is an unknown level of risk that node operators could be classified as sex offenders (or some other type of criminals depending on the content) for possessing and distributing toxic content. This threat does not come from me, or from Ocean, but rather from Core 30 and its effect on node operators themselves, their consciences, and the communities in which they live. Core 30 forces every single node operator, from the moment toxic content is posted to the blockchain until the end of time, to be complicit in sexual (or other) crimes via possession and distribution of illegal data. So now that Core 30 is gaining adoption, it's very likely that, given the choice of whether to participate in Bitcoin or not, most normal people will simply choose not to participate, and then Bitcoin becomes just another BSV. If Core had just left the OP_RETURN limit where it was, no significant legal threat would exist, and no consensus changes would be urgently needed. I am not saying "I'm going to sue you if you don't support the fork". That is ridiculous. I am saying "you probably want to support this fork if aiding and abetting sex offenders (and potentially being one yourself) does not appeal to you, and you may not want to run a node once Core 30's new default policies become the standard (which is about to happen)." Most Bitcoiners I know signed up for permissionless money, and believe strongly in the freedom to transact, even for people who do things we don't like, since the vision of a maximally neutral monetary standard is why we're all here in the first place. Because Bitcoin's purpose is to be permissionless money, simply storing and forwarding a record of an "illegal" purchase is acceptable to most node operators, because that is the price of entry for trustless, digital money. Storing and forwarding actual illegal content, in the clear, however, is not a problem Bitcoin was ever intended to solve, nor something in which Bitcoin node operators are interested in participating. Indeed, permissionless censorship-resistant data storage is probably not a sustainable idea, without some kind of periodic payment to the person tasked with storing the data. In any case, forcing all Bitcoin node operators to knowingly commit crimes totally unrelated to the operation of Bitcoin as permissionless money, for the rest of eternity,Β is obviously a foolish idea and will quickly lead to node centralization and irrelevance if we do not act. Yet this heavy-handed and completely unnecessary imposition is precisely what Core 30 achieves, unless it is enthusiastically opposed by the community. Even in the best case, Core 30's new default policies set a terrible precedent that must be immediately reversed. Since almost all forms of illegal data can be avoided by limiting data fields to 256 bytes, BIP-444 seems like a no-brainer to me, because it neatly dodges the dark fate that awaits us down the data storage path. Having engaged many principled Bitcoiners on this topic for a long time, I can confidently say that Bitcoiners overwhelmingly support keeping Bitcoin as permissionless money, and overwhelmingly oppose Bitcoin's block space being used for data storage. Limiting large data storage in consensus, as BIP-444 does, is the easiest way I can see to give everyone what they want. So even if BIP-444 does not activate in its exact current form, I am dedicating myself to helping Bitcoin re-affirm its commitment to permissionless money while re-affirming its opposition to data storage. I am incorporating all feedback I am hearing (which is a lot!) into the next draft of the BIP. Thanks again to everyone for your thoughtful and respectful engagement on this matter critically important to the future of Bitcoin. Together we will find the way forward. Sincerely, Dathon

Replies (60)

I guess this is the guy who wrote that bip. Don't just read one side - one side is claiming there was a legal threat. I haven't been able find it, and its looking like that was an example of influencers misleading people.
Dathon Ohm's avatar Dathon Ohm
Here is an updated version of my email to the bitcoindev ML, which fixes a typo: Hi list - I was hoping to post this on the PR, but it's still locked so I will post it here. I don't really have any other methods of addressing the public as my X account has also been suspended due to trolls reporting it. I did create a Nostr account, but Nostr doesn't seem to have many users. There is a wild misconception floating around that the BIP I am proposing is a "legal threat from Ocean Mining". This could not be further from the truth, and I suspect this nonsense is being pushed by people who would love to see Bitcoin become a data storage service. I would like to take this opportunity to correct the record. Though I am in direct communication with some Ocean employees (and the BIP was originally drafted by one of them), I am not affiliated with Ocean in any way. I am just a Bitcoin dev who is concerned about the implications of Core 30 having been released and gaining adoption. The references to "legal risks" in the BIP are not "threats". They are warnings about a major legal and moral threat that has been created by Bitcoin Core 30's officially designating Bitcoin as a storage service for files up to 100kB. Specifically, there is an unknown level of risk that node operators could be classified as sex offenders (or some other type of criminals depending on the content) for possessing and distributing toxic content. This threat does not come from me, or from Ocean, but rather from Core 30 and its effect on node operators themselves, their consciences, and the communities in which they live. Core 30 forces every single node operator, from the moment toxic content is posted to the blockchain until the end of time, to be complicit in sexual (or other) crimes via possession and distribution of illegal data. So now that Core 30 is gaining adoption, it's very likely that, given the choice of whether to participate in Bitcoin or not, most normal people will simply choose not to participate, and then Bitcoin becomes just another BSV. If Core had just left the OP_RETURN limit where it was, no significant legal threat would exist, and no consensus changes would be urgently needed. I am not saying "I'm going to sue you if you don't support the fork". That is ridiculous. I am saying "you probably want to support this fork if aiding and abetting sex offenders (and potentially being one yourself) does not appeal to you, and you may not want to run a node once Core 30's new default policies become the standard (which is about to happen)." Most Bitcoiners I know signed up for permissionless money, and believe strongly in the freedom to transact, even for people who do things we don't like, since the vision of a maximally neutral monetary standard is why we're all here in the first place. Because Bitcoin's purpose is to be permissionless money, simply storing and forwarding a record of an "illegal" purchase is acceptable to most node operators, because that is the price of entry for trustless, digital money. Storing and forwarding actual illegal content, in the clear, however, is not a problem Bitcoin was ever intended to solve, nor something in which Bitcoin node operators are interested in participating. Indeed, permissionless censorship-resistant data storage is probably not a sustainable idea, without some kind of periodic payment to the person tasked with storing the data. In any case, forcing all Bitcoin node operators to knowingly commit crimes totally unrelated to the operation of Bitcoin as permissionless money, for the rest of eternity,Β is obviously a foolish idea and will quickly lead to node centralization and irrelevance if we do not act. Yet this heavy-handed and completely unnecessary imposition is precisely what Core 30 achieves, unless it is enthusiastically opposed by the community. Even in the best case, Core 30's new default policies set a terrible precedent that must be immediately reversed. Since almost all forms of illegal data can be avoided by limiting data fields to 256 bytes, BIP-444 seems like a no-brainer to me, because it neatly dodges the dark fate that awaits us down the data storage path. Having engaged many principled Bitcoiners on this topic for a long time, I can confidently say that Bitcoiners overwhelmingly support keeping Bitcoin as permissionless money, and overwhelmingly oppose Bitcoin's block space being used for data storage. Limiting large data storage in consensus, as BIP-444 does, is the easiest way I can see to give everyone what they want. So even if BIP-444 does not activate in its exact current form, I am dedicating myself to helping Bitcoin re-affirm its commitment to permissionless money while re-affirming its opposition to data storage. I am incorporating all feedback I am hearing (which is a lot!) into the next draft of the BIP. Thanks again to everyone for your thoughtful and respectful engagement on this matter critically important to the future of Bitcoin. Together we will find the way forward. Sincerely, Dathon
View quoted note →
Since author of BIP 444 clarified the Legal Threat FUD, let's see what else @ODELL comes up with to FUD about BIP 444. It seems like @Dathon Ohm is humble enough to accept the mistake and he is open to make some improvements in the next draft of BIP 444. If gay retarded core devs would have done the same thing before forcing V30 (aka malware) on us, we wouldn't be talking about this BIP. Anyways, I can't wait to hear LIAR OR FUCK OFF from @ODELL. View quoted note β†’
Any time there is a way to add arbitrary data to the blockchain, the risk exists for something someone doesn’t want in their node. If you were sincere in wanting to remove said unwanted data, you would develop a BIP that would let node operators delete arbitrary data from their historical record database as well as add filters, but still maintain the merkle root and β€œtip of the chain”. Oh, wait, that’s what OP_RETURN pruning does. I guess that doesn’t fit the narrative.
How can anything illegal be limited? You can simple break data up and do multiple transaction and add more and more utxo bloat to the chain. Your entire BIP was put Onchain as bip444 complaint transaction. Your acquiescence to fear is pathetic.
The risk you allude to always existed (and probably will always exist) because 1) it was always possible to mine a block with illegal content in an OP_RETURN, and 2) illegal content can always be embedded in the blockchain using various other methods (even if your BIP is adopted). Fortunately, there appears to be pretty broad consensus among experts in law that this is not a real risk, anyways:
Protos
EXCLUSIVE: Lawyers call Bitcoin Core v30 CSAM concerns β€˜overblown’
Bitcoin Knots supporters have argued that a change to an upcoming release of Bitcoin Core could open node operators up to legal attacks.
↩ replying to npub1art8...m0w5
Thank you for actually engaging with this question. I read that article back when it came out and I'm not convinced just reaching out informally to a few lawyers is enough due diligence. At least not when the risk is this high. Even then 1/7 of them actually was concerned about it. If we roll with that as the only evidence that was gathered we have a 1/7 chance Bitcoin will be deemed illegal in the future. I'd be more reassured if we had any lawyers actually seriously look into the risks involved. Or had some statements from government bodies that'd be involved that we're in the clear. (FCC in the US? Equivalent EU bodies?)
↩ replying to npub1art8...m0w5
The difference is that pre-Core-30, Bitcoin did not officially support large file storage. So node operators had much less culpability. As for the "lawyer consensus" in that article you linked, you must not have read it if your conclusion is that "this is not a real risk". Almost all of the lawyers in the article said it's a risk. The question is whether Core 30 meaningfully increases the risk. I think it's obvious that it does, as I said above. Data spam is a slippery slope. We have to draw the line somewhere, and this may be our last chance to draw the line. BIP-444 is the line.
↩ replying to Dathon Ohm
There is nothing β€œofficial” in Bitcoin. I think it’s obvious that Core 30 does not meaningfully increase the risk, because as pointed out these same risks already existed. If node operators are nevertheless concerned about legal risks if they run Core 30, they can just run a different node implementation, whether that’s an older version of Bitcoin Core, Bitcoin Knots, or whatever.
↩ replying to npub1art8...m0w5
Bitcoin Core was, until recently, the closest thing we had to something "official", because until recently, Core tried to represent a supermajority of its users. I don't agree at all that "it's obvious" that Core 30 doesn't meaningfully increase risk. "These same risks", namely Core 30 officially sanctioning large file data storage on the blockchain, have certainly never existed before. Running a different client does not change anything if the de facto standsard on the network is that data storage is an official use case. But forking will change things, because it reverses the official sanctioning into an official rejection of the data use case.
I might be wrong but, if there is illegal content in the op return of a minned block, it doesn't matter if you have core or knots. You will be storing and distributing it anyways, right? For what I understood the difference between them is in the transaction you admit and broadcast to the mempool It's all a question. I'm not sure if i've got it right #asknostr
**** This just in.. pedoland under 'pedo software' "crisis" **** The U.S. is the only UN member state that has not yet ratified the Convention on the Rights of the Child. As of July 2025, child marriage is legal in 34 states.