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

[Rath_]

again if erics payment_hash was used in a commitment HTLC then if that commitment was broadcast and confirmed on the separate bitcoin network.
eric has the secret to then sign out that UTXO to himself

I see that you can't read long pieces of code. Let me trim it a bit:

A's committent transaction:

Code: (https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs)

<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
[...]
OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG

B's commitment transaction:

Code: (https://github.com/lightning/bolts/blob/master/03-transactions.md#received-htlc-outputs)

<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_IF
        # To local node via HTLC-success transaction.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG

I can clearly see that you need either payment secret + B's HTLC signature or payment secret + A's and B's HTLC signature to spend the HTLC output. Eric knows only the payment secret.

just becasue you only want to reference a scenario describing a direct payment inchannel that doesnt involve routing/hopping. doesnt mean that routing hopping HTLC dont exist

I am not an English native speaker, but I learnt the meaning of "forwarding" at some point.

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.

I needn't have explained you what "irrevocably committed" means. It's been already explained in the specifications:

The respective addition/removal of an HTLC is considered irrevocably committed when:
    1. The commitment transaction with/without it is committed to by both nodes, and any previous commitment transaction without/with it has been revoked, OR

You keep saying that I am talking about direct payments, but you can clearly see that the last two quotes were extracted from "Forwarding HTLCs" section. In case you don't know what "forwarding" is:

to send a letter, email, etc that you have received to someone else

Before you send the incoming HTLC to someone else, you need to sign a new commitment transaction with an extra HTLC output with your partner. Only then you can safely forward it. If you don't send it further, the next hops won't know that such HTLC ever existed as they will never receive "onion_routing_packet", which is a part of "update_add_htlc".

[1714261345]

1714261345

[1714261345]

1714261345

[franky1]

again if erics payment_hash was used in a commitment HTLC then if that commitment was broadcast and confirmed on the separate bitcoin network.
eric has the secret to then sign out that UTXO to himself

I see that you can't read long pieces of code. Let me trim it a bit:

A's committent transaction:

Code: (https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs)

<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
[...]
OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG

B's commitment transaction:

i can tell your code is a scenario of just the commitment in channel HTLC of a direct payment where the destination is the channel party.(bob, not eric)
your now boring me with your obsession with the direct payment to bob example..

as it doesnt apply to routed/hopped payments

by the way the payment_hash inside that code is the alice or bob payment hash.. not erics

in a route/hop, scenario the situation is different and different messages are sent
eric does not get a alice or bob payment_hash
its actually alice, bob, carol, diana that use erics payment hash to 'pass the parcel'.(within LN payment messages, not commitments) which then(separately after) triggers channel partner negotiations of updating the separate and after commitment between the partners

again stop just referring to a alice-bob direct payment.. its boring and out of context, done just to avoid discussing LN payments in routes.

i have said multiple times about your avoidance of discussing the routed payment protocols.
and each time you just want to post code of inchannel direct payment to channel partner commitment examples

just take another day to try reviewing the other bolts

[Rath_]

by the way the payment_hash inside that code is alices(local), she sends that to bob(remote) who cant claim it without alices secret

No, the payment hash inside that code is a hash of Eric's secret.

its actually alice, bob, carol, diana that use erics payment hash to 'pass the parcel'.(within LN payment messages, not commitments) which then(separately after) triggers channel partner negotiations of updating the separate and after commitment between the partners

We're back to square one. Here's a simple question. How do all of these people communicate? You clearly can't use "onion_routing_packet" because you have admitted that it's a part of "update_add_htlc", which also triggers commitment update.

just take another day to try reviewing the other bolts

Okay, I have taken a look at bolt00. Here you go:

Forwarding

Such a conditional payment can be safely forwarded to another participant with a lower time limit, e.g. "you get 0.01 bitcoin if you reveal the secret within 5 hours". This allows channels to be chained into a network without trusting the intermediaries.
See BOLT #2: Forwarding HTLCs for details on forwarding payments, BOLT #4: Packet Structure for how payment instructions are transported.

(My beloved) bolt02 actually describes how payments are trustlessly routed through the network.

Oh, and in case you didn't notice: there's "forwarding" at the top which means "to send something you have received to someone else".

i can tell your code is a scenario of just the commitment in channel HTLC of a direct payment where the destination is the channel party.(bob, not eric)

Are you sure about that?

A Lightning channel only allows payment between two participants, but channels can be connected together to form a network that allows payments between all members of the network. This requires the technology of a conditional payment, which can be added to a channel, e.g. "you get 0.01 bitcoin if you reveal the secret within 6 hours". Once the recipient presents the secret, that bitcoin transaction is replaced with one lacking the conditional payment and adding the funds to that recipient's output.

See BOLT #2: Adding an HTLC for the commands a participant uses to add a conditional payment, and BOLT #3: Commitment Transaction for the complete format of the bitcoin transaction.

HTLCs are not necessary for direct payments as both parties could simply sign a new commitment transaction with updated balances without HTLC outputs. They are used to make the code look simpler, though.

[darkv0rt3x]

i do understand many nuances. gathering by the group mindset who believe that LN is bitcoin.

I honestly can't categorize this question to neither black or white. It's a misleading question that is interpreted differently by each individual. You're asking if LN is Bitcoin. In which terms? Network-wise? Of course they are not the same. Consensus-wise? Of course they are not the same. However, if I use Lightning I do use Bitcoin. The currency is the same. The way that transactions are accomplished is changed.

Also stop using these idiotic terms. Don't picture that you're shutting our mouths while we're crying, please.

funny part is you answered that question.. you then cried by adding in another opinion you wanted to set.

Funny Ridiculous part is that it wasn't an opinion, but a fact.

Not LN is Bitcoin as cents of Euros or Dollars are not Euros or Dollars! lol
If you agree that milisats are not Bitcoins, then, you must agree that cents (of Euros or Dollars) are not themselves Euros or Dollars. This is so ridiculous as it gets!

He, not only won't stop using those idiotic terms to insult other people as he keeps repeating himself.

I said a few posts back. He's not discussing LN nor Bitcoin anymore. He's discussing wording, semantics, grammar, synonyms and other language tools to try to brute-force his point of view to others! That's all. And the clock keeps repeating itself, as it is supposed to.

This guy will keep it coming even after he's been proven wrong over and over again by @_Rath and other members! He still using the same buzzwords like facepalm, ignorant and yawn (new one), to insult every other people!
More social drama as he calls it! But it's mostly on his side. That's the funny part!

[BlackHatCoiner]

More social drama as he calls it! But it's mostly on his side. That's the funny part!

No, the funny part starts once he comes shortly and insult you for bringing more social drama!

Let's see how many times he's (ab)used those words:

• buzzword: 231 times
• social drama: 353 times
• facepalm: 419 times
• yawn: 52 times

[franky1]

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. imagine 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 box call this (V(w(M))) M is for messages transmitted through w's via V in msat format
a LN payment is (V(w(M))) not (V(X(Y(Z))))

also 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))) for Ln payments in sats
(V(X(Y(Z)))) for commitment changes
.. there are hundreds of messages but lets just for demo sake just concentrate on two, as it seems you have preference for just 1 and i dont want to stretch you too far

