[self-moderated] Is LN Bitcoin? franky1: About scaling, on-chain and off-chain

[franky1]

minus a few contradictions you made, you have actually took a few steps forward

so lets summarise:
contradictions

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.

VS

Here's what routing hints look like in invoices

invoices are not htlc updates to a blockchain formatted transaction output. but thank you for now recognising the messages that go between nodes, especially beyond the initial network map gossip
you have been narratting for pages that payments are blockchain formatted transaction(commitment) changes
where you have been thinking all HTLC are the outputs of a commitment

anyway, lets reply to the other points.

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.

you like games, but do you know the game pass the parcel
if alice does not know diana or eric. then diana or eric cant tell alice about the bob-carol channel
bob has been told by carol not to tell alice about the bob-carol channel.
bob can tell alice about other public channels bob might have with different peers. but ot about carol. which is where alice does not know about diana and eric. and so alice cannot get the EDCBA back path from eric.. because bob is not passing the parcel of eric and diana.. and alice is not connected to eric

thus alice does not know there is a route to eric via bob-carol-diana-eric via a map

bob however is ok with being public to carol. so bob knows of alice. and carol knows alice-bob and carol is ok to send to diana and diana sends to eric. meaning eric knows of alice route. but eric is not node peer handshaked to alice to tell alice

messages are sent pass the parcel. not to some uber mempool map everyone is connected to.
its like bitcoin. there is no central mempool everyone uses, each node has a mempool only of the stuff it gets relayed by a peer. different nodes will have different maps(mempools) if certain peers are not connected to their peer or peer of peer

which is where you get a better map view if you have lots of channels with lots of peers and those peers have lots of channels to increase the chances of mapping everyone. (if they are all public)
its called the 6th degree of separation(kevin bacon)

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.

exactly. because alice has not been given details of carol, diana, eric. she cant get a copy of a eric->alice path unless eric connects to alice ((invoice with hints) where invoice is sent in some out of network communication EG blog post or a DM on a social platform)

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:

its a pass the parcel game.. not everyone connects to everyone randomly

again if you know the pass the parcel game you could turn that into a positive about how it avoids DDoS of random nodes

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.

in a BC private channel set by carol.
carol is refusing to tell bob about diana.. meaning alice and bob dont know about diana which mean alice and bob dont know about eric on the map

again in the pass the parcel game. your not connecting to all nodes and interrogate their channels. your being passed parcels from a peer who gets data from a peer thats allowing said data to be passed or not

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.

so now your saying LN is not private and has no privacy.. wow the tables have turned.
the channel announcements are not broadcast to all nodes.. all nodes are not connected to all nodes.
as that would be a waste of bandwidth!!
its a pass the parcel game peer to peer. where a peer in the middle can refuse to pass
a node only knows of the map of its peers, peers
and so on. meaning its not one tree of everyone.. but several trees where one node in one corner wont have the same trees as another node in another corner.

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

ill thank you with one step forward for admitting that its not all done in the network map. oh and yea invoices are not commitment edits(pre-empting you your narrative twist i can predict you will make)
oh and invoices are messages in msat denomination, not a blockchain formatted transaction template

you say that the transparent network map is on by default and requires an opt out to become private. but its actually the opposite. its an opt-in process of being private first and deciding to go public

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.

ok then if LN is now public. the privacy advert needs to stop.
seems bitcoin has privacy. because it does not reveal partners of partners to show all possible places to pay.
Ln has now become public and can show all possible people to pay

EG. if my network map is where ABCDE only have A and E with 1 channel and BCD with  2 channels

then the only network map ABCDE has is only of ABCDE. because they are peered to pass the parcel

because E is not connected to Z or M or T elsewhere. ABCDE wont know about all the other channels. it only knows about the ones peered to it

again needing an invoice or message outside of the network map. outside of a route parcel game

and multiple times i have been saying you cant update a HTLC until you know the amounts, and details to put into a HTLC
alice is not psychic.

you cannot change a HTLC unless you know the data that needs to be put in it, to change change it

It seems that your main argument now is that you can use private channels.

seems you again want to avoid the point and jump back to private channels, but hey lets go with it..

