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

So - I used this Code to run your command on my Umbrel Node:
(sat_per_vbyte did not seem to exist as parameter)

It gave me this: [lncli] rpc error: code = Unknown desc = peer disconnected

LND Log:


 

I don't know if this was already asked (probably), buuut:

Are my LN Wallet & Channels on my Node connected to my btc wallet?

I'm asking because I was wondering what a User should do if his private Key
is leaked or compromised in any way to use an alternate BTC wallet on an
Umbrel Node. For it being a hot wallet it would be plausible to switch it out
once in a while, or am I beeing to paranoid?

Maybe it's just a UI thing and LN is capabale of this, but Umbrel isn't?

In short: My attempt would be to transfer the leftover UTXO's to a new
Private Key / BTC Wallet, but use the old LN Wallet & Channels for it.

I checked my logs and I kept getting the following error.


Since your node was out of sync, it could not verify if the funding transaction had been confirmed while my node kept sending "funding_locked" message. Everything looks good now. It could also be the reason why you were not able to open a channel to me. You should keep your Bitcoin node synced at all times. If someone broadcasts an outdated commitment transaction, you have limited time to publish a penalty transaction.


Take your time and don't worry about it. I will be fine even if you don't open a channel back to me.

SSH keeps saying I entered the wrong password   ... thats why I use GUI at the moment.
"peer disconnected" Is what I get as Error. I already restarted my Node.

My btc core seemed to be out of sync for about 11 Hours. I'm at 100% by now again.
Could this be a problem? Running Umbrel btw. I'll try it later again, promised! Don't close your channel

Try restarting RTL. I have never had any problems with it, but I am running c-lightning as the backend. Why don't you try to open the channel using the command line? Here's the right command along with all parameters.

Hi,

"You have exceeded the limit of 2 personal messages per day. Buying a Copper membership may increase your limit."

...so I'll write here. I'm trying to open a Channel to your Node right now with 70k Sats. RTL did load indefinitely.
I get a "502 Bad Gateway"-Error. I'll try it again, maybe it's just a small hick-up? Never had this problem, but I
did not open too many channels by now
 

Since all the signing is done on user's device, such node will probably not able to route payments. The only advantage over some mobile wallet I can think of is ability to use advanced features like: dual-funding, multifund, keysend payments.

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.