now more technical version of the analogy explained
https://github.com/lightning/bolts/blob/master/01-messaging.md#lightning-message-format

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(v(w(?))) it has its own payload called hop_payload
and inside that hop_payload 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

   [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(M))) happening at the outer box string level(v) 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 or 1003 with alice 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,diana1003,carol1002 to then commit to 1002 with carol and commit to 1003 with alice

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

but you are ignoring the routing and hop messages of payments outside of channels

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

the reason i use analogies and simple common english. is because the bolts has all the technical stuff for those that want the technical waffle. i break things down into simpler explanations average joe can interpret(as long as they are not grammar nazi/ignorant insulting) so that other readers outside the technical people can learn something, in "common speak", not "elitist speak".

i know im about to get hounded by grammar nazi's saying that i used (V(X(Y(Z)))) instead of their favourite group decided buzzword of the month.. well tough. if you cant translate it back to your buzzword thats your failing of translation.

english is not just the queens elitist post scholar speak. it has many variations. someone from hacney speaks differently than someone from liverpool or glasgow.
if you just want to grammar nazi about 'its not posh english' go somewhere else and play games with other people. your boring

[Rath_]

https://github.com/lightning/bolts/blob/master/04-onion-routing.md#legacy-hop_data-payload-format

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

There are no keys or signatures in here because "hop_data" consists only of routing instructions for the current hop.

