Topic: The Lightning Network FAQ - page 56. (Read 33677 times)

You're going to like the start_height option I recently noticed:
First:
Use "false" for rescan.
Next:
If you lookup the address on a block explorer, you'll know which blocks to rescan.

Stupid question which is a follow up to my above post:

So I have a lightning node with 0 funds, I want to open a couple of channels but would 1st have to send funds to the node wallet.
Can I just run importprivkey in wallet that my node uses and then open channels with those funds? I don't see why it would not work but I'm not sure.
Since the mempool is still pretty full I figure it would save me some tx fees.

Normally I would just do it and see what happens but the node is on a RPi and when you import a key and rescan the blockchain it takes a really long time.

Thanks,
Dave

Quoting myself here because the last few days have proved this true at least for me.
I have a few new channels that I want to open but with the fees what they are since at least Friday it's not going to happen soon.
No, I am not going to send it at a very low fee and "possibly" they will confirm. Just going to sit here and wait for now.

How many other people are doing the exact same thing?

-Dave

that would involve unannounced channels too, Lightning network channels are announced to other nodes by default. Sometimes unannounced channels enable types of attack, but at least in the case of spamming, they help mitigate against attacks.

With good routing algorithms (i.e. involving multipath routes) and effective anti-spam, I would imagine there would fewer benefits to unannounced channels. But this of course means that LN nodes with a complete network-wide routing table still know the channel balances, and so privacy is harmed. IIUC, it's not possible to run the LN effectively if all channels are unannounced, and realistically it's impossible to have entirely private channels (as your channel counterparty always knows the channel exists)

this does not preclude the possibility of having 2 or more Lightning nodes, of course (I would suggest that most people running their own nodes will end up opening a 2nd, if only temporarily to improve anonymization of funds).

I believe when Taproot is activated, helping obfuscate the opening of channels, a Lightning privacy-app might be THE killer-app the community is waiting for in my opinion.

Hi again...

I was expecting to understand the values on my post above but I think that can wait. I have other questions I need to see if my reasoning is correct.

Is it correct to assume that command fundchannel, is a combination of commands fundchannel_start and fundchannel_complete ??

Also, what would be the options to use in argument announce of command fundchannel_start? I can't see nothing about the options available in the docs (lightning-cli help fundchannel_start)?

Arbitrage is actually really an excellent point - this could perhaps even be Lightning's killer app, as payments in BTC (be it per LN or not) are still not too popular, but the speculation business with BTC is thriving as never. And it would offer real added value for arbitrageurs.

So maybe Bitstamp customers should spam them with feature requests to try to get it added ASAP? If they already operate a node (and have already more than a year of experience with it), it should not be too difficult for them.

Tether currently operates on several blockchains. Bitcoin (via Omni and also on the Liquid sidechain) continues to be one of them, but they added Ethereum, EOS and also some minor altcoins like Tron, SLP, OMG, Algorand and Nano. See https://tether.to/faqs/ .

Tether could also be huge for LN, because once it's possible to transfer an "USD token" around without high delays, the arbitrage business would get a new thing to play with. And it would also perhaps mean that the "minor altcoin" incarnations of Tether would slowly die because they wouldn't offer more transaction speed than the Bitcoin-based TUSD.

But as far as I understand the concept of "tokens on LN", Tether channels would not work for Bitcoin and vice versa. (There could actually exist some magic tech I am not aware of, but how should the HTLC concept work for different tokens with different values if the tokens aren't locked each one separately?) Anyway, it would bring increased publicity for LN. I also do not really like Tether but if it helps ...

Thank you once more.

Ok, I have now tried to make a transaction (once again) from my Bluewallet (installed on my phone) to my Spark-Wallet (installed on my laptop and connected to my node). The first attempt, I got a message saying "In transit" but I received nothing in my Spark-Wallet. After a while, I tried again, got the same message, but this time the payment got in!

Edited:

I would like to understand the numbers stated by the command 'listfunds' and what my Spark-Wallet shows me:

When I run the command 'listfunds' I get this output (I shorted it for convenience and to make the post shorter but everything related to the funds is here, the rest are the open channels):


and my Spark-Wallet shows this:


So, how those these values relate to each other?

Correct. That would be the maximum you could receive through that channel.


There could be no route at all between your nodes or some node in the path might suddenly stop responding or the payment could be too large for a single channel to handle. The last one can be mitigated using multipart payments, but most wallets don't support them.


Yes, it does. Most of my Lightning payments were instant while others took under 10-15 seconds. Some payments took even longer time, but it didn't happen too often.

Thanks a lot for answering all questions clearly. Going to ask a couple more questions that arises as a consequence of previous replies.

So, I was supposed to be able to receive sats, at least, up to the amount of outbound liquidity the other node has to me, right?

And if someone else, other than the person who opened the channel with me, tries to send sats to me, it's never granted that the route can be done. That might happen if, for some reason, between the sender and me, there is some break in the routing, yes? Is this accurate?

What if there is a route but it needs to go through many many nodes, does that has any influence in the time the sats takes to be available on my side?

You can use them interchangeably in this context (inbound/outbound liquidity/capacity).


Yes, but it's also more complicated. See the last answer.


You get outbound capacity when: 1) you open a channel with someone 2) someone opens a channel to you and sends you some coins or routes a payment through you.


