Topic: The Lightning Network FAQ - page 73. (Read 32053 times)

I thought about it, I really did, but

lnd.conf

[neutrino]
; Connect only to the specified peers at startup. This creates a persistent
; connection to a target peer. This is recommended as there aren't many
; neutrino compliant full nodes on the test network yet.
; neutrino.connect=


So, LND needs a full node and I can specify the only one of them. What happens to my LND node if that neutrino node stops working? It would be much more convenient if I did not need to specify a node. I wish it could find a compliant full node on the network itself and connect to it. Like torrent clients do.

One more question about tor nodes. I often see in logs that my node fails to connect to nodes with tor addresses (*.onion). Do I need to choose between Tor and the regular Internet or I can install tor and connect to both of them?

Data Loss Protection, it was mentioned in the LND v0.6 changelog which you quoted.


Actually, you don't have to run a full Bitcoin node if you are using LND! LND supports neutrino which lets you interact with the blockchain using third-party nodes. Keep in mind that it's still experimental but it's been vastly improved since it was released. You might give it a try. Thanks for clarifying your previous message.

I'm sorry, what is DLP?

You did not get the idea; let me clarify.
I mounted a remote directory to my local directory /mnt/nfsstorage. So, everything I put in there ends up on my NFS server (in amazon cloud). Then I added the backup file path in the lnd.conf file (backupfilepath=/mnt/nfsstorage/lndbackup/channel.backup). The lnd service keeps channel.backup updated constantly. Thus, I do not need to copy anything; the backup file will be updated by lnd directly on the cloud server.

The only problem I might have is with connection to the cloud server. However, the NFS protocol allows to automatically reconnect to a server if the previous connection was interrupted (that's what manual says .
I installed the NFS server yesterday, It seems to be working fine.

PS I would have gladly put everything on a cloud if I had not needed to store the entire blockchain there. Keeping 300Gb on a cloud server is quite expensive.

I totally forgot about this method, sorry! Since SCBs make use of a feature built into the protocol, they should be reliable. Personally, I have never had a chance to restore my node from such a backup. Once the DLP is initiated, the remote node sends the latest commitment transaction and forcefully closes the channel. The only problem with your proposal is that your NFS backup might become invalid anytime unless you stop participating in the payment routing. How often would you backup the file? Every time it was modified?

Thanks for the answer with the explanation!
I googled about possibilities to organize an offchain backup. The developers say:

After version v0.6-beta of lnd, the daemon now ships with a new feature called Static Channel Backups (SCBs). We call these static as they only need to be obtained once: when the channel is created. From there on, a backup is good until the channel is closed. The backup contains all the information we need to initiate the Data Loss Protection (DLP) feature in the protocol, which ultimately leads to us recovering the funds from the channel on-chain. This is a foolproof safe backup mechanism.

We say safe, as care has been taken to ensure that there are no foot guns in this method of backing up channels, vs doing things like rsyncing or copying the channel.db file periodically. Those methods can be dangerous as one never knows if they have the latest state of a channel or not. Instead, we aim to provide a simple, safe method to allow users to recover the settled funds in their channels in the case of partial or complete data loss. The backups themselves are encrypted using a key derived from the user's seed, this way we protect privacy of the users channels in the back up state, and ensure that a random node can't attempt to import another user's channels.

Thus, we can assume that the backup file has always actual data about our channels. So, we just need to put it in a safe place. I am thinking of setting up an NFS server somewhere in a cloud. That way I can mount a remote directory on my LND node and backup the offchain data to it.
What do you think about this solution?

TCP should be enough just like for a Bitcoin full node.


Same as above.


There is no safe method of channel backup at the moment. It's much easier for private channels since they don't participate in payment routing. If you lose a backup and don't want to try using the old one, the only "solution" is to wait for the other party to close the channel.


Watchtowers do not store any backups of your channel. They simply monitor the network in case the other party of your channel attempted to cheat by broadcasting an old state of the channel. They store and publish justice transactions when needed.

Every time a Lightning Network transaction is settled, a commitment transaction (a transaction which settles the current balance of the channel) is signed and the revocation key for the previous transaction is shared. The commitment transaction also states what happens if the other party revokes the transaction or if they don't do it in x blocks (x=144 by default). A justice transaction revokes the outdated commitment transaction.

Hi everybody, I set up a lightning node (CentOS + bitcoind + lnd + some scripts) and I have some question about configuring LND.
1. The port, which LND uses to listen to incoming connection is 9735. Is it tcp only port or tcp + udp?
2. The same question about watchtowers' port (9911)
3. How to securely backup offchain data? If something goes wrong with my node's software or hardware, how can I make sure if I have actual offchain data? I know that I will be punished for using outdated data even if I don't mean it. I found the channel.backup file but it's stored localy, what would I do if my ssd died?
4. I read about the watchtowers client, that it is supposed to "connect to backup encrypted justice transactions". I don't know what justice transactions are. Are they my offchain data or they are something else? Is watchtowers client help me to backup offchain data?

so here would be a way to make it work...

set up that private Lightning network, and keep it very exclusive to people within a given area. The crucial part would be: don't use it, except in outage situations. Use uptime of the general internet to store BTC in the private network, but use the regular Lightning network for everyday payments while internet remains up. Maybe a good idea would be to physically assemble people at a certain time every week to top up the liquidity in the private network, that way any disputes about which channel balances on the private local network are valid can be worked out there and then if internet dies coincidently while the actual meeting takes place.

Then, when internet goes down, this group of people have a pool of money that can reliably be exchanged in a zero hop fashion, as in my first example. And, if they can set up a meshnet, then they can achieve your suggestion: use multi-hop routing within the local private channel network to increase the liquidity

All of the above is possible today with some patching of Lightning software to switch between the mainnet and the private-net, and configuring devices and network routers to be capable of switching to mesh and/or adhoc modes Plus, the organizational task of setting and topping up the private channel network. Channel factories may serve as a fully packaged solution to that, but that's future stuff.

Good idea, thanks! I will report this idea to the Spanish forum. It is surely appliable for many cases, above all in urban areas, but also in some rural use cases (e.g. a person buying essential goods at the same grocery with BTC like it seems to be the case in countries like Venezuela).

The question remains if the setup I outlined is compatible with the Lightning network, i.e. if there is a way to pay offline when there is no direct payment channel between both.

Thanks, that sounds interesting, too, although I would need to know more details to know if it's applicable to the "offline payment" use case. The "forwarding", however, could indicate it's based on a similar principle like that I had in mind.

I have found the Lightning Rod protocol here at Github, but I must re-read it to fully understand it.

I don't know if it is related to your question, but this actually just hit the news:

A form of offline payments is being developed for Bitcoin’s Lightning Network


The functioning is quite simple in principle:


It's not clear (to me, at least) if this solution is fully trustless. If it weren't it would be little more than a gimmick. Otherwise, another step in the right direction of a more flexible and user-friendly UX for the Lightning Network.

ok



hmmm, not seeing the necessity of this

if alice and bob have a payment channel open between one another, there's no need at all for additional commitment exchange, they can perform the zero hop routing operation in an ad-hoc network i.e. out of band at their meeting spot. If both Alice and Bob live in the same area, and both lost internet at the same time, then the exisiting protocol can work just as well offline as online (private channels are essentially doing exactly this. We typically assume they do it connected to the wider internet, but it's not strictly necessary)


