you do realise that there are many messages that happen separate to the initial sync map build.. right?
and the map is only as good as the peer connections allow.
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".
i know you think that the only way for bob to dissuade alice from using bob as a route to carol is for bob to rack up his min fee to 1btc a hop. .. where bob has to stay public all day but with a large fee to prevent alice using his BC as a route path..
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.
MAY create and send a channel_update with the disable bit set to 1, to signal a channel's temporary unavailability (e.g. due to a loss of connectivity) OR permanent unavailability (e.g. prior to an on-chain settlement).
but you can actually just break the branch in the map and tell alice that the BC channel is not available by responding to a query without mentioning BC channel. or even just telling alice your BC is shutdown/offline
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 from other Lightning nodes as you assume that Diana knows about that channel all the time.
.. alice can later just query bob and bob can decide to respond. or bob can send an update message to alice to change this.
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.
oh and seeing as you want to break the PR campaign about privacy not being private, to fit your narrative
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.
are you now trying to break the "instant payment" PR campaign of needs to wait for map updates, to fit your narrative
"channel_update" is usually sent to advertise updated fee rates of the channel. For example, c-lightning recently has introduced a grace period:
setchannelfee now has a grace period during which both old and new fee policies are considered. This prevents a fee update from making the channel unusable until the update propagated.
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.
so if you want to say that a payer cannot make a payment while another node is 'inflight' with a different payment for their different reason, because its not yet updated to tell YOUR map.
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.
type: 258 (channel_update)
data:
[signature:signature]
[chain_hash:chain_hash]
[short_channel_id:short_channel_id]
[u32:timestamp]
[byte:message_flags]
[byte:channel_flags]
[u16:cltv_expiry_delta]
[u64:htlc_minimum_msat]
[u32:fee_base_msat]
[u32:fee_proportional_millionths]
[u64:htlc_maximum_msat] (option_channel_htlc_max)
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.
even things like feature to allow watchtowers to hold onto a 'revoke' payment to use when one side cheats. the watch tower does not get/store blockchain format transactions
Watchtowers need only txids of revoked commitment transactions and actual penalty transactions for each commitment, to function properly.
if anyone is still unsure. lets use Lightning-C. () asadvertised by Rath
https://github.com/ElementsProject/lightning#sending-and-receiving-paymentsPayments in Lightning are invoice based. The recipient creates an invoice with the expected <amount> in millisatoshi (or "any" for a donation), a unique <label> and a <description> the payer will see:
https://lightning.readthedocs.io/lightning-pay.7.htmlOn success, an object is returned, containing:
payment_preimage (hex): the proof of payment: SHA256 of this payment_hash (always 64 characters)
payment_hash (hex): the hash of the payment_preimage which will prove payment (always 64 characters)
created_at (number): the UNIX timestamp showing when this payment was initiated
parts (u32): how many attempts this took
amount_msat (msat): Amount the recipient received
amount_sent_msat (msat): Total amount we sent (including fees)
status (string): status of payment (always “complete”)
destination (pubkey, optional): the final destination of the payment
there are other things about monitoring the progress of payments (inflight)
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.