Paid. I also received the 10 satoshis which you sent me yesterday through my offer. Feel free to deduct them from the refund payment.

Manager: yahoo62278
Nazwa kampanii: Gamdom.com Signature Campaign
Ile do zarobienia/tydzień / ilość postów: Member - $20 w BTC/tydzień , Full Member - $40 w BTC/tydzień, Sr Member - $60 w BTC/tydzień, Hero Member - $80 w BTC/tydzień, Legendary - $100 w BTC/tydzień
Jakie rangi: 50x (Member, Full Member, Sr Member, Hero Member, Legendary)
Dodatkowe informacje: Minimum 25 postów tygodniowo, w tym przynajmniej 5 w sekcji Gambling.

I actually enabled them a couple of days ago, but I didn't have a chance to test them out. I would appreciate if someone could try paying my offer. I will send the coins back.

If some node breaks or goes offline then it can no longer route payments. Usually, such nodes are ignored during route construction as their peers should broadcast a channel update message stating that their channel cannot be temporarily used for routing.

Payments can also fail due to:
- no route to the destination,
- lack of liquidity in the route; in other words, you should be able to send less coins through the same route,
- out-of-date information about channels in the route,
- a node going offline while the payment is being routed.

The most common causes are the first two. Payments are usually split into smaller parts and sent through different paths to improve privacy and mitigate the liquidity problems.


All of the implementations you mentioned allow you to specify if you want your channel to be private while opening it. Private channels are not advertised across the network. They are not listed on Lightning explorers as well. I believe that most, if not all, mobile wallets create only such channels. Someone might learn that you had a Lightning channel through an on-chain analysis if either you or your peer closes the channel uncooperatively at some point. Channel openings and cooperative closes are indistinguishable from other transactions (involving multisig addresses).

Even if you have a public channel, no one beside your peer knows your current balance. Everyone can see the total capacity of your channel, though. It is possible to probe the balance through various techniques, but private channels are invulnerable as they are generally not used to route payments.

So, if you are really concerned about your privacy, you should open only private channels using mixed coins so that no one can reveal your identity if your channel gets closed uncooperatively. You can make your node run behind Tor easily.

Manager: yahoo62278
Nazwa kampanii: EGOcoin Signature and Avatar campaign
Ile do zarobienia/tydzień / ilość postów: Member - 0.0003 BTC/tydzień , Full Member - 0.0006 BTC/tydzień, Sr Member - 0.0009 BTC/tydzień, Hero Member - 0.0013 BTC/tydzień, Legendary - 0.0017 BTC/tydzień
Jakie rangi: 15x (Member, Full Member, Sr Member, Hero Member, Legendary)
Dodatkowe informacje: Minimum 25 postów tygodniowo.

I don't have any more ideas for now. We might find a clue in either Tor or c-lightning* logs.

* - you need to append log-level=debug:connectd to your config file and restart your node.


Why don't you follow the official documentation? It's pretty straightforward. There are instructions for a couple of different operating systems if you want to compile the source. You can also use pre-compiled binaries if you don't have much time.

You need to remove all '$' signs from the command.


Do you have any incoming connections in Bitcoin Core? Does it run behind Tor as well?

Did you look at other instructions in this documentation? Maybe your user is not a member of Tor group?


The output is {TORGROUP} which you need for the next command.


Try restarting c-lightning afterwards.

@BlackHatCoiner, I see that n0nce's guide includes some instructions on editing the /etc/tor/torrc file, but it appears to me that something is missing.

Try adding the following lines of code to your torrc file.


Also, you need to double-check your c-lightning config.


Don't forget to restart Tor (systemctl restart tor) and c-lightning after making changes.

I tried opening a channel to your node through Electrum and I got the same error, but I also enabled logs:


I looked up your node on 1ml.com and for some reason your onion address is not listed there, which means that it is not advertised properly. There might be something wrong with your Tor setup.

Yes. Service providers can claim that they do not own a particular on-chain address as they are not forced in any way to sign a message with it.

If the destination node id (a public key) is not encoded directly in the invoice, it is recovered from the message (invoice data) and the signature. If the public key is included in the invoice then the signature recovery is omitted and the signed message is verified.

As per specifications, wallets are required to validate the signature. If the validation fails, the invoice should not be paid.

The receiver (merchant) generates a secret and makes a hash of it. Then, that hash is put in the invoice and used in HTLCs during routing. So, as the sender, you can prove that you have paid the invoice if you provide the secret and the invoice.

