Bitcoin Forum

Table of contents

      1. What is the Lightning Network? (#post_point1)
      2. How do I use it? (#post_point2)
             a) Creating a payment channel (#post_point2a)
             b) Sending and routing payments (#post_point2b)
             c) Closing a channel (#post_point2c)
      3. Wallets and nodes (#post_point3)
      4. Planned features (#post_point5)
      5. Security risks (#post_point6)
      6. Useful sources of information (#post_point7)

1. What is the Lightning Network?

The Lightning Network is an alternative to the traditional Bitcoin on-chain transactions. It doesn’t replace them completely because on-chain transactions are still needed for closing and opening payment channels. The Lightning Network is a second layer solution and is fully opt-in. Transactions done between Lightning Network participants have no negative impact on the Bitcoin network. The Lightning Network allows for instant and extremely cheap P2P (micro)payments.

The Lightning Network consists of nodes which maintain payment channels with some of the participants of the network.

2. How do I use it?

To start using the Lightning Network, you have to use a compatible software (see Wallets and nodes (#post_point3) section). Every wallet has a different setup process and features so you should look up a guide for the one you choose on your own.

a) Creating a payment channel

What is exactly a payment channel?

Quote from: https://en.bitcoin.it/wiki/Payment_channels

Payment Channel is class of techniques designed to allow users to make multiple Bitcoin transactions without commiting all of the transactions to the Bitcoin block chain. In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimted number of payments can be made between the participants.

Two people establish a payment channel by locking up funds in a multi-signature address which needs both signatures to spend from it. Payment channels can be used as long as both participants remain cooperative. The maximum size of a channel is about 0.16 BTC. All major implementations now allow node operators to lift this limitation manually.

b) Sending and routing payments

Both parties transact without broadcasting the current state of their trade to the blockchain. They both keep the copy of the channel information. Each time a channel is updated, both parties sign a commitment transaction which keeps a record of the current state of the channel. This transaction can be published to perform an uncooperative channel close.

Sending payments over the Lightning Network is possible as long as there is at least one path from you to the other person through other nodes which have open channels between themselves. All nodes in the path must have enough liquidity. Each node is rewarded for routing the payment accordingly to their fee policy. Large payments can be split and routed via different routes thanks to MPPs (multipart payments); while all implementations support them, most wallets don't.

Ensuring that there is enough liquidity is the most difficult thing for most beginners. When you open a channel to someone, you gain outbound capacity. You won't be able to receive any coins through that channel unless you spend the channel reserve (1-3% of the channel's capacity). The more coins you spend, the more you will be able to receive. If someone opens a channel to you then you will gain incoming capacity and be able only to receive through that channel unless you receive more coins than the value of the channel reserve.

Secure payment routing would not be possible without Hashed Timelock Contracts (https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts) (HTLCs). The example below explains why they are needed.

Quote from: https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts

1. Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
2. Alice wants to buy something from Charlie for 1000 satoshis.
3. Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
4. Alice uses her payment channel to Bob to pay him 1,000 satoshis, but she adds the hash Charlie gave her to the payment along with an extra condition: in order for Bob to claim the payment, he has to provide the data which was used to produce that hash.
5. Bob uses his payment channel to Charlie to pay Charlie 1,000 satoshis, and Bob adds a copy of the same condition that Alice put on the payment she gave Bob.
6. Charlie has the original data that was used to produce the hash (called a pre-image), so Charlie can use it to finalize his payment and fully receive the payment from Bob. By doing so, Charlie necessarily makes the pre-image available to Bob.
7. Bob uses the pre-image to finalize his payment from Alice

Mobile clients establish private channels which do not take part in the payment routing.

c) Closing a channel

Payment channels can be closed either cooperatively or uncooperatively (forcefully).

Uncooperative channel close can be initiated at any time. Although, it doesn't make much sense to do it if the other node is online and fully cooperative. By default, one has to wait 144 blocks (~24 hours) before one will be able to spend the closing transaction. This value is decided during initial channel negotiations. Note that this value can be significantly higher in some cases. For example, Eclair Mobile (https://play.google.com/store/apps/details?id=fr.acinq.eclair.wallet.mainnet2&hl=en) sets the delay to 2048 blocks (~2 weeks) if one enables receiving over the LN. The delay gives the other party time to come back online and check if the latest commitment transaction was published. If the other party broadcasts an old commitment transaction then one can revoke it and broadcast a penalty transaction within the delay.

Cooperative channel close can be initiated only when the other party is responsive. The closing transaction can be spent immediately if both parties agree on the current state of the channel.

3. Wallets and nodes

There are only few Lightning Network implementations and each of them might contain some bugs which may lead to the loss of funds. Keep in mind that the Lightning Network is still in beta. iOS and Android wallets are easy to use and don’t require much setup as opposed to LND, Eclair and c-lightning which are used to run stand-alone nodes.

Implementations

• LND (https://github.com/lightningnetwork/lnd) (guide (https://dev.lightning.community/guides/installation/))
• Eclair (https://github.com/ACINQ/eclair)
• c-lightning (https://github.com/ElementsProject/lightning) (guide (https://github.com/ElementsProject/lightning/blob/master/doc/INSTALL.md))

Desktop clients

• Electrum (https://electrum.org/#home) (guide (https://bitcointalk.org/index.php?topic=5259973.msg54732922#msg54732922))
• Zap (https://github.com/LN-Zap/zap-desktop)

Android clients

• Phoenix (https://play.google.com/store/apps/details?id=fr.acinq.phoenix.mainnet&hl=en)
• BlueWallet (https://play.google.com/store/apps/details?id=io.bluewallet.bluewallet) (custodial wallet)
• Electrum (https://play.google.com/store/apps/details?id=org.electrum.electrum&hl=en)
• Eclair Mobile (https://play.google.com/store/apps/details?id=fr.acinq.eclair.wallet.mainnet2&hl=en)
• Bitcoin Lightning Wallet (https://play.google.com/store/apps/details?id=com.lightning.walletapp)
• Wallet of Satoshi (https://play.google.com/store/apps/details?id=com.livingroomofsatoshi.wallet) (custodial wallet)

iOS clients

• BlueWallet (https://apps.apple.com/app/bluewallet-bitcoin-wallet/id1376878040) (custodial wallet)
• Wallet of Satoshi (https://apps.apple.com/us/app/wallet-of-satoshi/id1438599608) (custodial wallet)
• Zap (https://apps.apple.com/us/app/zap-bitcoin-lightning-wallet/id1406311960) (LND required)

4. Planned features

• Dual-funded channels - two users instead of one will be able to fund a payment channel as originally described in the Lightning Network Paper.
• Eltoo - eltoo will be an alternative to the current method of settling payments between users. Channel updates are done by building a chain of timelocked transactions. A soft fork is needed to make eltoo available on the Lightning Network (in order to avoid having to broadcast the whole transaction history between users). Here (https://bitcointalk.org/index.php?topic=4638321.msg44134955#msg44134955) you can find out which opcodes need to be modified.
• Channel factories - existing Lightning Network channels could be used for creating new channels without broadcasting anything to the rest of the Bitcoin network. Normally, a channel is opened to only one person. In channel factories we have multiple people forming a group. Group members maintain channels between themselves. More interested users = higher savings. If one of the participants is uncooperative, existing channels are not affected - new channels can't be created, though.
• Splicing In/Out - currently, it is not possible to add or remove funds from channels without reopening them.

There are a few things which can be changed in the Bitcoin code in order to improve privacy. Introducing Schnorr, MAST and Taproot (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015961.html) would make transactions opening/closing channel indistinguishable from any other ordinal transaction.

5. Security risks

• Improper timelocks - sufficient time should be given in case of interaction with non-cooperative or malicious channel counterparties.
• Forced expiration spam - closing many channels at the same time might lead to filling up the whole block completely. If the spam lasts enough time, some timelocked transactions might become valid.
• Data loss - most of the Lightning Network clients don’t provide reliable method of backup. Using an old copy of the database might be considered as cheating. The other party broadcasts a penalty transaction in such a case. Data Loss Protection (https://medium.com/@ACINQ/adding-data-loss-protection-to-eclair-598c62494096) is available in all implementations.
• Coin theft - most of the Lightning Network nodes work 24/7 and store their coins in hot wallets which makes it easier for an attacker to steal them.
• Colluding miner attacks - miners have power to decide which transactions they want to include in the block so they can refuse certain transactions selected by an attacker. This attack is very unlikely to happen due to high cost and complexity (all miners would have to cooperate).

6. Useful sources of information

bitcointalk: The Lightning Network FAQ (https://bitcointalk.org/index.php?topic=5158920.msg51615708#msg51615708), Electrum Lightning Network walkthrough (https://bitcointalk.org/index.php?topic=5259973.msg54732922#msg54732922), Lightning Network Discussion Thread (https://bitcointalk.org/index.php?topic=4638321.msg41920502#msg41920502)

Lightning Network explorers: 1ml.com (https://1ml.com/), lightblock.me (https://lightblock.me/)

News: Telegram channel (https://t.me/lightning_network), bitcoinlightning.com (https://www.bitcoinlightning.com/), coindesk (https://www.coindesk.com/tag/lightning-network), Cointelegraph (https://cointelegraph.com/tags/lightning-network)

This post is a quick proof reading and critique as per the request of OP.


Technically I mean if it reduces the total number of on chain transactions this is an impact on the bitcoin network. I understand what you mean but perhaps this sentence could be more clear. Something like "once a lightning channel has been established transactions within said channel do not impact the bitcoin blockchain". Or something like that. Not trying to write it for you, just explaining what I mean.




I would change wording and the order a bit here.

To start using the Lightning Network you have to use a compatible software. Two people may establish a payment channel by locking up funds in a multi-signature address which needs both signatures to spend from it. This transaction is time locked so that the funds will be automatically dispersed in the event that one of the parties becomes uncooperative. Payment channel can be used as long as both participants agree to cooperate remain cooperative. One can close the channel even if the other participant is offline but it won't happen instantly in that case.


Great post. Thanks for being a continued asset to the community. +merit

Thank you for that great post!

It confirmed a doubt I had for a long time but nobody was able to "refute" it: the "forced expiration spam" problem. That weakness has an important consequence: We should never let Lightning "hubs" become too big, otherwise they would become a systemic risk, as they could spam the blockchain for a long time if they're malicious.

I'm currently installing Neutrino+LND to test the "light client" scenario which would make LN available "for the masses", but I ran into some problems. But I won't spam this thread with them - I'll look if I can solve them myself (I'm a total Go noob, so maybe a bit of RTFM is enough ;) ). Perhaps we can start another thread of this "Lightning series": "Lightning Network Experiences"?

Thanks for this well laid out piece, I'm really going to dig in at some point soon! My burning question is actually about that "Other" second layer you mention: Rootstock. So I apologise if this is completely unrelated, though since I saw you linking to Rootstock...

My first encounter with it was in 2016 I believe, when looking at Bitcoin smart contracts. The interest then, (and still now) was in smart contract use for e-scrow. This is also the use case described by some old articles on Google, but then I can't seem to find a link to an actual code that shows a working example for such a trustless escrow, a service still very much in demand.

I wonder, if during this LN implementation, it would be too difficult to add a second second layer (or 2 parallel layers) to also allow for escrow, or perhaps within LN itself? Or using LN as an escrow method?

If miners start censoring transactions, then it would be the only time that I will sell all of my Bitcoins. But, it would also be the best time to start calling for a UAHF type POW change.

Well, it actually depends on how you define censoring.

Miner do choose transactions based on some properties. And the most important one is the fee rate (sat/B) payed.

Since all miner have to agree, there needs to be an incentive for all of them. And all miner do definitely benefit from higher fees.
So most do choose the top X transactions from their list (ordered by fee rate) from transactions from the mempool.

They might not censor transactions from/to specific addresses since an incentive for all miner is missing here, but as far as all of them can profit, they probably always 'favor' transactions based on some properties.

But at some point of time the tx will be mined by someone not in the group of miners that wants to censor these tx's right?

These tx's might just take a little bit longer, because they have less miners fees, but they will be picked up by some desperate

miner.  ::)  Some people might even target these "scraps" because it is being discarded by the big boys? 

That might be a good idea. Feel free to PM me if you need some help.


Thanks for your suggestions. I haven't mentioned Schnorr signatures because they are not strictly connected with the Lightning Network. Updated.


There won't be any problems with having more than one second layer, especially if they have different features. It is possible to build more layers on top of the Lightning Network. Some think that ordinary people will use them instead of on-chain transactions.

I am going to write a long guide on the Lightning Network wallets once they stop changing so much. Developers are constantly updating their implementations.

What I am trying to say is real censorship by miner collusion or miner centralization. If that becomes real in the network then it will become nothing but an inefficient and expensive FED 2.0.

But a community-backed UAHF will happen before FED 2.0 happens in my opinion. The miners should be careful.

Theoretically, yes.
But practically, most miner (probably each one) has a financial incentive to mine bitcoins.
And with choosing the transactions with the highest fees to be included (either the pool operator or the solo miner decides this) the financial benefit will be the biggest.




This is definitely a possiblity.
But why should a miner be desperate enough to pick a low-fee tx over a high-fee tx (assuming the mempool is by far NOT empty).
He would give up on some btc's.

This is actually the scenario I believe will happen as well. I mean, the way people use Bitcoin now, most don't realise which implementation they're using, or even if they're actually signing any transactions at all. If/When these LN implemetations get to the point they look just like any Bitcoin wallet, you can be sure people will be using LN without ever interacting with the chain. In the end, this probably won't matter I suppose. It will take a lot more to convince me to move over, though I'm really keen (if I'm the typical example of a mainstream user).

Thank you for this nice post !

Unfortunately this confirm that LN = centralization ! It's against Bitcoin's primary objective and personally i can't support this technology (In the current state and especially if nothing will be made to improve the idea more in decentralized way).

2 importants depreciated factors join the game: Middle man and Trust.

Of course there adventages using it like enjoying a micro transaction fees, save Blockchain transactions ... but what about security (Keeping things decentralized) ?

I am not the negative guy of the gang, it's great to offer solutions to improve bitcoin or blockchain technology ... but security first (Especially when people's money at stake).

 ???
How did you get to THAT conclusion ?  ???
This doesn't make any sense. Please elaborate.

---

Fortunately, you don't have to support anything.
If you believe the LN is centralized, take a look at it again. Read a few articles. And come back with more knowledge. The LN is anything but centralized..

---

Well, good thing is: The LN does NOT need a middle man and does NOT require trust.

You seem to be overwhelmed by looking at the pictures illustrating the LN.
Please, do yourself a favor, and read into the LN.

This takes 5 minutes of your life, but will keep you safe from embarrassing moments/posts (like this one).

---

What has security to do with centralization ?! You seem to be mixing up a lot words you have heard.

As already mentioned, LN is no way decentralized. And you would know that if you would have read at least 1 proper article about the LN.

If you have any security concerns, feel free to shout them out. I will be glad to answer all of your questions regarding security.

---

You seem to be the 'uneducated' guy of the gang. At least regarding the LN.
You have a lot of misconceptions regarding the LN.

Before going furthur, stay educated and do not shoot garbage there face to someone you don't know.

So let start with MIDDLE MAN:


So Bob here is the middle man, he can affect time of transaction and especially if he go offline.

LN is a network of several centralized hubs ... and you have to choose a performent and all time online to prevent delaying transaction etc ... So here a contract of trust ...

I invite you to read more here for disadvantages of LN in the current state and what make it centralized:
https://medium.com/crypto-punks/lightning-network-ux-centralization-b517037b92ec

Colluding miner attacks - miners have power to decide which transactions they want to include in the block so they can refuse certain transactions selected by an attacker. This attack is very unlikely to happen due to high cost and complexity (all miners would have to cooperate).

You have to trust miners.

And please read more about "what make a technology decentralized" before posting anything else ... and also to prevent spamming this thread since the first goal is to give some knowledge about LN and not to debate it (I given my feedback like you did yourself, there many other threads about this.).

The time is not a real problem since every transaction has its own timeout. It all happens nearly instantly. I have sent about 100 LN payments and the longest one took 1 minute. Bob can't steal funds because of HTLCs


You can still open a direct channel to someone who you are going to transact with very often. Here (https://1ml.com/node?order=capacity) you can see the largest nodes. Only one node has 1/4 of the total Lightning Network capacity. Keep in mind that principal is not the most important factor; the number of connections and channel balancing are much more important. The need of being online is definitely a huge disadvantage for some people, can't argue with that.


If ALL miners decided to cooperate with a single person then you would have to be more concerned about 51% attack. It won't happen since it would scare future investors and users. Miners would lose money long-term.

It took me some time to format this text on my phone. I am going to read what you have linked once I get home.

Instructive return, thank you.

Waiting your feedback about the link of my previous answer.

The same applies to the current Bitcoin network, without Lightning Network. If all miners decide to reject transactions from a certain address, they break the one thing that makes Bitcoin so great, and severely treaten the value of their investment.

The article (https://medium.com/crypto-punks/lightning-network-ux-centralization-b517037b92ec) linked by you is well written. It covers a lot of problems and suggests solutions which are quite reasonable. However, one thing drew my attention.


That's why eltoo (https://www.bitcoinlightning.com/eltoo-protocol/) was proposed. It will be an alternative to the current penalty system. A softfork is needed (https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki). Also, it's not possible to spend all funds that are locked up in the channel - there is such a thing as reserve which is a minimum balance that channel must maintain. For example, one of my channels has 0.0049 BTC capacity; the reserve is 0.000049 BTC.

Thank you for your time reading the article ! Yes it cover many cases with offering a solutions to remedy the problems.

Eltoo solve the problem by continuously updating payment channel balances off-chain.

Soft fork is required since “SIGHASH_NOINPUT” flag for signature must be introduced to Bitcoin Protocol to make it working.

I suggest you to edit your post and add this basic video explaination about how LN works:
https://www.youtube.com/watch?v=rrr_zPmEiME

You could mention that BIP157 & BIP 158 (implemented in Neutrino) will improve privacy for SPV based Lightning wallets.



And you could mention that Schnorr, MAST & Taproot will make the on-chain transactions opening/closing Lightning channels indistinguishable from regular 1 input/1ouput transactions (another privacy improvement, + extra fungibility)

@BitCryptex

Thanks for starting the thread! Could you please add https://lightblock.me to the list "8. Useful sources of information" ? It's a lightning network explorer for mainnet.

Regards.

Thanks for pointing out these things. I have just updated "Planned features" and "Security risks" sections. I would appreciate any further suggestions.


Sure. I have added 1ML.com (https://1ml.com) as well.


This has been fixed in the v0.5 release of LND (https://github.com/lightningnetwork/lnd/releases/tag/v0.5-beta). When a channel is being closed or a peer node has gone offline, the rest of the network is informed that they are incapable of routing payments. It is also possible to create unadvertised channels which won't route payments.

I have posted here about a video I have seen on YouTube about Lightning Network because I wanted to hear your opinions and this thread was a good choice, I assume.

This video shows how easy it is to send and receive transactions on LN and to be exactly author buys coffee and pays with LN transaction.

At the end of video, he has some doubts and I wanted to discuss them here but my post was deleted by a moderator and even a quote together with an answer to this post from a member @DooMAD was deleted too.

I don't think my post was spammy so I ask why it was deleted?

I have a copy of this post but don't want to post again until I don't know what is going on.

This is a forum and I thought that all of us here are supporters of freedom of speech and expression.

HERE (https://www.youtube.com/watch?v=8kkYZOpc688) is a link to this YouTube video, please watch and share your thoughts about the doubts in the end.

I like that debate. As much users must run full nodes as possible. But would he also agree that all users should stop using blockchain.info wallet, and other custodial wallets for on-chain transactions? Or was that video but a weak attempt to attack Lightning?

Ask him.

It was also disingenuous of him to make it look like Lightning is run only by trusted third parties.

I don't think this is possible in LN for users to run full nodes and that's one of the concerns he raises.

Do you think this is an attempt to attack LN? Maybe yes but a few of his concerns are valid and I thought about it too already.

Third party trust problem, centralization, no control, LN acting like a bank to name only a few first which cross my mind.

I am not a fan or against Lightning Network. We need a working solution which will make the BTC faster, cheaper, safer, better and additionally don't lose all the core values during the process. To be able to compete with this new GEN4 cryptocurrencies popping up every day with lightning speeds built into them, much safer, cheaper and way more scalable.

Has Lightning Network fulfilled this needs?

I just read on Reddit and also on there official website that
LNWallet.io is closing.
So if you still have any funds there withdraw it.

What? There are more nodes in the Lightning network than both Bitcoin Cash ABC and SV nodes combined. Haha.


He was being disingenuous in his debate. I would like to hear him say that users should stop using blockchain.info wallet, plus other custodial web wallets for on-chain transactions. To take it even further, stop using light clients like electrum, and use Bitcoin only through running full nodes. 8)


GEN4 cryptocurrencies? What are they?


Maybe it will, maybe it won't. But developers are free to experiment with anything on top of the network because it doesn't alter anything in the consensus layer.

Just checked and you are right:
I thought that these nodes are LN nodes not connected to BTC but I was wrong. I took my time today and read a lot about LN and how exactly this all works.


Like many others, I call them Gen4 but there is still debate if this is still 3rd blockchain generation or already fourth. Or even if there are generations of the blockchain at all? In the crypto world, everything is constantly evolving, sometimes so fast that we don't add up with how to call or name it. English is not my first language and when I translate crypto related text to Polish I have many times to figure out how to call things properly because such words even don't exist in our language and there are no professional translations available yet. Many times we have just to agree on something and I think this is the case with how or if to call different blockchains as different generations or something else. There are differences between blockchains for sure.

You can read more about the 4th generation of blockchain and the best projects HERE (https://www.quora.com/What-are-your-best-cryptocurrencies-that-have-4th-gen-blockchain)

Meaningless marketing buzzword bullshit.   ;D

Every time someone talks about their coin somehow being "next generation", it's just a desperate plea for attention.  It's invariably a case of "Look at me, I have the shiniest baubles!" and generally not much else.  If it didn't shatter the illusion and they thought they could get away with it, they would probably try and call their coin Gen1000.   ::)

it's completely meaningless marketing rhetoric

if you believe it, you deserve to lose anything you invest

Never said I believe in such marketing rhetoric.

I just answered your question about the 4th generation blockchain cryptocurrencies as best as I could.

Like many others, I call them Gen4 but there is still debate if this is still 3rd blockchain generation or already fourth. Or even if there are generations of the blockchain at all?

In the crypto world, everything is constantly evolving, sometimes so fast that we don't add up with how to call or name it.

English is not my first language and when I translate crypto related text to Polish I have many times to figure out how to call things properly because such words even don't exist in our language and there are no professional translations available yet.

Many times we have just to agree on something and I think this is the case with how or if to call different blockchains as different generations or something else.

There are differences between blockchains for sure.

there is no such (credible) debate

Additionally, there's no clear indicator/feature to classify blockchain generation which proves "blockchain generation" only a buzzword.

From what i've seen, most generation discussion only focus fancy features or output/throughput (such as high TX/s), not efficiency, decentralization, security or immutability.

And what makes the debate especially about cryptocurrencies or blockchain credible?

I agree with you that this is a buzz word but shall I don't use it because of that?

Like I said:

I made a few adjustments to this topic. I removed some information regarding wallets which need to be constantly updated. By the end of the month, I will publish a new thread about Lightning Network wallets.


I have already explained in other threads that LND has introduced support for altruist watchtowers which don't take a cut if one party attempts to cheat. More features and varieties of watchtowers will be available in future updates.


And it looks like there won't be anytime soon. Each implementation has its own backup solution. Eclair Mobile allows user to back up their channel state to Google Drive while LND and Eclair (desktop) support data loss protection (https://medium.com/@ACINQ/adding-data-loss-protection-to-eclair-598c62494096) and manual backups.

Yes, like that.
But unlike Altcoin mining, your GPUs won't be running at full load, so just consider the regular power consumption of your rig.

BTW, next time, check the date of the topic that you're replying.
But this one IMO might be needing a bump.

it may never submit your node hardware to the load that mining does, but for a node routing 100-10,000 payments per day, I dunno, maybe the w/h might start to become significant. Difficult to judge at this stage, as there clearly aren't enough payments over Lightning to expect that kind of load, but in time that kind of routing volume will be possible. We also don't know how efficient routing algorithms will become, or exactly how the network will stratify along the lines of routing v.s. non-routing nodes (the need for the "trampoline node" concept implies this will happen to some extent)

I have reviewed and updated the first post. I got rid of outdated information and made the explanations easier to understand. Feel free to suggest what other information should be included in this thread. I think there might be too little information in the "Creating a payment channel" section, but I can't come up with any idea. The old version of this thread is available here (https://archive.is/mJRRq).

Hi everyone,
I may have an idea that could significantly improve the lightning network if it works. I'd like to share it with you.

The proposed improvements are:
-Anyone could connect to several nodes on the same payment channel then go offline without disrupting the channel.
-We would only need the public key of the people we want to connect with to start a channel with them.
-The LN users would be able to make instant withdrawals with the cooperation of their peers.

For now let's call it the multidirectional payment channel. I didn't introduce any line of code which I will be working on asap but you can understand the logical pretty easily.

Channel opening: One of the participants opens the channel by transferring any amount of coins to a new multi-signature wallet. For security reasons the creator of the wallet (or the main user) must set a limit on the withdrawal fees (this restriction can be overruled with the signature of all the participants).
Deposits/withdrawals: Only the creator of the wallet can fund the channel but any participant can withdraw their coins. The withdrawals can be validated by one participant or by all the participants (the funds will be temporarily frozen unless the transaction is signed by everyone).
Payments: To make a transaction the payer must sign a payment to the payee then have it signed by all the other participants (they will actually sign their new balance on the channel). The main user does not have to validate the payments of the other users (so he  can go offline and it will not affect anyone).
Security: All the channel participants must protect themselves against fraud by verifying the payments that are made from their wallet. Any user can invalidate a fraudulent transaction with a penalty transaction and prevent the cheater from withdrawing more funds. A transaction can no longer be invalidated after the funds are unfrozen.


DISPUTE RESOLUTION CLAUSE

The case can be resolved at any of these steps (a delay for reply has to be determined):

1-User 1 makes a withdrawal.
2-Any user posts a penalty transaction to invalidate User 1’s withdrawal.
3-User 1 sends the latest lightning payment that was signed to him to prove that he has enough funds for his withdrawal.
4-Any user posts a more recent payment signed by User 1 to invalidate his proof.

A few important things to mention..
1.The creator of the wallet basically signs the total balance of the other users when he makes a payment and the other users sign their own total balance when they send him a payment. Therefore he doesn’t need to know the balance of each participant as he can invalidate a withdrawal by simply proving that the user who is making it is spending his coins (on the opposite side the other participants can invalidate his withdrawals by proving that he’s trying to spend their coins).  
2.The public key of any cheater will be removed from the channel (the coins on his channel will be transferred to a new wallet where his key is removed).
3.A withdrawal does not close the channel (the user who makes it must return the amount he owes to the other users).
4.A penalty transaction does not need to include any proof against the targeted user if he is not the main user (that is simply because there could be no proof if the targeted user has never made a payment).

The concept seems to work in theory but I don't know if it is feasible in practical.. maybe someone more knowledgeable can answer that:o. Thank you all for paying attention and hopefully we can do something with this! ;D

@Rath_ Hey, I'd like to have Phoenix (https://phoenix.acinq.co/) and Breez (https://breez.technology/) added to the iOS Clients list!

I tested both for months and still use both regularly for transactions and onboarding new users!
I prefer to onboard with Phoenix, since it recently finally launched on the official AppStore (https://apps.apple.com/us/app/phoenix-wallet/id1544097028), where everyone can download it.

Instead, Breez has more functionality, like sending to on-chain addresses (submarine swapping outwards) and shows all lnd functions in a  'developer menu' so you can manually fix stuff if things go south. However, it's not yet on the AppStore, but still available for everyone through the TestFlight Beta (https://testflight.apple.com/join/wPju2Du7). It's still a slight hurdle for non-tech savvy users, so to those I always recommend Phoenix.

The development of Lightning excites me more than its implementation. Does anyone know when lightning was bipped into the bitcoin network? Was it hard forked or is it a different layer as layer 2 scalability suggests? Either way I can likely find more material surfing the web  thanks  8)

It was never bipped, some people believe that it should be, maybe it will be in the future, but for now it is not.
No, implementing LN was possible after Segwit (which was a soft fork), because signatures were detached from calculating transaction hash.
It is some kind of second layer, but it still has many dependencies on the first layer, for example introducing every user to the second layer needs on-chain transaction (for now).

The reason why it's not a BIP is that it's not a change to Bitcoin whatsoever. It just utilizes and relies on the Bitcoin network, of course.
https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals (https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals)

I would like to clarify this a little: it doesn't just "still" have some "dependencies" on first layer and "for now" - Lightning channels are created through normal Bitcoin transactions (hence no BIP needed) and the security of your funds lies in the fact that you can at any time close the channel (through another Bitcoin transaction) to transfer them to your Bitcoin address. It is thus highly interconnected with the Bitcoin blockchain and completely relying on it. It would simply not work without the first layer that is Bitcoin. This is the core foundation of Lightning, so I don't see how it will ever change (opposed to the 'still' and 'for now' additions in @garlonicon's reply) without fundamentally changing what Lightning Network is.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018858.html

There are other second layers where they are connected with the first layer, but where introducing new people does not require creating on-chain transaction. Now, you cannot receive LN coins if you don't have any LN channel, you need on-chain transaction for that. Maybe things like Pedersen Commitments could solve that issues in the future, because I can imagine a network where there are on-chain transactions moving coins from and into some second layer, but where everything else can happen directly inside that second layer. Also, as far as I know, in Litecoin Mimble Wimble Extension Blocks will be made in that way: only sending between new and old addresses will need mainchain transaction, everything else will happen inside Extension Blocks, so maybe in LN it will be also possible in the future. Also, Paul Sztorc's Thunder Network will allow introducing new people to the second layer directly: https://www.truthcoin.info/blog/thunder/. Technically speaking, it is possible for other second layers, so it may be also possible for LN.

Right, but still that 2nd layer is always relying and depending on the first layer, otherwise what kind of "2nd" layer is that? ;)

i guess the point of garlonicon was not that the 2nd layer doesn't depend on the 1st layer, but that the onboarding of new users will be possible without touching the 1st layer directly (still depending on it)

Oh yes, I guess that can be technically implemented.
But I wanted to clarify, through all of his "still relies", "some dependencies", "for now" etc. that LN very much depends and forever will be based and secured by, L1. Even if you might be able to onboard users without a new Bitcoin transaction every time.

This goes a bit into another topic, but this is a general LN thread so I guess it's fine: In my personal opinion, we should be good with the current setup for years to come. With SegWit and long-living LN channels, it shouldn't be needed to create channels without BTC transaction, even if millions of people join Bitcoin. One transaction per person (and everything after that mostly via LN) should easily be handled by the Blockchain as long as they don't all join at once ;)