Post
Topic
Board Bitcoin Discussion
Re: [self-moderated] Is LN Bitcoin? franky1: About scaling, on-chain and off-chain
by
franky1
on 16/01/2022, 20:54:24 UTC
We're back to square one. Here's a simple question. How do all of these people communicate?

you think that everything is done within commitment changes. of channel management.. its not ill summarise(analogy first):
z. now take a htlc. a piece of paper as a contract with terms
y. now, take a commitment. imagine its a box. with a HTLC piece of paper inside that box
x. now take a channel. imagine thats a box that has a commitment boxes inside it (1 for each partner)
w. now take a node. imagine thats a box that can contain many channel boxes
v. now take a string. that peer connects to other node boxes
now take a separate flimsy box that has its own htlc call this (V(w(M))) M is for messages transmitted through w's via V

all messages are send via V not Z
within the V messages they can be in many formats. lets just call them (V(w(M)))

now more technical version of the analogy explained
https://github.com/lightning/bolts/blob/master/01-messaging.md#lightning-message-format
Quote
After decryption, all Lightning messages are of the form:

    type: a 2-byte big-endian field indicating the type of message
    payload: a variable-length payload that comprises the remainder of the message and that conforms to a format matching the type
    extension: an optional TLV stream

The type field indicates how to interpret the payload field. The format for each individual type is defined by a specification in this repository. The type follows the it's ok to be odd rule, so nodes MAY send odd-numbered types without ascertaining that the recipient understands it.

The messages are grouped logically into five groups, ordered by the most significant bit that is set:

(v)Setup & Control (types 0-31):
(x)Channel (types 32-127):
(Y)Commitment (types 128-255):
(w)Routing (types 256-511):
Custom (types 32768-65535): experimental and application-specific messages


inside the payload of say a onion_packet(w) it has its own payload called hop payload
and inside that it has its own payload called hop data
and that data is
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#legacy-hop_data-payload-format
Quote
   [short_channel_id:short_channel_id]
    [u64:amt_to_forward]
    [u32:outgoing_cltv_value]
    [12*byte:padding]
the amount is in Msat, and does not contain keys, or HTLC for a commitment.
it is not sending a signature or HTLC to change a channels commitment HTLC

if you read all the bolts(requested many times now) you would see many messages without payload in (Y or Z) format
the (y) format is in sats. other messages are in msats... get it yet.(different messages, do different things)
its not all related to commitment changes not everything is in Y or Z format

you want to think that LN payments are done via commitments HTLC messages or channels updates
(y)Commitment (types 128-255) (x)Channel (types 32-127)

but they are done at the string level on the outer box
(v)Setup & Control (types 0-31) or (w)Routing (types 256-511)

LN payments
the payload for the messages(v(w(?))) happening at the outer box string level is payments in Msats (before everything).
the payload is not in Y or Z formats. nor sat denominated

this is the LN payment stuff. right at the start where alice wants to pay eric. IT'S NOT COMMITMENT(changes at the point of already finding the destination and they all agree to accept with their fee's included). because participants dont yet know amounts to commit to (obviously)
get it yet. you cant commit to an amount that you dont know.
a commitment(y(z)) happens after the LN payment(v(w))

and again. before you say that the payload of (v(w)) is (y(z)) i have just shown you the hop data is Msat amount without any (z) stuff.
they dont know (z)HTLC yet because they dont know what they should commit to yet

this is because if alice wants to pay eric 1000.
1. (alice knows erics invoice details(v or uri). but doesnt know which route to take to pay him 1000)
2. alice sends exploratory(v(w)) message with a payload of 1000msat to bob)
    (alice asks bob if he can forward, bob wants 1 for his fee. so bob is willing to forward alice payload+1 (1001))
    bob sends exploratory(v(w)) message with a payload of 1001msat to carol
3. (bob asks carol if she can forward1001, carol wants 1 for her fee. so carol is willing to forward bobs payload+1(1002))
4. carol sends exploratory(v(w)) message with a payload of 1002msat to diana)
    carol asks diana if she can forward1002, diana wants 1 for her fee. so diana is willing to forward carols payload+1(1003)
5. diana asks eric if he can accept payment.
6. he acknowledges knowing he gets 1000(minus 3(fees))
at this point.
alice does not know that the actual amount is 1003 yet. because she has not yet got the route response(v(w))

on the response.  
7. diana then knows she has to pay 1000 to eric. so asks carol for 1001
8. carol then knows she has to pay 1001 to diana. so asks bob for 1002
9.bob then knows he has to pay 1002 to carol. so asks alice for 1003
0. alice then knows she has to pay 1003 to bob

at this point is when they update the commitment and send a (v(z)) message with commitment update message to their partner who then signs his side and (v) message back

these messages are done on the node level not the commitment level
also note that 6,7,8,9 include other data not related to commitment. and also note that 1,2,3,4,5,6,7,8,9 are messages measured in msat

yes. once receiving node level (outer box string messages denominated in msat) the nodes then look within their boxes to adjust their commitment box contents within the particular channel box content accordingly.

but dont confuse the msat payment messages of deciding what to sent how to send and what the fee is and the acknowledgement parts are commitments done at only commitment adjustment level.

again you cant adjust a commitment until you know something different that needs to be changed.
and a commitment is about commuting to something. so a commitment is not altered every time a message is received as it may not be in their favour.

the commitment is done AFTER and separate from the routing messages..
EG how does bob know he has to commit to 1002 with carol if he at point 1 has only got a message from alice for 1000
he has yet to try carol, and yet to get a acknowledgement from eric,diana,carol to then commit to 1002

i know you only want to speak about the inchannel direct payment to channel peer. where the only messages are done between JUST the string of the partners. where the only message is to update HTLC of commitments.

but your missing out on the outer box thinking of the LN network and the LN payment messages that hop across many strings multiple boxes away