No, check out that transaction. The limits for script witness are currently 4MBs by consensus and 400kBs by standardness.
(Please correct me if I'm wrong, but this is my read of it)
https://bitcoin.stackexchange.com/questions/117594/what-are-bitcoins-transaction-and-script-limits
And if I'm correct, then the whole Knots CSAM argument is just fear mongei, right?
No, check out that transaction. The limits for script witness are currently 4MBs by consensus and 400kBs by standardness.
(Please correct me if I'm wrong, but this is my read of it)
https://bitcoin.stackexchange.com/questions/117594/what-are-bitcoins-transaction-and-script-limits
Raw bytes of data (probably incl CSAM) are already on your hard drive, because people have been putting these into witness for years as inscriptions, since these bytes are actually discounted in terms of fees. 
E.g. Transaction: 521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79da - mempool - Bitcoin Explorer https://share.google/yr7OQxAgC6XNThp7w
Fixes get backported usually in couple versions back. Again, up to you whether you update your node or not.
"Note: A 4% convenience fee will be charged when processing your payment with a credit or debit card."
Thank you! Very convenient. It would be even more convenient if you set all your systems on fire and just switch to bitcoin already.
On Nostr you are the algorithm, so maybe you just need a better rhythm?
Luckily the Ethernet MTU limit is 1500 bytes, so no CSAM is possible. Oh, wait.
We have early access to Android Security Bulletin patches and will be able to set up a workflow where we can have releases already built and tested prior to the embargo ending. For now, we've still been doing the builds after the embargo ends. It will mainly help when they screw up pushing to AOSP.
We're in the process of obtaining early access to the major quarterly and yearly releases. This is a much bigger deal and will substantially help us. There's an immense workload with a lot of time pressure for porting to new major releases without early access which gets worse the more we change.
We did not have early access to Android 16 QPR1 and have not been able to start porting yet. We should have early access prior to Android 16 QPR2.
We're going to need to make private repositories for working on this stuff internally. We can potentially make special preview releases based on these.
Google recently made incredibly misguided changes to Android security updates. Android security patches are almost entirely quarterly instead of monthly to make it easier for OEMs. They're giving OEMs 3-4 months of early access which we know for a fact is being widely leaked including to attackers.
We can't break the embargo ourselves but if someone posted the patches publicly we would be able to ship them months early, as would others. The patches are broadly distributed to OEMs where most of their engineers have access. Companies like NSO can easily obtain access. It's not a safe system.
Google's existing system for distributing security patches to OEMs was already incredibly problematic. Extending 1 month of early access to 4 months is atrocious. This applies to all of the patches in the bulletins. This is harming Android security to make OEMs look better by lowering the bar.
The existing system should have been moving towards shorter broad disclosure of patches instead of 30 days. Moving in the opposite direction with 4 months of early access is extraordinarily irresponsible. Google has also abandoned pretending it's private by allowing binary-only embargo breaches.
Android's management has clearly overruled the concerns of their security team and chosen to significantly harm Android security for marketing reasons. Lowering the bar for OEMs to pretend things are fine while reducing security for everyone is a ridiculous approach and should be quickly reversed.
Android is very understaffed due to layoffs/buyouts and insufficient hiring. This is impacting Linux kernel and Android security. Google hasn't fixed http://taptrap.click which is a serious issue privately disclosed to them in October 2024. We were informed in June 2025 and it took us a few hours to fix...
Google does a massive portion of the security work on the Linux kernel, LLVM and other projects including implementing exploit protections, bug finding tools and doing fuzzing. They're providing the resources and infrastructure for Linux kernel LTS releases. Others aren't stepping up to the plate.
We don't expect there to be much pushback against this via tech media despite how obscene it is to provide 4 months of patch access to sophisticated attackers. They can easily get it from OEMs or even make an OEM. Whistleblowers should publicly post the signed zips since attackers have it already.
Security patch backports were pushed to the Android Open Source Project on September 2nd but it wasn't done properly. Android 16 QPR1 was also supposed to be pushed to the AOSP on September 3rd and it was even confirmed they'd still be doing that but it hasn't happened. Perhaps too many layoffs...
Even if no whistleblowers leak the signed zips we can still bring this system down ourselves without breaking any embargo. Our plan is to make special releases with the patches which are otherwise identical to our regular releases. External developers can reverse it from that for regular GrapheneOS.
We're allowed to make a release with currently available revision of the December 2025 Android security patches right now but we wouldn't be allowed to publish sources. Therefore, we'd need to do this separately from regular GrapheneOS. We could special release channels for it with delayed tags...
The purpose of this approach is for someone to reverse the Java and Kotlin patches to source code within an hour of us releasing that. They could then submit security patches elsewhere including to GrapheneOS that is open source. This clearly isn't something Google's technical security people came up with as it's completety nonsensical.
It's probably a good idea to implement/expand good open source tooling for reverse engineering of the security patches and provide very clear automated guidelines/scripts for how to use it 😉
So don't store those OP_RETURNs. These are not needed for the validation, excluded from UTXO set...
What is the practical difference between being Proxy+VPN feature versus VPN first?
Why would anyone buy the nft from this guy for that much?
There are many folks in the space that have a gap or two in their communication skills and that's often the root cause of the conflicts in my opinion.
If someone is in such situation (on either side), pls chat with Rusty or I'm also happy to jump on a call and talk through it, maybe give some tips and tricks.
I have been helping resolve conflicts between engineering teams for the last 12 years.
I'm still amazed how good Jellyfin is. Simple clean UI, no garbage, no ads, it works on my Samsung TV controlled with Samsung remote, it has IMDB score integrated, can download subtitles directly from it, it automatically pulls images for each movie in the Library, I just need to upload the movie to the right folder over scp and it indexes everything automatically, it works on my phone and laptop anywhere (over Tailscale), each movie has description, trivia on the actors...
#jellyfin #selfhosting
Yep, both correct. If the concentration would go higher people will get measurably stupider. If the concentration goes lower, then plants will die.
i have some WM and DE install scripts for Debian
https://github.com/e33io/scripts?tab=readme-ov-file#window-managers-and-desktop-environments
Very cool! Although there are small changes I'd recommend... like using keyd instead of input remmaper. And I'd probably switch the bigger apps to flatpak instead. I understand installing Signal and Brave natively though.
I have PopOS, but my plan is to just switch to plain Debian now...
Geyser now creates nostr profiles and posts for the campaigns, so the integration via nostr may not be that far. I don't know enough details about either though.
Keep soaking and flourishing.
Geyser has a good experience for this though. Anyway, just a thought...
Idea: Wouldn't it be cool if nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qpq0r8xl2njyepcw2zwv3a6dyufj4e4ajx86hz6v4ehu4gnpupxxp7s85uvay has integration with nostr:nprofile1qyt8wue69uhkummnw3ezuer9d3hhgett9e6xktcpremhxue69uhkgetk9ehx7um5wfcxcctevaex7atwvshxxmmd9uqzpdkumh0cve6jslg6f6rzpkf24yzuykxc2zlcejfr6wwlrm07uhh878n2y8 to have a streamlined way for app authors to create a crowdfunding projects? From app author perspective I could upload to Zapstore and then click on a button to "create crowdfunding" and that would give me full experience of having a campaign, profile, etc.
Just let it out on us for no good reason, so we get the full experience 😅
When you are in a room with more than 1000, you get measurably more stupid. Over 2000 your performance on standard tests goes down to something like 50%.
Of course there is. Bitcoin chain has been used for all sorts of stupid data for many years.
I think you may appreciate other, non bitcoin chains... like Fedwire.
Or we can lose and we can save a lot of book writing time?
If someone wanted to donate to a non-profit that supports Bitcoin, which one is doing the best work?
HRF, OpenSats?
My mrs has superpowers in getting discount on anything. Things like 20% on Airbnb stay BEFORE the stay.
Nostr has now its first german psychopath.
Walking through a corn field.
Without a shirt.
Doing a vlog.
Enjoy wasting 3 minutes of your lifetime 🧡
Timestamp of freedom 910,602
https://blossom.primal.net/5fc2df386b2776f541abe2e303603157f52378d59ae5c25ccb5c895e8a2633b0.mov
I like the part when the corn leaf slapped his face...
New Debian 13 is great!! I really enjoy the new GNOME, and I like the fact that now I actually only a small number of extras/addons on top of the baseline. That gives me comfort that if I'm installing this from scratch it would do well out of the box.
I recklessly installed this over existing Debian 12. The install wasn't as smooth as hoped - it bricked it a bit during installation and GnomeSession wouldn't start, since I had some old config in `~/.config/xkb/`, but nothing that ctrl+alt+F2 wouldn't solve 😉
If you are reckless like me, then you just need to replace the word
"bookworm" in `/etc/apt/sources.list` with the word "trixie", save and then run
`sudo apt update && sudo apt full-upgrade && sudo apt autoremove` and reboot.
#debian #trixie
