After many months using custodial wallets (coinos) - but I kept seeing 'not your key, not your cheese!' and saw on many occasions the wallet being offline.
Finally I decided to get into self-custodial for the benefit of being able to control the wallet, now I am running shockwallet with lightning node, and to me the critical problem is the trust I can have on the setup, how it can be recovered in case of trouble, how to restore a node, that sort of thing ...
What specifically can we clarify on this? Obviously have to trust the code if you're unable to review it, and bootstrap mode is trusted but opt-in...
With your own node and bootstrap disabled it's designed to be completely trustless.
The nostr comms are also all encrypted so using our relay (or any public relay for that matter) doesn't open a risk.
how can it be recovered
Currently its the same as any other LND node, you need your seed phrase and channel backups to recover funds if shit hits the fan. Backing up the Pub database is also a typical manual process of automating a copy.
For shockwallet itself in boostrap mode, your nostr key is enough to recover the account keyring from the relay.
We are in the home stretch on a massive Backup/Restore PR for Pub that includes the Pub database shards, identity, account balances, offers etc... that chunks to an FTP server every 30s... and should make restore simple via a graphical wizard so you can get your guests back up and running quickly. Goal is for that to be enterprise class so you can rely on it for even bigger operations.
First I need to clarify that I really enjoy shockwallet, and I've tried to understand it as much as I could on my own. There is no equivalent out there, except Zeus, or Alby but then they charge for inbound liquidity ...
With Shockwallet, I never managed to properly use the lnd command line, every time I tried to run lnd, I noticed it is not connected to the node because the balance is always zero. And the second thing lacking is NWC support, which would allow to use it with nostr client app.
Lastly I have to say as well that I was a bit afraid the project would be abandoned, because there are a few typos, and annoying messages (when I click to return on the homepage), which were giving me the feeling the product was not fully finalized and like many Nostr projects would stay like this ...
If LND is at 0 and you're connected to your own Pub via the nprofile then it is in bootstrap mode, it will open an outbound channel automatically once the balance is sufficient. The only cost then is the chain fee for the channel, no lease.
We created CLINK as a superior protocol to NWC, if using with Nostr what you're looking for it's bxrd.app support it.
Definitely rough edges as we're still focused on driving innovation and a comprehensive ecosystem as part of that, wallet is getting pretty mature now though and polish is coming. Wallet is just one part, Pub, Bxrd, LV, CLINK, Sanctum... all primatives to a bigger vision intending to work better than the ad-hoc disjointed projects the ecosystem is stunted by... the trade-off for that being our dev effort bounces around to each component over a long time horizon.
the field "ndebit string" in wallet setting https://bxrd.app/settings cannot be edited, when login using the nostr extension (as recommended best practice)
"Browser-extension login cannot save or use ndebit: import your nsec in BXRD so your key can sign CLINK debit requests and encrypt the wallet link."
Hopefully there will be a workaround, or is this technically impossible?
A venn diagram of tooling and use-cases, building for dumb use-cases have left Lighning with equally dumb tooling.
If your coffee dealer isn't already storing their wealth in Bitcoin, they have little reason to accept Lightning for payments. Lightning isn't for coffee. People want to rush ahead to meatspace payments when very few people in the meatspace know what to do with Bitcoin in the first place.
Dumb tooling has also been a product of bad incentives, Lightning inherits this problem from Bitcoin itself... because it is permissionless/trustless there's no real business in making great tooling, so funded projects generally deal in slop like mobile nodes that are only useful for losing money on swaps and liquidity to tinker with something useless.
Maybe the catch-all answer here is Bitcoiners are dumb and have largely misallocated Lightning?
Meatspace payments and zaps, pretty much every tool for lightning presupposes these as the clear cut usecases for lightning when they don't exist outside of a little bubble
402 and AI is starting to wake up some people to the real use cases for API level machine to machine payments, be it for the wrong reasons, 402 stuff is still largely memecraft because of an ancient http code hipsters soy out over... And AI larp like OpenClaw is the latest bandwagon hipsters can't resist... Neither are actually practical ways to do these things ofc but at least it's directionally correct
The biggest problem is offline payments imo. The general problem is that the UX is nearly orthogonal to onchain payments and onchain payments work like we expect payment systems to work (payers/payees do very little except maintain a "credential"). So channel management and liquidity management are also problems. I think that's why swap-based lightning wallets see more market fit than actual lightning wallets.
You said that is the main problem. I do not see it as a problem because LN is a payment network as is VISA for fiat. Are you still using paper checks to pay your groceries ? No. You and the merchant are looking for instant settlement.
The main problem for LN is people knowledge about how it works. If the majority of its users will try to learn more, will not be such a pain in the ass.
As I explain it here #552822 with the water pipes analogy. Those who will understand how to manage the water pipes, will know how to manage also LN nodes.
channel management and liquidity management are also problems
Are problems for clueless noobs that start running PUBLIC nodes instead of just using private ones, simple ones, where liquidity is not such a pain. So again is an EDUCATION problem, not a LN problem.
Yeah, that's true. Actually where I live checks were never used. I am not actually sure how they work/worked. You get a notebook from the bank, tear a page, write a payment amount on it and give it to the person you are paying to? Then he goes with this paper to the bank and they exchange it for money? Was this the system?
Inbound liquidity management is my vote. Most non-technical users hit a wall the moment they try to receive for the first time and have no idea why. The UX around explaining channel capacity in plain terms is still basically unsolved, and it quietly kills onboarding.
voted inbound. sending on lightning is mostly fine for me now. receiving anything non-trivial is where the ux falls off. you either pay an lsp fee, do a swap, or ask someone to open you a channel, and each path leaks something or fails in its own way. channel and liquidity management i can mostly automate around, but inbound feels structural rather than tooling pain.
From the builder side: the wall isn't the payment, it's the receipt.
Shipping a static-page Lightning checkout last month, the hard part wasn't generating an invoice (two API calls). It was knowing the buyer paid without trusting a centralized backend. LUD-21 verify URLs solve it but aren't universally implemented; NWC support is inconsistent; there's no portable session primitive. So everyone reinvents polling, failure modes vary by wallet, and a paid-but-unverified buyer ends up chasing the merchant.
That asymmetry probably kills small-merchant adoption faster than liquidity does.
After many months using custodial wallets (coinos) - but I kept seeing 'not your key, not your cheese!' and saw on many occasions the wallet being offline.
Finally I decided to get into self-custodial for the benefit of being able to control the wallet, now I am running shockwallet with lightning node, and to me the critical problem is the trust I can have on the setup, how it can be recovered in case of trouble, how to restore a node, that sort of thing ...
@justin_shocknet
thanks
What specifically can we clarify on this? Obviously have to trust the code if you're unable to review it, and bootstrap mode is trusted but opt-in...
With your own node and bootstrap disabled it's designed to be completely trustless.
The nostr comms are also all encrypted so using our relay (or any public relay for that matter) doesn't open a risk.
Currently its the same as any other LND node, you need your seed phrase and channel backups to recover funds if shit hits the fan. Backing up the Pub database is also a typical manual process of automating a copy.
For shockwallet itself in boostrap mode, your nostr key is enough to recover the account keyring from the relay.
We are in the home stretch on a massive Backup/Restore PR for Pub that includes the Pub database shards, identity, account balances, offers etc... that chunks to an FTP server every 30s... and should make restore simple via a graphical wizard so you can get your guests back up and running quickly. Goal is for that to be enterprise class so you can rely on it for even bigger operations.
https://github.com/shocknet/Lightning.Pub/compare/master...wizard-wip
Docs will be revisited once we get this fully tested and merged.
First I need to clarify that I really enjoy shockwallet,
and I've tried to understand it as much as I could on my own.
There is no equivalent out there, except Zeus, or Alby
but then they charge for inbound liquidity ...
With Shockwallet, I never managed to properly use the lnd command line, every time I tried to run lnd, I noticed it is not connected to the node because the balance is always zero. And the second thing lacking is NWC support, which would allow to use it with nostr client app.
Lastly I have to say as well that I was a bit afraid the project would be abandoned, because there are a few typos, and annoying messages (when I click to return on the homepage), which were giving me the feeling the product was not fully finalized and like many Nostr projects would stay like this ...
That's helpful information, thank you.
If LND is at 0 and you're connected to your own Pub via the nprofile then it is in bootstrap mode, it will open an outbound channel automatically once the balance is sufficient. The only cost then is the chain fee for the channel, no lease.
We created CLINK as a superior protocol to NWC, if using with Nostr what you're looking for it's bxrd.app support it.
Definitely rough edges as we're still focused on driving innovation and a comprehensive ecosystem as part of that, wallet is getting pretty mature now though and polish is coming. Wallet is just one part, Pub, Bxrd, LV, CLINK, Sanctum... all primatives to a bigger vision intending to work better than the ad-hoc disjointed projects the ecosystem is stunted by... the trade-off for that being our dev effort bounces around to each component over a long time horizon.
the field "ndebit string" in wallet setting https://bxrd.app/settings
cannot be edited, when login using the nostr extension (as recommended best practice)
"Browser-extension login cannot save or use ndebit: import your nsec in BXRD
so your key can sign CLINK debit requests and encrypt the wallet link."
Hopefully there will be a workaround, or is this technically impossible?
Just pushed a probable fix for this, see if it works now after a hard refresh
did some test yesterday, I think I broke it
May 12 11:09:39 debian12amd64 bash[8411]: Node.js v24.15.0
May 12 11:09:39 debian12amd64 systemd[539]: lightning_pub.service: Main process exited, code=exited, status=1/FAILURE
May 12 11:09:39 debian12amd64 systemd[539]: lightning_pub.service: Failed with result 'exit-code'.
May 12 11:09:39 debian12amd64 systemd[539]: lightning_pub.service: Consumed 22.751s CPU time.
May 12 11:09:39 debian12amd64 systemd[539]: lightning_pub.service: Scheduled restart job, restart counter is at 14.
May 12 11:09:39 debian12amd64 systemd[539]: Stopped lightning_pub.service - Lightning.Pub Service.
May 12 11:09:39 debian12amd64 systemd[539]: lightning_pub.service: Consumed 22.751s CPU time.
May 12 11:09:39 debian12amd64 systemd[539]: Started lightning_pub.service - Lightning.Pub Service.
May 12 11:09:40 debian12amd64 bash[8456]: > lnpub@1.0.0 start
May 12 11:09:40 debian12amd64 bash[8456]: > npm run clean && tsc && node build/src/index.js
May 12 11:09:40 debian12amd64 bash[8743]: > lnpub@1.0.0 clean
May 12 11:09:40 debian12amd64 bash[8743]: > rimraf build
thanks for these explanation
found the wallet setting in https://bxrd.app/settings
looking forward seeing the whole project reaching momentum
A venn diagram of tooling and use-cases, building for dumb use-cases have left Lighning with equally dumb tooling.
If your coffee dealer isn't already storing their wealth in Bitcoin, they have little reason to accept Lightning for payments. Lightning isn't for coffee. People want to rush ahead to meatspace payments when very few people in the meatspace know what to do with Bitcoin in the first place.
Dumb tooling has also been a product of bad incentives, Lightning inherits this problem from Bitcoin itself... because it is permissionless/trustless there's no real business in making great tooling, so funded projects generally deal in slop like mobile nodes that are only useful for losing money on swaps and liquidity to tinker with something useless.
Maybe the catch-all answer here is Bitcoiners are dumb and have largely misallocated Lightning?
What use-cases would you put prominently on the Venn diagram?
Meatspace payments and zaps, pretty much every tool for lightning presupposes these as the clear cut usecases for lightning when they don't exist outside of a little bubble
402 and AI is starting to wake up some people to the real use cases for API level machine to machine payments, be it for the wrong reasons, 402 stuff is still largely memecraft because of an ancient http code hipsters soy out over... And AI larp like OpenClaw is the latest bandwagon hipsters can't resist... Neither are actually practical ways to do these things ofc but at least it's directionally correct
I was just doing a focus group with 50 boomers and asked why they don't use lightning in their day to day.
49 of them said unilateral closures were the reason, I was stunned.
BCH and monero haters that refuse to learn more about LN
last point applies especially to you. Nobody mentioned bch or monero dumbass.
Learn to program, darth. You might learn more about these longstanding technical problems.
I know very well about those issues. But that doesn't mean LN doesn't work. Is still a baby.
That is not an obligatory requirement in order to use and know how to use Bitcoin.
The biggest problem is offline payments imo. The general problem is that the UX is nearly orthogonal to onchain payments and onchain payments work like we expect payment systems to work (payers/payees do very little except maintain a "credential"). So channel management and liquidity management are also problems. I think that's why swap-based lightning wallets see more market fit than actual lightning wallets.
agreed. If we want self custody we need a system that's more robust to people's personal tech going down
Why LN must be used offline?
I didn't say it must be used offline.
You said that is the main problem.
I do not see it as a problem because LN is a payment network as is VISA for fiat.
Are you still using paper checks to pay your groceries ? No. You and the merchant are looking for instant settlement.
The main problem for LN is people knowledge about how it works. If the majority of its users will try to learn more, will not be such a pain in the ass.
As I explain it here #552822 with the water pipes analogy. Those who will understand how to manage the water pipes, will know how to manage also LN nodes.
Are problems for clueless noobs that start running PUBLIC nodes instead of just using private ones, simple ones, where liquidity is not such a pain.
So again is an EDUCATION problem, not a LN problem.
I agree, but we probably can't change that.
If lightning becomes as easy to use as onchain, I think more people would use it. That's all I'm saying
Most people use paper cash actually.
paper cash is instant debt settlement, totally opposite of checks.
Yeah, that's true. Actually where I live checks were never used. I am not actually sure how they work/worked. You get a notebook from the bank, tear a page, write a payment amount on it and give it to the person you are paying to? Then he goes with this paper to the bank and they exchange it for money? Was this the system?
IOU - I owe you
just a worthless piece of paper that you never know if you will get the money. You are trusting 100% the words of the issuer.
running low on sats!
I gotcha.
Inbound liquidity management is my vote. Most non-technical users hit a wall the moment they try to receive for the first time and have no idea why. The UX around explaining channel capacity in plain terms is still basically unsolved, and it quietly kills onboarding.
voted inbound. sending on lightning is mostly fine for me now. receiving anything non-trivial is where the ux falls off. you either pay an lsp fee, do a swap, or ask someone to open you a channel, and each path leaks something or fails in its own way. channel and liquidity management i can mostly automate around, but inbound feels structural rather than tooling pain.
From the builder side: the wall isn't the payment, it's the receipt.
Shipping a static-page Lightning checkout last month, the hard part wasn't generating an invoice (two API calls). It was knowing the buyer paid without trusting a centralized backend. LUD-21 verify URLs solve it but aren't universally implemented; NWC support is inconsistent; there's no portable session primitive. So everyone reinvents polling, failure modes vary by wallet, and a paid-but-unverified buyer ends up chasing the merchant.
That asymmetry probably kills small-merchant adoption faster than liquidity does.