New favorite energy usage comparison.

These days, there are many possible ways to communicate Bitcoin payment instructions. QR Codes, BIP 3/21 bitcoin: URIs, lightning: URIs, LN-Address, BIP 353 HRNs, loose addresses, lighting BOLT 11/12 invoices/offers and all kinds of ways to communicate those. Here's a simple parser to help you figure out your options:

bitcoin_payment_instructions - Rust

These days, there are many possible ways to communicate Bitcoin payment instructions. This crate attempts to unify them into a simple parser which ...

(early version, hope to add more later!)

Lighting absolutely does not take 5-10 seconds to settle a payment. Looking at payments from one of the largest custodial providers settlements are *way* faster than that most of the time. Sure, if you’re sending from a shitty node that doesn’t have good pathfinding[1] then it can take a bunch of retries and a while, but, like, don’t do that? Cashu could take 5 seconds if you hit bad Tor relays, but, again, like, don’t do that 🤷‍♂️. [1]

Lightning Dev Kit Documentation

Pathfinding with LDK

Learn how LDK built the most advanced pathfinder in the Lightning Network

View quoted note →

Don’t forget that Ripple was the largest donor to the largest non-party/candidate superpac in the last election cycle. If you thought they weren’t going to get a seat at the table (and ice out Bitcoiners), you weren’t paying attention.

Trust Models (refer back to this when someone claims their thing is “non-custodial”, note that privacy is a different spectrum) * Holding Funds On Chain * Trusting you can get a transaction confirmed in some time horizon where your balance is way higher than the on chain cost (LN) * Trusting you can get a tree of many transaction confirmed in some time horizon where your balance is way higher than the on chain cost of the whole tree (in-round Ark for high-ish balances, rollups for *very* high balances after some future soft-fork) ^ non-custodial v custodial * Trusting you can get a tree of transactions confirmed in some time horizon where your balance is similar to the on chain cost (in-round Ark for moderate balances, rollups for most folks after some future soft fork) * Trusting 1-of-N with keys (rollups with BitVM) * Trusting N-of-M to do something honestly once in a TEE (statechains maybe?) * Trusting N-of-M to do something honestly once (statechains/statechains-on-Ark) * Trusting N-of-M with keys (Liquid, Fedimint) * Trusting 1 entity with keys (Cashu, Coinbase, …)

This isn’t specific to BOLT 12 and is really stretching the line on accuracy. Yes, if you reuse a BOLT 12 across two companies they can compare notes and see that you used the same one (duh!), but it’s not “because you reuse the same public key”, it’s because it’s the same thing! But, of course, you don’t *have * to do this. Wallets, by default, should generate a fresh BOLT 12 every time they display the receive key (and LDK will every time the wallet asks for a BOLT 12), including fetching a different “offer_issuer_id”. Ultimately, don’t assume things just based on the name of a field in a spec - the “offer_issuer_id” is a misnomer, LDK actually has a different name for it because of this, and IIRC the spec even says don’t reuse it if you’re a regular end-user wallet! View quoted note →

What dimension am I in?

Turns out Taproot is great for post-Quantum in Bitcoin. https://groups.google.com/g/bitcoindev/c/8O857bRSVV8