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?
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 new output? Doesn't it update the balance of the initial commitment transaction?
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. For allowing Alice to make the commitment transaction? Could you explain why Bob would need that?
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. 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.
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. |
|
|
|
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.
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. 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?
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. |
|
|
|
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 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. I have never bought a Raspberry Pi and I want you to tell me if it'll be a very tiring procedure.
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'm not sure we'll start out with sufficient funds to do that for each user.
You don't need to open a channel to every single user. You could open a single large channel to some medium/large sized node which could take care of payment routing for a small fee. When some node routes a payment, it receives coins in one channel and uses some other channel to send the same amount of coins (minus the fee).
You could even open a direct channel to BlueWallet node to make sure that there would not be any failed routings. In such a case, you would not have to pay any transaction fees for withdrawals made to BlueWallet. |
|
|
|
In all seriousness though, as much as mempool.space is great for newbies, casual users, or anyone looking for a quick and reasonable fee estimation, you cannot get as much information from its charts as you can from Jochen's.
It's very likely going to be improved in the next update. A new chart library is supposed to be implemented. |
|
|
|
LN contracts require a pre-payment, though, don't they? And a contract is between max two parties.
Yes, you need to lock up a certain amount of coins in a multi-signature address beforehand. Meaning an additional amount will always be tied up in open LN contracts.
You also need to worry about inbound/outbound liquidity. When you open a channel, all funds are on your side of the channel. Unless someone opens a channel to your node or you spend some coins over the Lightning Network, you won't be able to receive any payments. I know it's complicated. An average minecraft player would not bother to do all of that. That's why you could recommend BlueWallet to your players. This way, they would be instantly able to receive Lightning payments without any extra configuration. It's a custodial wallet, though. |
|
|
|
Correct. Furthermore, my understanding of the Lightning Network is that for channels with < 2 recipients (other than sender) the fee is actually bigger than if the main network was used.... didn't really read much into the technical side of the LN though.
I am not sure what you are trying to say here. A channel is maintained between only two people. A node can have multiple channels. When some node routes a payment, it receives coins in one channel and uses some other channel to send the same amount of coins (minus the fee). If there was only one node which could route a payment from you to the player, it would not be necessarily more expensive than an on-chain transaction. The LN was designed for micro-payments, so you would end up paying a couple of satoshis or even less. The LN might work if the player requested multiple withdrawals without sending coins between each withdrawal to an address/recipient not on the LN.
In other words, the player can receive payments over the Lightning Network as long as they don't close their channel. |
|
|
|
Perhaps I should have been more specific with my terminology. My understanding was that a mutual close settlement transaction can have any fee you like, since you are negotiating it in real time with the other party, and so you would simply both agree on an appropriate fee. A forced closed settlement transaction will potentially have been signed well in advance, and so the fee is fixed at whatever you chose at the time, which may or may not still be an appropriate fee to pay. This is where anchor outputs come in, allowing you to set a low fee which you can later bump. Am I mistaken?
Sounds good! Sorry for nitpicking. I just wanted to make sure no one else gets confused. The negotiation part is very tricky, though. I still haven't figured out how not to overpay by a lot. I have recently closed a channel with a 60 sat/vbyte fee while 2 sat/vbyte was enough for a fast confirmation. Next time, I will try adjusting the negotiation strategy manually (by the way, such a feature is available only in c-lightning). |
|
|
|
[...] but yes, you can choose the fee your settlement transaction pays. The issue is that sometimes your settlement transaciton may have been signed days, weeks, or even months, before it is broadcast, so whatever fee you pick could end up being very inaccurate.
It sounds like you are confusing a commitment transaction with a mutual close. A mutual close involves only one transaction while commitment transaction needs two (see more detailed explanation). You cannot choose a fee for both of them. The fee is negotiated between you and the other party automatically (based on your feerate which you should constantly be updating). A new commitment transaction is signed whenever you or the other party adjust the feerate. I confirm this. I just paid lots for closing a lightning channel from electrum. Is there an option to change that (probably) hard coded value?
You cannot specify the fee of the closing transaction in Electrum. It probably relies on the estimates provided by the Electrum server you are connected to. By the way, I wrote a walkthrough for the Electrum implementation of the LN; you might have missed it. I can always run my own LN node, but I can't connect it to my BlueWallet. It'll take me some time to find another wallet so user-friendly as that.
Actually, you can! You need to be running LND and you need to install LNDHub, and then you can point BlueWallet to your node in the settings. While I was running LND before I had switched to c-lightning, I was using Zap Wallet. It integrates well with LND, but it was a real pain to set up. LND has a lot of fancy stuff, but it does not have as many "power user features" as c-lightning, which lacks those fancy things. [...] and they will use their own nodes to open a channel for you (it's possible that they don't even do that).
Here you can see all of their channels and their liquidity. They opened a few channels in advance. |
|
|
|
In the OP it says that LND supports neutrino, but I have no idea what is it
Neutrino is a Bitcoin light-client. Its GitHub page states that it still should not be used on the mainnet. Is there any tutorial that explains how I'll setup my LN node without running a Bitcoin node?
You need a Bitcoin node. Your Lightning Network node needs to constantly monitor the mempool and the blockchain. Otherwise, it would not be able to tell when it's safe to use a specific channel or if any of your peers is trying to cheat. It also needs to know what transaction fees look like at the moment so that a commitment transaction could be updated with a reasonable fee. You should be able to use a pruned node with c-lightning without any extra setup. Keep in mind the following. You can use a pruned node if you choose either c-lighting or LND. However, whichever you choose, you need to be careful about the discrepancy in the reported blockheight by your Bitcoin and Lightning nodes. If your Lightning node crashes for some reason and your Bitcoin node prunes a block which has not been processed yet by the other node then your Lightning node will get stuck. See the following links for more information ( #1, #2). |
|
|
|
One source of excessive fees might be closing of Lightning Network channels. It's all automatic. I just closed one and paid 30 s/b.
If you are using c-lightning then you can modify the negotiation strategy of your node and make it more aggressive. It's very likely that the other peer forced you to overpay. https://lightning.readthedocs.io/lightning-close.7.html#description - see [fee_negotiation_step] |
|
|
|
Can you update ledger live now on the windows app as oppose to going directly to their website? Still using the older ledger live at the moment because i didn't want to download the new ledger live a while back when they said it had to be done on the website.
No, you still have to download the updated version directly from the website. Apparently, Ledger was unable to sign the update so the built-in updater would not work. |
|
|
|
nice one - do you run by any chance behind tor and could try to connect to my node? lightning-cli connect 025b5150c66f3ea41367829f6e4639c772fe4c7939b71933802233493e6e972a8e
Yesterday, I asked darkv0rt3x to try connecting to your node and it worked. Another dual-funded channel here!  As you can all see, it's not that difficult. Who will be the third bitcointalk member to open a dual-funded channel with me?  If any of you were thinking about setting up a Lightning node, now might be the right time. Transaction fees have been extremely low for the past few days. |
|
|
|
Najnowsza aktualizacja c-lightning wprowadziła eksperymentalne wsparcie dual-funding, które umożliwia zasilenie kanału przez obu jego uczestników. Zamierzam przetestować tę funkcję z dwoma innymi członkami forum jakoś w przyszłym tygodniu. Jeżeli będzie ona działać bezproblemowo, to będzie to duży krok do przodu - balansowanie kanałów od razu po ich otwarciu jest po prostu męczące.
Z przyjemnością mogę Was poinformować, że wczoraj wraz z innym użytkownikiem forum udało mi się otworzyć kanał, który został zasilony jednocześnie przez nas dwoje. Wszystkie szczegóły opisałem w tym poście. |
|
|
|
3. entering two commands (now that i think about it, maybe the first command wouldn't be necessary if my node would be "older"/ better connected)
Just for clarify, the first command was lightning-cli connect and the other one lightning-cli fundchannel. You cannot fund a channel unless you manually connect to the person you want to open a channel with. By the way, if both peers support dual-funding, they can also use RBF to bump the fee of the opening transaction. but onrampsincomingliquiditycustodialwalletchannelbalancinghubslightningbankcentral ization  Thanks, you made my day! |
|
|
|
how is RTL secured? is there a password prompt when you access the site? if not - everyone who knows your domain (and port) can access your node or did i miss something?
Yes, there is a password prompt. You can also set up two-factor authentication in the settings. |
|
|
|
I am pleased to announce that I and ndalliard are (probably) the first bitcointalk members to open a dual-funded channel We both compiled the latest master branch of c-lightning and added "experimental-dual-fund" to our config files. ndalliard was the founder, so I had to configure the funder policy plugin which is not documented well, yet. My funder policy currently looks as follows. lightning-cli funderupdate
{
"summary": "fixed (750000sat)",
"policy": "fixed",
"policy_mod": 750000,
"min_their_funding": "500000000msat",
"max_their_funding": "4294967295000msat",
"per_channel_min": "500000000msat",
"per_channel_max": "4294967295000msat",
"reserve_tank": "0msat",
"fuzz_percent": 0,
"fund_probability": 100
} In short, my node contributes 750k satoshis to every incoming channel (as long as I have enough funds in the wallet and the founder supports dual-funding) if that channel is bigger than 500k satoshis. I will keep my contribution at zero for most of the time. If someone running c-lightning wants to open a channel with me, let me know in advance so that I can change it back and help you with setting-up dual-funding. It might become easier in the upcoming v0.10.1 update. |
|
|
|
Do you think my 8GB Pi 4 can handle ElectrumX + Bitcoin Core?
I was trying to set up ElectrumX on a 4 GB Raspberry Pi 4 and I gave up after a week. The initial sync was taking too much time and I ended up building a normal server (the sync took almost 3 days on an SSD and a recent Intel i5 CPU). If you are patient enough and have some solid cooling system then sure. |
|
|
|
the wording here is a little bit off imo. i guess you are not talking about the lightning technology used on another network than bitcoin. that means the lightning network it is clearly dependent on the bitcoin network and also i would say, that both networks have an impact on each other. i agree with the last part, that no one is force to use neither networks (some say people in el salvador are now force to use it, but that is another topic)
I get your point. I should mention that there is a possible risk of flooding the network if a large number of channels is closed at once. Uncooperative channel close results in 2 on-chain transactions, so that's how someone could do even more damage. A few moments ago, I answered ndalliard's question about timelocks in the commitment transactions. I ended up explaining in detail how uncooperative channel close is performed. Some of you might find it interesting. is the period of that timelock every time a new commitment is broadcastet updated? so it is a moving timeframe? and that timeframe will be set in stone with the opening transaction on the base layer, is that correct?
I might have phrased that slightly wrong, so let me explain it in more detail. If you are closing a channel uncooperatively, there are actually two on-chain transactions involved instead of just one. First of all, the timelock is decided before the channel is established. By default, most nodes force the other peer to wait 144 blocks (~1 day). The maximum acceptable value by default is 2016 blocks (~2 weeks). I configured my node to create channels with their_to_self_delay = 432 blocks (~3 days), so if someone decides to close the channel opened to my node uncooperatively, they will have to wait 432 blocks (after the commitment transaction has been included in a block) before they can spend the output belonging to them. Those timelocks are relative which means that you do not have to sign a new commitment transaction whenever a new block is mined. New commitment transactions are signed periodically because their fees need to match the current state of the mempool. There is no point in paying 60 sat/vbyte when 1 sat/vbyte transactions are getting confirmed in just a few minutes. It also applies the other way around. The first transaction is the commitment transaction. Let's say there's node A(lice) and node B(ob), and node A broadcasts the commitment transaction. That commitment transaction includes two outputs: - output #0: 3 BTC (spendable by node B's private key) - reflecting node B balance - output #1: 6 BTC (RSMC) - reflecting node A balance There is one more important detail before we go any further. Whenever a new commitment transaction is signed, both parties exchange revocation keys for the previous commitment transaction so that they can both be sure that the other party is very unlikely to broadcast an old state of the channel. RSMC is short for Revocable Sequence Maturing Contract. Such an output contains a relative timelock. This means that you can't spend this output until a certain amount of blocks have been mined since the transaction which includes that output was mined. Let's say node B didn't change the default value of 144 blocks and the commitment transaction has been confirmed. There are two possible scenarios. 1) Node A attempts to cheat and broadcast an old commitment transaction. Node B has 144 blocks to spend the RSMC output using his and node A's revocation key which he got while they were working on a new commitment transaction. 2) Node A broadcasts the latest commitment transaction. In such a case, node B never got node A's revocation key for that commitment transaction, so he cannot spend that RSMC. Node A can broadcast another transaction spending that output after 144 blocks have been mined. I know it sounds complicated. I am working on a thread which will explain it in a more understandable way. |
|
|
|
|
Show Posts
