Thanks franky1 for finally answering my question. There are two problems with your answer.
1)
Notice that the failure_codes are not of the same type as other message types, defined in other BOLTs, as they are not sent directly on the transport layer but are instead wrapped inside return packets.
Here's another interesting fragment:
The association between the forward and return packets is handled outside of this onion routing protocol, e.g. via association with an HTLC in a payment channel.
Let's take a look at HTLCs again then.
type: 131 (update_fail_htlc)
data:
[channel_id:channel_id]
[u64:id]
[u16:len]
[len*byte:reason]
The reason field is an opaque encrypted blob for the benefit of the original HTLC initiator, as defined in BOLT #4 [...]
type: 135 (update_fail_malformed_htlc)
data:
[channel_id:channel_id]
[u64:id]
[sha256:sha256_of_onion]
[u16:failure_code]
So, bolt04 says that failure errors are returned as a part of HTLCs and bolt02 says that those errors are described in bolt04.
2)
I looked through all failure messages and I couldn't find any that explicitly states that there is no enough liquidity in the outgoing channel.
well a good privacy thing is that nodes dont have to network gossip their fee's and updates to become known on a public map.
By default, Lightning channels are public and they advertise themselves through "channel_announcement" and "channel_update".
You can use Lightning explorers like
amboss.space or
1ml.com to see information extracted from the gossip protocol for each public node.
Here's my node. You can see all of my channels, including their fee settings which are necessary to construct the routing path. Private channels are generally not used for payment routing as the invoice would have to include routing hints.
Even a lightwallet like Electrum
forces their users to wait for the local graph to sync through the gossip protocol if they don't want to be able to connect only to trampoline nodes, which can take care of the path calculation for the user if they are willing to compromise their privacy.
You should take a look at at least one paper describing the probing attack on the Lightning Network.
LN nodes gossip about channels available for routing and their total capacities. To issue a (multi-hop) payment, the sender creates a route based on its local knowledge of the graph. As local channel balances are not public, payments often fail due to insufficient balance at an intermediary hop. In that case, the payment is attempted along multiple routes until it succeeds. This constitutes a privacy-efficiency tradeoff: hidden balances improve privacy but hinder routing efficiency.
You can download the paper and learn how Lightning payments actually work.
Another question for you. I would appreciate if you could interpret my node's debug log.
I posted my node's debug log some time ago. My node failed to forward an incoming HTLC due to no liquidity ("CHANNEL_ERR_CHANNEL_CAPACITY_EXCEEDED"). You can see messages like: "update_add_htlc", "commitment_signed", "update_fail_htlc".
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: peer_in WIRE_UPDATE_ADD_HTLC
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: NEW:: HTLC REMOTE 408 = RCVD_ADD_HTLC/SENT_ADD_HTLC
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: htlc added LOCAL: local 3828178009 remote 1171821991
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: -> local 3828178009 remote 1074154247
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Creating commit_sig signature [REDACTED] for tx [REDACTED] wscript [REDACTED]
hsmd: Client: Received message 20 from client
3562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Creating HTLC signature [REDACTED] for tx [REDACTED] wscript [REDACTED]
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-chan#85: HTLC in 403 SENT_ADD_REVOCATION->SENT_ADD_ACK_COMMIT
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Sending commit_sig with 1 htlc sigs
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: peer_out WIRE_COMMITMENT_SIGNED
037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba-channeld-chan#29: Failed to add 1 remove 0 htlcs
037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba-channeld-chan#29: Adding HTLC 1126 amount=97653097msat cltv=716528 gave CHANNEL_ERR_CHANNEL_CAPACITY_EXCEEDED
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: FAIL:: HTLC REMOTE 408 = SENT_REMOVE_HTLC/RCVD_REMOVE_HTLC
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: peer_out WIRE_UPDATE_FAIL_HTLC