Lightning invoices are signed by the node which generates them. It is impossible to modify the amount, the payment hash or the destination as it would invalidate the signature, which is included in the invoice.

The answer is 3. "Circular rebalance" is a process of sending your coins from one channel and receiving them to one of your other channels. This way, you can make space for incoming funds in the first channel and you gain outgoing liquidity in the other channel. "Loop-In" is a third-party service which refills a channel through an incoming off-chain transaction if you pay them on-chain.

You should visit Basics of The Lightning Network and The Lightning Network FAQ. More and more exchanges and companies integrate Lightning Network payments. You should learn at least some basics about the LN. They will eventually come in useful.

Again, about that fantasy....


I also run my own node and I can see that some random nodes connect to me from time to time. You know what? Let's leave this topic. You're being ignorant just like with HTLC signatures in the HLTC outputs of commitment transactions.

---

Private channels are channels that have never been announced to the network. Disabling a channel does not make it private. All nodes still have that channel on their map, but they know that they can't temporarily use it for their payment.


That's possible. However:



Even the ping/pong messages? Are you sure that we are looking at the same specifications? You might as well put a picture of your cat inside of your "ping" message, but the recipient won't know how to handle it correctly as it's non-standard.

---

If you actually looked at my logs and posts, you would know that my payments failed either at some further point in the route or due to no liquidity in my second channel.



Imagine that B, C, D, E updated the parameters of their channels and didn't broadcast the changes as "it's spam". Alice would have to query every single one of them to be able to send the payment. By the way, how would Alice know that all of her information is out-of-date? Asking each hop individually would consume a lot of time.

If the payment fails due to outdated "channel_update", "update_fail_htlc/update_fail_malformed_htlc" can actually return an error message along with the latest "channel_update". Still, the payment would fail 4 times in the above scenario.


I don't think that any implementation behaves this way as it would complicate routing a few different payments at the same time. The sender can actually obfuscate both.

CLTV:


Fees:

In the "onion_routing_packet", the sender can intentionally set "amt_to_forward" to a lower value. As a result, the fee paid would be bigger than the one that can be calculated from publicly known parameters.

Nevertheless, you are ignoring the fact that you can connect to any Lightning node even without having any active channels and start syncing the map of the whole network. Even if Alice is stuck in the "ABCDE" fraction of the network, she will eventually connect to some outside node. The same goes for every other member of the fraction.

You acknowledge the existence of the initial sync, but you insist that Alice knows only about "ABCDE".

---

Bob can also send a "channel_update" message to disable his side of the channel with Carol. Alice would not be able to send payment in the BC direction, but she could still receive a payment in the CB direction.



You are changing your assumptions again. Now, you are saying that BC channel is public, but B refuses to let Alice use it. Even if Bob doesn't send "channel_announcement" and then "channel_update" to Alice, she will eventually learn about it from other Lightning nodes as you assume that Diana knows about that channel all the time. Diana forwards every Carol's "channel_update" message.


It would be a waste of time for Alice to message Bob and ask if he made any changes. Alice should use the information from her local map as it's the fastest way. Bob has no real reason to postpone sending "channel_update" message, which would reach Alice immediately.

---

I am not breaking any "PR campaign claims" as it is common knowledge that you can learn a lot of information about public nodes; Lightning explorers (amboss.space/1ml.com) are more popular than you think. This does not change the fact that Lightning payments are private.


"channel_update" is usually sent to advertise updated fee rates of a channel. For example, c-lightning has recently introduced a grace period:


So, even if someone uses an old feerate in their "onion_routing_packet", the payment won't fail (for a certain period of time). If the feerates are too old then the payment is failed (update_fail_htlc) and the exact error is reported through this message.

Some error messages, which are always encapsulated in "update_fail_htlc" as per bolt04, might actually include the latest "channel_update" so the sender can try resending the payment immediately.


Again, "channel_update" is not sent across the network when you send someone an invoice or when you are in the middle of routing a payment. If either was the case, what would be the reason? Take a look at "channel_update" again.


Which of these parameters in your opinion change when you send someone an invoice or when you are routing a payment? My answer is: none. If there are no changes to those parameters then the update is not necessary.

---

Watchtowers need only txids of revoked commitment transactions and actual penalty transactions for each commitment, to function properly.


created_at, parts, amount_msat, amount_sent_msat, destination are all known before the payment is sent.

payment_hash is a part of the invoice. payment_preimage is known upon receiving "update_fulfill_htlc". status relies on "update_add_htlc", "update_fail_htlc" and "update_fulfill_htlc" messages.

