179 sats \ 29 replies \ @thebullishbitcoiner 14 Sep \ on: LightningPub / Shockwallet video demo setup š„ bitcoin_beginners
Bullish.
What happens when trying to receive before you have a channel? Iām assuming that 2222 sat invoice is not enough to cover the fees.
Does it do something similar to the auto liquidity feature in phoenixd?
It says clearly at min 3 - "we boostrap directly from LSP channels...".
But you can also manage manually the channels as you like.
And no, this is not like phoenixd autoliquidity. Why people still do not make the difference between LN implementations Eclair and LND, LDK, CLN ?
reply
Because people are still learning my guy. What does ābootstrap directly from LSP channelsā mean? š
reply
It means opening on the fly channels from those LSP (liquidity service providers), same is doing Alby Hub, Zeus, Blixt, Bitkit.
The only downsize of these on-the-fly channels is that people are opening the first channels with small amounts, it means will be really small channels, with not suficient liquidity to be reused. Some kind of what was doing Phoenix v.1 and is costly for the user.
As per 1st channel opening is better to use a larger amount. Read more here #679242
reply
Actually its probably more like Phoenix than not, since in any scenario payments that are too small to be resolved on chain are inherently trusted. In both our case and Phoenix's case, they queue until a channel open is afforded.
The difference is we outsource the LSP role and you can use literally any other Pub instead of us by piping in their Pub nprofile. This is the gateway to decentralizing the LSP's and reducing costs 80% through channel batching.
reply
Actually its probably more like Phoenix than not, since in any scenario payments that are too small to be resolved on chain are inherently trusted. In both our case and Phoenix's case, they queue until a channel open is afforded.
When you say queue, were you referring to the sats essentially being locked (i.e. unable to be sent out after receiving) until a channel is opened?
I havenāt used phoenixd yet but I assume thatās how it works with them too? This also seems similar to what Alby Hub is doing when custodial accounts are converted. I think they refer to the sats as āhosted balanceā.
reply
They're not locked atomically but yes its similar in that its a hosted balance, what you're seeing there though in the screenshot is just the fee reserve for routing out payments... For example if you had a balance of 1000 sats it would still only hold 100 sats, if you had 20k sats it'd hold ~1%, 100 sats or 1% whichever is bigger.
reply
Ah that makes sense. I usually test with small amounts. Turns out this was right at the threshold. š
So a couple more questions:
-
Those 100 sats were received via the PWA. I decided to give the TestFlight a try so I downloaded that and added the nprofile. Was expecting to see the same 100 sats but didnāt. Am I missing something?
-
Also, when I initially add my nprofile, itās labeled as ārelay.lightning.pubā
But when I come back later, it just says āwalletā.
Is this a bug or is it the same source? I was expecting to be able to verify by clicking on the edit icon and seeing the nprofile but it comes up blank.
reply
With the PWA you probably pasted the nprofile:secret from the install script, which made the keypair generated by the PWA the administrator account such that you can send invite links and access the dashboard...
On the next device, the nprofile is creating a new account as a guest (invite links are just using the nprofile as a connection parameter)
To have the two devices sync'd on the same account, you have to auth into the first one (Uses Nostr to back up the wallet settings and sync via nip07 browser extension or our Sanctum remote signer service). Then log into the next device to pull down the sync'd state from Nostr so that your admin keys are in both places.
#2
Yea that's the same source, its just temporarily showing the relay its connecting over until it resolves the Pub's vanity name (can set this in Dashboard for each app, wallet is just the default app, will have avatar and other stuff soon :tm:)
Actually its probably more like Phoenix than not, since in any scenario payments that are too small to be resolved on chain are inherently trusted. In both our case and Phoenix's case, they queue until a channel open is afforded.
Thanks Justin. This is what I wanted to know. So during this trusted phase, I technically donāt have a channel.
Now my questions are:
- Are there higher fees during this phase or do I just accumulate sats until a channel is afforded? In other words, is it a lump sum or do I pay for the channel over time?
- Do I get to decide the threshold when that channel should be opened?
The difference is we outsource the LSP role and you can use literally any other Pub instead of us by piping in their Pub nprofile. This is the gateway to decentralizing the LSP's and reducing costs 80% through channel batching.
Let me see if I understand this. Channel batching occurs when multiple users (e.g. the ones that are connected to Uncle Jimās node) are using my nprofile so we can all essentially share the channel-related costs. Is that right?
reply
Sats just accumulate as a fee credit, this is just the naive default and triggers when the opening cost is <1% the size of the channel. Pub fetches a quote on every balance update and then executes the open so all the logic is completely self-hosted.
Threshold is adjustable in the .env file on the Pub node, but the best way is really just open a channel any time you want via cli since its just LND underneath... we don't have creation UI in the dashboard yet, but should very soon (read-only is already there)
Channel batching
I think you're describing node-sharing, whereas channel batching is a batch open of channels on-chain to multiple nodes at once.
Scenario: You run a Pub, but have no channels, your only balance is trusted at another Pub. Either your or their Pub could advertise/solicit a batch open position, and then apply your balance towards that.
Since we already have the connections and node identity over Nostr, we'd use that for additional coordination... These batch opens might even leverage the broader Nostr web-of-trust, and the incentive exists because batches reach almost 80% savings on opening costs with just a handful of participants
reply
Channel batchingI think you're describing node-sharing, whereas channel batching is a batch open of channels on-chain to multiple nodes at once.Scenario: You run a Pub, but have no channels, your only balance is trusted at another Pub. Either your or their Pub could advertise/solicit a batch open position, and then apply your balance towards that.Since we already have the connections and node identity over Nostr, we'd use that for additional coordination... These batch opens might even leverage the broader Nostr web-of-trust, and the incentive exists because batches reach almost 80% savings on opening costs with just a handful of participants
This sounds really cool. Iām not a Lightning pro so I wouldnāt know, but it sounds like channel batching has been around for a while. The only difference now is that thereās coordination. So instead of my opening 10 channels with an LSP to save on costs, itāll be up to 10 different participants each opening a channel.
Thanks for taking the time to explain all of this btw. Def will pass on the knowledge.
reply