Quote from: Rath_ on January 20, 2022, 04:18:58 PM

Quote from: franky1 on January 19, 2022, 06:14:45 PM

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".

alice can connect to bob without a channel, to sniff bobs channels, or create a channel with bob. but alice can only get a route tree(map) of only the data bob has access to(wishes to disclose), which is in the case of ABCDE faction.. only ABCDE (only if all ABCDE are public(allowing disclosure))

you then pretend alice pings the entire network or a central mempool/repo/dns for the rest of the network(whatever fantasy variable your have tried to add in)

you than back down and say another fantasy, that alice magically must connect eventually to some outside node.
..
sorry but your statements are utopian hope. not actual fact at opening the node to have a entire network map of all nodes everywhere within seconds so she can make a payment "instantly" 100% success..
.. sorry that just doesnt happen

Quote from: Rath_ on January 20, 2022, 04:18:58 PM

Quote from: franky1 on January 19, 2022, 06:14:45 PM

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.

Code: (https://github.com/lightning/bolts/blob/master/07-routing-gossip.md)

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).
[color=green]
MAY sent a subsequent channel_update with the disable bit set to 0 to re-enable the channel.[/color]

FTFY

thank you for agreeing that channels can be made private/publicly at a whim any time..
(after your multiple post saying its not)
thank you for agreeing that alice cant send to carol. but eric-diana-carol can send bob or to alice when bob goes private

Quote from: Rath_ on January 20, 2022, 04:18:58 PM

Quote from: franky1 on January 19, 2022, 06:14:45 PM

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 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.

funny part is. my quotes "tell alice that the BC channel is not available" is not me changing my assumptions. it is not me saying that BC channel is or is not public. its that there is more then 1 way to dissuade alice from using BC as a route.
im clearly still using the narrative that bob isnt telling alice about BC. so the assumption is the same. im highlighting there is more than one way to do so.
im saying more than one way, becasue you think that there is no way, because before this evening you were adamant that the nodes are all default to public from the start.. so im just showing you that its not true.

its not just by setting the disable_bit, it can also be done if bob is also public, but when alice query bob, he can also:
time out the query
respond by missing out details of a channel
there is absolutely nothing FORCING bob to submit to alices request, when she asks for a list of channels.
there is nothing FORCING bob to have to list all channels.

Quote from: Rath_ on January 20, 2022, 04:18:58 PM

Quote from: franky1 on January 19, 2022, 06:14:45 PM

.. 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.

in your utopia of a network map showing all channels all updated in 0.001seconds, yea sure, waste of time, go ahead built your route and send your payment.. .. i think i now see how you got your 70% fail rate.

because payments are private. and not on the map. even by using limitede info from the 'map' alice still does not know how many 'inflight' payments (pending) bob,carol, diana has.. this means alice does not know the liquidity of the route. and so alice can 'walk the route" to gain details like cltv and fee's aswell as see if a route is viable.
you know. because users may want to update their fee's and cltv for every payment to add some obfuscation.

the process is lots of messages happen before-during and after. [pre-flight] [in-flight] [post-flight]
is not like one initial sync and then nothing for minutes-hours.
nodes can talk to each other using query messages.
its not just to get updates but also to make sure they are still online.

Quote from: Rath_ on January 20, 2022, 04:18:58 PM

Quote from: franky1 on January 19, 2022, 06:14:45 PM

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?

i know you are obsessed with just 3 messages. but there are other query messages to get fee amounts and cltv amounts.
also i was not the one setting a narrative of a full network broadcast where everyone gets the information for everyone to have a global map of everyone, thats always uptodate... YOU WERE

each node has a different map tree of their connected(directly and peer of peer indirects). and thats all they have.

your the one that thinks a node knows everyone or just needs to initial sync or get a invoice and everything is ready to just commit.

funny part is an invoice doesnt always include 'possible route' hints.
why. because when someone makes an offer to sell something and has their LN uri to show a users were to send payments to on a forum post/blog post or private communication DM on other platforms.. that recipient does not know who wants to pay him to have even sniffed the network map or his routes to find a payer.

again time travels in one direction. you cant know everything before someone decides to pay,

its getting more obvious why you have had 705 event fail rate. and why your still unclear as to why

Quote from: Rath_ on January 20, 2022, 04:18:58 PM

Take a look at "channel_update" again.

Code: (https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#the-channel_update-message)

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.

an invoice is just an offer.. its not a thing that has a 'network map' of insight of all possible routes. because invoices could be static uri with offers, where the invoice is posted to a forum as the way of saying 'pay me'

you still then need to look for a route or other routes before just paying the invoice giver
again your forgetting about all the messages inbetween.

for instance if eric is handing an invoice saying he wants 1000msat..
you still need to know about bob, carol, diana.

for instance since the last 'network map' update via bob of carols 'state' carol could have changed her fee 100 times. this is because carol might want to use different fee's per payment for some obfuscation. or change her cltv value instead of keeping the 9 default.

she may have updated via a different channel partner where she has inflights with zoe or tina
t
/
a-b-c-d-e
\
z

but because for last 5 minutes she has not sent or received a payment from bob, she has no reason to update bob
..
i really am starting to understand your 70% fail rate now. seems you have been coding in some stuff that doesnt use logic or checks.

Quote from: Rath_ on January 20, 2022, 04:18:58 PM

Quote from: franky1 on January 20, 2022, 02:16:38 PM

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.

something even more surprising for you.
most node software dont even store their own commitments in a binary form of a blockchain transaction format.(raw tx)

they actually store it in variables of value input output signatures and keys. much more similar to the messgaes i have been talking about.
heck i know you want to imagine LN only store blockchain format transactions. and only sends messages containing updated committments already signed or to be signed..
but thats not how it works

there are no messages sending blockchain formatted transaction templates. even the hard 'backup' doesnt store blockchain format transaction in raw byte array.

the messages are not like that, the storage is not like that

yep they dont store blockchain transactions. just bits of data that they compute a signature in ram by temporarily building binary arrays. to sign. and then store the signature plus the amounts and keys. (not a full raw blockchain tx)

(but ill get more into that later, im not sure your at that point yet. maybe a month, or more.)
(you took a few steps forward so your on your way, but you seem to want to drag it backwards so im not predicting your going to cotton on to LN's real differences just yet)

also, maybe i will skip a few steps ahead rather than wait for you to dance back and forth

imagine i was carol..
A>B>C(my node1) Z<Y<X<W<C (my node 3)

(my node 2) C>D>E

A can pay Z even though A only has a network map tree of B>C(if i(via node1) decided to respond about my node3)

yep i dont actually need to have a tree linking all channels via a peer pass the parcel of linked peer channels.

yep DEWXYZ can all pay A. even if the Z does not have a network map tree of
ABCWXYZ.

ill let you have a little think about that.
hint my node 1 has no 'channel' to my node 3.. yet via my private messages i can allow A to pay z or A to pay A without either of them having either of them on THEIR maps.