Last Notes
FYI @nprofile…xr9f. Probably not a honey badger but close enough. And definitely furious!
None of those are due to LN problems right? If your code that manages BTC onchain has a vulnerability, it's going to be hacked as well.
lol https://github.com/SwissBitcoinPay/app/commit/1a23cb2e811f584639bdfe01d78765705bdc2398
🇨🇭 Swiss Bitcoin Pay potentially hacked
https://x.com/SwissBitcoinPay/status/2099473448162488618
> A malicious user has likely gained access to Swiss Bitcoin Pay’s internal systems. As a precaution, we are temporarily shutting down our servers while we investigate and secure our infrastructure.
https://stacker.news/items/1571579
Would it be better if Bitcoin was "completely confidential"?
Let's skip the "shitcoins" debate. Would it be better if Bitcoin was "completely confidential" ™️?
Assuming it was like that from the beginning and that we had certainty of no inflation bugs being possible. Lots of hypotheticals, but to center the debate around full confidentiality vs. the state.
The idea comes from https://stacker.news/items/1571256/r/m0wer. The thought behind it is whether "privacy" coins are a bad idea because they become a clear target for the state or actually the opposite because they "force" people to opt-out. Maybe there are many other considerations.
The question is, if you had a magic wand and could make Bitcoin have been completely confidential from the beginning without bugs, would you?
https://stacker.news/items/1571269
Zcash: EU AMLR prohibits anonymisation-enhancing coin accounts
https://www.tradingview.com/news/coinmarketcal:27d9af694094b:0-zcash-eu-amlr-prohibits-anonymisation-enhancing-coin-accounts-10-jul-2027/
Controversial(?) opinion: "privacy" coins are a bad idea because they become a clear target for the state. Or maybe the opposite because that would mean "forcing" people to opt-out?
https://stacker.news/items/1571256
A Severe Misalignment of AI in Mathematics
https://terrytao.wordpress.com/2026/09/11/a-severe-misalignment-of-ai-in-mathematics/
TLDR: Tao and 24 other Fields Medalists warn that AI companies are optimizing for “solving” famous math problems, while mathematics is really about developing understanding, ideas, and new methods. Rapidly mass-producing solutions risks destroying the human process that turns problems into lasting knowledge, while creating serious attribution and plagiarism issues. They’re not against AI in math; they argue it should accelerate understanding rather than turn research into a benchmark race.
https://stacker.news/items/1570423
The AI Language We Can't Read: Neuralese - YouTube
https://www.youtube.com/watch?v=iuHddnIzKRA
First, we gave models a scratchpad: instead of forcing a one-shot answer, let them spend more tokens reasoning through a problem. In a sense, you get more capability out of the same model by giving it more serial computation.
That reasoning is also useful because humans can read it. You can inspect how the model reached an answer, spot mistakes, and potentially debug or monitor it.
But there’s an obvious incentive to make that reasoning cheaper. Compress it, shorten it, remove redundant words. The problem is that if you keep optimizing for efficiency, the reasoning can drift into shorthand or “Neuralese” that still works for the model but becomes gibberish to us.
So there’s a tradeoff: more efficient reasoning vs. preserving one of the few windows we have into how the model reached its conclusion.
https://stacker.news/items/1569287
https://blossom.primal.net/6f86d8aa3b2c89eebc28382e8e53d2b63a52d73696cca6e1b23e1eb9a519b986.png
github-backup: backup a github user or organization
https://github.com/josegonzalez/python-github-backup
It's never a good idea to put all your eggs in one basket, so don't let GitHub have the power to take away all the issues, PRs, and discussion history of your project!
Even if you have repo mirrors and local copies, that's just the code. But everything else around it is just as valuable.
This is a tool that allows you to easily backup all your user or organizations repos, including the code, and all comments in issues PRs or wherever. Basically everything that you have in GitHub. It supports incremental backups and just needs a read access token with as many permissions as things you want to back up.
Don't leave it for when it's too late!
https://stacker.news/items/1565321
Honestly wouldn't say so... In both cases you are trusting the coordinator more than you should. And in both cases users often have very bad post mixing practices.
But in whirpool it's especially easy for the coordinator to tag users: https://gist.github.com/m0wer/e701bf5934474935c459b5e84e5d4e1b
And the coordinator choosing what inputs make it to the round... idk, way too much trust for my taste.
I used to think the same but meshtastic appears to scale way better where I'm at. It was just a matter of finding a better preset (not LongFast). We now have hundreds of kms of range without saturation with more than 200 nodes.
JoinMarket NG 0.39.0 and 0.39.1 are out.
Comes with supply chain attack hardening.
0.39.1 TLDR: Pre-release workflow (to pevent releases with all needed signatures), rescan bug loop fix, local installer for updates (supply chain hardening), UTXO selector redesign, and local up to date config.toml.template reference copy.
0.39.0 TLDR: Bug fixes, security hardening, and privacy improvements. Takers now consider only quantized maker offers by default, with an optional equalized payment policy. New features like jm-wallet delete and improved usability and logs noise.
https://github.com/joinmarket-ng/joinmarket-ng/releases/tag/0.39.1
not without revealing what repo it is😅
I did send an unencrypted email mentioning a vulnerability (without the details) and still no response.
BTW some cool thing that I learned during the process is that you can fetch the GPG key that some maintainer has uploaded to GitHub easily with curl. Example:
curl -fsSL https://github.com/m0wer.gpg | gpg --import
Not nice to trust GitHub for that, but it really helps when maintainers just post their key fingerprint without publishing the actual public key anywhere.
#nevent1q…a8wj
Found a vulnerability in some LN software with hundreds of stars in GitHub. The repo has no security policy and does not accept private reporting. The maintainer does not advertise his email but managed to found it in some commits. The GPG used to sign them and other stuff is expired but still being used. I did not manage to convince neomutt to encrypt an email with the expired key, because if I changed the system time, then my key was not yet valid xD
Anyway sent an email asking for a fresh GPG key for the report, the maintainer has not answered after a few days.
Do I just open the issue openly? Or what does one do in this cases?
do we really have PTLCs? the idea exists, but no implementation or gossip spec yet right?
what could be done with complex contracts inside LN? as ideas/inspiration
Implicit Deletions and Improvements in Utreexo IBD
https://delvingbitcoin.org/t/implicit-deletions-and-improvements-in-utreexo-ibd/2881
The interesting idea is that Utreexo IBD can exploit something live validation normally can’t: during historical sync, you already know which outputs will eventually be spent. That means you can avoid inserting those outputs into the accumulator only to later download proofs and delete them, and instead build the accumulator as if those deletions had already happened. Combined with Swift Sync-style spentness hints that remain verifiable, this cuts a large chunk of Utreexo’s IBD proof overhead and also makes block processing much more parallel, potentially turning sync into a mostly bandwidth-bound problem even on low-end hardware.
https://stacker.news/items/1562634
Not sure if related, but there is a bug in Bitcoin Core signet fee estimator that usually gives 100ish sats/vb. Fixed in v31 iirc. But super annoying bc it has forced me to use huge fees when testing coinjoins with older signet makers (jm-ng makers now reject CJs whose fee rate is below their 10 block estimate).
The Many Headaches of CoinJoin
https://spiralxyz.substack.com/p/the-many-headaches-of-coinjoin
https://stacker.news/items/1561639
NVIDIA to Acquire Hugging Face for almost 13B USD
https://blogs.nvidia.com/blog/nvidia-to-acquire-hugging-face/
https://stacker.news/items/1561625
How do you generate the xpub for hodling?
Why are OpenAI, Claude, and Grok simultaneously down? Coincidence? | Hacker News
https://news.ycombinator.com/item?id=49551096
https://stacker.news/items/1561520
Payments should be done over LN for many reasons, this is one of them.
A new routine for JoinMarket NG releases is to do an incremental security audit with Kimi K3/GLM 5.3 since the last checkpoint.
Oh, and there's also a new daily GitHub CI for checking vulnerabilities in the dependencies and built Docker images.
https://swapmarket.github.io/ CC @nprofile…9fel
JoinMarket NG 0.38.0 is out!
Lots of security hardening, privacy improvements, new default for 5% zero fee maker allowance (including bondless), quantized feeround up for takers, concentrated mixdepth selection policy for improving maker liquidity, CJ ID logging, ...
https://github.com/joinmarket-ng/joinmarket-ng/releases/tag/0.38.0
Forked the library `python-bitcointx` and did some housekeeping and security fixes. The original one was unmaintained :(
https://github.com/m0wer/python-bitcointx
It could have been me who stamped that coin🤭
Discreet Log Contracts (DLCs)
https://bitcoinops.org/en/topics/discreet-log-contracts/
https://stacker.news/items/1555330
With this plugin: https://docs.lnbits.com/extensions/nwcprovider/
https://blossom.primal.net/836952d054292f39fc784cffaca0f5a22b2a8fcb76b4f2b6453338929f8a8328.jpg
Market for renting Fidelity Bonds · joinmarket-ng
https://github.com/joinmarket-ng/joinmarket-ng/issues/597
https://stacker.news/items/1551914
DeepSeek plugin based harness - Fireship - YouTube
https://www.youtube.com/watch?v=xBByvFrqmWU
https://stacker.news/items/1551900
Bitcoin xpub watchdog with transaction notifications
https://gist.github.com/m0wer/498490d77fd33b5a41eb6bd480c7fae8
After the event of the last weeks, I wondered how long would it take to realize that you have been stolen from. Given that people don't manually check all of their balances daily (I guess). And that noticing fast, could help you save part of your stack (maybe).
So I made a tiny Bitcoin Core watchdog.
The idea is simple: import account-level xpubs into watch-only descriptor wallets and let Bitcoin Core notify a small Python script whenever something moves.
By default it alerts twice if appropriate: once when the transaction first appears in your node's mempool, and once when it gets confirmed.
That second alert is important because a transaction does not necessarily have to enter the public mempool. It could, for example, be submitted directly to a miner and first become visible to your node when the block arrives.
The script has no database and keeps no wallet state. Bitcoin Core does all the actual monitoring.
Install it:
```
sudo install -m 755 bitcoin_core_watchdog.py /usr/local/bin/bitcoin_core_watchdog.py
```
Store a Gotify application token somewhere readable by Bitcoin Core:
```
echo 'YOUR_GOTIFY_TOKEN' > /etc/bitcoin-watchdog.token
chmod 600 /etc/bitcoin-watchdog.token
```
Then add to `bitcoin.conf`:
```
keypool=5000
blockfilterindex=1
walletnotify=env GOTIFY_URL=https://gotify.example.com GOTIFY_TOKEN_FILE=/etc/bitcoin-watchdog.token /usr/local/bin/bitcoin_core_watchdog.py notify %w %s %b %h
```
A self-hosted Gotify instance is ideal if privacy is the goal. The Gotify-specific part is isolated in `send_notification()`, so adapting it to ntfy, Pushover, email, Telegram, etc. should be straightforward.
Test notifications:
```
GOTIFY_URL=https://gotify.example.com \
GOTIFY_TOKEN_FILE=/etc/bitcoin-watchdog.token \
bitcoin_core_watchdog.py test-gotify
```
Then add the accounts you want to watch.
Native SegWit/BIP84:
```
bitcoin_core_watchdog.py add cold-storage segwit 'zpub...' # or xpub... (also works)
```
Taproot/BIP86:
```
bitcoin_core_watchdog.py add taproot-vault taproot 'xpub...'
```
Don't put seed phrases or private keys on the monitoring node. Export an account-level xpub from the actual wallet and keep the Core wallets watch-only.
For an existing wallet, give Core an approximate birthday so it knows how far back to scan:
```
# get the epoch with `date -d "2026-01-01 00:00:00" +%s`
bitcoin_core_watchdog.py add cold-storage segwit 'zpub...' \
--timestamp 1767222000
```
Or use:
```
--timestamp 0
```
to scan the entire chain. New wallets default to `--timestamp now`.
The `add` command is only a convenience wrapper. You can do the same thing manually with `bitcoin-cli`: create a blank watch-only descriptor wallet with autoload enabled and import the appropriate descriptor.
A normal transaction might therefore produce:
```
Bitcoin mempool activity: cold-storage
sent 0.5 BTC · RBF
Unconfirmed / in local mempool
https://mempool.space/tx/...
```
followed by:
```
Bitcoin confirmed activity: cold-storage
sent 0.5 BTC
Confirmed at block 123456
https://mempool.space/tx/...
```
If the transaction bypasses your mempool and gets sent directly to a miner, you simply get the second notification.
The explorer link defaults to `https://mempool.space/tx/<txid>`. That's not ideal for privacy, but the script never queries mempool.space. It only puts the URL in the notification, so nothing is sent there unless you actually click it.
If you run your own explorer, set:
```
MEMPOOL_URL=https://mempool.example.com
```
So the whole thing is basically:
Bitcoin Core → watch-only descriptor wallets → mempool/block detection → walletnotify → Gotify
No external address lookup service, no xpubs handed to a third party, and no private keys on the monitoring machine.
https://stacker.news/items/1551517
After a `docker system prune -y` xD
https://blossom.primal.net/5d0dbdc1c95c4672c71a3371c9ce55cfff9d49d2cdeb74f7d80d41d5c1dd509a.png
Buying hashrate as a form of coinjoin/coinswap xD
One protocol level vulnerability that @nprofile…79xu found recently is https://github.com/joinmarket-ng/joinmarket-ng/issues/577
Summary: the directory nodes don't authenticate peer nicks, so peers can impersonate others and steal their connection. For example by updating the onion to their one and by being the newest connection with that nick and getting their messages. Important messages are encrypted, but the impact of "eclipsing" other makers is relevant. No loss of funds, but yes denial of service.
The fix required a protocol fix, that involves makers and directory nodes. My signet directory node is updated with the fix. Directory node runners on mainnet are encouraged to update.
The fix is only for jm-ng, but backwards compatible. So old directories and makers keep working, but are vulnerable to the attack. Good thing is that new directories still benefit old peers by not allowing new connections to steal their nick. But this is not a strong protection.
The full details are at https://github.com/joinmarket-ng/joinmarket-ng/issues/577
And the protocol improvement proposal is at https://github.com/joinmarket-ng/jmp/blob/main/jmp-0005.md
Thanks to floppy for finding it and to waxwing for helping us understand the issue and design the fix.
A SeedSigner with modified firmware that allows for creation and spending of JoinMarket Fidelity Bonds.
no idea, haven't looked into it yet
Not perfect, but very good: opencode + @nprofile…8ren
they just did😳
great timing