Code: (https://github.com/lightning/bolts/blob/f6c4d7604150986894bcb46d67c5c88680740b12/11-payment-encoding.md)

r (3): data_length variable. One or more entries containing extra routing information for a private route; there may be more than one 

r field
    pubkey (264 bits)
    short_channel_id (64 bits)
    fee_base_msat (32 bits, big-endian)
    fee_proportional_millionths (32 bits, big-endian)
    cltv_expiry_delta (16 bits, big-endian)

note: this is not a change to a commitment. this is not a network map view. its a message. measured in the denomination of msats

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.

wait. but for a few posts you have been saying everyone knows everything... and now you admit that alice would have no way of knowing about eric via the network map..
.. finally another step forward

again for emphasis. because network map does not hold all info. such as CLTV amount_msat of active available balance, nor any other personal parameters like adding a bit of shade to each CLTV. making each one unique.
you cant just create a route in A using just A network map and just commit to bob. for an amount A guessed based solely on the network map

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

finally it appears your getting it. alice doesnt just use a network map and then constructs a commitment and signs it to bob. to initiate a payment(your narative all along) there are alot more messages that happen. before a commitment is edited/signed

also update messages(msat) are not just sent once at a network map initialisation of opening an app. or once at the invoice send

updates happen after invoices and also update again when things change, including along a route
EG even after alice knows of a route to diana by invoice(not map). alice then needs to
send message which then update the cltv so that alice can then once the route is established and everyone is accepting messages.
channel updates are not forced to only happen at 3 times:(your view)
network map initialisation
invoice send
commitment signed

channel updates can happen all the time
EG if alice is preparing to pay carol using say map or invoice. but during that preparation crol wants to pay her partner zoe, carol then has to change stuff.
EG if while alice is preparing to pay carol. bob(for his own reason separately) pays someone else for something else. he too has to change something.
EG if alice is preparing to pay diana, where diana sent an invoice with a hint path through CBA at each transaction BCE can change their cltv per transaction to add some privacy. meaning random numbers change every few seconds and updates occur

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.

again updates are not done just 'sometime in the past' (your view of just 3 times they occur)
i can right this second change my min dust, fee, cltv. anytime and update, without having to wait for a map gossip or invoice message or a payment.
when routes are built alice needs to know the latest total of msat and the cltv of the entire route. which can change from the app opening initialising network map view. and change from the invoice sent 5 minutes ago. because bobs circumstance has changed in the last 2 minutes

LN is not a network of relaying signed transactions like the bitcoin network

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

thank you for admitting its not about commitment editing/signing..  and thank you for admitting is about sending messages (messages denominated in msat)

feels we have made some progress. even when you have contradicted your self in some small ways inbetween.. dont step back now

[Rath_]

wait. but for a few posts you have been saying everyone knows everything... and now you admit that alice would have no way of knowing about eric via the network map..

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.

thank you for admitting its not about commitment signing and is about sending messages (messages denominated in msat)

Read my reply again.

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

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:

Code: (https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#forwarding-htlcs)

Forwarding HTLCs
*until an incoming HTLC has been irrevocably committed:
    MUST NOT offer the corresponding outgoing HTLC (update_add_htlc) in response to that incoming HTLC.

invoices are not htlc updates to a blockchain formatted transaction output. but thank you for now recognising the messages that go between nodes, especially beyond the initial network map gossip
you have been narratting for pages that payments are blockchain formatted transaction(commitment) changes
where you have been thinking all HTLC are the outputs of a commitment

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.

a node only knows of the map of its peers, peers

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.

channel updates are not forced to only happen at 3 times:(your view)
network map initialisation
invoice send
commitment signed

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.

EG if alice is preparing to pay carol using say map or invoice. but during that preparation crol wants to pay her partner zoe, carol then has to change stuff.
EG if while alice is preparing to pay carol. bob(for his own reason separately) pays someone else for something else. he too has to change something.

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

EG if alice is preparing to pay diana, where diana sent an invoice with a hint path through CBA at each transaction BCE can change their cltv per transaction to add some privacy. meaning random numbers change every few seconds and updates occur

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

If a route is computed by simply routing to the intended recipient and summing the cltv_expiry_deltas, then it's possible for intermediate nodes to guess their position in the route. Knowing the CLTV of the HTLC, the surrounding network topology, and the cltv_expiry_deltas gives an attacker a way to guess the intended recipient. Therefore, it's highly desirable to add a random offset to the CLTV that the intended recipient will receive, which bumps all CLTVs along the route.

its a pass the parcel game.. not everyone connects to everyone randomly [...]
again in the pass the parcel game. your not connecting to all nodes and interrogate their channels. your being passed parcels from a peer who gets data from a peer thats allowing said data to be passed or not [...]
the channel announcements are not broadcast to all nodes.. all nodes are not connected to all nodes.

You need to read bolt07 more carefully:

BOLT #7: P2P Node and Channel Discovery

This specification describes simple node discovery, channel discovery, and channel update mechanisms that do not rely on a third-party to disseminate the information.
Node and channel discovery serve two different purposes:

    Node discovery allows nodes to broadcast their ID, host, and port, so that other nodes can open connections and establish payment channels with them.
    Channel discovery allows the creation and maintenance of a local view of the network's topology, so that a node can discover routes to desired destinations.
To support channel and node discovery, three gossip messages are supported:

    For node discovery, peers exchange node_announcement messages, which supply additional information about the nodes. There may be multiple node_announcement messages, in order to update the node information.

    For channel discovery, peers in the network exchange channel_announcement messages containing information regarding new channels between the two nodes. They can also exchange channel_update messages, which update information about a channel. There can only be one valid channel_announcement for any channel, but at least two channel_update messages are expected.

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:

To make a payment, a participant needs to know what channels it can send through. Participants tell each other about channel and node creation, and updates.

See BOLT #7: P2P Node and Channel Discovery for details on the communication protocol, and BOLT #10: DNS Bootstrap and Assisted Node Location for initial network bootstrap.

bob however is ok with being public to carol. so bob knows of alice. and carol knows alice-bob and carol is ok to send to diana and diana sends to eric. meaning eric knows of alice route. but eric is not node peer handshaked to alice to tell alice

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.

when routes are built alice needs to know the latest total of msat and the cltv of the entire route. which can change from the app opening initialising network map view. and change from the invoice sent 5 minutes ago. because bobs circumstance has changed in the last 2 minutes

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.

[franky1]

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.

i mentioned private channels as one example, due to your assumption everything is public as if there is a central 'mempool' of ALL channels that all nodes has access to. so that in your view commitments can be signed without checking with peers or recipients.

infact each node has a different 'tree' layout depending on their particular pass the parcel game with their particular tree. where some branches of said tree are broke off for multiple reasons

i simple used an example of where:
1. its a pass the parcel game, not central mempool all nodes talk with
2. due to not only private channels,(other examples apply('turbo' shouldnt announce while unconfirmed)) not all channels are passed back to a node (pass the parcel game)
3. parameters do change. fees, cltv, many other parameters

i would have mentioned many other examples, but seeing as for pages of posts you have had particular issues getting yourself out of the 'direct payment to channel partner' scenario.. i thought i would take things slowly on you. give you a chance to gently come out of your box.
EG one step, realise its not just commitment signings but actually lots of messages
EG two step, messages are in msat and not blockchain formatted transaction templates
EG three step, not all nodes psychicly know everything when they open the app or minutes/hours later(things change)
EG four step, show more messages and scenarios that contravene your commitment signing thoughts of how LN work

your fluctuating between step 1-2, but your trying to pull it back to step minus 0
your not at step 3 yet

EG YOUR "update_add_htlc forces commitment update'. where YOUR thinking the only messages are update_add_htlc (again facepalm)

here is something for you to think about outside of your box

until an incoming HTLC has been irrevocably committed:

    MUST NOT offer the corresponding outgoing HTLC (update_add_htlc) in response to that incoming HTLC.

take a second. and think.
an incoming HTLC... hmm....  how is that formed(what data is inside this incoming htlc).
next
how is the data in that incoming HTLC collated/determined/checked/viewed before alice sends it to bob
(before bob sees it)

yep before alice even sends bob an (incoming to bob) alice needs to do stuff, which requires lots of messages.

i know you think that there are only 3 times a node gets gossip.
1. app opening initialisation to get a map
2. invoice received. to add a node and then add to map (60 seconds later)
3. when a node within the map updates due to a successful payment or a shutdown

but you are wrong. nodes can actually send query messages and respond to queries aswell.
nodes also can change their fee anytime they please. they are not arm-strung into sticking with the same fee at app-open or channel creation. they can change the fee regularly, at their whim.

even the cltv can be changed so that its not a default of 9, but instead random per attempt.
but alice would need to know these changes to then commit to bob

lots of messages happen before a commitment is signed.

i know you want to endlessly quote the in-channel commitment stuff of a direct payment.(alice to bob only)
but thats just you wanting a 'alice pays bob' scenario. where messages and variables are simple for you

there is alot more involved that happens before alice even signs to bob on a route payment

* this is not not just formulated from a network map. for many reasons

...
also there are many reasons(not just private channels) as to why branches of a nodes map(tree) differ from other nodes map(tree)
...

theres other things like
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#legacy-hop_data-payload-format
if you read the entire chapter of legacy hop payload format.
NONE of it is about commitment editing or signing. its about MESSAGES
and showing how MESSAGES should fail/reject if parameters are not as expected.
commitments are done after checking the messages and seeing the contents meet the parameters
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#returning-errors
these are messages, not commands to un-edit/re-edit a commitment
there is no reason to write and sign a commitment if the parameters are wrong


update_add_htlc is not a command locally, its a message to remote peer
it only initiate changing a blockchain formatted transaction output if the parameters are good

..
a node has hundreds of message types,
i know you want to only discuss 3 (channel_update and update_add_htlc and commitment_signed)
but you are stepping back into your bolt 2 direct payment box

here is some more stuff
https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#rationale-5

Future nodes may not have complete information; they certainly won't have complete information on unknown chain_hash chains. While this full_information field (previously and confusingly called complete) cannot be trusted, a 0 does indicate that the sender should search elsewhere for additional data.

The explicit reply_short_channel_ids_end message means that the receiver can indicate it doesn't know anything, and the sender doesn't need to rely on timeouts. It also causes a natural ratelimiting of queries.
The query_channel_range and reply_channel_range Messages

for instance. if i have a bitcoin funding locked channel(bitcoins chainhash) the network map only shows PUBLIC bitcoin channels that are only my peers, my peers of peers and their peers of peers

but i can also query a peer and find out updates of the parameters anytime i want. including seeing which peers have, say litecoin channels to see if i can atomic swap

[Rath_]

yep before alice even sends bob an (incoming to bob) alice needs to do stuff, which requires lots of 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.

EG your "update_add_htlc forces commitment update. thinking the only messages are update_add_htlc (again facepalm)

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

an incoming HTLC. how is that formed(what data is inside this incoming htlc).

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:

The Lightning Network solves this problem by implementing a gossip protocol. Gossip protocols are typical for peer-to-peer (P2P) networks and allow nodes to share information with the whole network with just a few direct connections to peers. Lightning nodes open encrypted peer-to-peer connections to each other and share (gossip) information that they have received from other peers. As soon as a node wants to share some information, for example, about a newly created channel, it sends a message to all its peers. Upon receiving a message, a node decides if the received message was novel and, if so, forwards the information to its peers. In this way, if the peer-to-peer network is well connected, all new information that is necessary for the operation of the network will eventually be propagated to all other peers.

The construction of a channel graph is not a one-time event, but rather an ongoing activity. As a node bootstraps into the network it will start receiving "gossip," in the form of the three update messages. It will use these messages to immediately start building a validated channel graph.
The more information a node receives, the better its "map" of the Lightning Network becomes and the more effective it can be at pathfinding and payment delivery.

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

then the only network map ABCDE has is only of ABCDE. because they are peered to pass the parcel
because E is not connected to Z or M or T elsewhere. ABCDE wont know about all the other channels. it only knows about the ones peered to it
EG. if my network map is where ABCDE only have A and E with 1 channel and BCD with  2 channels [...]
a node only knows of the map of its peers, peers

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.

[franky1]

EG your "update_add_htlc forces commitment update. thinking the only messages are update_add_htlc (again facepalm)

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

1. you mistook my saying of YOUR mindset that YOU still think update_add_htlc is a command to changes blockchain format transaction output (which i facepalmed)
here is some clarity to your grammarism game

EG YOUR "update_add_htlc forces commitment update'. where YOUR thinking the only messages are update_add_htlc (again facepalm)

2. ok so below is you again thinking everything is done by a network map everyone has publicly.. i did laugh, ill explain my laughter after the quotes

yep before alice even sends bob an (incoming to bob) alice needs to do stuff, which requires lots of 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.

an incoming HTLC. how is that formed(what data is inside this incoming htlc).

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".
The gossip protocol:

The Lightning Network solves this problem by implementing a gossip protocol. Gossip protocols are typical for peer-to-peer (P2P) networks and allow nodes to share information with the whole network with just a few direct connections to peers. Lightning nodes open encrypted peer-to-peer connections to each other and share (gossip) information that they have received from other peers. As soon as a node wants to share some information, for example, about a newly created channel, it sends a message to all its peers. Upon receiving a message, a node decides if the received message was novel and, if so, forwards the information to its peers. In this way, if the peer-to-peer network is well connected, all new information that is necessary for the operation of the network will eventually be propagated to all other peers.

The construction of a channel graph is not a one-time event, but rather an ongoing activity. As a node bootstraps into the network it will start receiving "gossip," in the form of the three update messages. It will use these messages to immediately start building a validated channel graph.
The more information a node receives, the better its "map" of the Lightning Network becomes and the more effective it can be at pathfinding and payment delivery.

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

the more information a node receives, the better its "map" becomes and more effective it can be

share (gossip) information that they have received from other peers.

the construction of a channel graph is not a one_time event but rather an ongoing activity

As soon as a node wants to share some information, for example, about a newly created channel, it sends a message to all its peers. Upon receiving a message, a node decides if the received message was novel and, if so, forwards the information to its peers.

notice all the wants, decides, if's, cans..
try not to imagine the utopia of a central mempool(DNS server) for all nodes to access, showing all nodes channels of the whole network.(like you have been suggesting, then contradicting and then suggesting again, as if its the sole source of information ever needed)
 and instead imagine each node with its own mempool of only data it can see from its peers which its peers has allowed it to get

i know you want to emphasise a quote of andreas saying "whole network" but thats not the reality. its actually local built based on only the peers with direct path to you publicly. (there may be other peers on path that are private or just decide to go silent on such queries)

example of small map
EG imagine your own scenario of your small box direct payment to bob.. where its only in your view ever a alice-bob negotiation..
guess what. alice doesnt know zoe and in your scenario bob doesnt know carol.. so in your map. based on your small box scenario you try deviating back to your map is just 1 branch of bob.. not a tree of thousands of branches..

example of missing branch map
EG imagine the ABCDE  where your alice and im bob. i can be public with BC meaning carol can tell diana all about me and becasue i told carol about you(alice) diana knows this too.. but here is the thing. i can just refuse to reply with my BC channel when talking to you.

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.

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..
(an old trick people told each other years ago)

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
meanwhile carol can tell diana it is available and online, which tells eric

.. 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 does not require alice having to turn off-on her app to trigger another gossip challenge. or patiently wait for an invoice to trigger a map update.

oh and seeing as you want to break the PR campaign about privacy not being private, to fit your narrative
are you now trying to break the "instant payment" PR campaign of needs to wait for map updates, to fit your narrative

because in your view payments can only be made when network maps are updated, which only happen infrequently, which cant happen IN YOUR VIEW 'on the hop'(adhoc) by messages during a payment, but instead IN YOUR VIEW by waiting for nodes to announce to update a map. which are themselves delayed during their own payments being 'inflight'(pending)

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.

just know that YOU are really calling out that LN is not 'instant' and not 'fast', just to fit a narrative to your opinion

[Wind_FURY]

This topic reminds me of my debates with franky1, but this topic is on steroids. BUT let’s make it simple. Newbies, whatever the trolls say to disinform you, whatever the trolls post to gaslight you, YOU only need to know that those coins in channels are signed transactions that have not been broadcasted and included in the blockchain yet. No one in Lightning is sending something worthless in the network. They are literally BITCOINS.

[BlackHatCoiner]

This topic reminds me of my debates with franky1, but this topic is on steroids. BUT let’s make it simple. Newbies, whatever the trolls say to disinform you, whatever the trolls post to gaslight you, YOU only need to know that those coins in channels are signed transactions that have not been broadcasted and included in the blockchain yet. No one in Lightning is sending something worthless in the network. They are literally BITCOINS.

If only it was that simple. You have to make your point with arguments. Even if I consider franky a troll, I can't just say to everyone that he's a liar and I'm right. The whole point of the thread is to show why and where he's right/wrong.

Also, there's no way newbies reach the 10th page of this mess.

[franky1]

This topic reminds me of my debates with franky1, but this topic is on steroids. BUT let’s make it simple. Newbies, whatever the trolls say to disinform you, whatever the trolls post to gaslight you, YOU only need to know that those coins in channels are signed transactions that have not been broadcasted and included in the blockchain yet. No one in Lightning is sending something worthless in the network. They are literally BITCOINS.

(until you learn about turbo and other services that open channels with msat balance without the 6confirm funding lock)
(which cannot then commit to anything because the 'locking' utxo is not actually confirmed to have a block number.)

buy hey, i guess people dont want to know things, and instead want to shout insults if anyone tries making users risk aware.
but hey, you can instead believe the utopia of network maps being always full and uptodate of all details to not need to check nodes.
you could instead believe that everyone is honest and symbiotically wants whats best for you.
you could believe its permissionless (even though it requires TWO signatures(someone elses authorisation))
you could instead believe that LN is 100% successful. and all other utopian adverts are true. but then you are putting yourself at risk.
when i show bips that prove there are over 500 messages types. and even some of those have dual purpose.. yet someone else says everything is only done via 3 messages. you can see who is hiding things the most.

but hey if you think that there are only 3 messages types and those 3 messages are blockchain formatted transactions.. you keep dreaming that. enjoy your sleep
it would be better if those promoting LN actualy showed how and why its different to bitcoin. then it may reveal real niche usecases they can actually promote. rather then the usual "bitcoin is broke and wont scale, everyone should use this alternate network instead" game.

if anyone is still unsure. lets use Lightning-C. () asadvertised by Rath
https://github.com/ElementsProject/lightning#sending-and-receiving-payments

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

On 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)
and there is even juicier stuff if you have the time about how 'payments' are stored locally. spoiler its not in a blockchain formatted transaction.
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

[n0nce]

it would be better if those promoting LN actualy showed how and why its different to bitcoin. then it may reveal real niche usecases they can actually promote. rather then the usual "bitcoin is broke and wont scale, everyone should use this alternate network instead" game

Wait, you think the Bitcoin blockchain scales? We basically have a hard limit of transactions per second of around 20.

maximum of 12195 transactions

12 thousand transactions per block (10 minutes) means 20 transactions per second and some pocket change. This will never suffice without off-chain (or other? sidechain?  ) scaling mechanisms.

Franky, you're always going deep into implementation details that half of the people here can't even understand; let's see it from a high-level perspective: how do you think Bitcoin adoption should work on a large scale purely based around the blockchain? Recording every little transaction, every micropayment, every in-game purchase, everything on the almighty blockchain? It will clog up bad.

I mean, even with the super controversial SegWit introduction we only went from 10 tx/s to 20 tx/s... I would be very interested how you envision scaling to the required hundreds to thousands range (of tx/s... that's 1-2 orders of magnitude) without going off-chain, purely on a high level.

[franky1]

actually the logical limit is 4200tx a block. about 7tx/s (which was stated even back in 2010)
we have never had a single hour, day or month where its had an average of 7tx/s

the most we actually get on average is under 2500tx a block(4.16 tx/s)
https://api.blockchain.info/charts/preview/n-transactions-per-block.png?timespan=3years.

this this limit has been purposeful prevented from being lifted. for multiple reasons.
the main excuse is the pretence we still work with 1990's tech (dial-up and floppy disks)
where 4mb every 10 minutes has been deemed too slow (facepalm)..

but with that all said. thank you for proving my point that you too want to propagandise the narrative that bitcoin cant scale, just to hide that certain people dont want it to scale.

i know you also want to propagandise that you believe bitcoin needs to be 100mb a block this year to 'scale' to this years daily use. but thats just exaggeration on the part of the group you also cling to.

on average. a human only buys (in life) 1-3 things a day. so if we take LN's 1Ml stats(rath believes is complete public view of all LN users) thats 33,000 nodes. (some are sybil nodes of same user)
but lets take this 33,000 as a exaggerated userbase (i know the user numbers are lower due to multiple nodes per user, but ill go with the number to actually give a number that helps LN feel comfy with high users)

so 33,000 * lets say.. hmm 5 payments a day. lets be generous
thats 165,000 payments.

bitcoin at an average of say 1700tx a block * average 144 blocks a day=244800
bitcoin has the bitcoin Dev consent that 4mb is ~acceptable(if uncludged by other limits) which could allow 1-2.4m/day

which is more then whats needed.
so please stop thinking bitcoin needs to scale to 1.7mill transactions a block(244m a day) this year just to cope with the presumed LN advertised usage.(LN group rhetoric of needing 100mb blocks to scale(facepalm))

because even my exaggerated usage is actually is not even 1mill a day, definitely not needing to scale to 244m a day.

emphasis: bitcoin scaling. not LN narrative bitcoin leaping.

as for other networks that peg locked funds(LN included) they can have their niche services for certain features. as long as they advertise them HONESTLY and actually mention what makes them different to clearly advertise their unique usecases and the risks users may encounter.

emphasise: stop pretending bitcoin is dead, cant grow.. to pretend that altnet pegs are the only way forward

[BlackHatCoiner]

(until you learn about turbo and other services that open channels with msat balance without the 6confirm funding lock)

Wait for a sec, franky. Do you think that including this into parentheses will make it look less significant? Okay, so what does it mean that a bunch of services decided to open channels without having the necessary confirmation(s)?

I'll take Exodus as an example, which is a closed-source Bitcoin wallet. What does it mean if its developers decided to not allow you double-spend your transactions using RBF? That Bitcoin is faulty or that Exodus is a bad choice?

but hey, you can instead believe the utopia of network maps being always full and uptodate of all details to not need to check nodes.

This is definitely not the case. I don't believe that the map of the network remains the same nor the its nodes are always up-to-date of all details. Some even go offline, but they must not be many. If you provided me some valid statistics, we could negotiate this.

buy hey, i guess people dont want to know things, and instead want to shout insults if anyone tries making users risk aware.

Let's assume that we do, which is not true but let's say that we do. You insult all the time. How does that differentiate you from us?

you could instead believe that everyone is honest and symbiotically wants whats best for you.

I'm sure Bitcoiners know that everyone isn't honest nor they want their good. That's why they're using Bitcoin.

Wait, you think the Bitcoin blockchain scales?

You just opened a can of worms. You've no idea how many franky's nonsense posts will follow if you decide to continue this further.

[franky1]

(until you learn about turbo and other services that open channels with msat balance without the 6confirm funding lock)

Wait for a sec, franky. Do you think that including this into parentheses will make it look less significant? Okay, so what does it mean that a bunch of services decided to open channels without having the necessary confirmation(s)?

I'll take Exodus as an example, which is a closed-source Bitcoin wallet. What does it mean if its developers decided to not allow you double-spend your transactions using RBF? That Bitcoin is faulty or that Exodus is a bad choice?

if you want to deposit gold into a bank vault to then have a bank note promising to be backed by that amount of gold. fine. vault it up first. ensure its locked and witnessed. and ensure its signed to get a promissory note..
but then if the bank starts offering bank notes not backed by gold.. dont trust the bank note. its not backed

as for saying insults.
you might want to use some word finder tools and actually look at this topic. find who uses the most insults and which words were the worst words used... it may surprise you

when five repeated people of a group throw many insults(of varying degrees) in my direction, i laugh, i yawn. i facepalm..
when i call those 5 in the group "fangirls" they act as if its a savage attack and they have been murdered

you can play the victim card. but that card is a blank bit of paper of no substance, wave it all you like. saying your a victim does not make you a victim

[Rath_]

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.

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

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.

.. 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 a channel. For example, c-lightning has recently introduced a grace period:

Code: (https://github.com/ElementsProject/lightning/releases/tag/v0.10.2)

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.

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.

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

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

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

[BlackHatCoiner]

if you want to deposit gold into a bank vault to then have a bank note promising to be backed by that amount of gold. fine. vault it up

The same disanalogous example... Again... And again... While I've told you it's not the same kind of IOU... Sorry, but I won't repeat it. You want to not understand me.

you might want to use some word finder tools and actually look at this topic. find who uses the most insults and which words were the worst words used... it may surprise you

I've never insulted anybody if they hadn't insulted me first. I challenge you to search my posts. You're the only person who I've really insulted in this forum.

when five repeated people of a group throw many insults(of varying degrees) in my direction, i laugh, i yawn. i facepalm..

Half truth: You're doing this every time someone corrects you. You don't want to get better, you just want to seem correct.

Please sit down and realize that all of the users in this thread (besides foulmouthed suchmoon) never insult no one. You're the only one who feels insulted for having his sayings corrected.

[n0nce]

~

Only because at the moment the mempool is not clogged up, is not proof that a blockchain scales. A blockchain does not scale by definition / design. It's not made to do it and it's perfectly fine. It allows us to run it on a multitude of devices, at affordable prices and with pretty quick setup time (less than a week in most cases) which is essential for decentralization and security of the whole Bitcoin network.

For the record though, I'm not a promoter of big blocks, of faster blocks or of shitcoins as a scaling solution.

I'm instead a promoter of performing real Bitcoin transactions, but keeping the majority of them off-chain, that's a pretty simple and logical concept in my eyes.

You think I'm a propagandist? I'm just giving you obvious facts. Yeah, it's also a fact that Bitcoin is at under 4tx/s at the moment, but how is this proof that the number won't change? And do you want it not to change? Because I do want the number of Bitcoin users to go up; it's in my and their interest. So I try to look into the future optimistically and assume / hope we will soon have the need of 40tx/s, one day 400tx/s and maybe in a very far future 4000tx/s. That's why I'm trying to start building the infrastructure for such a future now, not when it's too late and the 'demand' for more transactions/sec. is way higher than the 'supply' Bitcoin can deliver.

bitcoin at an average of say 1700tx a block * average 144 blocks a day=244800
bitcoin has the bitcoin Dev consent that 4mb is ~acceptable(if uncludged by other limits) which could allow 1-2.4m/day

Wait, the second step is wrong. At the moment, I showed you before, you can put a theoretical maximum of 12195 transactions per block, which is 1,756,080 transactions per day. Not sure how 2.4m would be possible. Fact of the matter is, Visa for example, does 100 millions per day in just the U.S. alone. That's 50x, just Visa, just U.S. If you add Mastercard and all the other countries in the world, you'll be at 1000x or more. Since you can't go from a 4MB block to a 4000MB (4GB) block every 10 minutes, you cannot feasibly scale on-chain. Simple as that...

[DooMAD]

this this limit has been purposeful prevented from being lifted

I mean, that's certainly one opinion.  Another opinion would be that those securing the network, right now, as we type here, could easily amend their code to increase that limit, but they are choosing not to do that.  Why do you think that is?  Perhaps your view is that there must be a conspiracy of some kind.  Maybe that seems like the most rational explanation to you.  But I would suggest the real picture is altogether less sinister:  

What if (and please consider this carefully) some people do want the same thing you want, however, at the same time, some of them don't want the same thing you want?  

So, if the thing you want requires a hardfork (and naturally it does, because you've gone to great lengths to express how much you despise softforks), that likely results in splitting the network if we don't have a significant proportion of people in agreement.  It's difficult to paint that as a positive outcome.  That wouldn't achieve anything good.  So that's probably a pretty reasonable explanation as to why it's not happening.  Do you see the sense in that?  
  

certain people dont want it to scale.

Again, that's certainly one opinion.  Another would be that people generally want to scale responsibly and aren't in any particular hurry.  Also, hate to break it to you, but you're sharing a network with those people.  You can't exactly make them go away.  They have as much right to exist as you do.  But as much as you might disagree with their views, the fact remains you are all agreeing on the current rules every single time you use Bitcoin, so you continue building a network together.  

The status quo is easy to maintain.  Change is much more difficult.  

If you want to change something, the onus is on you to convince everyone else that it needs to change.  And to date, it's fair to say you haven't really had much of an impact there.  If all the things you've been demanding for the last 5 or more years really were as brilliant as you suggest they are, do you honestly not think that there might be a small but noticeable swell of grass-roots support made up of people who are just as angry and vocal as you are?  Where are they?  Where should I be witnessing the same level of outrage in others that I see in you?  It's just not there.  Let's be real here.  I can't think of anyone on this entire forum who has a more intense disposition about this issue as you.  No one else here is as relentless or persistent.

Then again, I suppose it's fair to argue there would be more vociferous support for on-chain scaling if the BCH fork hadn't happened, but they made their choice.  It's likely most of those people no longer care what we do, because they just went ahead and made the changes they wanted to make.  And that's valid.  They didn't try to force everyone to agree with them, they just did it.  That's probably the most effective way to get stuff done.  But it still remains to be seen that they've made the "best" choice.  It doesn't seem to be working out all that well for them.  The outlook long term doesn't look encouraging.  Perhaps if BCH and the other myriad forks continue to weaken and eventually die off, those users might return to BTC.  Then you might see that swell of support for on-chain scaling.  

Honestly, when enough people want it as badly as you do, greater on-chain scaling will happen.  It will.  But not right now.

emphasise: stop pretending bitcoin is dead, cant grow.. to pretend that altnet pegs are the only way forward

I don't see anyone saying LN is the "only" way forward.  Your inference that people are saying that appears to be embellished for dramatic effect.  I think everyone would welcome a little less hyperbole.  Please let's try to keep things in perspective.  Again, further on-chain scaling will almost certainly come at some point, but we're trying some other stuff first which doesn't have as much overhead in terms of cost.  Please try to be patient.

[franky1]

aaaanndd domad has gone back to ignorance of the consensus stuff of 2017 all over again
pretending it didnt happen.

i though finally 2022 will be the year doomad remembers and accepts the 148/91 stuff.. understanding what happened. the real sequence of events.
but looks like he instead has retreated back to his other rhetoric of ignorance again..

im not even going to redeem him by suggesting that he does know what actually happened and is just trolling a different narrative just to be argumentative.. instead ill just go with what he is trying to pretend himself as, someone ignorant and forgetful. (well he wants to present himself as this, so illl go with it)

i thought it would take him 3 weeks to retreat back to his foggy memory.. he managed it in 3 days

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(only bob in this faction example) 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) and only if bob wishes to disclose)

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.
..
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 simply make a payment "instantly" 100% success..(in your view) to anyone without sniffing with regular messages
.. sorry that just doesnt happen

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[FROM carol] a payment in the CB direction.FROM carol, diana or eric]

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

    MAY sent a subsequent channel_update with the disable bit set to 0 to re-enable the channel.

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

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, because 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.. and all have a global map of everyone.. 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 queries bob(different messages) , 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.

.. 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 limited 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.
i know (in your view) you think there are only 3 messages structures and all involve update channell update htlc and commitment signed..
but there are hundreds of messages.. heck even the simple ping/pong messages can include updates to the fee's cltv's and such..
its not some mass harmony of network gossip that makes everyone public right from the start. its lots of messages happening before during and after payments, which make payments happen

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 70% event fail rate. and why your still unclear as to why

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.

if eric sent me an invoice. he would want to obfuscate some details for each payment even the ones not for me. so his last 5 parameters may be different for my invoice from him, compared to an invoice he sent to someone else 2 seconds earlier..

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


also eric might have changed them parameters in the 5 minutes of me getting the invoice and deciding i definitely want to buy something from him..

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 other channels..
         t
       /   
a-b-c-d-e
       \
         z
..other channel partners(t&z) where she has inflights(pending payments) with z or t
but because for last 5 minutes she has not sent or received a payment from bob, she has no reason to update bob
nor would she want to 'network map rebuild gossip' bob every payment she gets from d, e, z or t as thats alot of messages to update to b even when B is not doing anything.

and eric too could have changed his parameters too depending on his other payments with others.

if you really think that all channel updates result in keeping an map tree uptodate, you are thinking of spam.
and yes nodes do want to change things like cltv and fee to add obfuscation per payment even with out publicly announcing it everywhere..
because whats the point of advertising it to (your view of a network map) to add obfuscation, if the point of adding obfuscation is to hide from the network map
..
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.

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 messages i have been talking about.
heck i know you want to imagine LN only store blockchain format transactions. and only sends messages containing updated commitments 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)

