never, because you will have many cases where you don’t share mint with the recipient

what do you use then? Lightning!

this is the exact same as everyone reinventing trains.

Reply to this note

Please Login to reply.

Discussion

we can get rid of the special case for when there are no overlapping mints, and instead just use lightning

if it’s the same mint it’ll immediately succeed so who cares

also why do we need cashu now, we can just directly generate LN invoices

oh wait

Nope, they receive the untrusted ecash to their NIP-60 ecash wallet and swap it to a trusted mint or lightning wallet later, on their own time. This moves the error case from the sender to the recipient.

It's just a better system for zaps.

Why should I as a recipient have to pay the fees for others’ zaps, because mints can set any fee they want

I also as a recipient don’t want to show “zaps” that could be paper Bitcoin with no backing, thanks

"Why do I have to pay a fee on free money people gave me?"

Do you ever listen to yourself?

Don't like ecash? Don't use it! No one can make you. Stick with lightning zaps.

If people give me $1, and publicly show a zap saying they did, then I should not have to claim it in a process where I might end up $0.

If the sender sees a lightning failure, it was going to fail anyway with nutzaps. But instead of pushing the problem down in the stack by making it harder to receive money, the problem could be addressed immediately.

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

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.