Topic: [self-moderated] Is LN Bitcoin? franky1: About scaling, on-chain and off-chain - page 8. (Read 3193 times)

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.


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.


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


You are starting to troll.

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

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.


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.

hmm really?

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

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

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.


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.


It doesn't matter.


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



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

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

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


Here's what a proper message should look like:


Your message would look like this:


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.

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


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

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

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!

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


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.


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


Are you sure about that?


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.

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

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

A's committent transaction:


B's commitment transaction:



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.


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


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


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:


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

gotta laugh..

a HTLC is not specific to bitcoin. or to blockchain formatted stuff. and its not only used within LN for blockchain denominated contracts that can be broadcast to blockchains.

again (hop/route model scenario described before) if erics payment_hash was used in a commitment HTLC, and 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

LN payments(that route/hop through nodes) use a HTLC thats not the same data as the one inside a specific channels commitment.

just because you read HTLC it does not mean it only refers to a commitment.
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

you can have different ones in different things.
you can have them in channels using different blockchain chainhash. and in LN micropayments.

seems rath_ has not gained any new insight over the last day and just wants to stick to the bolt2 (again)(facepalm)(yawn)

that part he quotes. is about updating commitments..
a totally separate part thats not to do with LN payment messages

LN payment messages also can have their own HTLC.

for instance the commitment HTLC has terms of payment of the two partners
a LN payment HTLC has the terms of the final destination of a routes key being used by all nodes along the route.

the terms of the HTLC in a commitment are measured in sat
the terms of the HTLC in a Ln payment are measured in msat

---

ok. lets get to the crux of the consensus debate, by summarising your questions with questions of my own. to avoid your silly games.

1a. true consensus 'cause->effect' trail is: vote->threshold met-> activation -> issues with minority who are incompatible
[ * ] agree  [  ]disagree

1b. true consensus 'cause->effect' trail is: vote->issues with minority who are incompatible-> threshold met-> activation
[  ] agree  [ * ]disagree

2a. the bitcoin network mandated rejecting legacy/normal(2009-2016 standard format blocks) before segwit activated

• agree  [  ]disagree

2b. the bitcoin network activated segwit without mandating rejecting blocks that were not voting for segwit
[  ] agree  [ * ]disagree

2c. the bitcoin network never had a bit number change flagging for a mandatory rejection of normal blocks in july
[  ] agree [ * ]disagree


