Pinned Tweet
Tune out the noise. Keep stacking. Practice self custody.
Did I mention self custody. Get your coins off exchanges.
Don’t fk around with leverage.
Get your coins off exchanges.
Do this and you will sleep without worry.
Lightning Labs opened Wavelength to everyone on mainnet yesterday, and the design gets the most important part right: the user can always leave.
Wavelength is a toolkit for adding bitcoin payments to apps and AI agents, built on an Ark-like settlement layer. Three reasons it's worth watching:
1. Keys stay with the user from the first command. Lightning Labs says the coordination service that settles transfers never has unilateral control of funds, and the exit command moves a balance back on-chain without anyone's permission.
2. Agents get least-privilege access. A service can be given the right to receive payments with no ability to sign or recover the wallet.
3. The limits are stated up front. Mainnet accounts cap at 300,000 sats and each VTXO at 50,000. Small caps on day one are honest.
Convenience that keeps the exit open is how self-custody scales.
lightning.engineering/posts/…
Bitcoin Core just changed how it handles easy-to-find bugs, and it's the right call.
On Oct 22, Core developer Antoine Poinsot told the bitcoin-dev mailing list that reports of easily rediscovered vulnerabilities are up, largely because LLMs have lowered the bar to find them. For bugs flagged as easy to discover, Core will now backport a fix to every maintained release and ship it as soon as possible with a security advisory, instead of holding it behind the usual embargo.
1. A bug anyone can find with one prompt isn't a secret. Waiting only helps whoever finds it first.
2. Backports put the fix on the version node runners already run, without forcing a major upgrade.
3. Everything else still follows the severity-based disclosure timelines. The policy adapted in public, in writing. That's how open source should work.
Run a node. Keep it patched.
bitcoincore.org/en/security-…
A letter asking you to scan a QR code for your wallet is a scam. Every time.
Fake letters dressed up as Ledger are going around again. They push you to scan a QR code for some urgent security step, and the code leads to a site or software built to take your recovery phrase. Ledger's own support page says it almost never sends physical mail and will never ask you to enter your recovery phrase online, by phone, or through a QR code.
1. Paper feels official. That's the whole trick. A letter is just a slower way to deliver the same phishing link.
2. A recovery phrase belongs on the hardware wallet itself, when you set it up or restore it. Never on a phone, a computer, or a website.
3. Once it's typed into a website, treat it as burned. Nobody can reverse a Bitcoin transaction for you.
Your recovery phrase goes on the device and nowhere else.
support.ledger.com/article/p…
A private key is only as good as the randomness behind it.
Over the weekend, Google and Mozilla pulled browser trust from eight intermediate certificates issued under eMudhra, a certificate authority. Mozilla's incident report says each of those private keys was a whole number below 256. Anyone holding the public certificate could work the key out almost instantly. The keys were made in April 2025 and weren't caught until this month.
1. Bad keys don't look bad. A weak key and a strong one look the same until somebody checks.
2. Your Bitcoin key is the same kind of number. Use wallets that are open about how they generate it.
3. Nobody can revoke a bad Bitcoin key for you. Key generation has to be right the first time.
Check where your seed came from.
bugzilla.mozilla.org/show_bu…
Privacy isn't one big feature. It's a lot of small refusals.
Last week's Bitcoin Optech newsletter covered a fix in LDK, the Lightning Dev Kit. When a recipient builds a blinded path for onion messages, it can add dummy hops: extra encrypted layers that hide where it really sits in the path. Normal forwarding hops rejected message content stuffed into a middle layer. Dummy hops accepted it. A malicious sender could plant that content at different layers, watch whether a reply came back, and possibly work out where the real path ended. LDK now rejects that content at dummy hops too.
1. Nothing was cracked. One layer just behaved differently from the others.
2. A reply or no reply is enough to leak. Privacy code has to answer the same way every time.
3. The fix and the write-up are public. Anyone can read the change.
Lightning privacy gets built one boring check at a time.
bitcoinops.org/en/newsletter…
A confirmation is a count, not a promise. One block is the weakest count there is.
Last week's Bitcoin Optech newsletter covered a fix in BDK, the Bitcoin Dev Kit wallet library. An Electrum-backed wallet could lose track of a transaction's confirmation after a reorg if the same transaction was mined again at the same height. BDK could keep the displaced block's header in its cache, miss the confirmation in the replacement block, and show the transaction as unconfirmed. The fix refreshes the header cache during sync, including after a one-block reorg.
1. The chain tip can change. Wallet code has to treat it as provisional.
2. This bug failed toward caution. It showed a confirmed payment as unconfirmed, not the reverse.
3. A stale cache is the quiet failure mode. Nothing crashes. The numbers just go out of date.
If a payment matters, wait for more than one block.
bitcoinops.org/en/newsletter…
Old coins moving isn't a crash signal. Sometimes it's just good key hygiene.
On Saturday, one transaction in block 971,894 swept 471.10 BTC from seven legacy P2PKH inputs. About 416.69 BTC of it was received between August and November 2013. It all went to 15 fresh native SegWit addresses, plus a tiny change output, for a fee of 3,362 sats, about 1.9 sat/vB. By this morning, one of the 15 had moved again. The owner hasn't said why.
1. Coins received in 2013 were still spendable in 2026. Somebody kept those keys for about 13 years.
2. Moving to native SegWit is plain housekeeping. Those outputs cost less to spend later.
3. Every number here can be checked from the transaction ID. No press release required.
Headlines will call it a whale waking up. The chain just calls it a spend.
mempool.space/tx/d46a16cc78e…
Lightning moves payments. It may also run contracts, without asking the base layer for anything new.
Adam Gibson posted a proposal to the Bitcoin-Dev mailing list called LN-GAP, for running complex, multi-round, two-party contracts inside a Lightning channel, with disputes settled onchain in a constant number of transactions. His demo is a game of chess where the winner takes the pot. To handle a player who stalls, a committee he calls a venue attests only whether a move was published before a deadline, not what the move was. The venue never holds funds, and fraud can be pinned on the members who commit it. The stated catch: if more than half the venue colludes with one player, funds can be stolen.
1. The heavy logic stays off the chain. The chain only sees disputes.
2. The trust assumption is named up front, so users can weigh it.
3. The same pattern could back bonds for proof-of-storage, not just games.
Read the paper before you believe the hype or the dismissals.
bitcoinops.org/en/newsletter…
