Subnostr

the big deal about #cashu is that it lets you do async payments, for when lightning is offline

well, first of all, if the lightning is offline you simply can't redeem those nuts anyway, because your lightning is offline, see?

secondly, if you want async payments, there's this thing called "bitcoin on chain", maybe you heard of it?

oh, no good for less than $100?

i'm not gonna argue that lightning network's connectivity is inherently flaky at the edges because that's just how it is, receiver makes a list of nodes to pass the payment through, and as it is doing that, one of them can become a full channel, or go offline, and then the payment will not work

as it is, lightning implementations are barely keeping up with implementing Atomic Multipath Payments but what we really need is Redundant Multipath Payments where clients make multiple paths that carry the payment in parallel and first to the other side blocks the others from being accepted

the other thing is that the p2p network of lightning network is really stingy on useful data (network intelligence, or network state consistency) to help ensure that receivers don't pick dodgy paths

i don't think that even it's on the table yet the kind of addition to bitcoin scripting that would enable a path-routed payment, or if such a thing can even be trusted, this is the challenge of state channels - who picks the paths, can be spying on you by picking their node at the first hop in the channels... and tracing you to an LNURL probably isn't that difficult either

none of the solutions existing are really sufficient, and ecash is worse than insufficient, it's a wide open field for scamming and incompetence

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 11mo ago

nostr:nprofile1qydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcpr3mhxue69uhhg6r9vd5hgctyv4kzumn0wd68yvfwvdhk6tcpzemhxue69uhk6mr9dd6juun9v9k8jtnvdakz7qpql5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqsc0mm8q it occurs to me that you should maybe consider an on-chain donation address

if people are sending multi-100k+ payments the fee rates are not that onerous

Silberengel 11mo ago

Yeah, we just realized that the donations might start to get bigger (👀) and we need on-chain stuff that isn't just one person's private wallet.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 11mo ago

the plague of success

semisol 11mo ago

cashu is a centralized IoU and also “offline” payments could be fake until you get online

Silberengel 11mo ago

Sure, but at least you have some chance of getting that donation, since donors don't tend to hang around and attempt 15 times. Different market than with direct payments to a supplier or something.

I'd like the ability to have a secondary LN wallet, so that I could keep the self-hosted one up, and it automatically falls back to #Minibits, if the payment doesn't go through or the wallet is offline, or something.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 11mo ago

the subject of resilience of nodes on LN has loomed big over my horizon just now thinking about this... this is something that could be added to LN to make it simpler to run multiple peers replicating the channels on different IP addresses that can pick up the slack if the primary goes down

of course, this would also be needed for cashu mint nodes as well, though they don't have to p2p it exactly, they have to signal it to wallets

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 11mo ago

yeah, i think it's a false argument that it solves the liveness problem of lightning at all, i'd say the opposite, cashu mints are probably more likely to be of lower quality (at this point) and even in ideal circumstances, they are just as prone to downtime, at least, as a lightning channel (which is one or both nodes in a channel down) which even sorta suggests that the cashu mint may be actually less stable, since where lightning channel failure is a 1 out of 4 probability the offline probability grid for cashu mint is 1 out of 2 (because it's only one)

oh, sure, you could have a dns round robin or you could have a loadbalancer but that itself is a centralization vulnerability, in both cases

i think that a strategy for failover for lightning nodes would be a great thing to have exist... such as a backup that heartbeat broadcasts proof it can maintain a given channel end and the peer falls back to it in such a case. and the backup can act as a mirror, just needs a sync protocol, and it could act as a signed broadcast message

when i was working with the Steem protocol there was this possibility to set up a peer to sign over to another peer to cover for a particular pubkey that was in the stake-to-validate race, i could cook up such a cryptographic scheme so that it is even less noisy, one node syncs state to another(s) and a protocol for a takeover message to move the channel addresses to a new IP

Silberengel 11mo ago

I can't really follow this, but I like the idea of a backup node.