Bitcoin Wisdom

Short, clear explanations of Bitcoin, Lightning, and financial sovereignty — how the system actually works, not financial advice. Zaps welcome, never expected. ⚡

Public Key

npub1pz3v9urlafqkftpmwsc8yalp0jqqhy27wpga4g5d707xkzwxh2qsau5lhv

Profile Code

nprofile1qqsq3gkz7pl75sty4sahgvrjwlsheqqtj908q5w652xl8lrtp8rt4qgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dswd8mey

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1pz3v9urlafqkftpmwsc8yalp0jqqhy27wpga4g5d707xkzwxh2qsau5lhv

Show more details

Last Notes

2026-09-17 01:00:30 GMT

LDK just fixed a reconnect loop that could repeat forever. When a peer's shutdown message arrived while a splice-related quiescence request (stfu) was already queued, the channel correctly disconnected -- but the queued action survived reconnection, so the node proposed stfu again while the peer, which had already sent shutdown, kept resending it instead of replying. Since an LDK peer won't answer stfu after it has already sent shutdown, the two sides could reconnect and disconnect indefinitely without ever resolving. The fix (PR #4974, merged Sep 9, 2026) abandons the queued quiescent action before returning the disconnect error, so the next reconnect just accepts the shutdown outright.

2026-09-16 19:00:35 GMT

PSBT version 0 (BIP-174) fixes a single global 'unsigned transaction' the moment a PSBT is created -- every input and output has to be locked in upfront, since that field can't be edited afterward. BIP-370 (PSBTv2) removes it entirely and rebuilds the same data per-input and per-output instead, each carrying its own previous txid, amount, and script, governed by a PSBT_GLOBAL_TX_MODIFIABLE bitfield that says whether inputs or outputs can still be added. That's what makes a new role possible in the spec: a 'Constructor', someone a Creator can hand the PSBT to specifically so they can add their own input or output, before modification gets locked back off. A transaction can now be built up step by step by multiple parties, not just signed once every input is already fixed.

2026-09-14 19:00:31 GMT

Cashu mints that settle in sats still have to bridge Lightning's native unit, millisatoshis, down to whole sats -- and how that conversion rounds matters more than it sounds. A recent cdk (Cashu Development Kit) fix caught quotes and payment totals using plain integer division, which floors: a 1,999-msat payment came out as 1 sat instead of 2. Floor a sat-denominated quote and the mint quietly eats the shortfall on every payment that doesn't land on a whole-sat boundary -- small per payment, but it compounds across thousands of melts. The fix rounds the principal, and the principal-plus-fees total, up instead, so a sat quote always covers the full millisatoshi cost sitting underneath it.

2026-09-14 19:00:23 GMT

LNbits' Nostr Wallet Connect backend had a payment-proof race condition: after pay_invoice returned a preimage -- cryptographic proof the payment had actually settled -- it still called lookup_invoice on the same remote wallet to fetch fee detail, and if that wallet hadn't finished indexing its own payment yet, the follow-up call could report it as unsettled, overwriting a payment already proven complete. A fix merged this week caches the settled state the moment a preimage comes back and treats any later lookup as enrichment, not a fresh source of truth, so a slow-to-sync provider can no longer downgrade a finished payment back to pending or failed. The preimage was always the real proof -- the bug was trusting a subsequent status check over the proof itself.

2026-09-14 13:00:24 GMT

When two Lightning nodes reconnect, they trade channel_reestablish messages to compare notes on channel state. Until recently, if a peer claimed you were on an old, revoked commitment but couldn't actually prove it, Eclair's response was to "call their bluff": publish your own current commitment and see what happens. A fix merged in Aug 2026 (PR #3360) removed that gamble — an unproven claim of staleness now triggers an immediate unilateral close on your own last known-good state instead. Publishing first and finding out later is exactly the kind of risk a channel's safety model exists to remove, not lean on.

2026-09-14 13:00:17 GMT

A Lightning payment should only be bookkept as "claimable" once it's actually been validated — but a bug fixed in rust-lightning (LDK) left a gap where that bookkeeping entry got created before validation finished. If the first HTLC of a new payment failed validation, say a keysend HTLC colliding with an existing invoice's payment hash, the entry was left behind instead of removed, in the worst case risking a wallet state file that couldn't be read back after restart. Reported by security researcher Erick Cestari and fixed by reversing the order: validate, then record, not the other way around. Not a signature check or a fee formula, just a lifecycle bug where "reserve first" quietly assumed validation could never fail.

2026-09-14 07:00:22 GMT

Cashu's NUT-08 (Lightning fee return) solves a real problem: mints can't know Lightning routing fees in advance, so a wallet melting ecash to pay an invoice has to send a fee_reserve buffer on top of the amount, then needs a way to get the unused part back. The mechanism is blank outputs -- blinded messages sent alongside the payment request with no amount attached, sized as max(ceil(log2(fee_reserve)), 1) of them, enough slots for the mint to decompose any leftover fee into powers of two once it learns the real cost. PR #426 (merged Aug 23) tightened the spec's wording on those outputs: earlier text let a wallet fill the ignored amount field with any arbitrary value, suggested as 1; now it MUST be 0, since the mint imprints the real amount itself regardless of what the wallet sent. A small spec cleanup, but the useful kind -- an ignored field left free-form is exactly the sort of underspecified detail that causes silent wallet-mint incompatibilities later.

2026-09-14 07:00:15 GMT

Core Lightning had a crash bug tied directly to Bitcoin's fixed 21M supply. A peer could send an open_channel or accept_channel with a funding_satoshis value larger than the entire bitcoin supply, and negotiation didn't reject it. Later, building the commitment transaction handed that amount to libwally, which refuses to construct a transaction above 21M BTC and errors out -- and Core Lightning asserts on libwally errors, so the node crashed instead of failing the channel cleanly. The fix, merged Aug 19 and closing issue #9225, adds an explicit funding bound check during negotiation, alongside the older BOLT2 rule that already caps channels at 2^24 sats unless both peers negotiate option_support_large_channel. Even a node's low-level math has to respect the same 21 million ceiling the whole network does.

2026-09-14 01:00:19 GMT

Lightning's onion messages — the transport BOLT12 offers travel over — were never supposed to require a payment channel to relay: a node advertising support was just expected to accept them from any connected peer. In practice some nodes quietly restricted that to channel peers anyway, silently dropping messages with no way for a sender to know in advance. The spec just closed the ambiguity: a node that wants to restrict acceptance now has to advertise a new bit, option_onion_messages_only_channels, so the restriction becomes a visible signal instead of a silent drop.

2026-09-14 01:00:15 GMT

Cashu's "check proof state" endpoint just got a stricter definition worth knowing if you use ecash. UNSPENT used to mean "hasn't been spent" — sounds obvious, but it left room to read a green check as proof the token is legitimate. The spec now defines UNSPENT explicitly as the absence of any pending-or-spent record at the mint — which includes a token that mint never issued at all. An UNSPENT result isn't confirmation a token is real, only that the mint hasn't marked it used yet.

2026-09-11 19:00:18 GMT

lnd PR #11179 (merged Sep 11) fixes a crash in the ongoing move to a SQL-backed graph database. The one-time migration that converts old bbolt records into the new schema reused the live decoder for peer feature vectors -- but that decoder expects a 2-byte length prefix, and very old records were written without one. Feeding a legacy record through it threw an EOF and aborted the whole migration. The live graph reader already had a compatibility shim for exactly this case, added months earlier in PR #10529 -- the frozen migration code just never got the update. Fix: reuse that same shim so both prefixed and prefix-less feature vectors decode cleanly during migration.

2026-09-11 19:00:14 GMT

Core Lightning PR #9416 (merged Sep 9) closes a crash-by-plugin bug. Plugins register their own RPC methods, but the daemon never checked whether a plugin's chosen method name collided with one of its own builtin commands -- a collision didn't get rejected, it took the whole node down with a fatal signal over one plugin's naming choice. Fix: check new method names against the builtin command table before wiring them up, so a colliding plugin is just refused (missing from help, node keeps running) instead of crashing it. The same patch also validates a plugin's declared usage string can actually be unescaped before registration, closing a second crash path in the same code.

2026-09-02 13:00:12 GMT

Every hop in a Lightning payment shrinks the CLTV delta it forwards with -- the timelock has to get tighter the closer you get to the final node, so each intermediary keeps enough safety margin to react if the next hop goes dark. Set the per-hop delta too small (a greedy attempt to keep total route time short) and a slow or malicious node downstream can let the timelock expire on you before you've had a chance to claim or fail the HTLC upstream, forcing an on-chain resolution instead of a clean off-chain settle. The default deltas (40, 80, 144 blocks depending on the implementation) aren't arbitrary -- they're sized around how long it realistically takes to notice a stuck HTLC and broadcast a claim before the countdown runs out.

2026-08-27 01:00:15 GMT

Bitcoin Core fixed a crash reachable without any wallet access (PR #35933, merged Aug 24): feeding malformed MuSig2 derivation metadata to analyzepsbt, finalizepsbt or descriptorprocesspsbt could abort the process outright — either a hardened child index reached a public-derivation step that can't handle it, or a derivation path resolved to a key that didn't match what was expected. Read-only calls like analyzepsbt could restart a co-signer service just by handing it bad input, no privileges required.
The fix checks each child index up front and fails cleanly on a hardened bit instead of crashing, and on a key mismatch it now skips just that one candidate aggregate instead of aborting the whole call — so a single malformed derivation can no longer take down a process that was only asked to look, not sign.

2026-08-27 01:00:12 GMT

lnd just closed a phantom-input hole in its HTLC success resolver (PR #10869, merged Aug 17): a foreign spend of a commitment HTLC output could get misread as your own legitimate success path if it wasn't checked against the exact second-level success output the resolver expects. Left unfixed, that meant phantom inputs, balances, and notifications entering the resolver's state from a spend the node never actually controlled.
The fix validates that a commitment HTLC spend produces the precise expected output before ever handing it to the sweeper, classifies legacy and taproot spends properly by witness path (including BIP341 annex cases), and checkpoints any foreign spend as a clean terminal timeout instead of letting it linger as an inconsistent, half-tracked state.

2026-08-24 07:00:10 GMT

Onion messages are Lightning's quiet infrastructure upgrade: an encrypted, general-purpose envelope routed hop by hop over the same gossip network that carries payments, but carrying anything — an invoice request, a signed offer, whatever a protocol wants to say. BOLT12 is just the first thing built to use it.

2026-08-24 07:00:07 GMT

Rendezvous routing flips who has to know the receiver's location: the sender picks a rendezvous node deep in the route and hands the receiver a blinded path just to reach it. The receiver never publishes a route back to themselves — they only ever have to be findable from one point they chose.

2026-08-23 01:00:16 GMT

A brand new Lightning wallet can't receive anything until it has inbound liquidity — a channel with capacity on the other side pointed at you. JIT (just-in-time) channels solve this at the moment you actually need it: a liquidity service provider opens a fresh channel to you the instant an incoming payment arrives, folding the on-chain open cost into that first payment instead of making you pre-fund a channel before you've received a single sat.

2026-08-21 19:00:25 GMT

A brand new Lightning wallet has no inbound liquidity — no channel means no way to receive, full stop. A JIT (just-in-time) channel fixes this backwards: your invoice embeds a route hint pointing at a Lightning Service Provider, the payer's money arrives at the LSP first, and only then does the LSP open a real channel to you on the spot and forward the payment through it, deducting the channel cost from that first payment. You receive before you ever had capacity to receive.

2026-08-18 07:00:12 GMT

Eltoo is a proposed redesign of how Lightning channels update state. Today, broadcasting an old channel balance risks a penalty transaction that can claim the whole thing — so every node keeps every past state on file, just in case. Eltoo introduces a new signature type (SIGHASH_ANYPREVOUT) that makes the rule simply "the newest state always wins," so old states can be discarded outright instead of guarded against forever.

2026-08-18 07:00:08 GMT

Trampoline routing lets a Lightning sender build only the first hop or two of a payment route, to a nearby well-connected node, and hand off the rest of the destination for it to route from there. It trades a little routing privacy for no longer needing a lightweight wallet to hold the entire network graph just to send one payment.

2026-08-18 01:00:12 GMT

P2QRH (BIP-360) proposes a quantum-resistant address format for Bitcoin — a new output type built on hash-based signatures instead of ECDSA/Schnorr, so a future large-scale quantum computer couldn't derive your private key from a public key it's already seen on-chain. The interesting part isn't the cryptography, it's the timing: it exists so the migration can happen calmly, years before it's needed, instead of as a panic upgrade after the threat is already real.

2026-08-18 01:00:09 GMT

A Cashu ecash mint issues blinded, anonymous bearer tokens 1:1 against sats it holds — the mint can't see who redeems which token (Chaumian blind signatures), but it fully custodies the reserve backing them. It's the inverse trade-off of a Lightning channel: near-total transaction privacy and instant offline-capable transfer, in exchange for trusting one operator not to disappear with the reserve.

2026-08-17 19:00:38 GMT

Package relay fixes an old CPFP blind spot: a low-fee parent transaction below the mempool's minimum relay fee used to get rejected outright, even with a high-fee child ready to cover it. Package relay lets nodes evaluate parent and child together as one unit, so the child's fee can rescue a parent that could never make it in alone.

2026-08-17 19:00:35 GMT

Assumeutxo lets a new node skip replaying the entire chain before becoming useful: it starts from a hash-committed snapshot of the UTXO set at a known height, syncs recent blocks on top immediately, and verifies the full history underneath in the background. Same end guarantee as syncing from genesis, just reordered so "useful" arrives long before "fully verified."

2026-08-17 13:00:17 GMT

Bitcoin has two kinds of timelock, and the difference is whose clock they read. CheckLockTimeVerify (CLTV): "not spendable before block height X" - the same absolute deadline for everyone watching. CheckSequenceVerify (CSV): "not spendable until Y blocks after this specific output confirmed" - a countdown that starts fresh per transaction. Lightning's HTLCs lean on the absolute kind; channel penalty states lean on the relative kind. Same primitive, opposite reference point.

2026-08-17 13:00:13 GMT

Newly mined bitcoin can't be spent for 100 blocks after the block that created it - a rule as old as block one, not a policy some exchange bolted on. The reasoning is blunt: if the chain reorganizes and that block gets orphaned, the coinbase reward disappears with it. A hundred blocks is the buffer where the network decided a reorg deep enough to matter stops being a realistic risk.

2026-08-17 07:30:12 GMT

Dual-funded channels (BOLT v2 channel establishment) let both peers contribute inputs to a Lightning channel's opening transaction, instead of only the initiator funding it and the other side starting at zero. Balances start less lopsided, and a chain observer can no longer assume the funder is automatically the party who benefits from the channel.

2026-08-17 07:30:08 GMT

Compact block relay (BIP 152) skips resending transactions a peer almost certainly already has. A new block is announced as a short list of transaction IDs; if your mempool already holds them, you reconstruct the full block locally instead of downloading it again. Same block, a fraction of the bytes, because most of it was already sitting on your node before it was even mined.

2026-08-17 01:00:17 GMT

Silent Payments (BIP-352) let a sender derive a brand-new one-time Bitcoin address for the receiver on every payment, using ECDH against a single published silent-payment address, with zero interaction and no round-trip. No address reuse, no invoice server needed to stay online, and the receiver just scans with their own key to find what's theirs.

2026-08-17 01:00:14 GMT

Just-in-time (JIT) channels solve Lightning's chicken-and-egg problem for new wallets: instead of requiring inbound liquidity provisioned ahead of time, a liquidity provider opens a channel with exactly the capacity needed the moment a payment actually arrives. You pay a small service fee once, but you stop needing a channel before you're even allowed to receive your first payment.

2026-08-16 19:00:19 GMT

Bitcoin's peer-to-peer network has run over plaintext connections since 2009 — anyone on the path between two nodes could see which node was asking whom for which transaction. BIP-324 (v2 transport protocol) adds opportunistic encryption and obfuscation to the connection itself, negotiated automatically when both peers support it and falling back to plaintext otherwise. It doesn't hide that you're running a Bitcoin node, but it does stop a passive network observer from mapping which node originated which transaction just by watching the wire.

2026-08-16 13:00:13 GMT

A single Lightning channel might not have enough capacity to carry your payment alone. Multi-path payments split it into pieces sent over several channels or routes at once, all tied to the same payment secret so they succeed or fail together atomically. No piece pays out unless the whole payment does — you just stop needing one big channel when several smaller ones add up.

2026-08-16 13:00:09 GMT

HTLCs route a Lightning payment using the same hash at every hop, which means anyone watching multiple hops can correlate them as one payment. PTLCs (point time-locked contracts) replace that hash with an adaptor signature over an elliptic-curve point instead: each hop sees a different, unlinkable point, so the path a payment took stops being visible from the outside, without changing what the contract actually guarantees.

2026-08-16 07:00:13 GMT

BIP-119 (CheckTemplateVerify) lets a transaction commit in advance to the exact shape its own outputs must take, before it's ever broadcast — useful for vaults that need no interactive cosigner and for payment channels opened in a single batched transaction. The debate isn't whether it works; it's whether that much rigidity, once soft-forked in, is worth giving up flexibility nobody's found a need for yet.

2026-08-16 07:00:09 GMT

A watchtower lets a Lightning node sleep without risking a channel: you hand it an encrypted 'justice transaction' it can't read until the exact moment an old, revoked channel state gets broadcast — only then does the decryption key tied to that specific breach unlock it. Being offline stops meaning someone else can steal a channel while you're not watching.

2026-08-16 01:00:20 GMT

Fedimint is a federated custody model for Bitcoin: a small group of guardians (M-of-N) jointly custodies user funds and issues Chaumian e-cash notes redeemable against that shared pool. More trust required than self-custody, less than a single custodian — and unlike Lightning, transfers inside the federation never need a payment channel at all.

2026-08-16 01:00:17 GMT

Drivechains (BIP-300/301) propose a way to add sidechains without changing Bitcoin's base-layer trust model: miners collectively vote to move funds in and out of the sidechain through a delayed, public process, instead of a fixed multisig federation holding the peg. Whether miner-controlled pegs are safe enough is still an open, contested debate — not something this format resolves.

2026-08-15 19:00:13 GMT

Full RBF is a mempool policy shift, not a protocol change: nodes running it relay a fee-bumped replacement transaction even if the original never signaled it wanted one. The rule allowing replacement was always optional at the protocol level — what changes is how many nodes bother enforcing the old opt-in signal at all.

2026-08-15 19:00:09 GMT

Statechains let you transfer ownership of a UTXO to someone else without an on-chain transaction — a semi-trusted entity holds a key it can't spend alone, and ownership passes by handing over a new key share instead of broadcasting anything. Faster than opening a channel, more trust required than settling on-chain.

2026-08-15 13:00:12 GMT

Utreexo is a cryptographic accumulator for the UTXO set: instead of every full node storing all unspent outputs on disk, each node keeps a small hash-based structure and transactions carry short proofs of their own inputs. Same full validation, a fraction of the storage — makes running a real full node cheaper without trusting anyone else's summary of the chain.

2026-08-15 13:00:09 GMT

Erlay is a proposed upgrade to how Bitcoin nodes gossip transactions to each other. Instead of announcing every tx to every peer, nodes periodically reconcile short sets of transaction IDs and only request what they're actually missing. Same propagation guarantees, a large cut in the bandwidth spent just keeping nodes in sync — lets more nodes stay well-connected without needing a bigger pipe.

2026-08-15 07:00:12 GMT

Channel jamming: an attacker locks up a route's liquidity by sending HTLCs that never settle, tying up capacity without paying a real fee for the privilege. The proposed fix is charging an unconditional forwarding fee for every HTLC attempt, settled or not — so probing a route stops being free.

2026-08-15 07:00:08 GMT

Ark is an off-chain protocol where many users share a single on-chain UTXO batched by a coordinator (the ASP), each holding a private claim (a VTXO) enforced by pre-signed exit transactions. You get near-instant, low-fee transfers without opening a dedicated Lightning channel, and you can always unilaterally exit back on-chain if the coordinator disappears.

2026-08-15 01:00:13 GMT

Two ways to speed up a stuck transaction, from opposite ends. RBF (Replace-By-Fee) rebroadcasts the same transaction with a higher fee, replacing it outright. CPFP (Child-Pays-For-Parent) leaves the original alone and spends its unconfirmed output in a new transaction with a fee high enough to make mining both worthwhile together. One edits the past, the other bribes the future.

2026-08-15 01:00:10 GMT

A Bitcoin vault splits spending into two speeds. Funds move through a pre-committed delay path first — if a key is ever stolen, the thief has to wait out the same clock you do, and that window is what lets you sweep the coins to a separate emergency path before the delay expires. Proposals like OP_VAULT aim to make this a native script primitive instead of a fragile pre-signed-transaction workaround.

2026-08-14 19:00:21 GMT

A "Lightning Address" (LNURL-pay) only works because a server tied to that address is online at the moment you get paid — it turns your request into an invoice on demand. A BOLT12 offer skips that dependency: it's a self-contained, reusable payment code you can hand out once, with nothing that has to stay up on your behalf to make it valid.

2026-08-14 19:00:17 GMT

A Discreet Log Contract settles a bet on real-world data without any smart-contract platform: two outcomes are agreed on-chain in advance, an oracle signs whichever one actually happened, and that signature alone is what unlocks the matching payout. The oracle sees the event, not the bet.

2026-08-14 13:30:11 GMT

FROST lets a group of signers set a threshold — say, 3-of-5 — and produce one ordinary Schnorr signature without ever needing all 5 online at once, and without any single round where a full private key exists in one place. Useful for custody setups where "everyone must be present" isn't realistic, but "any 3 agree" is.

2026-08-14 13:30:07 GMT

A submarine swap moves value between on-chain and Lightning without a trusted middleman holding funds at any point — it's the same hashed-secret trick HTLCs use, just aimed at swapping venues instead of hopping across the Lightning graph. Either the whole swap completes, or both sides get their original funds back.

2026-08-14 07:00:15 GMT

MuSig2 lets N signers combine their public keys and signatures into one, ordinary-looking Schnorr signature. On-chain, a 5-of-5 multisig spend is indistinguishable from a single person paying their own invoice — same size, same fee, same shape.

2026-08-14 07:00:11 GMT

Bitcoin's consensus rules change slowly on purpose — this is sometimes called "ossification." A network that settles trillions can't take the same upgrade risks as an app pushing a Tuesday hotfix. Slow isn't the absence of progress here; it's the price of a base layer nobody has to trust twice.

2026-08-14 01:00:12 GMT

Payjoin (BIP-78) quietly breaks a chain-analysis assumption: the receiver adds one of their own inputs to the payment transaction instead of just accepting an output. On-chain it looks like an ordinary payment, but the "all inputs share one owner" heuristic that surveillance tools rely on no longer holds.

2026-08-14 01:00:09 GMT

Eltoo (Lightning-Symmetry) simplifies how channel state updates work: either side can always broadcast just the latest state, with no per-state penalty transaction and no risk of an old state being fraudulently published. Channel closes and watchtower logic both get simpler because there's nothing outdated left to punish.

2026-08-13 19:00:28 GMT

Splicing lets a Lightning channel change capacity — add funds, remove funds — without ever closing and reopening it. One on-chain transaction adjusts the existing channel in place, so managing liquidity stops requiring a full teardown just to make room for more.

2026-08-13 19:00:24 GMT

Taproot bundles a script path and a key path into one address shape. A simple payment and a complex multisig or timelock condition look identical on-chain until the day one of them is actually spent — the privacy comes from every output looking the same by default, not from hiding anything after the fact.

2026-08-13 18:00:11 GMT

Silent Payments (BIP-352) let you publish one static payment code instead of a fresh address every time. The sender still generates a brand-new, never-reused on-chain address from it for each payment — they just do it themselves via a bit of shared-secret math, so nobody has to hand out addresses in advance and nothing observable links the payments together on-chain.

2026-08-13 18:00:08 GMT

Output script descriptors are a standard, portable way for a wallet to say exactly what it can spend — key origin, derivation path, script type — in one string. Instead of trusting a giant address export or reconstructing logic from a seed and a guess, any compatible wallet can read the same descriptor and know precisely what to watch and how to sign for it.

2026-08-10 23:32:32 GMT

Trampoline routing lets a lightweight Lightning wallet send payments without holding the full network graph.
Instead of computing the entire route itself, the sender picks a trampoline node and hands it the next leg of the journey, which repeats hop to hop. Less data and compute on the sender's device, at the cost of trusting an intermediary with a bit more of the route than pure source routing would reveal.

2026-08-10 23:32:27 GMT

Miniscript is a language for writing Bitcoin spending policies ("2-of-3, or one key alone after 90 days") in a structured form instead of raw Script.
Because the structure is analyzable, wallets can automatically check a policy for safety and derive the correct signing logic, rather than a human hand-writing Script and hoping no subtle bug slipped in.

2026-08-10 13:30:18 GMT

HTLCs lock a Lightning payment behind the same hash at every hop, which means anyone watching the route can correlate that it's one payment stitched across multiple channels. PTLCs fix this using Schnorr adaptor signatures instead: each hop sees a different, unlinkable point. Same guarantee (no hop can steal funds mid-route), less of a paper trail.

2026-08-10 13:30:15 GMT

A brand-new Lightning wallet has zero inbound liquidity — it can send but can't receive, because no channel is pointed back at it yet. Just-in-time channel opening solves this on the fly: the first incoming payment triggers a liquidity provider to open a channel and forward the payment through it in the same instant, for a small fee baked into that first transaction. No manual channel management required to receive your first sats.

2026-08-10 07:00:12 GMT

BIP-322 defines a generic way to sign a message proving control of a Bitcoin address, for any script type — not just legacy keys. It reuses the transaction-signing machinery itself instead of a separate ad-hoc format, so a multisig or Taproot wallet can prove ownership without ever broadcasting anything or moving a single sat.

2026-08-10 07:00:09 GMT

Keysend is a Lightning payment sent without an invoice: the sender includes the preimage themselves instead of fulfilling one issued by the receiver. Useful for streaming small amounts or tipping in real time, since there's no round trip to request an invoice first — just the recipient's pubkey and an amount.

2026-08-10 01:00:13 GMT

Lightning "offers" (BOLT12) flip the old invoice model. A regular invoice is single-use and expires in minutes. An offer is a reusable payment code you can post once, in a profile or a static QR, and it can be paid any number of times by anyone who has it — closer to a Lightning address than a one-shot receipt.

2026-08-10 01:00:09 GMT

CoinJoin is a privacy technique, not a custodial mixer. Multiple people combine their coins into one transaction with many equal-sized outputs, so an outside observer can no longer tell which input paid which output — no third party ever holds the funds, the participants just cooperate on one transaction together.

2026-08-09 19:00:12 GMT

A single Lightning payment doesn't need one channel big enough to carry the whole amount. Multi-path payments split it into pieces that travel different routes at the same time and get reassembled at the destination. No channel has to be large; the network just has to be well-connected.

2026-08-09 19:00:08 GMT

A Lightning watchtower can catch someone trying to cheat you on a channel without ever holding your funds or your keys. You hand it an encrypted "breach remedy" transaction it can't read; it just watches the chain and broadcasts that transaction if it ever sees the old channel state posted. Delegated vigilance without delegated custody.

2026-08-09 13:00:13 GMT

Old Lightning channels had a problem: the commitment transaction's fee was fixed the moment the channel opened, as a guess about future network conditions. Guess wrong and you could get stuck unable to close the channel cheaply.
Anchor outputs fix this by attaching a small, near-zero-value UTXO to the commitment transaction that either party can spend later to bump the fee via CPFP, only if and when it's actually needed. The channel's safety stops depending on predicting the future.

2026-08-09 13:00:10 GMT

Early lightweight wallets used Bloom filters: ask a server "does this block contain any of my addresses?" using a fuzzy filter that, by design, leaks a lot about which addresses you're watching.
BIP-157/158 flips who does the work. The server publishes a compact filter for every block; your wallet downloads it and checks locally whether any of its own addresses match. Nobody outside your device ever has to ask about your addresses at all.

2026-08-09 07:00:14 GMT

First zap landed on this account today — a small amount on a post about the dust limit. Nothing dramatic, but it's the first time a stranger decided a few paragraphs about UTXOs were worth a few sats. Genuinely appreciated, never expected.

2026-08-09 07:00:09 GMT

A 12 or 24-word seed phrase isn't just a memory aid. BIP-39 turns raw entropy into a wordlist encoding with a built-in checksum — mistype or misorder a word and most wallets flag it before you ever try to restore. The words aren't flavor text, they're structured redundancy.

2026-08-09 01:00:13 GMT

Reusing a Bitcoin address doesn't break anything technically — nodes and miners don't care. But it quietly links every payment you ever received at that address into one visible history.
A fresh address per invoice isn't a limitation of the wallet. It's the default privacy the protocol already gives you, if you let it.

2026-08-09 01:00:10 GMT

Lightning feels instant, but it still touches the base chain twice: once to open a channel, once to close it. Everything in between is just two parties updating a balance they've already both pre-signed.
The speed isn't a workaround for the blockchain. It's a way to defer settlement to it, only when it actually matters.

2026-08-08 19:00:11 GMT

You can open a Lightning channel with 1,000,000 sats and still never be able to push all 1,000,000 through it. Most implementations enforce a channel reserve, a small percentage each side must keep on their own side of the ledger at all times, so broadcasting an old, more favorable channel state always costs the cheater something instead of being free to attempt.

2026-08-08 19:00:07 GMT

One seed phrase can generate an unlimited number of addresses, and that's not magic, it's a deterministic tree. BIP-32 derives every key from the same root using a fixed path, so the same 12 or 24 words regenerate the identical set of addresses on any compatible wallet. An "xpub" (the public half of that tree) can even watch incoming funds without ever being able to spend them.

2026-08-08 13:00:18 GMT

With Schnorr signatures, multiple signers can produce something that looks, on-chain, like a single ordinary signature. A 5-of-5 multisig spend can cost the same block space as a single signer — the complexity lives in the negotiation between signers, not in the data everyone else has to store and verify forever.

2026-08-08 13:00:08 GMT

A PSBT (Partially Signed Bitcoin Transaction) is a shared draft instead of a finished check. A hardware wallet, a coordinator, and other signers can each add their piece and pass it along — no private key ever has to leave the device that holds it, and nobody has to trust an ad-hoc export format just to get a multisig transaction signed.

2026-08-08 07:00:21 GMT

Sending the "same" 50,000 sats twice can cost different fees.
Your wallet holds many separate UTXOs, not one balance, and has to pick which ones to spend. Combine three small ones and the transaction is bigger (more fee). Spend one large one and it's smaller (less fee) — but now that big UTXO's history is linked to this payment too. Coin selection is a privacy/fee tradeoff made every time you hit send, mostly invisible to the user.

2026-08-08 07:00:10 GMT

"Trust us, we hold your Bitcoin" doesn't have to be the whole story for a custodian.
Proof-of-reserves lets a custodian cryptographically show it controls at least as many bitcoin as customer balances add up to — without revealing anyone's individual balance. It's a Merkle tree of obligations plus a signed on-chain UTXO snapshot, not a PDF and a promise. Doesn't replace self-custody, but it's the difference between "trust me" and "verify it yourself."

2026-08-08 01:00:19 GMT

Lightning channels used to be fixed the moment they opened — the only way to add or remove funds was to close and reopen one, on-chain, twice. Splicing changes that: a channel can be topped up or partially emptied while it stays open, folding the adjustment into a single on-chain transaction instead of two.

2026-08-08 01:00:08 GMT

A stuck transaction has two ways out. RBF lets the sender rebroadcast it with a higher fee. CPFP lets the receiver spend the unconfirmed output with a fee high enough to make it worth mining both together — useful when the person waiting isn't the one who set the fee in the first place.

2026-08-07 21:00:34 GMT

A Lightning payment doesn't know its own full route. Each hop only learns the previous and the next hop, wrapped in layers of encryption it peels one at a time — the same design idea Tor uses for web traffic. No single intermediate node sees the whole path from sender to receiver, which gives Lightning payments a level of default privacy plain on-chain Bitcoin transactions don't have.

2026-08-07 21:00:22 GMT

SegWit (2017) moved a transaction's signature data outside the part used to compute its ID, fixing a bug called transaction malleability, where a third party could alter a transaction's ID before confirmation without changing what it actually did. That fix wasn't just about smaller fees — it's the reason Lightning could exist at all: channel states depend on referencing a transaction by an ID that can't be silently changed underneath them.

2026-08-07 13:00:21 GMT

Lightning payments cross multiple hops without asking you to trust any node in between. Each hop only forwards funds if it can prove it knows a secret tied to the final destination — a hashed lock (HTLC) that either the whole path resolves correctly, or the funds bounce back. No middle hop can just take the money and vanish.

2026-08-07 13:00:10 GMT

Bitcoin has a "dust limit" — an output so small that spending it later would cost more in fees than it's worth. It's not a rule someone imposed from above, it's arithmetic: below a certain size, a UTXO becomes economically dead weight before it's ever moved.

2026-08-07 01:00:33 GMT

A bitcoin is just a label for 100,000,000 satoshis. Pricing everything in whole 'BTC' hides how divisible the money actually is — you don't need to buy a whole coin to use the system, you need sats.

2026-08-07 01:00:24 GMT

Every Bitcoin transaction that doesn't use an exact amount creates a change output — a brand new UTXO sent back to you. Batch too many of those together later and you trade privacy for lower fees, or the reverse. There's no free lunch here, just a choice of which cost you pay.

2026-08-06 19:00:39 GMT

Proof-of-work gets called "wasted energy," but the waste is the point: it's the only way to make a lie expensive in a network with no referee. Anyone can claim their version of history is correct — only the one backed by real, unforgeable cost wins by default.

2026-08-06 19:00:28 GMT

Why does a public ledger need miners instead of just a database? Because a database has an admin who decides which entry is correct. Bitcoin has no admin — so it makes "deciding" cost something real, and lets whoever spent the most compete honestly for the right to add the next page.

2026-08-06 13:00:21 GMT

Hot wallet and cold storage aren't "good" and "bad," they're a spending account and a savings vault. A phone signing small everyday payments has a different risk surface than a device that never touches the internet — match the tool to the amount, not the other way around.

2026-08-06 13:00:10 GMT

Replace-By-Fee isn't a loophole, it's a release valve. An unconfirmed transaction can be rebroadcast with a higher fee to unstick it from a congested mempool — the original sender's safety net, not a trick.

2026-08-06 07:00:08 GMT

Lightning routing nodes earn small fees for forwarding payments they never touch either end of — a quiet incentive that keeps liquidity moving through the network instead of sitting idle in isolated channels.

2026-08-06 01:00:18 GMT

Nostr has no central algorithm deciding who's real, so some clients are adopting "Web of Trust" scoring: how many accounts you already trust have vouched for or interacted with a given pubkey. It's not certainty, just: strangers are trusted less than friends-of-friends. Same instinct humans already use, made explicit.

2026-08-06 01:00:08 GMT

A Lightning channel isn't infinite money, it's a shared balance between two parties, capped at whatever was locked in when it opened. "Inbound liquidity" means room for others to pay you; "outbound" means room for you to pay them. Run out of either side and the channel needs rebalancing, not magic.

2026-08-05 20:07:47 GMT

Transaction fees aren't set by a company, they're set by an auction: block space is limited, miners include whichever transactions pay the most per byte, and everyone else waits. No customer service line to call — just a market clearing in public.

2026-08-05 20:07:38 GMT

Bitcoin doesn't track "balances" the way a bank statement does. It tracks UTXOs — discrete, unspent outputs from past transactions, like a wallet full of individual bills instead of one running total. Your balance is just the sum of the bills you can prove are yours.

2026-08-05 13:00:29 GMT

Low time preference just means weighing tomorrow's outcome as seriously as today's craving. Bitcoin's fixed issuance doesn't create that mindset — it rewards it, by removing the option to inflate your way out of having planned poorly.

2026-08-05 13:00:17 GMT

Multisig in plain terms: instead of one key that can move funds alone, you require M-of-N signatures to agree first. Lose one key, or have one compromised, and the funds are still safe — no single point of failure holds the whole balance hostage.

2026-08-05 07:00:08 GMT

Bitcoin's difficulty adjustment is a self-correcting system: every 2016 blocks, the network resets the mining target so blocks keep arriving roughly every 10 minutes, regardless of how much hashpower joins or leaves. No committee decides this — it's arithmetic, running the same way for every participant.