While your channel has some inbound capacity now, all incoming payments have to go through the node which opened the channel to you. You are also limited by the liquidity of other nodes in the route.

The "buy LN coins directly" step seems curious, possibly because they need a way to assess demand for LN withdrawals. With Wumbo channels and LN withdrawals, Bitfinex have that huge advantage as an exchange over the others, manifest as the potential for their own liquidity to be far greater than other exchanges without Lightning support. In a (likely soon) bullrun, this will make Bitfinex the most attractive platform to traders who wish to have more control over risk management. Then perhaps the "convert LN coins" step will be moot. Once a 2nd major exchange enables LN deposits & withdrawals, all of them will be essentially forced to do it so as not to lose out in the arbitrage battle.



However questionable Tether is as a concept, that would be a pretty remarkable facility for Bitfinex traders to have at their disposal. I thought that Tether had changed into an Ethereum based token though?

Hello.

There are 2 questions I still couldn't get a 100% accurate answer to. It's about opening channels, outbound and inbound liquidity/capacity.

First of all, is the term liquiddity the same as capacity?

And the 2 questions are:

1 - Do I get inbound capacity/liquidity when someone simply opens a channel with me?
2 - If [1] answer is no, do I MUST send some sats to the one who opened this channel with me to be able to have inbound capacity/liquidity???

And an extra question is if this work exactly the same way for outbound capacity. If so, the above 2 questions also answer to the case of outbound capacity/liquidity.

I have someone that opened a channel of 100k sats with me (his reserve is 1k sats) but he didn't send any sats to me neither I did to him and I can't send sats from my wallet in my phone into the wallet I have on my laptop connected to my node. The error is always the same: "Does the destination has inbound capacity??"...

Thanks

The problem is that if fees continue to be very low, people will continue to think that this will be so forever, and not bother about LN. They could even refuse to open a LN channel because of the fear that opening and closing it could cost them even more fees (which is a fallacy, as for LN you typically pay fees 1 time for many transactions).

Bitstamp has a LN node (which seems to be even older than Bitfinex's), but as far as I know it doesn't offer deposits/withdrawals.

Thanks for the info, that's really good news and I wasn't aware of it. It seems also to include withdrawals to LN (which is, imo, at most least equally important than deposits, so people can buy directly LN coins) and seems to have been added already in December 2019. The deposited coins are credited as "LNX" and can be converted for free to Bitcoin. It is true however that there are relatively few news articles about that and most of them focus on Bitfinex' LN node. Since September 2020 also Wumbo channels seems to be supported.

They also seem to want to add Tether deposits/withdrawals via LN. As Tether is an Omni token, this could mean OmniBOLT support.

Haha. That makes me wish that Bitfinex was a "model-exchange" that the other exchanges could follow. To be honest, I was expecting Bitstamp to be the first Lightning-capable exchange.

The dust limit is brought over from bitcoin core. I think it rpc's into core but I don't think it takes any of its settings (but I could he wrong on that one)..

I think that's stayed for cross compatibility so core can still broadcast the transactions.

Well, the output of that is:



But in the meantime, I was talking to (what I think is) a dev and he told me this is actually a bug and he started an issue on github.
https://github.com/ElementsProject/lightning/issues/4140

In less than a week, I have already stumbled into 2 bugs. On one hand, this is bad, because a noob user and a new lightning user is coming across with quite a few bugs. On the other hand, it's good because I'm kind of contributing for the enhancement of this Lightning Network implementation.

This dev tried to push me to fix the bug, as it's apparently simple to fix, but I'm too afraid of messing things up, so I'm not going to do anything without supervision.

As far as I understood, every node in the Lightning Network has these 2 settings: channel reserve and dust limit. This said, when one node (A) tries to open a channel to another node (B), node (A) needs to make sure tat it's own channel reserve parameter is equal or greater than its own dust limit. Moreover, it also needs to make sure that its own channel reserve parameter is greater or equal to node (B) dust limit parameter.

I'm not sure about this because in the meantime, this dev stopped talking to me. He's probably afaik and where I live is now time to go to bed. If I can find this dev tomorrow again, I my try to discuss with him, the fix I have in mind, in case my assumption above is true and accurate!

It's the minimum reserve YOU would have to change, try typing to the command line

And see what comes up, replacing clightning with how you'd normally run it and potentially /? with -h or - -help.

I was trying to search through the docs but there was a lot of them on their github.

We don't have any channel open. I mean, me and Friend B. (My only channel open now is with Friend A).

Do you know what is the setting I should use to set the dust limit to 573 sats?

I think you're wanting to change the channel reserve limit to 573 or they can change their dust limit to 546 (that might be easier for them to do and not interfere with the channel)...