Dathon Ohm

GPG: 0x2E3A66FF67F98B4F

Public Key

npub1azrgrnlmutgxvvjnrtvsn6npm6a08vqz0n0k3k4kf226sv2n93ls4ajl96

NIP-05 Address

Profile Code

nprofile1qqsw3p5pela795rxxff34kgfafsaawhnkqp8ehmgm2my49dgx9fjclcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgdwaehxw309ahx7uewd3hkceutcdg

Publishing to

Author Public Key

npub1azrgrnlmutgxvvjnrtvsn6npm6a08vqz0n0k3k4kf226sv2n93ls4ajl96

Show more details

Last Notes

2026-01-22 19:35:40 UTC

I'm pleased to announce Release Candidate 3 of the UASF BIP-110 v0.1 official client: https://github.com/dathonohm/bitcoin/releases/tag/v29.2.knots20251110%2Bbip110-v0.1rc3
@Start9Labs, @Umbrel, and @mynodebtc have been updated (see below for details).
Thanks to our many contributors, and to the Bitcoin community, for your support.
Bitcoin is money!
-----
@Start9labs v0.3: https://github.com/dathonohm/knots-startos/releases/tag/v29.2.knots20251110%2Bbip110-v0.1rc3
Follow the instructions here to install this package from the official BIP110 marketplace: https://bip110.dev/howto
You may also sideload this package, as usual.
-----
@Umbrel users may now signal for BIP-110 from the latest version of the Knots app. Just go into your settings and select "BIP110" from the dropdown.
Special thanks to the Umbrel team for getting this over the line!
Umbrel PR: https://github.com/getumbrel/umbrel-apps/pull/4237
Instructions for running BIP-110: https://x.com/dathon_ohm/status/2014371554700718449
-----
@mynodebtc support has also been added in this PR: https://github.com/mynodebtc/mynode/pull/986
Special thanks to the MyNode team for getting this over the line!
-----
A package of RC3 for the alpha-stage @Start9labs v0.4 has also been released: https://github.com/dathonohm/knots-startos/releases/tag/v29.2.knots20251110%2Bbip110-v0.1rc3-startos0.4.0
This package can be sideloaded like any other package.
-----
A third-party PR for experimental @RaspiBlitz support has been submitted. I have neither reviewed nor tested this install script (so please use at your own risk!), but if others would like to confirm that it works, I would consider adding official support: https://github.com/dathonohm/bitcoin/pull/8
-----
With this release, all known issues with the BIP-110 code have been resolved, so your experience should be smooth.
As always, thanks again to the Bitcoin community for your patience, feedback, and support.
Bitcoin is unstoppable, sound money!
(originally posted on X: https://x.com/dathon_ohm/status/2014049821712093356)

2025-11-08 01:54:00 UTC

- reply

Can you explain your reasoning?

2025-11-08 01:52:34 UTC

The new draft of the BIP has been posted to the bitcoindev mailing list:
https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8/m/d4tkNi0DAQAJ
The code has been published here:
https://github.com/bitcoinknots/bitcoin/compare/29.x-knots...UASF:bitcoin:29.2.knots20251010+BIP444?expand=1
I'm looking forward to hearing your feedback.

2025-11-05 15:42:17 UTC

- reply

It's possible.

2025-11-04 22:45:02 UTC

After much discussion and consideration, I have decided to remove the reactive deployment method and the legal/moral motivations from the BIP document.
I still think those things are important and the reactive deployment may become necessary in an emergency, but I want to continue building consensus and those features were hampering progress.
I hope to have the new draft ready in the next day or two.
Thanks to everyone for your support so far.

2025-11-01 20:52:48 UTC

- reply

Updated
https://primal.net/e/nevent1qqsd343pq5gwlc90lsyvhw7lsn7t6fkqnnrsv2q0u2v6t4neh6qduzc5phv50

2025-11-01 20:29:19 UTC

- reply

Claims of confiscation are just FUD. A competent person tried to find an example of a TXO that could be confscated by BIP444 and came up with nothing. But to be completely sure, I'm adding a UTXO height check in the next draft of the BIP.

2025-10-30 23:51:38 UTC

- reply

Respecfully, no one's money is being "seized". That is sensationalism.
A few UTXOs may be frozen up to a year, but only if created after the fork activates.
See:
https://primal.net/e/nevent1qqsfggty50a8jk2h32yn79kpn94esh0aqjutlzpaq0frgh58c0uc52ct3equn

2025-10-30 23:41:55 UTC

- reply

How?

2025-10-30 19:47:10 UTC

- reply

This fork will, among other things, decisively determine whether Core 30 is an authority. I think a large majority agrees that it is not.

2025-10-30 05:09:45 UTC

- reply

OP_RETURN officially supports up to 100kB of file storage, as of Core 30.

2025-10-30 05:08:31 UTC

- reply

Exactly

2025-10-30 05:07:01 UTC

- reply

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.

2025-10-29 15:25:57 UTC

- reply

BIP-444 is not about fighting spam in consensus
https://blossom.primal.net/259c86ecb01d420c6d740efafa554f270c6ade2505f8d5aecb29a047d69b998e.jpg

2025-10-29 15:13:22 UTC

- reply

Rules, not rulers

2025-10-29 14:59:03 UTC

- reply

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.

2025-10-29 14:18:13 UTC

- reply

If BIP-444 (or something like it) doesn't activate, then everyone will be required to knowingly possess and distribute whatever nasty things end up in the chain, in the clear, for the rest of eternity.

2025-10-28 20:41:26 UTC

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

2025-10-27 19:41:47 UTC

- reply

To verify this message, you can `curl` it from primal:
`curl -s https://primal.net/e/nevent1qqsftjva2mrgqz4txclsnqdh2squfmecms97e9cx4n8muhs5p756wrqmgxxvt`
Then copy the "content" field and parse it like so:
`echo <content> | sed 's/
/\n/g' > temp.asc && gpg --verify temp.asc && rm temp.asc`

2025-10-27 19:25:32 UTC

- reply

2025-10-27 19:01:12 UTC

- reply

nevent1qqsy65qgx6papt2nkhprryuv85dy29xlnd4qwkevyt8grhawcljyrsq4dd3v4

2025-10-27 18:58:26 UTC

My GPG key can be installed like so:
curl -s https://api.github.com/users/dathonohm/gpg_keys | jq -r '.[0].raw_key' | gpg --import

2025-10-27 18:56:38 UTC