[moderator's note: consecutive posts merged]

That's not the question I'm asking.    

And again, I've given you free reign to remove any ambiguity if you feel you can give a more precise statement.  I'll highlight some of the reasons why I haven't used absolutes in some areas and request clarification from you about each specific question in regards to the issue you have:  

---

Consensus:

8. Any developer is free to code what they want.  <- This is an absolute statement.  Please highlight in what way it is "open" or "uncertain".
agree[ ]   disagree[ ]

9. Everyone will be free to run any code they choose.  <- This is an absolute statement.  Please highlight in what way it is "open" or "uncertain".
agree[ ]   disagree[ ]

10. If enough people run code with different consensus rules, change can happen even if a minority disagree.  <- If I had said "change WILL happen", this statement could be flawed.  As an example, the required activation threshold may not be met for one particular proposed ruleset if multiple different proposed rulesets are being run concurrently.
agree[ ]   disagree[ ]

11. If you run code which is incompatible with the code a majority of users are running, you can be disconnected from the network.  <- You are free to state "you WILL be disconnected" if you like.  However, you would need to be confident there are no exceptions to that statement.  I'm happy to leave margin for error, but you aren't compelled to.
agree[ ]   disagree[ ]

12. Features implemented by soft fork can be considered "opt-in" and you can continue to remain part of the network even if you don't want to use those features.  <- To say "you WILL continue to remain part of the network is incorrect, as someone may choose not to remain part of the network.  Anyone is free to leave the network at any time.
agree[ ]   disagree[ ]

13. If you are unhappy with the current consensus rules, there is no onus on any Bitcoin user to surrender to your demands.  <- Please highlight your issue with this statement
agree[ ]   disagree[ ]

14. If anyone wants features which are wholly incompatible with current consensus rules, it is reasonable to suggest they consider looking at other projects geared towards that purpose.  <- Please highlight your issue with this statement
agree[ ]   disagree[ ]

---

//EDIT:

You accept that I answered 3 of your questions, but you won't make an attempt to answer any of mine.  Instead, you avoid my questions completely and go on to ask different questions.  This is not conducive to establishing your level of understanding.


This applies equally to you.

Commitment transactions and HTLC are inseparable if you want to discuss whether or not we are dealing with empty promises.

Let me quote (my beloved) bolt2 again:


irrevocably commited = both parties sign a new commitment transaction, which includes an additional HTLC output. HTLCs can be a part of commitment transactions. For some reason, you ignore the sophisticated locking scripts and pretend that HTLCs can't be enforced on-chain. Before you brag that HTLCs use msats and not satoshis, read my reply to the end.


I took you a while to admit that nodes use "update_add_htlc" to forward payments rather than send "hop_data" or "onion_routing_packet" out of blue. They do update the commitment transaction. Again:


I am aware that commitments are denominated in satoshis while "update_add_htlc" uses msatoshis. Thus, I can agree that beside the commitment transaction, both parties create a promise that X amount of msats, which is less than 1000, belong to either of them. The rest of the coins are not a promise since they can be claimed on the blockchain through the commitment transaction. It would be a promise if the transaction was not signed by both parties.

Yeah, out loud.

You're the reason we're back to the circle. What worries you more? The fact that Lightning has subunit of a satoshi or that it doesn't move in the Bitcoin blockchain? Would you be happy if we stopped exchanging msats, but had sats instead?

Yes, because in both cases my money exist and transactions happen, because of a game theory. In Lightning it's the discouragement to cheat in a channel as you may lose all of your funds. In Bitcoin it's the discouragement to work for a 51% attack as it's less profitable.

so are you saying that in YOUR 'fact' (opinion) the currency inside LN payments is the same?
.. and now we full circle back to Msat discussion. and the 1:1000 peg.

are you certain that Msats are not used in the payment messages sent around the hop/route, where by in YOUR 'fact' (opinion) only bitcoin is used?

or are you saying that Msats are only bitcoin related and Msats are not used in other blockchain pegged channels and payments?

also in relation to things like 'turbo'(plus other LN use-cases).. are you really certain that Msats are locked/pegged to a 6 confirm ('locked') bitcoin blockchain utxo?

are you sure LN transacts "bitcoin"? even though "bitcoin" never leaves the bitcoin blockchain and the pegged/locked "bitcoin" you speak of is locked. and does not transact until its confirmed to have transacted on the bitcoin network.

now before replying. do not confuse the locked funding or the not on blockchain "commitment" vs the "LN payment" of messages denominated in msat.
do not try to say lightning only handles sat measured bitcoin 'payments' by discussing commitments that are never sent around hop/routes of the LN network, just to ignore the msat LN payment stuff that is sent around the LN network.

i played that game with rath_ already and it didnt work

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 Ridiculous part is that it wasn't an opinion, but a fact.

i do understand many nuances, and many details outside your groups narrow focused box of scripts you have recited.
and so gathered by the group mindset, and their many arguments, cries and recited scripts where they believe that LN is bitcoin. they can only think in one option. and consider any other option as something to reject and oppose and try to get rid of
because it doesnt fit their narrative

the only reason i done the questions in strict certainty of question wording, and answers in agree or disagree format, is because of the group cries that didnt want grey flimsiness.. i done it for the groups benefit

it is done to get to the crux of their stance of their opinion in a short, quick, hard certain form.
you cant cry that the questions are now more precise after the group cried that the first questions seemed grey.

reference to cry

funny part is you answered that question.. you then cried by adding in another opinion you wanted to set. which is why in the revision of the questions i added in extra questions to resolve your other opinion.

so dont cry to me that i didnt try.