I'm pleased to announce Release Candidate 3 of the UASF BIP-110 v0.1 official client:

GitHub
Release UASF BIP-110 v0.1 Release Candidate 3 · dathonohm/bitcoin
Same as RC2, with a couple of important improvements:
Output limits now apply to generation transactions. This slight tightening brings the consen...
@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:

GitHub
Release UASF BIP-110 v0.1 Release Candidate 3 · dathonohm/knots-startos
Release Candidate 3 of the official BIP-110 client, for StartOS v0.3.5.1.
ImportantDue to the technical limitations of StartOS v0.3.5.1, once you i...
Follow the instructions here to install this package from the official BIP110 marketplace:
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:

GitHub
BIP 110 Bitcoin Knots by Retropex · Pull Request #4237 · getumbrel/umbrel-apps
Instructions for running BIP-110:

X (formerly Twitter)
Dathon Ohm / BIP-110 (@dathon_ohm) on X
To signal for BIP-110 on @Umbrel, update to the latest version of the Knots app and choose "BIP110" in the version selector.
-----
@mynodebtc support has also been added in this PR:

GitHub
Bitcoin Knots + BIP-110 RC3 by dathonohm · Pull Request #986 · mynodebtc/mynode
Description
This PR adds Release Candidate 3 of the BIP-110 Reduced_data Temporary Softfork official activation client.
It replaces the PR for RC2....
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:

GitHub
Release UASF BIP-110 v0.1 Release Candidate 3 (for StartOS v0.4) · dathonohm/knots-startos
Release Candidate 3 of the official BIP-110 client, for StartOS v0.4.
ImportantThis release is only for StartOS v0.4.
About
Release Candidate 3 o...
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:

GitHub
Raspiblitz script by SatoshiNakamotoBitcoin · Pull Request #8 · dathonohm/bitcoin
This script updates Bitcoin KNOTS+BIP-110 from Bitcoin Core, providing options for info, tested, reckless, or custom updates. It includes version c...
-----
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)
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.
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