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

There can be an cyber attack if the if the payment channel become crowded and thus participants might not be able to get back their money. These bugs needed to be solved.

Just saw this pop up: https://blockstream.com/2021/07/21/nl-greenlight-by-blockstream-lightning-made-easy/
So they are now beginning to push out their hosted "node in a box" solution.
Don't know how much traction it's going to get but it's another way for people to use lightning so unless it's total garbage I see it as a good thing.
If I have a free moment I'll look at it over the weekend. If someone else gets to do it earlier that would be good to

-Dave

Since the payments can be split across multiple channels, I wouldn't be surprised if a single payment exhausted your liquidity in all three channels at once. I would open more than just one channel to the same node if the funds in my existing channel would be often moved the other side despite high fees. That's the only workaround until splicing-in becomes available.


You could save a ton of money on the fees by opening multiple channels in a single transaction.

@Timelord2067: many different small channels makes it much more work to balance all of them. Even worse: opening that many channels probably costs more in fees than making only on-chain transactions.

"If someone gifted me BTC 10.0 (   ) I probably would open a thousand channels with BTC 0.001 capacity."  ( It'd probably be more likely BTC 0.0011 per channel to enable 0.001 to be sent in one piece - per channel and the other 0.0001 to cover opening/closing fees...)


Basically, I'd be looking at cornering a portion of the low end $1 - ~$30 transactions - I'd cover all gaming sites, low cash payment sites such as coffee or snack foods and would tap into nodes with about 20 - 50 open channels.  Let even smaller operators with less than twenty channels connect to those smaller nodes then my BTC 10.0 block would be like a cross-city expressway.

---

---

Just as a thought bubble question - would having two or three 0.001 channels to the one larger node be better or hinder itself Vs one larger 0.003, 0.004, 0.005 channel?  (to my thinking two channels out of three could be unbalanced while one is still freed up for more traffic)

By the time that happens, splicing-out will have been already implemented. It will allow them to remove some coins from that channel without closing it.


In my opinion, 0.001 BTC per channel is too little. You would quickly run into liquidity problems and most of your channels would be unbalanced. Still, that's a better strategy than none! It might actually work to some extent.


It's a channel between ACINQ and OpenNode.com


Your connectivity is far more important if you want to route a higher volume of transactions. I have a fairly large channel to Bitfinex (0.05 BTC) and a small one to Nicehash (0.01 BTC). Apparently, I am providing the shortest and the cheapest route for both directions as my Nicehash channel keeps being exhausted all the time at either of the sides. My Bitfinex channel remains balanced since it's much bigger.


Payments can be split into many small chunks and sent through different routes. See Atomic Multi-Path Payments.

If you have at least two channels with a lot of capacity, you potentially can charge higher fees because some transactions would need to be routed through your node, and you would potentially have a higher volume of transactions route via your node for similar reasons.

To my knowledge, it is not possible to route a portion of a payment through a channel. So if you have channels with BTC 0.001 of capacity on each side, you would be unable to handle any transactions above this amount.

It goes without saying if bitcoin were to become worth $1M, or even $100k, then it might be very tempting to cash that amount out and install a much small amount in its place.

With BTC 10 I'd probably go the other way and open 1,000 channels worth BTC 0.001 each.  That would enable me to  have a much wider spread of nodes / regional access than just sending coins backwards and forwards to just one other node.

Which node do they connect to?

thanks, i am reading the whole thread right now (over the next few days probably  )

i just saw, that some days ago acinq and opennode opened the biggest channel until today with 10 btc capacity

We discussed it in this topic. Check out this post first and then take a look at the 39th page. As for the subforum, there is nothing we can do beside waiting and talking about Lightning as usual.

you are probably right, i think i got carried away with the new "hip" thing to do on lightning... 

@Rath: did you ever write in the forum about the topic lnd vs c-lightning and why you made the switch from one to the other? might be interesting for others (it was for me) - we need that lightning network subforum. can i do anything to make that happen?

I'm not even sure if triangles are actually good for the network. It's like we are isolating all other peers in the network out of our tiny triangle. I think it's better to try to open channels to anyone that is not connected to any of our peers, exactly to avoid triangles and loops between just a couple of users.
I think this is like if we stitch together 2 arms of an octopus. If we do that, then we have 2 less arms to grab another octopus 2 arms.

Your example looks like this: Alice 0.1 BTC <---> Bob 0 BTC, Bob 0 BTC <---> Charlie 0.1 BTC

Alice has a direct channel with Bob and so does Charlie. Alice and Charlie are connected indirectly through Bob. Oh, and you have to specify how many coins Bob has on his side of the channel with Charlie. If he has less than 0.02 BTC then he can't route Alice's payment.


A commitment transaction can have up to four different types of outputs: local balance, remote balance, offered HTLCs and received HTLCs. The last two cannot be added to or subtracted from either side's balance because otherwise it would not be possible to enforce the condition which I mentioned in my previous post.

What's more, each party has a different commitment transaction reflecting the same state of the channel because one party offers an HTLC and the other receives it. Also, the asymmetry enables penalties if an old state of the channel is broadcast.

HTLC outputs in commitment transactions actually include an absolute timelock (a specific blockheight) as well as a relative timelock. I won't explain it right now. It would probably confuse you even more.


Bob forwards Alice's payment (HTLC) to Charlie. Bob needs to make sure that he will get his money back if Charlie does not reveal the payment pre-image. Alice also signs a new commitment transaction with Bob for the same reason.


It's because of the relative timelock. You can't reliably tell when a transaction enters the mempool. If you used an absolute timelock, you would have to update the commitment transaction every time a new block is mined. Instead, a relative timelock is included in the output of the commitment transaction which reflects your balance in the channel. It can be spent either using your private key after the timelock has expired or immediately using yours and other party's revocation key for that particular transaction. You need the second transaction to move those coins to your wallet.

How would a direct channel be like? I take the example of using the same node (Bob) to simplify. Isn't that a direct channel?

A new output? Doesn't it update the balance of the initial commitment transaction?

For allowing Alice to make the commitment transaction? Could you explain why Bob would need that?

I may haven't understood the entire post, but what I did got is that the “locktime” of the closing transaction takes place once it's mined. I'd really want to have an explanation of the reason in which two on-chain transactions are required instead of one.

Alice does not have a direct channel to Charlie, so she can't sign a commitment transaction with him. She can't directly send Charlie any coins through a commitment transaction signed with Bob.

Alice signs a new commitment transaction with Bob which includes a new output. That output has a specific condition: it can be claimed within X blocks only using the payment pre-image. After X blocks, it can be spent only by Alice. Bob also needs to sign a similar commitment transaction with Charlie.


No, they can't. I explained uncooperative channel close in detail in this post. Please, read it and let me know if it helped clear your doubts. It should answer all of your questions. I can try to explain it in a different way if it doesn't help.

Help me understand, I probably messed some things up in my mind (again).

Alright, let's assume that Alice and Charlie deposit 0.1 BTC on Bob. Before they broadcast anything, they already have Bob's signature so that if Bob disappears/loses his key, they can get their money back. Charlie generates a random number and gives its hash to Alice. Alice says to Bob that in order to finalize (sign from her side) the transaction, she has to receive the pre-image. Thus, Bob essentially gets the pre-image from Charlie and gives it to Alice.

Now, Alice can sign a commitment transaction saying that she gives 0.02 BTC to Charlie, but she also adds that the output can be spent after 144 blocks and they add this limit so that if one broadcasted an old channel state, the other person could send a penalty transaction. Once they both agree for the channel's closure, they can also agree not to wait so many blocks.

Am I right 'til here? If yes:
- Aren't they setting the block limit given a block height? For example [current_block_height + 144] just like in locktime. If yes, can't they cheat each other once 144 blocks have passed since the commitment transaction?
- Is it the same for Alice whether Bob or Charlie are offline? If the lightning node is offline, then they can't transact and if Charlie is offline, she also can't move her funds. I exclude the uncooperative way.
- How would the penalty transaction “rescue” you? Isn't it a commitment one? Shouldn't you also wait for 144 blocks?
- Aren't non-yet-spendable transactions valid? For example, if Alice broadcasted an old channel state wouldn't see get her transaction confirmed? Wouldn't that make the penalty non-valid? Even if she can't spend her funds in the next blocks.

I'd suggest not using these pre-configured LN node linux images for the same reason as I'd give for not using these Android/iOS lightning wallets: what's in the black box, fellas?


this is money. your money.

if you trust someone else to give you clean software, you're literally begging to get yourself mugged by an internet mugger


I find it more than a little suspicious how much wallet and node software is being pushed so hard at people with the level of computing skill that ends when they push the On button of their Playstation/XBox

you're gonna get robbed with that kind of thinking, and you will thoroughly deserve it

I remember a few years ago I tried to run pruned LN node with c-lightning and spruned, but it didn't go well.

As far as I can recall, I have funded the address from lightningd, but haven't opened a channel. Upon inspecting the old file, I'm able to retrieve the hsm_secret file.
According to the doc, I should be able to get my BTC back right? since it still on the onchain(?).

Also, I notice that the funds on the lightningd address, have been moved. I guess it is just how the way c-lightning works right?

I had a 4 GB Raspberry Pi 4 and a full Bitcoin node + LND worked perfectly fine. I installed both of them on my own, though. ElectrumX had been taking way too much time to build its database, so I eventually built a small home server and sold the Pi. Someone keeps mentioning that a used NUC might be a better idea.

Oh and most, if not all, Lightning-in-a-box projects for Raspberry Pi come only with LND.


You should be able to install everything on your own without any problems. There's plenty of good tutorials and the documentation for both LND and c-lightning is quite good. Also, Raspberry Pi 4 gets really hot for some reason. I had a metal case and a heatsink with a small fan on the CPU and it was still running too hot.

I think I'm just going to buy a Raspberry Pi 4 and install mynodebtc to it. Has anyone done this? I already have a 1 TB external disk and I believe that it's a cheap way to run both a full and a lightning node.

I have never bought a Raspberry Pi and I want you to tell me if it'll be a very tiring procedure.