The Lightning Network FAQ

[JayJuanGee]

LN & Liquid may use segwit / locking features of bitcoin program code, but their own code development is separate ,
therefore, I have no choice but to consider them 3rd party.

If people abandoned Core Wallets in favour of other forms of wallets for their bitcoins (such as gee, I dunno... a Lightning Wallet for example) then would that mean consensus has been reached and the LN is actually how bitcoin evolved?

Core is not the only type of bitcoin wallet out there.

I am not sure if this Timelord response post can be used as an example.  

The original question raised by OGNasty seems to have been whether posts/threads related to LN should be in the bitcoin section or maybe they should be in the altcoin section (which has already been responded to).  

Regarding the evolution of LN, merely because lighting network wallets interact with bitcoin would not cause them to become bitcoin, even if they may be evolving into something more and more intertwined into bitcoin... but surely, from a user's perspective, they might NOT be able to tell whether they are using lightning or bitcoin, and they might not give any shits about what they are using, as long as from their perspective, the service works to transfer value and does not steal/lose any of their money along the way.

[Timelord2067]

...

I also received a glib PM (which was probably sent out to a few more users than just us two I would imagine.  My response was intended to be fairly glib and lo and behold!  I got a glib reply.

I just had a look for the thread asking for a LN sub forum to be created, but I just can't find it at the moment.  It would save the hassle of responding to dense questions for people who have no intentions of using the Lightning Network at all.

[Rath_]

I just had a look for the thread asking for a LN sub forum to be created, but I just can't find it at the moment.  It would save the hassle of responding to dense questions for people who have no intentions of using the Lightning Network at all.

As far as I remember, at least three such threads were created. This one is the latest one.

The average person is unlikely to engage with Liquid directly.  It seems to be oriented more towards businesses.

That's what I initially wanted to mention in my post earlier today. Most of the documentation determines Liquid Network as a solution targeted at the trading market rather than individual users.

[gmaxwell]

Why isn't this thread in the altcoin section?  Can anyone make a shitcoin fork and tie it to Bitcoin's blockchain and be able to post wherever they want on the forum or is this something reserved only for the Core development team?

What the heck?  There are several reports for your post for offtopic/trolling and I'm inclined to agree.  But in the off chance that you are actually just profoundly ignorant:

Lightning is just a technique of using Bitcoin smart contracts to compress multiple Bitcoin transactions into one transaction.   After some setup, I can make a payment to you but not immediately post it to the blockchain, keeping it available to be revised as funds move back and forth. At any time either one of us can post the latest transaction to close it it. Moreover, it's possible to securely and atomically update multiple of these not-yet-final transactions, which makes it possible to pay someone you don't directly have a channel with by updating the balances of a collection of channels.

That's it-- the rest is just implementation.

Through this we can make thousands of payments but only post two transactions to the chain, and as a side benefit these benefits enjoy instant reversibility and improved privacy because they only require the interaction of the participants rather than the global network.  The tradeoff is that the participants need to be online and the underlying wallet software required more engineering effort.

Payment channel support has been built into the transaction format and consensus rules of Bitcoin since day one.  The only transactions involved in lightning are Bitcoin transactions, so it has nothing to do with altcoins.  Your post is extremely similar to saying that posts involving multisig ought to belong in an altcoin subforum.    Guess what: Not everyone uses bitcoin exactly like you do.

Lightning doesn't have anything to do with Bitcoin core,  ... at least today there is no lightning support in Bitcoin Core.  If this subforum were only about Bitcoin core, then I suppose there wouldn't be any lightning stuff in it... but it isn't.

The fact that lightning has its own complexity means that there are plenty of technical things to discuss about it.

[Rath_]

If you are deleting my reply, then you should delete JayJuanGee also.
Unless you and him are working together.

I am not going to tolerate any direct insults in this topic. That's why I deleted your reply. Most of the replies that I have deleted so far were some copy/paste garbage or advertisements. I don't mind having some off-topic conversation here since everyone treats this topic as a place to post any Lightning related content rather than suggestions of changes to the first post. As long as it doesn't turn out to be another "Is Lightning good or bad" discussion for more than 2 pages with arguments that already have been addressed then I am fine with anything. Feel free to respond to my reply in some other thread if you have any further comments.

Edit: If anyone is curious, we have managed to sort everything out via PM.

[PrimeNumber7]

I think there are only two situations when some trust is involved. The first one is when you have milisatoshis and you really care about them. As long as the channel is open, you can spend them. The other one is when your node goes offline for some reason which means that the other party can broadcast an old commitment transaction. You can freely set the amount of time which the other party must wait before the transaction can be included in a block after it was broadcast. Most nodes will accept timelocks up to 2046 blocks (~2 weeks), so it shouldn't be really a problem. I could mention watchtowers here, but they are obviously a third-party.

I would add a situation to your list. If your channel at one point had inbound capacity, and you currently have zero, or very little inbound capacity. The cost of a peer to attempt to get an old channel state confirmed is zero. In some cases, the cost to broadcast the "penalty" transaction may be higher than the amount being stolen from your channel, if transaction fees are persistently high.

You could also set up watchtowers that are controlled by you but are separate from your LN node.

[DaveF]

...
Anyway, did anyone noticed that number of active Bitcoin Lightning Nodes jumped over 10,400 and that is almost double than in same time last year, and I think it's just getting started.
...

Wonder how many of them are people who did it from scratch and how many used one of the "lightning in a box" implementations.

Not that it matters that much, but all the pre-done ones that I know of are running LND so over time C-lightning could wind up being a much smaller player.
I like the C-lightning plugins idea, but LND seems to be more widely used.

-Dave

[NotATether]

Besides, there are many thread which mainly not about Bitcoin, but still on "Development & Technical Discussion" board. Some examples from current first page,

• How to create your own Cryptocurrency?
• Ways to accelerate 256-bit arithmetic with 64-bit ops?
• Is there secp25k1 for the cuda api on C ++?
• Playing cards with ECDSA and HD wallets
• How many of you check the code of open source software?
• PSA: Coders making ad hoc “random” schemes are like kids playing with matches.

I'd argue that the majority of those topics are more about "development" (except for this first one) and fall under this boards scope.

Liquid Network cannot work without third-party. You can exchange BTC to L-BTC on your own, but you won't be able to convert it back without Liquid Federation member's help. Liquid Network transactions are not instantaneous. Every minute, a new block is generated by one of the Functionaries and signed by the majority of other Functionaries. Functionaries are selected among the members of the Liquid Federation.

This is probably the single biggest reason why we're not seeing more Liquid transactions, more than the fact (idea?) that Liquid Federation is a closed membership entity. And L-BTC is something that can be positively called an altcoin.

lightning is not a feature of bitcoin. its a separate network from bitcoin. its a network that is compatible to multiple altcoins.

*Provided that you design the HLTCs for the altcoin in question yourself

LN is officially just a bunch of HLTCs, which itself is just a bunch of scripts - the rest of the parts like routing were never standardized in a white paper and are just different peoples' implementation AFAIK - so its hard to make a claim of it being an entire network.

[Rath_]

The above principles are important if LN is going to be successful. LN wallet software needs to have a good mechanism for not losing the latest channel state, and associated transactions if it will be successful.

I would like to point out a very important thing for node operators. In this post, I talked about what could possibly happen if you lost your channel database and decided to use a Static Channel Backup (SCB). Long story short, you should close channels which are offline for extended periods of time. Otherwise, you might not be able to get your coins back if your node's hardware ever failed.

Not that it matters that much, but all the pre-done ones that I know of are running LND so over time C-lightning could wind up being a much smaller player.
I like the C-lightning plugins idea, but LND seems to be more widely used.

I originally planned to use c-lightning, but I really liked how well LND integrates with Zap. I can easily spend coins from my node and open new channels without using a command line. Spark Wallet supports c-lightning, but it looks less appealing to me. I have used both LND and c-lightning before and I had a very similar (good) experience.

[DaveF]

The above principles are important if LN is going to be successful. LN wallet software needs to have a good mechanism for not losing the latest channel state, and associated transactions if it will be successful.

I would like to point out a very important thing for node operators. In this post, I talked about what could possibly happen if you lost your channel database and decided to use a Static Channel Backup (SCB). Long story short, you should close channels which are offline for extended periods of time. Otherwise, you might not be able to get your coins back if your node's hardware ever failed.

I looked a while ago, but did not find any of the "nodes in a box" that did automated offside backup.
Have to check again. They might have added it, but since I am doing regular VM replications it's not up there on my list of things to check.
But for those people who are using physical ones it would probably be very useful.

-Dave

[Rath_]

They might have added it, but since I am doing regular VM replications it's not up there on my list of things to check.

Aren't you worried that your VM backup might not reflect the latest state of some channel? Keep in mind that channels are updated not only when you send/receive transactions but also when you route payments.

By the way, the fee of the latest commitment transaction is periodically updated. I have two channels which have never been used. The first one was updated 19 times and the other one 31 times. I am not sure what would happen if I launched my node with an old backup of my channel database. Would a different fee be enough to trigger an uncooperative channel close?

[DaveF]

They might have added it, but since I am doing regular VM replications it's not up there on my list of things to check.

Aren't you worried that your VM backup might not reflect the latest state of some channel? Keep in mind that channels are updated not only when you send/receive transactions but also when you route payments.

By the way, the fee of the latest commitment transaction is periodically updated. I have two channels which have never been used. The first one was updated 19 times and the other one 31 times. I am not sure what would happen if I launched my node with an old backup of my channel database. Would a different fee be enough to trigger an uncooperative channel close?

Yes, but since it's triggered hourly it's not THAT big a risk.

I actually just did another look around ant people have written / added some auto backup functionality to some of them. But nothing that I found is a nice neat auto backup with a pretty front end which is what I think a lot of people who are using nodes in a box want. Click this box, add this info, and poof you channel info is backed up every time there is a change.

-Dave

[Karartma1]

https://starblocks.acinq.co/
Just found this awesome live shop free to use to have a first hand experience of the Lightning Network (testnet). I showed it to a few friends (skeptical about Bitcoin in general and LN in particular) and they were gobsmacked at the end.
Could it make sense to add it to OP for those who want to test it without getting hurt?

[Wind_FURY]

https://starblocks.acinq.co/
Just found this awesome live shop free to use to have a first hand experience of the Lightning Network (testnet). I showed it to a few friends (skeptical about Bitcoin in general and LN in particular) and they were gobsmacked at the end.
Could it make sense to add it to OP for those who want to test it without getting hurt?

That strengthens in my belief that Lightning Network adoption is more of a UI/UX, and a business development problem, than a tech problem. I believe Lightning Labs should hire a good consultant, and start talking to exchanges to actually start using Lightning.

[Karartma1]

https://starblocks.acinq.co/
Just found this awesome live shop free to use to have a first hand experience of the Lightning Network (testnet). I showed it to a few friends (skeptical about Bitcoin in general and LN in particular) and they were gobsmacked at the end.
Could it make sense to add it to OP for those who want to test it without getting hurt?

The website is still alive? I remember few years ago where i used it as part of testing LN and was popular to trying LN.

But since OP don't mention how to use/try LN, maybe it's better to mention it on different LN thread.

I wouldn't know where that could be done honestly, there are countless threads on LN and no one seems to fit. And I don't want to open then next Lightning Network thread on that also.
I think it's a great way to show the overall LN experience even if it's only on testnet.
Maybe the post will get indexed and those who are interested will find it.

[Wind_FURY]

Lightning service idea. After Taproot is activated, what about a tumbler/mixer built, and developed for the Lightning Network. You can’t force coffee drinkers to spend their Bitcoin, but you can make thouasands of Heroine dealers move their Bitcoin through a Lightning tumber. Can be more efficient through Lightning, or just making it more complicated?

[LoyceV]

Might be difficult/not practical, because
1. Since LN require you to connect to another node (which mean both party know each other IP), the usage of Tor/VPN will be important. It means you need to use system-wide VPN or LN wallet which support Tor.
~
3. Depending on how it works, you need specific LN wallet.

In a way, a custodial LN wallet is a mixer already. The only thing they'd have to add, is deleting all records after a transaction was made.
For a wallet that's not very practical, but if you're willing to trust a third party to mix funds, you can just as well use a wallet that does everything for you.

[PrimeNumber7]

Lightning service idea. After Taproot is activated, what about a tumbler/mixer built, and developed for the Lightning Network. You can’t force coffee drinkers to spend their Bitcoin, but you can make thouasands of Heroine dealers move their Bitcoin through a Lightning tumber. Can be more efficient through Lightning, or just making it more complicated?

I don't think taproot is needed for this.

In order to mix your coin, you will need two channels, one with outbound capacity, and one with inbound capacity in the same amount. Once you have the two channels open, you simply make a LN payment from one node to the other. You can increase your privacy by sending multiple payments from one node to the other over time. Privacy will also be increased as more users use the LN network for more transactions. Privacy can be increased by having both nodes have multiple channels open, by not transferring the entire balance in the channel, and by waiting an amount of time before closing the channels.

[Timelord2067]

In a way, a custodial LN wallet is a mixer already. The only thing they'd have to add, is deleting all records after a transaction was made.
For a wallet that's not very practical, but if you're willing to trust a third party to mix funds, you can just as well use a wallet that does everything for you.

I'm pretty sure that's a part of the point Frankie was trying to make a week or two ago and got shouted down for their efforts.

[Rath_]

I wouldn't know where that could be done honestly, there are countless threads on LN and no one seems to fit. And I don't want to open then next Lightning Network thread on that also. [...] Maybe the post will get indexed and those who are interested will find it.

Thanks for your suggestion. I will probably overhaul this thread at some point. Still, I think that there are plenty of YouTube videos and Medium articles showing such basics. Although, I am not sure how up-to-date they are since I didn't look at any of them in a long time.

I don't think taproot is needed for this.

Sure, but with Taproot, no one will be able to tell if coins were locked up in a channel (unless that channel ends up being closed uncooperatively). That's a significant privacy enhancement.

I'm pretty sure that's a part of the point Frankie was trying to make a week or two ago and got shouted down for their efforts.

You can see his deleted posts here. He was mostly arguing about Lightning not being Bitcoin.