Alice doesn't need to send any messages as she should be able to extract all the information she needs from her local network graph.


Thank you for finally admitting that "update_add_htlc" enforces commitment update.


Again, all the data she needs to prepare "onion_routing_packet" should be obtainable from her local network graph.

---

As both of us are probably getting tired of the "contradiction game". I invite you to play the "quote game".

I am quite sure that you know Andreas Antonopoulos and you must have read "Mastering Bitcoin" at some point. Let me introduce you to "Mastering The Lightning Network".

The gossip protocol:



So, you actually don't need any channel peers to start syncing the graph which contradicts your view:


You said that Alice has only B, C, D, E (completely ignoring that BC is a private channel) in her local map of the network.

Nice try franky1. A few posts ago you were not talking about private channels at all, so I assumed that all channels are public, which is the most common case. You are trying to prove me wrong by changing your assumptions. That's no bueno, my dear.


Read my reply again.


From the very beginning, I have been saying that you need to send "update_add_htlc" message which includes those instructions AND forces commitment update as per bolt02:



Routing hints are included in the invoice which Alice needs to receive (outside of the LN) before she tries to send the payment. It does not contradict with what I have been saying about HLTCs as it's a separate process.

---

You seem to forget that Lightning explorers, which obtain data through the gossip protocol, exist. All Lightning nodes should have exactly the same information as those explorers.


No, my view is that "channel_update" is sent whenever some node makes changes to one of their channel parameters (most commonly the fees). You don't need to send "channel_update" when you give someone an invoice or when you sign a new commitment transaction with someone. You can also send "channel_update" when your peer goes offline so that no one tries to route a payment through this channel. In other words, you can disable the channel.


Change what exactly? If liquidity is not public then there is nothing to change in this case through "channel_update".


You don't need to spam the network with "channel_update" messages. Here's an easier way to improve one's privacy:



You need to read bolt07 more carefully:


So, you can learn about node that you don't have a direct channel with. Why would you not be able to learn about its channels then?

If you suddenly stop liking bolt07, here's bolt00:



No, Eric still doesn't know anything the BC channel. Neither Alice's nor Diana's network map contain any information about the BC channel. The same goes for Eric. You can't make only one side of the channel private; the whole channel must be private.


If that happens then the payment attempt simply fails. Channels don't change their parameters frequently. It should take a couple of minutes for the message to propagate across the whole network. Alice should receive it fairly quickly as she's just a few hops away.

What you are describing is a really edge case scenario as most payment are probably routed through public channels. The only effective way to achieve that would be to include routing hints in the payment invoice, but that would require the cooperation of the sender. Usually, senders include only private channels that are directly connected to them. You also mixed up a few things.

If the BC side is private it doesn't mean that CD is private and that Alice doesn't know anything it. The CD channel is public. The gossip is advertised not only to people who you have a direct channel with, but also to other Lightning nodes that randomly connect to your node. Alice must have learnt about that channel at some point from her other peers.
If the BC channel suddenly goes public, the gossip will eventually reach every single node in the network. There would be no need for Alice to ask B for any details. However, If the BC channel was private all the time:

You can't ask B to temporarily tell you about C. You can't assume that B will have any way of forwarding your payment. In fact, Eric doesn't know it as well.
What would be the point of having a private channel if literally anyone could send a gossip message to your peer to reveal the existence of your channel? You would waste a ton of bandwidth and time trying to guess which node might have a private channel that could be used in your route.

If the channel between Diana and Eric was private, Eric could tell you about it through the payment invoice.


Yes, it is default for LND, c-lightning and Eclair nodes which make up the vast majority of the network. All of them open public channels by default.


It seems that your main argument now is that you can use private channels. Here's what routing hints look like in invoices:


So, if DE channel was private, Eric could give you all the information you need about that channel to construct the "onion_routing_packet". You wouldn't need to request any additional information. If either BC or CD channel was private, you would have no way of learning that you can use either of them to reach Eric.

---

Of course, you can. "cltv_expiry_delta" is a part of "channel_update" message, so Alice knows all the information she needs from her network map if all channels in the route are public.

If you want to assume that BC channel is private and Carol is the destination then Carol needs to include routing hints for her BC channel in the payment invoice. This way, Alice has all the information she needs to construct "onion_routing_packet".

I also really like how you quoted this routing example and talk about some weird update messages when the example clearly uses only two messages: "channel_update" which Alice received at some point in the past and "update_add_htlc" to send the payment.


No one is relaying signed transactions. Commitment updates are local. Nodes relay instructions which tell them how they should update their local transactions.