anyway this topic is getting boring with the contradictions and dancing back and forth thats happening
im not even going to bother to try pegging people down to one narrative using simple questions.. (tried that, they declined)

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

so here goes..
imagine i was carol(C)..
A>B>Cmy node1                             Z<Y<X<W<C my node3

                            my node3  C>D>E

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

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

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.

(i know your not ready to be out of the 'direct payment to channel partner' box, and think that nodes dont need to sniff routes when making a proposed payment.. but.. i hope you get out of the box soon)

[moderator's note: consecutive posts merged]

[BlackHatCoiner]

im not even going to redeem him by suggesting that he does know what actually happened and is just trolling a different narrative just to be argumentative..

Man, what's wrong with you? He's talking to you as politely as one possibly can and you behave with complete lack of courtesy. People talk to you calmly and you either insult them or snob (?) them.

You're constantly complaining about the off-chain solution (which works brilliantly IMO) and want to persuade everyone with demagogue that the block size increase will do the job while history has shown that it simply flusters the network.

And again;

What if (and please consider this carefully) some people do want the same thing you want, however, at the same time, some of them don't want the same thing you want?

[Wind_FURY]

This topic reminds me of my debates with franky1, but this topic is on steroids. BUT let’s make it simple. Newbies, whatever the trolls say to disinform you, whatever the trolls post to gaslight you, YOU only need to know that those coins in channels are signed transactions that have not been broadcasted and included in the blockchain yet. No one in Lightning is sending something worthless in the network. They are literally BITCOINS.

If only it was that simple. You have to make your point with arguments. Even if I consider franky a troll, I can't just say to everyone that he's a liar and I'm right. The whole point of the thread is to show why and where he's right/wrong.

Also, there's no way newbies reach the 10th page of this mess.

But it is that simple, because he is trolling you. Remember when I was alone debating him, and it only annoyed everyone because many topics became “Wind_FURY and franky1 show”? Someone actually said that.

I have limited technical knowledge, but I tried debating him alone, without help except from DooMAD, because I knew he was lying, only to learn weeks and months later that he was gaslighting the NEWBIES who will read through without technical knowledge themselves. He is also trolling you now, and he will post long technical stuff to confuse you. It’s better not to debate franky1, it’s also better to educate newbies.

[BlackHatCoiner]

But it is that simple, because he is trolling you.

You ignore him and demand from the rest to ignore him too, because you think he's a troll. You're suddenly sounding like franky. If you want to shut him up, better do it with arguments. This is the hard way, I know, but it turns out it's the only way. Ban requests or ignorance will do more harm than good.

The fact that we've made 11 pages in this thread and another 5 on my ban request proves that this case isn't simple.