Nostr Web Client

Now I remember why you got kicked out of the Nostr Telegram group in the early days of nostr. You get needlessly personal. I am a dev and I do know how to manage liquidity in lightning. That has nothing to do with the discussion we are having

LN works as intended. And that's the problem, because the way it works is not enough

Even if you are a gigabrain managing liquidity flawlessly, that's still terrible UX, and you are not gonna change human behaviour en masse to make it work

We can change the topic to talk about how dumb everyone except you is but that doesn't change the fact that lightning doesn't scale the number of users that can use Bitcoin, it only scales the number of txns we can make

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago 💬 3

my prediction on this is that stuff like NWC in nostr, combined with a replication consensus protocol for things like a name service protocol (i'm making one called Free Internet Daemon), will be where the legitimate progress with lightning happens.

lightning has no consensus, so individuals are the atom of the security. with a consensus system, where multiple parties can decentralize a coordination system, according to an appropriate set of rules for the process, things that we see currently centralized in for example the alby hub isolated wallets, can become a protocol.

once you get to the point where you can trustlessly coordinate such a group wallet, and the consensus has full 50% byzantine fault tolerance, like bitcoin (my design has this property, it uses web of trust attestations) then we have solved the increase users problem. increase transactions solution is a prerequisite.

anyhow. that's one of the half dozen little side things i'm doing at the moment. i probably should focus on that one more because my most favourite programming task is designing and implementing a novel consensus protocol.

Reply to this note

Please Login to reply.

Discussion

DarthCoin ₿⚡️ 1mo ago 💬 1

Look into CLINK for that, maybe it could help in your project.

https://clinkme.dev

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

anyway, repeating "lightning is complicated" isn't moving to the 80% solution part of the task.

how do you solve the problem of the complexity of lightning network, is the right question

IMO, the answer is making a BFT protocol with 50% byzantine resistance, and then using that protocol to coordinate lightning node replicas, who would get paid for faithful operation of their replica. and yes, replicas. if 100 people are sharing a single lightning node, that's some fierce downtime risk. if 100 people are sharing three, that's reducing that risk by 1/8th

also, increasing the capabilities of the onion routing of lightning will be critical. redundant atomic multi-path payments don't exist yet. we need fork and join operators and we need a mechanism for triggering a reversal once the first attempt succeeds, the others have to be rolled back immediately. that's just redundancy, solving the stuck payments problem. yes, it requires you to store an ample margin so you can effectively pay 3+ times as much but all but the first are returned.

there is also other things that you can do with a few more onion routing primitive commands. you can split payments at the end of the path, you can create paths that push more in than they pull back out, so multiple parties get paid on the route. forks, joins, and reversals. there.

lightning will eventually enable a replacement for Tor that actually scales too. i've built half of that already.

Basanta Goswami 1mo ago

Are you imagining using something like FROST for signing lightning operations that are somehow enforced by the consensus system? So instead of having a single custodian or a federation you have a decentralized bunch that's running the lightning nodes and the end users have balances on this system instead