The Lightning Network FAQ

[Rath_]

Did That Mean The 1 Satoshi (Rounded Down Satoshi) Is Left Behind On The Multisig Wallet?

Firstly, you wouldn't be able to open such a small channel due to dust limit. Let's assume that numbers are much higher (5000.1 sat and 4999.9 sat). Leaving 1 satoshi would not make any sense (dust limit) so the only reasonable answer is that it would be added to the fee.

What If The Channel Opener [X] Had So Little Balance That Will Not Enough To Pay For Fee? Did [Y] Must Give [X] Some BTC So He Can Pay For The Closing Fee?

By default, the funder [X] is obligated to cover all fees. The fee rate is negotiated before funding a channel and it can be changed anytime if both parties agree. [Y] won't be obligated to cover the closing fee. If the fee is too low then the channel MAY fail. Last commitment transaction will be used in such case.

BTW I See That There's A Minimum Time Limit Before A Party Can Close A Channel(A Party Can't Close A Channel Before XX/XX/XXXX). Did That Achieved By Timelock or by The Lightning Protocol Itself?

I have never heard of such limitation. One should be able to close a channel even before the funding transaction gets confirmed.

[Rath_]

Watchtowers - they will be responsible for taking care of people attempting to cheat while the other party is offline.

This feature is now available in Lightning Labs' implementation of the Lightning network. Currently, only altruist watchtowers are available. What are they? This kind of watchtowers doesn't take a cut if one party attempts to cheat; all funds are returned to the victim. Reward watchtowers should be available in the next release.

[Wind_FURY]

I would like some of your reactions/replies. Someone from Bitrefill once said that Lightning is like an "organized - serialized mempool". Any opinions?

[yojoots]

I would like some of your reactions/replies. Someone from Bitrefill once said that Lightning is like an "organized - serialized mempool". Any opinions?

I don't think this is a very good description, personally. The only notable similarity between a Lightning Network payment and an vanilla Bitcoin transaction seen in a node's mempool is that neither one has yet been confirmed in a block. There are significant distinctions between the two, though. For instance, the Lightning payment can be immediately used in a subsequent transaction without waiting for a block confirmation to occur.

[Rath_]

There are significant distinctions between the two, though. For instance, the Lightning payment can be immediately used in a subsequent transaction without waiting for a block confirmation to occur.

Technically, merchants could accept 0-conf transactions which would be instant in such case but that would expose them to double-spending. Instead of believing users, they can set up a Lightning Network node and trust themselves.

[LoyceV]

Merchants transact in fiat,
Most immediately convert BTC to fiat upon receipt making sure they don't lose money on btc instability.
Lightning network is even worse as the time locks insure no quick fiat conversion.

Meaning if a Merchant does use LN, they do it thru a 3rd party service that offers almost instant fiat conversion.

That's basically the same as the current situation: most merchants use a payment processor to take care of the Bitcoin transaction, and get paid directly in fiat. I don't even think the merchant has to choose for LN, once his payment processor accepts it, it gets added just like some merchants accept many different altcoins.

[Wind_FURY]

I would like some of your reactions/replies. Someone from Bitrefill once said that Lightning is like an "organized - serialized mempool". Any opinions?

I don't think this is a very good description, personally. The only notable similarity between a Lightning Network payment and an vanilla Bitcoin transaction seen in a node's mempool is that neither one has yet been confirmed in a block. There are significant distinctions between the two, though. For instance, the Lightning payment can be immediately used in a subsequent transaction without waiting for a block confirmation to occur.

But the coins are not yet settled in the blockchain, but "suspended" in payment channels. In another way, calling it an organized-serialized mempool is correct. Or maybe a zero-conf payment network?

[bones261]

There are significant distinctions between the two, though. For instance, the Lightning payment can be immediately used in a subsequent transaction without waiting for a block confirmation to occur.

Technically, merchants could accept 0-conf transactions which would be instant in such case but that would expose them to double-spending. Instead of believing users, they can set up a Lightning Network node and trust themselves.

Merchants transact in fiat,
Most immediately convert BTC to fiat upon receipt making sure they don't lose money on btc instability.
Lightning network is even worse as the time locks insure no quick fiat conversion.

Meaning if a Merchant does use LN, they do it thru a 3rd party service that offers almost instant fiat conversion.
Otherwise , a small $1000 variance lower in BTC verse fiat could have a devastating effects on their fiat profit margins.

Merchants want stability in price , odds are Libra become more popular than LN with merchants.

If LN is to make inroads with merchants theirs needs to be price stability added.
Find a way to do that, and you could increase merchant adoption.

Since Libra will be based on the blockchain, I would hope someone can integrate Libra in LN too. Also, the merchant can accept BTC and then do an atomic swap for Libra, Tether, or whatever "stablecoin" that they prefer.

[Rath_]

Or maybe a zero-conf payment network?

Sounds great but that's a false statement. I would rather stick to organized and serialized.

Since Libra will be based on the blockchain, I would hope someone can integrate Libra in LN too. Also, the merchant can accept BTC and then do an atomic swap for Libra, Tether, or whatever "stablecoin" that they prefer.

