Matt Corallo

FWIW you should also be able to just use the LDK `lightning` crate to decode offers pretty trivially. From the Rust end you can expose bindings to C/whatever language you...

Now that we've gotten this far..... Should we actually support BOLT 12 natively or should we support BIP 353? For making and receiving payments, ISTM most of the time you...

Specifically, I'd really like to better understand how wallets actually use the NWC stuff like listing invoices and such. I assume that most NWC clients really just want to generate...

Right, there's two highly distinct use-cases here - there's wallet frontend, which wants All Of The Things, and then there's wallet remote control (eg nostr client), which just wants create...

Right, my point here, though, is that we could almost entirely take exactly the changes here, and `s/bolt12/bip321/`, remove a few bolt-12 specific fields, and it would still be the...

BIP 321 is just `bitcoin:instructions`, so it depends a bit, but I think every type of Bitcoin payment instruction I'm aware of allows for additional funds to be included. The...

The nice thing about using BIP 321 is everyone already has logic for it, so doubling down on that as *the* "machine-readable bitcoin payment instruction format" seems like the right...

I was imagining, basically, `build_receive_instructions(single_use, min_amount, description)` (where `min_amount` is only allowed if `single_use` is set) which returns a BIP 321 and `pay_for_instructions(bip321, amount_incl_tip, payer_note_if_supported, proof_of_payment_metadata)`.

> Why would min_amount be only allowed if single_use is set though? I'm not aware of a bitcoin payment instruction format that has an amount field that is intended as...