Google Pay is the only significant thing which does not work with GrapheneOS, but you can use a smartwatch.
Tested Garmin Pay so far, no problems.
I come to X only to unfollow people. Maybe mute too.
UtxoPocket v0.11.0
* UTXO analysis suite – New Analysis tab adds interactive treemap tiles, age distribution chart, and spendability/value charts.
* Treemap drill-down – Tap tiles to see age bucket, outpoint, address, and jump straight to UTXO detail via the sheet CTA.
* Wallet output deep links – Transaction outputs in wallet views now open the UTXO detail screen directly for faster inspection.
* Change/own badges – Clarified change badges in transactions.
https://github.com/strhodler/utxopocket-android/releases/tag/v0.11.0
This is awesome!
Also please let us set a gap limit or specify the number of monitored addresses for both the deposit and change accounts.
Some well used wallets will thank you!
Check out the Sparrow Server, it has a fully featured Terminal UI:
True, but at least using the Free Open Source client Molly you can share between devices 
Open source, bitcoin native soft fork betting without intermediaries 👌
Nothing more motivating to hold your own keys than a hard fork lined up.
Yes, there is a whole section in the docs about different scenarios: https://docs.raspiblitz.org/docs/community/storage_migration
You can always exit to the terminal with CTRL+C then type: `menu`
If you have no channels might need to add a lightning peer manually to progress from the startup sync screen.
⚡Version 1.12.0 of RaspiBlitz Released⚡
New data layout with optional NVMe boot on Pi 5. On Proxmox now separate data & storage drives. Still works on Pi 4 - but 64GB SD card + 2TB SSD/NVMe now recommended. Many updates & fixes.
Download: https://docs.raspiblitz.org/docs/setup/software-setup/download 
This node running #Raspiblitz v1.12.0, Bitcoin Core v29.0 on RPi5 8GB + 2TB nvme, dbcache=4096, peering on Tor and I2P only has finished this morning in 2 days 16 hours (or 64 hours).
Should test syncing on clearnet next, then Bitcoin Core v30.

