Check yourself: Bitcoin, Lightning, and self-custody

Questions and answers, readable without JavaScript.

1. What is the practical test for whether you are in self-custody?

   • The wallet icon says non-custodial
   • You can see a balance in a browser extension
   • Who can unilaterally move the funds — if not you, or your documented multisig policy, you are not
   • The coins left an exchange
   Answer 1

   Who can unilaterally move the funds — if not you, or your documented multisig policy, you are not

   The note's test is who can unilaterally move the funds. If that is not you, or your documented multisig policy, the label on the icon does not make it self-custody.

   Read the note → · Self-Custody Without Verify-Before-Trust Is a Slogan

2. Why is a checksum alone a weak check of wallet software?

   • An attacker who replaces the download can replace the checksum list too, unless that list is signed by keys you accept as authentic
   • Checksums only work for text files
   • Checksums expire after one download
   • A checksum proves the vendor's website was not spoofed
   Answer 2

   An attacker who replaces the download can replace the checksum list too, unless that list is signed by keys you accept as authentic

   The note says a checksum without a signature is weak if the attacker can replace both, and a signature without an authentic key is theatre.

   Read the note → · Self-Custody Without Verify-Before-Trust Is a Slogan

3. What is address poisoning, as this site describes it?

   • A fee market attack on miners
   • A broken bech32 checksum that still pays
   • A Lightning invoice that never expires
   • A lookalike address, sharing prefix and suffix characters, planted in your history so you copy it later
   Answer 3

   A lookalike address, sharing prefix and suffix characters, planted in your history so you copy it later

   An attacker generates a vanity-like address that shares prefix and suffix characters with one you used, then dusts it into your history so a later copy-from-history pays them.

   Read the note → · Self-Custody Without Verify-Before-Trust Is a Slogan

4. What does a BIP 174 PSBT let the online and offline sides do?

   • The online machine holds the keys and the offline machine only watches
   • The online side can build and later broadcast, while the offline side signs using the packet, without the keys sitting on the networked machine
   • Both sides must share one hot seed
   • It replaces the need to check destinations
   Answer 4

   The online side can build and later broadcast, while the offline side signs using the packet, without the keys sitting on the networked machine

   BIP 174 separates roles: the online side can watch, construct, and later broadcast. The offline side signs. The signer should need only what is inside the PSBT.

   Read the note → · PSBT and Air-Gapped Signing: Keep Keys Offline While the Network Watches

5. What should you do if the signing device and the host disagree about destination or amount?

   • Trust the laptop screen, which has the full transaction
   • Broadcast anyway and dispute it later
   • Re-seed the device from the host so they match
   • Stop
   Answer 5

   Stop

   The PSBT note says clipboard malware and poisoned history rewrite what the host shows. If the device and the host disagree about destination or amount, stop.

   Read the note → · PSBT and Air-Gapped Signing: Keep Keys Offline While the Network Watches

6. Why is a seed phrase not a full wallet backup, in the BIP 380 note?

   • The same keys can map to several script types, and path data was rarely in the backup — a descriptor records script type, keys, and derivation
   • Mnemonics cannot generate keys
   • Seeds expire when SegWit is used
   • A descriptor replaces the need for any private key
   Answer 6

   The same keys can map to several script types, and path data was rarely in the backup — a descriptor records script type, keys, and derivation

   After SegWit, the same keys can map to several scriptPubKey forms. BIP 380's point is that a mnemonic backs up entropy, not wallet definition. The descriptor names the script, the keys, and the derivation.

   Read the note → · A Seed Phrase Is Not a Wallet Definition: BIP 380 Output Descriptors

7. Is a BOLT-11 invoice a reusable receive address?

   • Yes, like a Bitcoin address
   • Yes, if you omit the expiry
   • No. It is a signed, time-bounded request with a payment hash — one shot
   • Only when the amount is zero
   Answer 7

   No. It is a signed, time-bounded request with a payment hash — one shot

   The receive-only note's frame is explicit: a BOLT-11 invoice is a signed, time-bounded request with a payment hash, not a reusable Bitcoin address. Reuse patterns live in other layers.

   Read the note → · Receive-Only Lightning Is Not a Merchant Stack

8. What is a BOLT-12 offer (lno)?

   • A reusable invoice with one payment hash
   • A sticky precursor: the payer sends an invoice_request over an onion message and receives a fresh one-shot invoice
   • An on-chain address wrapped in bech32
   • A channel that receives while the node is offline
   Answer 8

   A sticky precursor: the payer sends an invoice_request over an onion message and receives a fresh one-shot invoice

   An offer is a precursor, not a reusable invoice. The payer sends an invoice_request over a Lightning onion message; the payee replies with a one-shot invoice. If the recipient is offline, there is no invoice to pay.

   Read the note → · A BOLT-12 Offer Is Not a Reusable Invoice