These are all obviously much better, but unless all wallets seamlessly support onchain, the various flavors of lightning, and cashu, you're always going to have friction when sending/receiving.
"scan what?"
"receive what?"
"what kind of qr code is this?"
"oh, my phone doesn't support NFC"
"my wallet doesn't do onchain, can you send me a lightning invoice?"
"it's saying something about liquidity"
"what's a 'mint'?"
"what is a 'melt'?"
"what is a 'submarine swap'?"
"why do I need to 'topup', can't I just transfer funds from my bank?"
None of these problems are impossible to solve individually, but solving all of them across a network of apps created by people with different ideas is combinatorially difficult.
In nostr we say "don't overload kinds". I think this is the problem — we've overloaded the term "pay with bitcoin". It means:
- P2PKH
- P2SH
- Native SegWit
- Taproot
- Bolt11 invoice
- LNURL
- Lightning address
- Bolt12 invoice
- Keysend
- Cashu eCash
- Fedimint eCash
- Spark
- Ark
I'm not saying each of these doesn't have its use case, or that innovation isn't good, but this complexity comes at a cost, which either the wallet developer or the user has to bear.
hodlbod
npub1jl…jynqn
2026-02-26 19:19:43 CET
in reply to nevent1q…nmf4
Author Public Key
npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqnPublished at
2026-02-26 19:19:43 CETEvent JSON
{
"id": "aa71a6a29d4e00fdbdb36d3e389e823a8cb5d71fe9f6cd8ea305f4352cc41260",
"pubkey": "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322",
"created_at": 1772129983,
"kind": 1,
"tags": [
[
"p",
"50d94fc2d8580c682b071a542f8b1e31a200b0508bab95a33bef0855df281d63",
"wss://yabu.me/",
"calle"
],
[
"p",
"8bf629b3d519a0f8a8390137a445c0eb2f5f2b4a8ed71151de898051e8006f13",
"",
"routstr"
],
[
"e",
"1f3ab770f2c03e349dbb2faeda07168037d4a927f53a7c773cf0e4a3619f126d",
"wss://eden.nostr.land/",
"root",
""
],
[
"e",
"8a1788351ba828bf55b284f4a40dca0dfaf8a8ac4e52e7925e9a20253b85eb84",
"wss://yabu.me/",
"reply",
"50d94fc2d8580c682b071a542f8b1e31a200b0508bab95a33bef0855df281d63"
]
],
"content": "These are all obviously much better, but unless all wallets seamlessly support onchain, the various flavors of lightning, and cashu, you're always going to have friction when sending/receiving.\n\n\"scan what?\"\n\"receive what?\"\n\"what kind of qr code is this?\"\n\"oh, my phone doesn't support NFC\"\n\"my wallet doesn't do onchain, can you send me a lightning invoice?\"\n\"it's saying something about liquidity\"\n\"what's a 'mint'?\"\n\"what is a 'melt'?\"\n\"what is a 'submarine swap'?\"\n\"why do I need to 'topup', can't I just transfer funds from my bank?\"\n\nNone of these problems are impossible to solve individually, but solving all of them across a network of apps created by people with different ideas is combinatorially difficult. \n\nIn nostr we say \"don't overload kinds\". I think this is the problem — we've overloaded the term \"pay with bitcoin\". It means:\n\n- P2PKH\n- P2SH\n- Native SegWit\n- Taproot\n- Bolt11 invoice\n- LNURL\n- Lightning address\n- Bolt12 invoice\n- Keysend\n- Cashu eCash\n- Fedimint eCash\n- Spark\n- Ark\n\nI'm not saying each of these doesn't have its use case, or that innovation isn't good, but this complexity comes at a cost, which either the wallet developer or the user has to bear.",
"sig": "b4630d4ebbed13b5bb5e0bda1e794db54e48a45bd29c4c80dc9083d3d3514f1490e3d3834d457dcfc9d2e6bb88d3541f74c72656abf0411e83f65c5d1cace151"
}