you then pretend alice pings the entire network or a central mempool/repo/dns (whatever fantasy variable your have tried to add in) for the rest of the network
you than back down and say another fantasy, that alice magically must connect eventually(facepalm) to some outside node.
Again, about that fantasy....
This specification describes a node discovery mechanism based on the Domain Name System (DNS). Its purpose is twofold:
Bootstrap: providing the initial node discovery for nodes that have no known contacts in the network
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.
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
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.
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.
That's possible. However:
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.
but there are hundreds of messages.. heck even the simple ping/pong messages can include updates to the fee's cltv's and such.
Even the ping/pong messages? Are you sure that we are looking at the same specifications?
i think i now see how you got your 70% fail rate. [...]
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.
If you actually looked at my logs and posts, you would now that my payments failed either at some further point in the route or due to no liquidity in my second channel.
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.. ..
if you really think that all channel updates result in keeping an map tree uptodate, you are thinking of spam.
I have never said that all updates would reach every node in the network that fast.
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.
If the payment fails due to missing "channel_update", "update_fail_htlc" can actually return an error message along with the latest "channel_update". Still, the payment would fail 4 times in the above scenario.
and yes nodes do want to change things like cltv and fee to add obfuscation per payment even with out publicly announcing it everywhere..
I don't think that any implementation behaves this way as it would complicate routing a few different payments at the same time.