We have been having quite a heated argument in the [self-moderated] Is LN Bitcoin? franky1: About scaling, on-chain and off-chain thread with franky1, who has been banned from this section, about some technical aspects of the Lightning Network.

We have been mostly arguing about the way payments are routed through the network. Feel free to join our discussion as both of us might be wrong. Here's a quote from my recent message:

I see that you have completely ignored my answers and remarks to your statements, again. Never mind.

You seem to forget that "update_add_htlc", which forces commitment update, always includes "onion_routing_packet" which contains routing instructions. That's how both peers know how to update the channel.

Actually, you can tell if Eric is online from the network gossip. Either of the peers can disable their side of the channel through "channel_update" and that's what all implementations do if their peer goes offline. Disabled channels are ignored during payment path construction. Carol doesn't need to know if Eric is online as she interacts only with Bob and Diana. If Carol or any other hop beside Alice knew that Eric is the final destination, it would be a huge privacy concern.

I have never said that the gossip protocol (bolt07) is used to reply whether or not there is enough liquidity in the channel to forward the payment. You keep saying that you need to send bolt04 payloads in a bolt01 format, but I have already proved you in my previous post that bolt04 error messages need to be associated with HTLCs from bolt02.


The only HTLC related messages that can return bolt04 errors are "update_fail_malformed_htlc" and "update_fail_htlc". Your peer cannot send them unless there is an HTLC commited to the channel ("update_add_htlc" + "commitment_signed" + revocation keys exchange).

---

Here's your view as far as I understand:

1) Alice constructs a path based on the information from her map. If she doesn't have some information about specific node, she requests it through the gossip protocol.
2) Alice sends just "onion_routing_packet" in a bolt01 format to learn if all nodes in the route have enough liquidity.
3) Each node in the path forwards that packet in the same way
4) Once the packet reaches Eric, he replies whether or not he can accept the payment.
5) All hops reply to their partners in the backwards order.
6) [Here should be the commitment part, but I have no idea how you want to handle it with a different secret for each hop and trustlessly without HTLC outputs in the commitment transaction]

My comments:

I have already shared most of my concerns before. I still don't know what message each node would use to say "I can forward your payment". I also didn't mention HTLC outputs here as you clearly ignore that they exist or say that they could be claimed with just payment secret, which is not true. Without them, if Eric claims the payment in his channel with Diana and Carol disappears, Diana can't claim the coins she was promised as the promise was not enforceable in any way.

---

Here's my current understanding of how the system works:

0) Lightning nodes constantly use the gossip protocol (bolt07) to forward/receive "node_announcement", "channel_announcement", "channel_update" messages and maintain a local view of the whole network.
1) Alice receives a payment invoice from Eric which includes information like: Eric node's public key, payment hash, amount, expiry (date) and cltv expiry.
2) Alice constructs a path to Eric using her local map of the network. She tries to find the cheapest and the shortest route. The longer the route, the higher the risk that funds will get stuck during routing.
2a) She prepares "onion_routing_packet" which includes encrypted routing information for each hop.
3) Alice sends "update_add_htlc" message to Bob, which includes the "onion_routing_packet" (which is the same for all peers), the amount, the payment hash and cltv expiry.
4) Alice and Bob sign a new commitment transaction with an HTLC output.
5) Bob sends "update_add_htlc" to Carol with the same "onion_routing_packet".
6) Carol and Diana, Diana and Eric do the same.
7) Eric sends "update_fullfil_htlc" message to Diana, which includes the payment secret.
8) Eric and Diana remove the HTLC output and update balances by signing a new commitment transaction.
9) Diana sends "update_fullfil_htlc" to Carol with the same payment secret and they update the commitment transaction.
10) Carol and Bob, Bob and Alice do the same.

Comments:

3) The amount Alice sends is actually bigger than the one in the invoice as she must account for the fees. Each hop forwards the HTLC with a smaller amount and keeps the difference. If some hop tries to claim higher fees than Alice expected, the next node in the route will fail the payment as the routing instructions say how much one's node is supposed to forward.

If Bob doesn't have enough coins to forward the payment on his side of the channel with Carol, he must send "update_fail_htlc" message and Alice needs to try sending the payment through another route.

All channels use the same payment hash. It is safe because HTLC outputs require both the payment secret and HTLC signatures, which can be produced only by channel partners, to be spent. See this post for explanation.


I can back up my statements by showing you my node's logs and quoting research papers and other resources, but you will totally ignore them as always.