Here the links for the UPS hat and batteries if you'd like to build a Floating Node for the lulz :
https://www.amazon.com/Geekworm-X1202-Raspberry-Shutdown-Detection/dp/B0CRZ4ZXQW
https://www.amazon.com/SOOCOOL-Authentic-Samsung30Q-3000mAh-Rechargeable/dp/B0BNLPWKXR
This guy is floating his RPi5 on water while it is validating the bitcoin blockchain under 4 hours.
https://pretyflaco.github.io/bitcoingovernance/
🧵 I published my perspective on Bitcoin governance.
Where does Bitcoin derive its censorship-resistance from? And how do we preserve it?
Sharing some frameworks I've found helpful 👇
The main insight: Bitcoin's unique value comes from censorship-resistance, and the two magic ingredients to achieve it are:
✅ Free users
✅ Free software
-> Censorship-resistance requires free users
-> Free users require free software
Traditional governance asks "who decides?"
These systems are easy to co-opt and can therefore never preserve censorship-resistance.
Bitcoin governance asks "how do we preserve free users?", and this is they key to preserving censorship-resistance.
For developers, this means:
-> Optimize for user agency
-> Default to user choice over "optimal" outcomes
Remember: we're building infrastructure for freedom.
These are just my current thoughts - governance philosophy evolves with experience - but it's clear to me that censorship-resistance is a derivative of free users.
There is a leap of faith required in bitcoin’s governance model.
We must trust that when users are given genuine freedom and access to good information, they will make choices that preserve what makes bitcoin valuable.
Users who want bitcoin to remain censorship-resistant will choose software and rules that maintain that property.
Users who prefer other properties may make different choices, but the network’s evolution will reflect the aggregate of all these individual decisions.
When we take the leap and trust that free users will make the right choices, Bitcoin succeeds.
I would love to hear perspectives from builders, users, and researchers working on or thinking about these problems.
Take a step back and think through how the rules of Bitcoin are coming to be.
This article provides valuable insight with a fresh perspective on the topic: https://pretyflaco.github.io/bitcoingovernance/
I appreciate the detailed response, but in these points we are in disagreement:
1. Policing your node vs. "the network": Framing this as only policing your own node overlooks the network externalities. Your filtering directly impacts the efficiency of block propagation for your peers. It turns an individual policy choice into a network-wide cost.
2. Your definition on what transactions should be allowed: The proposed definition of "spam" is not a filtering policy; it's an argument for a hard fork. The current Bitcoin consensus explicitly allows these transactions, and has for years. To enforce your narrow definition network-wide, you would need to change the fundamental rules of the protocol. This brittle definition would not only freeze Bitcoin's capabilities but would also classify many existing financial tools from multisig to timelocks and covenants as invalid. The arbitrary exception for L2 HTLCs only proves the point: you're not defining spam, you're just green-lighting your preferred use cases.
3. The arms race is asymmetric: This isn't a battle of diligence; it's a battle of economic incentives. There's a powerful financial motive to embed data, but only a weak, ideological one to filter it.
4. You're underestimating steganography: You're focused on overt data, but the real challenge is data hidden within what looks like a perfectly valid financial transaction. A filter cannot distinguish intent. To block it, you'd have to block entire classes of legitimate transactions that are valid under today's consensus, which is a non-starter.
Fair point regarding the fee estimation and appreciate the detailed breakdown. I gladly accept that the fee estimation is robust enough even with a partial view of the mempool.
> Core's strategy to achieve that goal is, I think, worse than the disease: Core's users opt to relay spam transactions as if they were normal transactions, that way they don't have to download them when they show up in blocks.
The choice isn't between a cure and a disease (purity vs. efficiency), but about upholding network neutrality. The Core policy relays any valid transaction that pays the fee, without making a value judgment.
The alternative - active filtering - is a strategic dead end for a few reasons:
- It turns node runners into network police, forcing them to constantly define and redefine what constitutes "spam."
- This leads to an unwinnable arms race. As we've seen throughout Bitcoin's history, the definition of "spam" is a moving target. Data-embedding techniques will simply evolve to bypass the latest filters.
- The logical endgame defeats the purpose. The ultimate incentive for those embedding data is to make their transactions technically indistinguishable from "normal" financial ones, rendering the entire filtering effort futile.
If that's not good enough could try a parallel with abortion clinics too.
Just because a block is mined by Ocean it is not guaranteed to be spam free exactly because they allow custom templates.
Less valid transactions in my mempool will make my node unreliable in predicting the next block and estimate fees, especially in extreme cases where it could be critical.
Not relaying is the same as not running that node for those transactions, does't stop anyone else.
The filtering node slows down it's own to verify blocks - will be later to reach the tip, will waste hashrate in that time if mining.
Only the fastest route counts so even a supermajority would not be signficant.
I just wonder what can be the endgame here?
Filterers want to stop transactions they don't like, but no penetration of filters can prevent a small fraction of nodes to relay non-standard transactions and miners to directly accept them.
Ocean is gathering hashrate.
When hard fork?
Increasing the OP_RETURN limit to match what can already be included in a valid block is like placing a garbage bin to a littered street.
Can't stop people from littering and can't even make them to put rubbish in the bin, but can at least provide them with a less bad path.
OP_RETURN outputs are paying a full price, not stored in the chainstate and are prunable from the downloaded data.
Can you share which operator is this?
Is it also cheaper in data? (probably the only thing which matters now)
have a VPN exit node, but not in the UK
This is the most in depth analysis of the 80K BTC move I have seen so far. I'd love to hear nostr:nprofile1qqsw3znfr6vdnxrujezjrhlkqqjlvpcqx79ys7gcph9mkjjsy7zsgygpzpmhxue69uh5ummnw3ezuamfdejsz9thwden5te0v4jx2m3wdehhxarj9ekxzmnymlvvup
comment on it.
https://www.cyphertux.net/articles/en/research/bitcoin-80k-btc-mystere-opreturn
Great read: https://www.cyphertux.net/articles/en/research/bitcoin-80k-btc-mystere-opreturn
we are living the sci-fi.
nostr:nprofile1qqs0ekqcg4qq9fky02vq8yls2jdvde3f62x4dzq3fwmqmqcmtsvr9fcpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsz9thwden5te0dehhxarj9ehhsarj9ejx2a30qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7m5lzc5 do you have a status update?
Both the website and service is down.
www.isitdownrightnow.com/lnvps.net.html
Check out the new nostr:nprofile1qqszr7k0w6gclv3usnqmey68uzs6h2yt7dpw2dyeqt0sh8ehaxl8xyqpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qeeu3ku VPN app to replace Orbot eventually:
https://gitlab.torproject.org/tpo/applications/vpn
Experimental version download here:
https://gitlab.torproject.org/tpo/applications/vpn/-/packages/726