I haven't read much about Libra so I can't say if it's possible. Every Bitcoin fork with SegWit support can run the Lightning Network by making a few small changes in its code. It would be better if developers focused on improving the Lightning Network rather than wasting time on supporting another altcoin (assuming it was possible in this case).

[Carlton Banks]

hope someone can integrate Libra in LN

that's unlikely

[Wind_FURY]

hope someone can integrate Libra in LN

that's unlikely

Plus how can developers integrate something that will never launch?

Since Libra will be based on the blockchain, I would hope someone can integrate Libra in LN too. Also, the merchant can accept BTC and then do an atomic swap for Libra, Tether, or whatever "stablecoin" that they prefer.

Define "blockchain". Because I would say it's a database validated by $10 million dollar "honest" nodes. Hahaha.

[LoyceV]

Can I post Pollo Feed here? I've just had my daughter feed some chickens using the Lightning Network!
It's just 1000 satoshi ($0.10), and I love how someone made this just to use the Lightning Network! I found this site on Lightning Network Stores directory.

[Rath_]

BitMex Research published an interesting article in which they examine all possible Lightning Network channel closure scenarios.

-snip

I don't mind. I was thinking of re-creating the Lightning Network Discussion thread but it would have to be self-moderated. I don't want to be accussed of keeping the discussion biased.

[LoyceV]

I was thinking of re-creating the Lightning Network Discussion thread but it would have to be self-moderated. I don't want to be accussed of keeping the discussion biased.

If you set clear guidelines in the OP, that should be okay. I'd do it for you, but I don't feel like I know or understand enough of LN to host the thread.

[LoyceV]

I'm quite certain now: In Eclair, the amount of LN funds that I can send depends on the Bitcoin network fees! A few days ago, had almost no sending capacity left, and received 30000 sat, and could send just over 30000 sat.. The next day, my sending capacity was reduced to about 24000 sat. I'd say that makes a non-custodial wallet like BlueWallet a better choice for using LN with a small balance, as it doesn't reserve anything for closing-fees.

It also looks like the sending capacity in Eclair isn't that accurate: I can't send all at once, but I could send multiple smaller payments.

I don't blame LN, which is still experimental, but it's good to note these things

[Rath_]

Have the watch towers not yet activated to prevent this stealing of funds?

Watch towers have to be configured manually for each node on a separate machine. They have been recently introduced in the latest LND update so that's why they haven't been mentioned in the article.

It also looks like the sending capacity in Eclair isn't that accurate: I can't send all at once, but I could send multiple smaller payments.

Sending capacity = Current channel balance - total can receive - minimum channel reserve (that's how I would calculate it, but I am still missing something). Each time you send a transaction multiple routes are calculated and the most efficient one is chosen. Total possible amount to send differs for each destination node. The problem you described is a liquidity issue; it's not Eclair's fault.

[LoyceV]

Sending capacity = Current channel balance - total can receive - minimum channel reserve (that's how I would calculate it, but I am still missing something).

There minimum channel reserve is only 1%. That's probably enough for a channel with high balance, but for my experimental channel with only 1.x mBTC, it's too low. So (I think) the total sending capacity varies depending on the average Bitcoin fee around that time (and I think that's the part you were missing).

Each time you send a transaction multiple routes are calculated and the most efficient one is chosen. Total possible amount to send differs for each destination node. The problem you described is a liquidity issue; it's not Eclair's fault.

This makes sense I just couldn't imagine there's no route with enough capacity (it was just around 0.00003 BTC) from my channel (connected to a well-connected node) to the destination (which I assume to be well-connected too).

It's not a problem for an experimental system of course, so I assume this will be improved in future updates.

[Csmiami]

I seem to be having some trouble connecting Eclair to the network (to open a channel and run a node). I've followed the github installation guide, step by step; but for reasons unknown, every channel I try to create gets timed out/disconnected. Apart from that, I seem to not be finding any other channels (All channels tab is with a big 0).

I already had the core client fully updated; and that one seems to be working fine for the moment. The only "issue" I have noticed between some youtube tutorials I've seen; is that when creating the bitcoin.conf file on core and restarting; I didn't get any "You need to rebuild the database....) message

Hope you can give me a hand

[Rath_]

Apart from that, I seem to not be finding any other channels (All channels tab is with a big 0).

Have you tried disabling Windows Firewall and Windows Defender (or any other AV software)? If this doesn't work then there is something wrong with your router settings. How many connections does your Bitcoin Core have?

The only "issue" I have noticed between some youtube tutorials I've seen; is that when creating the bitcoin.conf file on core and restarting; I didn't get any "You need to rebuild the database....) message

It seems that you have already set the txindex to 1. Instead of setting it in the config file, try adding it as a launch parameter.

[Wind_FURY]

I found two Lightning Network software reviews on Twitter for C-Lightning, and Eclair.

https://twitter.com/leonjohnson/status/1154093500515987456

https://twitter.com/leonjohnson/status/1154422184921767936

The reviews were made a developer, giving us a perspective on software fiddling. Haha.