pull down to refresh
the problem is NWC
why? how?
Why: convenience
How: convenience needs a hot key
I agree with that. But I think it's also fair to say that if we're taking root causes, the root cause here is an additional key liveness requirement for NWC on top of the set already required for LN. That subsequently there are no palatable p2p solutions for the less technical among us and thus everyone is using (unlicensed, uninsured) banks to centrally manage all the keys and moneys... is perhaps only a secondary problem.
Without NWC and without requiring automated invoicing, Zeus/Blixt with private channels, or simply Phoenix, works perfectly. That part is solved, but serverless, non-custodial connected wallets with auto-invoicing is not.
Quote from the lightning paper:
Currently the solution to micropayments and scalability is to offload the transactions to a custodian, whereby one is trusting third party custodians to hold one’s coins and to update balances with other parties. Trusting third parties to hold all of one’s funds creates counterparty risk and transaction costs.
Due to requirement goalpost shifting (a category that the C of NWC definitely belongs to), and a failure to solve liveness well outside of a server environment, the well-implemented use case for non-custodial LN is currently smaller than the "automated" NWC use-case requires, but the same also goes for lnaddr / lnurl. Every time we run into issues, we bring back custodial bitcoin :-/
Agreed.
I try to accept the world as it is and be optimistic about it (no pun intended xD).
Convenience is important to many. Also price stability.
I'm sure many of us here would be happy to be Uncle Jim service providers for friends and family. And a plebs lnbits node is not a juicy target, which would solve or mitigate this problem.
If we can't solve self custody, at least we could try and do better in decentralization.
Yes! Except if acceptance criteria aren't met, then there shall be no acceptance coming from me.
What I honestly wonder about though: are the acceptance criteria (for NWC / lnurl) right within LN constraints to begin with? Are they compatible with the baseline tradeoffs made for LN?
Bottom line, perhaps it all depends on whether you think Bitcoin should be for governments and mega corporations, or it should be for individuals too. To me, the "for individuals" part is the #2 acceptance criterium, after the promise that it "allow[s] online payments to be sent directly from one party to another without going through a financial institution", which is #1. I didn't walk this path to finally be enslaved / get rugged by banks ran by amateurs instead of professionals. As long as the individual-to-individual is enabled, all friction can probably be made bearable, scripted away - for me.
After all, the only place I connect a wallet is SN, and here I only do it to be environmentally responsible, as the sea levels will rise towards the point where on the Maldives you'll only have water villas and nothing else, through the addition of all the tears from stackers when they receive CCs.
I think your second criterium is already met. I've just zapped you from my LN node funded with self custody Bitcoin.
The fact that most people don't care or aren't willing to run one is not really a problem or at least not a problem any payments "solution" can fix.
I think email is a great invention (definitely not perfect, but that's not the point) because it allows people to self host their server. Not because everyone does. And that foxes many things in terms of incentives.
Maybe I'm seeing it as an emergency exit. If it exists and works, it's as good as it gets. It doesn't really need to be used by everyone at once for it to be a successful good door.
Ln Bits had so much promise until Tor killed it and all the bugs and issues to use any of the apps!
CLINK would require no key DB
NWC key fumbling has always been a hot mess
Didn’t know NWC had keys to fumble
Yea, you have to generate the nsec and then give it to the app/service you're connecting with
In the case of services that becomes a database of keys that were ingested by other, likely dodgy, means.
CLINK flips that, service maintains a single key that's never shared and can be kept away from databases.
The problem was storing secret keys in a wide open database (host 0.0.0.0) with no auth. Surprized this did not happen earlier. Secret keys are only needed once to generate NWC connection strings. After that, only public keys need to be stored on the server side. Sister wallet https://coinos.pro did not suffer this attack, but nevertheless wiped all the keys and patched this vulnerability.
Hacked again? Man coin os is one big honeypot!