pull down to refresh
179 sats \ 29 replies \ @thebullishbitcoiner 14 Sep 2024 \ 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.
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