If I can’t send sats now to someone, it won’t change the fact that they can’t receive it.

Instead of trying to improve LN reliability, we are trying to hide the problem in ways that will harm recipient adoption.

“The payment didn’t work” will become “the payment is stuck” “I paid a 20% fee for a payment” “I can’t get my own sats out”

This is an abhorrent system multiple times worse than EMV

Reply to this note

Please Login to reply.

Discussion

This has been my experience. Stuff going to error and the money being frozen and unusable.

And Lightning fees have been so cheap.

With Lightning, you immediately find out if they got the money. Nutzaps are in some weird limbo.

#paperbitcoin is ghey

I've used Minibits and it can be fun, but it offers me nothing over my Alby of Phoenix.

Also, we out QR code invoinces in Alexandria because I miss them. I hate being forced to zap.

the nostr integration via NWC is nice tho, but plain old school lightning invoices are definitely more universal.

a lot of idiots cast shade on lightning for its occasional payment failure, but the protocol keeps getting better. i did a lot of thinking about LN in 2023 and there is many strategies that can be used to improve reliability. AMP is just the beginning of ways that you can use it. the coolest thing is that the network graphs that you can create with lightning routing can have the shape of lightning. there is just some issues with allowing redundancy in paths so that they function as a first-to-destination overrides any backup paths thing. AMP allows you to make bigger payments, but it doesn't provide redundancy. making a variant of AMP that allows you to throw transactions across whichever path has the lowest resistance and ignoring any further transits that were backups would be huge.

idk how progress is with that. it also would be a useful technique for anonymised messaging protocols as well, i did a lot of work designing this, so that messages can fail on some paths but succeed on one out of 2 or more and it's twice as reliable.

that potential for encountering a "resistance" point in the path is why it happens sometimes lightning fails. the client defines the path, and that path is encoded in the invoices. for keysend and AMP, this path is created by the sender. sender-side source routing is notoriously poor at reliability, just search for stuff about source routing on wikipedia and other places to see what i mean. the source routing is essential to sender anonymity, which is the same principle used for lightning payment routing.