People with intermittent/zero internet access could always try setting up a smaller private network of payment channels to circulate currency locally, but agreeing on what channels are valid is a difficult problem if they lose access to the internet. Freezing the blockchain state to before the time at which internet access was lost limits lightning usage to devices that were in those precise geographical regions when the outage hit, and potentially different (but contiguous) areas went out at different times. The shorter period of time for which access to the blockchain is curtailed, the more viable a local channel network is.

Still though, huge amounts of trade are often local only, so depending on how well connected channels are in a given locality (reflecting high proportion of entirely local trade), it could work pretty well. The correlation of areas affected by internet outages with micro-economies could well be pretty high in practice, i.e. if a whole town loses internet, the whole town may well also happen to do 60-80% of trade internally. Is it not the case that mesh networking is more likely to exist in places with poor access to the corporate owned internet?

I have a question regarding LN which may deserve an own thread, but first (to avoid cluttering the Development forum) I ask it here.

Is it possible to use LN for offline payments?

The goal is to find a way for "pre-arranged" offline transactions in regions where internet connection is unstable/unreliable (people have asked me in the Spanish subforum with Venezuela in mind).

I had the following scheme in mind:

The situation

Alice wants to sell Bob a good, or sell BTC for fiat, but the trade will be carried out in an area without or with unreliable internet access. With on-chain transactions, there is a possible technique using timelocks and a secret to release the amount in question, but it requires a confirmed transaction on the blockchain (see here and for a similar example in another context, this proposal for payments of digital goods). This is not ideal because transaction fees would be paid even if the trade isn't carried out.

LN-based solution?

In a payment channel, we could arrange a "conditional payment" in the following way:

- Bob and Alice are connected by a payment channel.
- Bob (the buyer) sends Alice a signed commitment transaction, with a penalty like in a standard LN transaction, but a difference: the amount of the trade made conditional, requiring a secret to be spent (like in atomic swaps or the technique I just outlined). The transaction includes the hash of the secret.
- Bob and Alice meet in the place without Internet access.
-- If the trade takes place, Alice receives the secret from Bob, and she can verify it using the hash, with a simple electronic device not requiring internet access. She can now in theory release the funds including the amount of the trade with an on-chain transaction closing the channel. But instead, she tells the LN software the secret, and her balance is updated.
-- If the trade does not take place, Alice doesn't know the secret and thus cannot release the funds reserved for the trade, and thus she must use the last commitment transaction to close the channel, with the state of the channel before the trade.