We have already agreed that "hop_data" is a part of "onion_routing_packet" which can be sent only through "update_add_htlc". Knowing all of that...

https://github.com/lightning/bolts/blob/master/01-messaging.md#lightning-message-format

[some payload analogies]

Here's what a proper message should look like:

Code:

Type: 128 (update_add_htlc)
Payload:
○ 32: channel_id
○ 8: id
○ 8: amount_msat
○ 32: payment_hash
○ 4: cltv_expiry
○ 1366: onion_routing_packet

Your message would look like this:

Code:

Type: ???
Payload:
○ 1300: hop_data

This is wrong because:
a) "hop_data" is encrypted. "onion_routing_packet" contains a compressed public key which was used to generate a shared secret for all hops. Thus, sending just "hop_data" doesn't make sense.
b) as your message would be non-standard (no type), the receiving node would ignore your message.

Code: (https://github.com/lightning/bolts/blob/master/01-messaging.md)

A receiving node:
upon receiving a message of odd, unknown type:
    MUST ignore the received message.
upon receiving a message of even, unknown type:
    MUST close the connection.
    MAY fail the channels.

[franky1]

your again ignoring the hundreds of different message types. just to circle back to your favourite message of the commitment HTLC update.

you really are becoming very very obvious. even when i point out your narrow minded scenario of only wanting to talk about commitments. you still repeat it.

think outside of the commitment box. and look at the the other hundreds of messages that are not commitment related. then you might see

again. the commitment HTLC is measured in sats.
a commitment HTLC 'packet' is not msat.

so you are only focusing on the one type of HTLC thats only suppose to be used in one place. again ignoring the other HTLC stuff in micropayments (ln payment) messages

not all HTLC go into a commitment. some are separate promises outside of commitments. done so people can have no harm, no lost value indicators of possible future things. like when routing. you cant commit to an amount before your sure of the amount that needs to be committed.

you need to learn about the whole network gossip stuff and routing. and not just only want to concentrate on the channel partner commitments after negotiations

[Rath_]

your again ignoring the hundreds of different message types. just to circle back to your favourite message of the commitment HTLC update.

Hundreds of different message types? I am all ears to you. When I asked you what kind of message is used in your example, you kept ignoring me or saying "hop_data", which we already know that is wrong.

you really are becoming very very obvious. even when i point out your narrow minded scenario of only wanting to talk about commitments. you still repeat it.
[...]
you need to learn about the whole network gossip stuff and routing. and not just only want to concentrate on the channel partner commitments after negotiations

I am really sorry that the Lightning Network is designed this way! There is no other standardised message other than "update_add_htlc" which includes routing instructions. Prove me wrong.

again. the commitment HTLC is measured in sats.
a commitment HTLC 'packet' is not msat.

It doesn't matter.

again ignoring the other HTLC stuff in micropayments (ln payment) messages

I believe that the following message is a valid Lightning (HTLC) message as per bolt01.

Code:

Type: 128 (update_add_htlc)
Payload:
○ 32: channel_id
○ 8: id
○ 8: amount_msat
○ 32: payment_hash
○ 4: cltv_expiry
○ 1366: onion_routing_packet

done so people can have no harm, no lost value indicators of possible future things. like when routing. you cant commit to an amount before your sure of the amount that needs to be committed

That's actually a good example. However, you don't know if nodes along the path have enough liquidity unless you try to send the payment through them. Otherwise, it would be possible to probe any channel at any time without having to lock up a large amount of coins in a channel.

I posted my node's debug log some time ago. My node failed to forward an incoming HTLC due to no liquidity ("CHANNEL_ERR_CHANNEL_CAPACITY_EXCEEDED"). You can see messages like: "update_add_htlc", "commitment_signed", "update_fail_htlc".

Code:

03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: peer_in WIRE_UPDATE_ADD_HTLC
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: NEW:: HTLC REMOTE 408 = RCVD_ADD_HTLC/SENT_ADD_HTLC
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: htlc added LOCAL: local 3828178009 remote 1171821991
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: -> local 3828178009 remote 1074154247

03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Creating commit_sig signature [REDACTED] for tx [REDACTED] wscript [REDACTED]
hsmd: Client: Received message 20 from client
3562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Creating HTLC signature [REDACTED] for tx [REDACTED] wscript [REDACTED]
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-chan#85: HTLC in 403 SENT_ADD_REVOCATION->SENT_ADD_ACK_COMMIT
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Sending commit_sig with 1 htlc sigs
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: peer_out WIRE_COMMITMENT_SIGNED

037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba-channeld-chan#29: Failed to add 1 remove 0 htlcs
037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba-channeld-chan#29: Adding HTLC 1126 amount=97653097msat cltv=716528 gave CHANNEL_ERR_CHANNEL_CAPACITY_EXCEEDED
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: FAIL:: HTLC REMOTE 408 = SENT_REMOVE_HTLC/RCVD_REMOVE_HTLC
03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: peer_out WIRE_UPDATE_FAIL_HTLC

[franky1]

your again ignoring the hundreds of different message types. just to circle back to your favourite message of the commitment HTLC update.

Hundreds of different message types? I am all ears to you. When I asked you what kind of message is used in your example, you kept ignoring me or saying "hop_data", which we already know that is wrong.

hmm really?

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

as for your choosily picking type 128 ..

Code:

Type: 128 (update_add_htlc)
Payload:
○ 32: channel_id
○ 8: id
○ 8: amount_msat
○ 32: payment_hash
○ 4: cltv_expiry
○ 1366: onion_routing_packet

hmm let me see, ooooo you chose a type that belongs to just the commitment..(no surprise)
yawn.. .. rath try once more. but this time without concentrating on commitments

.. but quick explainer.
but in that example, it only sends the update HTLC message after it has done many payment messages unrelated to changing the HTLC in a committent.
i know you endlessly only want to discuss stage 10 of 10.... but your forgetting stages 1-9

update htlc message is a trigger to then commit.
whereby after the message(128) LN code then rounds the msats to sats.
and does some other funky stuff. (commitments are not created first, to then send payment. its the other way round, payments trigger commitments. again how else will they know what to commit to unless they are told)
the commitment is then the end of the negotiation and pass over.

that payment hash. in that example is a hash from a channel partner, in a direct payment not a routed hop to eric.
its used as a temporary offset allotment of funds reserved for channel partner. not used from erics payment hash to pay eric.
in a routed hop payment erics payment hash is put into its own temporary format.

..
you do realise a channel is just a blockchain transaction template right. nothing more..
and its actually the messages between nodes that trigger changes to the blockchain transaction template.

whereby you cant change a template unless you know what to put in it.
you cant know what to put in it unless you have tried something outside the template.
like sending msat denominated messages to see if peers have liquidity and get them to gossip with their peers. (which needs no editing of a blockchain transaction template to achieve this)

also
things like min dust, min payment and min fee are not things found inside the blockchain transaction template

so
when you notice the things outside the template that get changed or viewed without having to change the blockchain transaction template. then you might see out of the box

[Rath_]

(w)Routing (types 256-511):
as for your choosily picking type 128 ..
hmm let me see, ooooo you chose a type that belongs to just the commitment..(no surprise)
yawn.. .. rath try once more. but this time without concentrating on commitments

No worries. I knew that you would point it out and I have already prepared myself. All of the "routing" messages (type-wise) are described in bolt07 (P2P Node and Channel Discovery).

bolt07 messages: announcement_signatures, channel_announcement, node_announcement, query_short_channel_ids/reply_short_channel_ids_end, channel_update, query_channel_range/reply_channel_range

Their types are: 259, 256, 257, 261, 258, 263, 264 respectively.

None of these messages include "onion_routing_packet", "hop_data" or any other routing instructions.

that payment hash. in that example is a hash from a channel partner, in a direct payment not eric.

No, it isn't. Payment hash is reused in HTLCs. PTLCs will use a different hash for every hop, but those hashes will be cryptographically related to one another.

[franky1]

onion routing is bolt 4..
https://github.com/lightning/bolts/blob/master/04-onion-routing.md
oh look its says '4-onion-routing'

routing gossip is bolt 7
https://github.com/lightning/bolts/blob/master/07-routing-gossip.md
oh look its says '7-routing-gossip'

your obsession and small box thinking is of your 'types' found in
(x)Channel (types 32-127):
(Y)Commitment (types 128-255):
which is YOUR obsession with bolts 2&3


but nice try trying to think only channel/commitment stuff exist or that there are only 7 messages related to whatever your trying to create a narrative of now

totally ignoring all the message types from 256-511

and again when eric sends his payment_hash to alice. who passes it to bob, carol, diana.
if those people actually put it into a blockchain transaction template. and signed it.
thats 4 people the then committed to pay to erics key. (which he knows the secret of)

the HTLC in a commitment are the pubkeys of the channel partners. not the key of someone multiple hops away

[Rath_]

onion routing is bolt 4..
but nice try trying to thing only channel stuff exist

Wait... you laughed at me because "update_add_htlc" type was "Commitment" and not "Routing", but when I listed you all messages that are of "Routing" type, you laugh at me because I didn't mention bolt04?

Unfortunately, bolt4 does not contain any (bolt1 formatted) messages. It describes their payloads.

and again when eric sends his payment_hash to alice. who passes it to bob, carol, diana.
if those people actually put it into a blockchain transaction template. and signed it.
thats 4 people wanting to pay to erics key. (which he knows the secret of

the HTLC in a commitment are the pubkeys of the channel partners. not the key of someone multiple hops away

Back to square one again. HTLC outputs also require valid HTLC signatures from both channel peers. You fail to comprehend that for some reason.


I see that you have edited your post.

but nice try trying to think only channel/commitment stuff exist
totally ignoring all the message types from 256-511

Oh really? I think that I have listed quite a lot of "Routing" type messages.

bolt07 messages: announcement_signatures, channel_announcement, node_announcement, query_short_channel_ids/reply_short_channel_ids_end, channel_update, query_channel_range/reply_channel_range

Their types are: 259, 256, 257, 261, 258, 263, 264 respectively.

None of these messages include "onion_routing_packet", "hop_data" or any other routing instructions.

You are starting to troll.

[franky1]

onion routing is bolt 4..
but nice try trying to thing only channel stuff exist

Wait... you laughed at me because "update_add_htlc" type was "Commitment" and not "Routing", but when I listed you all messages that are of "Routing" type, you laugh at me because I didn't mention bolt04?

Unfortunately, bolt4 does not contain any (bolt1 formatted) messages. It describes their payloads.

you didnt mention all the messages/types related to onion routing and gossip routing. you tried to pin them down to just 6 types.. by ignoring the rest
(you only wanted to mention 6 messages you know of relating to channels stuff.. AS ALWAYS)

also i pre-empted you by purposefully doing the (v(w(m)))
because the V is the type (described in bolt1) which encapsulates (w)channel gossip, or onion route packets

i did not say w(v) aka 4(1) which you are narrating as your narrative to be "bolt 4 does not contain bolt 1"
its actually infact bolt 1 contains bolt 7 or contains bolt 4

but nice try trying to ignore bolt 4 (onion routing) and then state onion routing is not found in bolt (whatever game your playing) and its never quoted by me as 7 being just about the onion packets

payments which require finding routes. and then sending onions packets is the bolt 7(find) with 4 as payload. ..
emphasis again. nice try taking bolt 4 messages and cry that you couldnt find them in bolt 7

your obsessed with the messages that trigger commitment changes. (x(y(z))) aka (2(3))
but you ignore the other types EG (v(w(m))) aka (1(7)) message to find channel and (1(4)) for the onion packet

you just sound like your doing a doomad now

[Rath_]

its actually infact bolt 1 contains bolt 4

Oh, great. So, you have just admitted that "update_add_htlc" (which can be bolt01 formatted) contains "onion_routing_packet", which includes routing instructions ("hop_data"). Now, read the "Forwarding HTLCs" section of bolt02 again and you will learn that you have to commit that HTLC (for your own security) before you forward it to the next hop. You also admitted that bolt04 describes the payload and not the actual messages that are sent to other nodes, so don't bother mentioning it in this case again.

I am not going to answer your bolt4/bolt7 ramble as it is clearly a trolling attempt, just like the HTLC signatures and payment secret case.

Good night, franky1. It was fun to argue with you again.

[franky1]

its actually infact bolt 1 contains bolt 4

Oh, great. So, you have just admitted that "update_add_htlc" (which can be bolt01 formatted) contains "onion_routing_packet", which includes routing instructions ("hop_data"). Now, read the "Forwarding HTLCs" section of bolt02 again and you will learn that you have to commit that HTLC (for your own security) before you forward it to the next hop. You also admitted that bolt04 describes the payload and not the actual messages that are sent to other nodes, so don't bother mentioning it in this case again.

I am not going to answer your bolt4/bolt7 ramble as it is clearly a trolling attempt, just like the HTLC signatures and payment secret case.

Good night, franky1. It was fun to argue with you again.

yep your definitely doing a doomad trick.

bolt 1 involves explaining all messages.. do not now make it be narrated that your opinion is that bolt 1 is purely about HTLC updates.

yea i know you dont want to talk about bolt 7 and 4, because then it means coming out of your bolt 2&3 box

[DooMAD]

yea i know you dont want to talk about bolt 7 and 4, because then it means coming out of your bolt 2&3 box

Except for the part where Rath_ definitely has spoken about bolt07 and bolt04 and explained to you why they don't mean what you think they mean.  Here it is again as you appear to have missed it:

All of the "routing" messages (type-wise) are described in bolt07 (P2P Node and Channel Discovery).

bolt07 messages: announcement_signatures, channel_announcement, node_announcement, query_short_channel_ids/reply_short_channel_ids_end, channel_update, query_channel_range/reply_channel_range

Their types are: 259, 256, 257, 261, 258, 263, 264 respectively.

None of these messages include "onion_routing_packet", "hop_data" or any other routing instructions.

bolt4 does not contain any (bolt1 formatted) messages. It describes their payloads.

Also, I'm still waiting on a response on my previous post about consensus.  Kindly answer some of my questions before you attempt to add more of your own.  

[franky1]

yea i know you dont want to talk about bolt 7 and 4, because then it means coming out of your bolt 2&3 box

Except for the part where Rath_ definitely has spoken about bolt07 and bolt04 and explained to you why they don't mean what you think they mean.  Here it is again as you appear to have missed it:

All of the "routing" messages (type-wise) are described in bolt07 (P2P Node and Channel Discovery).

bolt07 messages: announcement_signatures, channel_announcement, node_announcement, query_short_channel_ids/reply_short_channel_ids_end, channel_update, query_channel_range/reply_channel_range

Their types are: 259, 256, 257, 261, 258, 263, 264 respectively.

None of these messages include "onion_routing_packet", "hop_data" or any other routing instructions.

bolt4 does not contain any (bolt1 formatted) messages. It describes their payloads.

yes which is where he is pulling a doomad

what rath_ is doing is although the fact of the actual writing of the bolts is that bolt 1 sets the type. and inside it are certain messages..
rath wants to narrate that its bolt 4 that then has bolt 1 inside.
its actually bolt 1 that then has 4 inside

i even pre-empted that game HOURS before he tried it by doing the (v(w(m)))
and i have explained it many times now..

he also tried to take some limited points about bolt 7, and pretend i said bolt 7 is purely about onion packets. when infact its bolt 4.

routing (both channel gossip and onion packet messages) are concerning both 4 and 7.

..
raths original game was to only want to narrate the flow of conversation towards the inchannel changes of bolts 2&3 which have nothing to do with the payment messages and forwarding stuff that involve bolts 4 and 7

Also, I'm still waiting on a response on my previous post about consensus.  Kindly answer some of my questions before you attempt to add more of your own.  

i did answer your question. but without having to play around with blue writing to edit the question, i just wrote some out to get to the real context of the contention/argument/debate
(second half of this post)
https://bitcointalk.org/index.php?topic=5380215.msg59001987#msg59001987
my answers have never waivered, and never been contradictory and i have stood by them for  years. so its more important that you answer them due to your own contradictions and flip flops. that way we can get to the actual opinions you want to stay strong on to actually know which narrative you wish to proceed on .. to hopefully end the contradicting narrative games

anyways
now lets get to the consensus topic doomad wants to discuss.. and ill do so by explaining what "doing a doomad" is

.. for 4 years doomad has been spouting endlessly that there was never a mandatory activation. he stated that bips91 and 148 were never used.
and then deviated to pretend 2 other bips were used and tried to play games about how there is no mandatory wording in his other bips he suggests were used.

the thing is. bips91 and bips 148 were used and both mention about rejecting blocks that dont signal to activate segwit.
he might forget/ignore that the blockchain data actually shows the bit flags in the block data of the bips involved in bip91 and 148.
even pieter wuille and theymos were quoted as saying it was used.
he might keep forgetting just to spin his narrative into his ignorance of wanting to talk about other bips.. but thats just him doing a doomad. (saying something unrelated and then suggest whats unrelated doesnt contain the related things.)

summary

There's no such thing as a "mandatory fork" in Bitcoin.

you might want to check devs own wording of bip148
https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
mandatory 'activation day flag" is mentioned a few times
"  Title: Mandatory activation of segwit deployment"

bip91
https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki
"While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected. "

bip 91 is blue line and bip 148 is red line

red(bip91) caused blue(148) to spike to 100%
doomad wants to only discuss things after august 2nd 2017 and avoid the stuff that happened from march-august1st 2017


rath wants to talk about channel changes to commitment and avoid all the messages about value movements that lead upto needing to commit

.. im bored of watching these groupies play these games.. goodnight

[Rath_]

rath wants to narrate that its bolt 4 that then has bolt 1 inside.
its actually bolt 1 that then has 4 inside

I have never said that. You are probably referring to this quote:

bolt4 does not contain any (bolt1 formatted) messages. It describes their payloads.

I hope that you read it too fast and misunderstood it. Let me repeat again.

bolt04 does not describe any independent messages than can be sent in bolt01 format. bolt04 describes payloads that can be included in other standardised messages.

For example, bolt04 describes "onion_routing_packet". It can't be sent as an individual message. You need to put in the payload of "update_add_htlc" message as per specifications.

he also tried to take some limited points about bolt 7, and pretend i said bolt 7 is purely about onion packets. when infact its bolt 4.
routing (both channel gossip and onion packet messages) are concerning both 4 and 7.

Don't forget that we were talking about bolt01's "Routing" type messages. As bolt04 does not describe individual messages, but payloads, they can't be bolt01 formatted.

but you ignore the other types EG (v(w(m))) aka (1(7)) message to find channel and (1(4)) for the onion packet

I am ignoring your (1(4)) message as it is a non-standard message and it would be discarded by other nodes. Again, here's what your message would look like.

Code:

Type: ???
Payload:
○ 1300: hop_data

This is wrong because:
a) "hop_data" is encrypted. "onion_routing_packet" contains a compressed public key which was used to generate a shared secret for all hops. Thus, sending just "hop_data" doesn't make sense.
b) as your message would be non-standard (no type), the receiving node would ignore your message.