I think with a simple payment channel this setup could work, if I've not overseen something. But is it also possible to route it via additional LN nodes? I don't know if the requirement of an additional secret would be possible to be "included" in the HTLCs necessary to route the payment through other LN nodes.

The solution would have a crucial advantage to the on-chain solution: it would not require any spendings of transaction fees, and in the case it's not carried out, not even LN fees would have to be paid.

Another use-case that illustrates that the future of Bitcoin payments is off-chain, https://medium.com/lightnite/lightnite-a-bitcoin-integrated-battle-royale-game-2ec9f3746b0e?sk=2145c0ea5da25a65c6a2d7a54fa23be1

The game's online store will start a more liquid marketplace for online items, finding more price-efficiency for those items.

Just to make you aware that in latest Bitcoin Optech Newsletter #66, we have full disclosure of LN vulnerabilities we have all been warned about during the last weeks:

it's good to bear in mind how increases in Bitcoin's exchange rate redefine what constitutes a micro-payment.

the "1 coffee use-case" is often considered the base level for in-person Bitcoin usage, but coffee can be anywhere up to $6 a cup, and the low levels are more like $1.50. What about typical purchases that are cost less than that?

• Bus/subway tickets
• mp3s
• chewing gum
• cups of Tea

At the current BTC exchange rate, you can pay anything from $0.005 up to $1 to get a transaction confirmed. It's not unrealistic that BTC could reach x10 it's value even next year, at which point the case for Lightning will be proving itself further (although the Bitcoin devs could of course change the 1sat/vbyte minimum feerate, but that comes with spam trade-offs)

IMO, cups of coffee should not be the baseline. mp3's would make alot of sense, they're one of the cheapest single items out there, and the people selling them (well, the people who write the music at least) are some of the most independent business-people there are.

I've said this many times; Bitcoin is the final piece in the puzzle for musicians, they can have a totally closed loop business model, where they control and own everything:

• production (studio equipment)
• promotion (social networks)
• distribution (own website)
• payment & banking (cryptocurrency)

I believe some people, whether FUD or not, have not thought of some use-cases that were tried on-chain, did not work, but would work in Lightning. One good use-case would be high frequency payments, Satoshi Dice.

Ah I understand... I actually naively thought you were honest and not spreading FUD. Have you ever read the whitepaper ? Or are you typing faster than you're learning ?

You want to discredit a network of routed payment channels by talking of the tradeoffs of a single payment channel. But you talk about the routing (a characteristic of a network of multiple channels) as one of these tradeoffs. That's why I thought you were obviously confused : actually you're not you're spreading FUD, but do you really think someone could actually believe such logic-less speech ?

That's true.
That's wrong. Intentionally or not ?

As the thread title is "The Lightning Network FAQ" and not "The Lightning Network FUDers challenging", I'll stop answering your messages. Please refer to the whitepaper (more conceptual) and the specifications (more technical and implementation-wise) for more accurate information about the Lightning Network.

Many people keep their Bitcoin on exchanges. Top 100 Richest Bitcoin Addresses shows a few billion dollars worth of Bitcoin in cold storage owned by exchanges.
Once LN becomes mainstream, I can imagine the people who store their funds on exchanges, won't have any problem using the same exchange to make their payments. Currently thats not a viable option because withdrawal fees are much higher compared to using your own wallet.
I imagine a future in which exchanges keep a couple million dollar worth of Bitcoin in their LN hot wallet, and many people use the exchange to make their small payments without ever needing to fund a LN channel on their own.
Say: paying from exchange to VPS provider, paying from exchange to buy a coffee, or paying from exchange to fund a balance on website x. The exchange, VPS provider, and website x will run their own LN-node. The coffee bar will most likely use a large payment processor that runs their own LN-node.

There are already custodial LN wallets, but they still need to earn their trust. If a large exchange would provide their own convenient (mobile) wallet, I'd love to use it!

As long as it's optional, I'm totally fine with that! I want to be able to use Bitcoin for small transactions, and for small amounts I don't mind trusting someone.

Is it really Bitcoin in which you and only you are in full control of your private keys? No.
Do I care for small amounts as long as I can make small payments without paying several dollars in fees? Hell no!

Hahaha. That would be their greatest development as a Bitcoin service. But have you used Bitpay? It now markets for Bitcoin Cash. But in a subtle/naughty way.

Plus criticizing Lightning is OK, but saying gift cards are more superior is the dumbest way to criticize it.

You are confused between direct payment channels and the actual Lightning Network. Having such a network is the whole point of solving the direct payment channels issue you pointed out. You can learn more about the Lightning Network here.

To answer the question : using the Lightning network is viable if you expect to do more than 2 payments using it. You will in practice have to pay some additional on-chain transactions to reload your channels.