And before you say that (4) refers to "onion_routing_packet" and not "hop_data", think about it again. "onion_routing_packet" can't be sent as an individual message as well. You need to send it through a standard message, like "update_add_htlc".

Here's what a proper message should look like:

Code:

Type: 128 (update_add_htlc)
Payload:
○ 32: channel_id
○ 8: id
○ 8: amount_msat
○ 32: payment_hash
○ 4: cltv_expiry
○ 1366: onion_routing_packet

[franky1]

i know you only know of the channel and htlc update stuff

and now your narrative is that onion routing is not encapsulated in a bolt 1 format

but then you contradict yourself by saying bolt 4 messages are payloads of standardised messages(as set by bolt 1)

so you are playing grammar games, as your way of ignoring bolts 1,4,7 just so you can quote 1 usage found in bolt 2, where that single usage is about direct payments to partner

...
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#packet-structure

   type: onion_packet(0x00)
    data:
        [byte:version]
        [point:public_key]
        [1300*byte:hop_payloads]
        [32*byte:hmac]

^ this here is the (1) aka (V)

The hop_payloads field is a structure that holds obfuscated routing information, and associated HMAC. It is 1300 bytes long and has the following structure:

   type: hop_payloads
    data:
        [bigsize:length]
        [hop_payload_length:hop_payload]
        [32*byte:hmac]
        ...
        filler

^ this is the 4 aka w of (1(4) aka (v(w)[/color]

   type: hop_data (for realm 0)
    data:
        [short_channel_id:short_channel_id]
        [u64:amt_to_forward]
        [u32:outgoing_cltv_value]
        [12*byte:padding]

^ this is the m of (1(4(m)) aka (v(w(m))

so now, take yourself off of the bookmarked bolts 2& 3 pages. and explore the pages of the other bolts more.
try to think outside of your channel management box, and think about the node functions, node messages between peers outside of a direct payment scenario