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

[franky1]

1. "LN allows private agreements".. has the word agreements in it. .. its not trustless. it requires both parties to be amicable. even the punishment cant be auto-trusted to work in un-amicable scenarios, it has flaws.

This has become tiring... I've repeatedly mentioned that it's a game theory. You read and write only what's in your interest. Yeah, Lightning payments are just IOUs and LN is designed to destroy Bitcoin. Keep thinking that way, I give up.

Now if you disagree there's no trust during the Lightning transactions, then everything you've said it's true. Including the analogy with the bank notes. However, I do agree it's trustless.

i know you want to keep being adamant about the funding commitment and using it as a settlement in times of non-amicable LN session..
but thats just your ignorance not wanting to enter the discussion of LN PAYMENTS

you know. the 'hop routing of millisats'

A<>B<>C<>D<>E
although you(A) have a funding or settlement commitment for you vs partner B.. there is no such final 'commitment' contract of you vs E(recipient of payment)

during the payment.. ill EMPHASISE PAYMENT. it requires B,C,D,E to be online to pay E.
E is not 'trustlessly' guaranteed to be paid when A<>B make a promise at the start of the pass the parcel game. or when E starts by giving a htlc public key to A at the start of the pass the parcel game
alot of things can go wrong during an LN PAYMENT

..
however on bitcoin. (the real bitcoin network not to be confused with altnets pretending to be), on bitcoin i can pay E direct and there is no need of any 'watchtower'/'punishment' need to be online..  or being online just to receive. or online just to initiate, or a way to take back funds after confirmation. or any of the other flaws.

i know you only want to direct back to talking about the A<>B funding/punishment as a 'backup' protection. but your forgetting that LN PAYMENTS are usually outside of the A<>B 'game theory' because its actually a PAYMENT trying to succeed between A and E, again the A and E PAYMENT can fail for many reasons.
EG delaying signing millisat promises of B<>C   C<>D   D<>E
EG not passing the HTLC secret
EG not being online
EG not having liquidity

call LN payments by any buzzword you like
(onion-routed-payments)(HTLC invoices)(microchannel payments)(millisat promises)(hop payment)
but atleast learn the difference between the LN payment promise of say A to E vs the 'commitment of A<>B

just stop trying to talk about the A<>B funding commitment just to avoid the game theory of LN payments to E.

oh and by the way.
B does not update the A<>B 'commitment'. until after E promise is signed,  which then pases to D, which then passes to C, which then passes to B

in short:
(alice paying eric)

B doesnt get to update a commitment until point 9, not point 2

B cannot spend(settle) a 'payment' until point 9 has completed
(A wont sign a commitment until it receives R(private key))

lots of things can go wrong between 1-9
there is alot of permissions required and trust and amicable 'hopes' for payment success needed during 1-9

..
by the way, A,>B do not create a 'commitment' at 2 using H(erics public key) in a commitment. because A<>B know eric has the privatekey(R) and if A or B broadcast a commitment with H, eric can jump in and send funds to where he likes using R.
and at point 6 and 7 diana and carol also have the private key(R).. so they can also 'spend' the A<>B.. if A<>B were to 'commit' using H as a output

LN payments are IOU promises measured in millisats that contain the H, but not in the format of a bitcoin transaction. it wont succeed in being accepted by the bitcoin network for many reasons of not being a bitcoin transaction, as its a different format specific to LN and only understood within LN

in short 1-8 are not bitcoin transactions. Bob cant just receive R at 8 and broadcast without doing 9. because 1-8 are millisat measured promises, and only becomes a 'commitment(requiring permission via 2 signatures) after point 9.


.. isnt it just funny that out of the multiple pages i have been the only one using references to back up my 'opinion'.. yet others opinion is backed up foolishly with 'i think its how it works so you are wrong because its not what i think'(lacking evidence, references)

[1714514770]

1714514770

[1714514770]

1714514770

[1714514770]

1714514770

[Rath_]

B does not update the A<>B 'commitment'. until after E promise is signed,  which then pases to D, which then passes to C, which then passes to B
[...]
(A wont sign a commitment until it receives R(private key))

Alice finds various paths and needs to try them one by one to see if selected nodes have enough liquidity to forward her payment. There is no other way to do that other than to send "update_add_htlc" and sign a new commitment transaction.

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

Once both nodes have exchanged funding_locked (and optionally announcement_signatures), the channel can be used to make payments via Hashed Time Locked Contracts.

Changes are sent in batches: one or more update_ messages are sent before a commitment_signed message, as in the following diagram:

    +-------+                               +-------+
    |       |--(1)---- update_add_htlc ---->|       |
    |       |--(2)---- update_add_htlc ---->|       |
    |       |<-(3)---- update_add_htlc -----|       |
    |       |                               |       |
    |       |--(4)--- commitment_signed --->|       |
    |   A   |<-(5)---- revoke_and_ack ------|   B   |
    |       |                               |       |
    |       |<-(6)--- commitment_signed ----|       |
    |       |--(7)---- revoke_and_ack ----->|       |
    |       |                               |       |
    |       |--(8)--- commitment_signed --->|       |
    |       |<-(9)---- revoke_and_ack ------|       |
    +-------+                               +-------+

I have already proved that in this post by showing you my node logs. If one the selected nodes is unable to forward the payment due to no liquidity in the outgoing channel, it sends "update_fail_htlc".

Please, don't bring up "funding_locked" again. It is used only to signal that the funding transaction has reached enough confirmations for the channel to operate safely.

by the way, A,>B do not create a 'commitment' at 2 using H(erics public key) in a commitment. because A<>B know eric has the privatekey(R) and if A or B broadcast a commitment with H, eric can jump in and send funds to where he likes using R.

No, Eric can't do that. HTLC outputs in commitment transactions require not only the payment secret to be spent but also a valid HTLC signature.

When you open a channel, you share your htlc_basepoint, which is a compressed public key used only for HTLC payments in this particular channel. The other node shares their htlc_basepoint as well.

You can use htlc_basepoint and per_commitment_point to calculate local_htlcpubkey and remote_htlcpubkey.

Now, let's take a closer at locking scripts of HTLC outputs. Commitment transactions are asymmetrical which means that there are two possible scenarios:

1) (Offered) HTLC output in Alice's commitment transaction:

Code:

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

If remote_htlcpubkey (Bob's HTLC pubkey) is on the stack then the provided secret (the payment preimage) is hashed and checked against the payment hash. Otherwise, this output can be spent via a HTLC-timeout transaction which is timelocked and signed by both parties beforehand.

Eric or any other intermediary node cannot spend this output as they cannot produce a valid signature for that public key.

2) (Received) HTLC output in Bob's commitment transaction:

Code:

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <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
    OP_ELSE
        # To remote node after timeout.
        OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

If remote_htlcpubkey (Alice's HTLC pubkey) is on the stack then the provided secret (the payment preimage) is hashed and checked against the payment hash and the output can be spent via a HTLC-success transaction.

Again, Eric or any other intermediary node cannot spend this output as they cannot produce valid signatures for these keys.

HTLC-timeout and HTLC-success transactions, which require both Alice's and Bob's HTLC signatures, consume HTLC outputs and create another locked output which is delayed so that the other party has enough time to broadcast a penalty transaction if necessary.

[franky1]

again your trying to show the A<>B millisat payment and commitment by blending them into one bx of ascii art

your ascii art of the bolts 2. is that -(1)->   -(2)-> -(3)-> is the LN millisat promise part simplified.
YOUR (1)(2)(3) is the same three 1,2,9 (using the diagram in my last post)millisat payment promise updates between alice and bob..
the commitment in your ascii art (4) doesnt happen until after your ascii art (3) has happened (my diagram9)

as for your other 2 boxes of text. that again is the commitment bits that happen secondary.
again your confusing the a<>b stuff with the payment of a-b-c-d-e

remember eric gives alice the payment_hash for the micropayment (millisat promise) with bob (not commitment)
bob uses the payment_hash to carol for his micropayment (millisat promise) with carol (not commitment)
carol uses the payment_hash to diana for her micropayment (millisat promise) with diana (not commitment)
diana uses the payment_hash to eric for her micropayment (millisat promise) with eric (not commitment)
eric then gives diana the payment_secret which she passes to carol who passes to bob who passes to alice

payment_hash=erics pubkey (H)
payment_secret=erics privkey (R)

they all then update as success and then make the commitment
whereby the commitments outputs = local_htlcpubkey remote_htlcpubkey

dont confuse the micropayment millisat promise of erics cycle of H and R through ABCDE, with the commitment of just AB.

because if you really think there is no ABCDE millisat micropayment temporary promise using H and R. and you think H and R are only used by commitments and only commitments exist. then erics H is going to be in AB's commitment which if AB broadcast such a commitment. then eric can spend the utxo put into his H using his R

you need to realise the different parts and how an LN payment is different to a commitment.

the LN millisat payments use erics H and R.. in your steps (123 of your ascii art first box)(129 my diagram)
the commitments(45) uses AB keys AFTER (123your first ascii box)(129 my diagram)

as you can see using my diagram in my last post
at the LN PAYMENT(emphasis) alice gets erics H at 1. and needs to get erics(R) to complete at 9
if alice was to put erics H into a commitment and then broadcast it.. eric could use his R to redeem money to him meaning alice and bob get nothing.

thats why LN payments are separate and another reason why they dont get broadcast. aswell as being in a format not understandable to bitcoin network. to prevent eric from scamming alice and bob.

at (your ascii art step 4) the actual commitment creation stage. yes alice make a commitment using their own AB agreed keys, not erics key used in the LN payment millisat promise.

as for you saying in your post that you explained it already using your node logs

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

please note this is not the commitment. but the LN payment.
you can tell because it says to add "amount=97653097msat" and we all know a "bitcoin commitment" does not handle msats. so whats being signed. is not a bitcoin commitment but a msat based LN payment

the confusion is your misunderstandings of commitments vs payment..
maybe because you have soo many buzzwords
payments via "Hashed Time Locked Contracts" vs commitments
payments via "Msat invoices" vs commitments
payments vis "micropayment channel contracts" vs commitments

your second and third code box of 'commitments' you numbered 1&2 are actually your ascii art(first box) 4
where they are only committed if the LN payment fails(HTLC-timeout) or succeeds(HTLC-success)

.. oh and um one last thing
when talking about payments in LN.. dont confuse the matter by using bolt2 (channel management) and instead use reference from bolt11 (invoice payment)

[Rath_]

remember eric gives alice the payment_hash for the micropayment (millisat promise) with bob (not commitment)
bob uses the payment_hash to carol for his micropayment (millisat promise) with carol (not commitment)
carol uses the payment_hash to diana for her micropayment (millisat promise) with diana (not commitment)
diana uses the payment_hash to eric for her micropayment (millisat promise) with eric (not commitment)
eric then gives diana the payment_secret which she passes to carol who passes to bob who passes to alice

Alice offers Bob an HLTC ("update_add_htlc") and waits for "commitment_signed" which contains signatures for the commitment, HTLC-success and HTLC-timeout transactions.

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

Forwarding HTLCs
Requirements

A node:

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

Bob won't talk to Charlie unless he signs a new commitment transaction with Alice. If you believe that Bob and Charlie can communicate in a different way, tell us what kind of messages they use.

because if you really think there is no ABCDE millisat micropayment temporary promise using H and R. and you think H and R are only used by commitments and only commitments exist. then erics H is going to be in AB's commitment which if AB broadcast such a commitment. then eric can spend the utxo put into his H using his R

thats why LN payments are separate and another reason why they dont get broadcast. aswell as being in a format not understandable to bitcoin network. to prevent eric from scamming alice and bob.

Did you read the other half of my post? Eric also needs two valid HTLC signatures that can be produced only by Alice and Bob.

as for you saying in your post that you explained it already using your node logs

The logs also include commitment related messages.

Code:

2021-12-30T02:00:21.308Z DEBUG   03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Creating commit_sig signature [REDACTED] for tx [REDACTED] wscript [REDACTED]
2021-12-30T02:00:21.310Z DEBUG   hsmd: Client: Received message 20 from client
2021-12-30T02:00:21.310Z DEBUG   03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Creating HTLC signature [REDACTED] for tx [REDACTED] wscript [REDACTED]
2021-12-30T02:00:21.311Z DEBUG   03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-chan#85: HTLC in 403 SENT_ADD_REVOCATION->SENT_ADD_ACK_COMMIT
2021-12-30T02:00:21.365Z DEBUG   03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Sending commit_sig with 1 htlc sigs
2021-12-30T02:00:21.366Z DEBUG   03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: peer_out WIRE_COMMITMENT_SIGNED

you can tell because it says to add "amount=97653097msat" and we all know a "bitcoin commitment" does not handle msats. so whats being signed. is not a bitcoin commitment but a msat based LN payment

The receiving node routes down the value to whole satoshis before preparing and signing the commitment transaction. The sending node does the same for their version of the commitment transaction. If either of them doesn't do that, the HTLC can be failed.

when talking about payments in LN.. dont confuse the matter by using bolt2 (channel management) and instead use reference from bolt11 (invoice payment)

bolt11 describes only how a payment invoice should be encoded/decoded.

[franky1]

you still do not realise that 2 vessels of data are signed independently of each other.
(actually its 3 but i wont complicate things)
first a LN payment(data not in blockchain accepting format, and contain millisat units) and separetly commitments (sat units in blockchain accepting format)

you are using bolt 2 which is one part of things.. missing the point of micropayments which is another part

the millisat payment comes first. and is then rounded up/down into sat commitment as a second part
i know most of you groupies only want to talk about the inchannel stuff of blockchain formated commitments. but at least learn about the other stuff too

where there is a value exchange between A<>B, commitments are formed after the 'success' or 'timeout'

but you have to realise that when trying to pay E(eric), via D(diana), via C(carol) a different part of things is used. where by a different message format measured in millisats is used and encoded in 'onion' layers of sphinx encryption.

but it is funny how you are using bolt2 (Peer Protocol for Channel Management).
and avoiding yet again:
bolt4: (Onion Routing Protocol)
bolt11 (Invoice Protocol for Lightning Payments)

i get it you dont want to learn LN, or you dont want to admit there is more to LN as a independent network.
i get it you want to pretend everything in LN is dependent on bitcoin format transactions..

but its not.

the HTLC in a LN payment (which also has amount measured in msat) which is wrapped in onion 'sphinx' encryption. sent to peers along a route, is different to the timeout/success commitments that happen just within a channel after they need to update due to the success/time out of the LN payment(msat payment wrapped in sphinx encryption)

the bolts tries to explain that
payment_hash (same for all parties involved in a route).. and its payment _secret (same for all parties of a route) is for the msat payment.

separetly the localpubkey remotepubkey(just between channel peers) and revoke keys(just between channel peers) are buzzwords for the channel commitment

just because both commitments and route payments both say "htlc" does not mean the specific HTLC happening during a route is the same data as a HTLC happening within a channel

HTLC is basically saying is a contract. an agreement but with complex conditions.
it does not mean that the contract is of only one format that is acceptable to blockchains.

a htlc can be a commitment(blockchain format) or a LN payment (msat denominated format)..


if you truly think that if A wants to pay E. only commitments are done. and commitments are signed before B pays C. and c pays D and D pays E..
then B can run away with A's funds before E has been paid.
sorry thats not how it works

payments are done as a separate HTLC(in msat) and once E has received the payment_hash from D, who got it from C, who got it from B who got it from A(who got it from E). then E knows to send payment_secret to D, who passes to C, who passes to B who passes to A. and then A and B make the commitment where B is deserved the value

inside the spinx encoded onion payments that go through a,b,c,d,e they all get the exact same payment_hash to use. and they all use the same payment_secret to validate the payment is success. which then triggers the commitment part to update which doesnt use the routed payment has/secret but instead the channel peers own pubkey and revoke key


..
funny thing is. although i have many reasons to not like LN, it seems i have done more research or atleast able to describe LN in its many functions.. yet the LN groupies seem to be ignorant to reveal features, or just lacking the research to understand the features, or even just avoiding explaining the features to set some narrative.

..
if LN groupies actually bothered to learn all the LN features. and understand them, and see the differences of them. they could actually use it to create some good PR campaign of why LN is a niche service for certain utility.. instead of being ignorant/avoiding features, just to prime some weird narrative that LN is fixed to or is bitcoin

[BlackHatCoiner]

Not from a merchant's POV. There is more hassle involved in receiving LN payments for no tangible benefit.

Isn't your customers' satisfaction a tangible benefit? Whenever I see Bitcoin as a payment method, but without Lightning, I'm a little more discouraged to do the transaction. For instance, I don't want to broadcast another transaction every month for the $10 of Spotify.

Also, if I had made all those transactions on-chain the merchant would have a ton of UTXOs. I've saved them money in fees.

[LoyceV]

millisat payment

Would you be more okay with Bitcoin LN if the minimum amount would be 1 sat? If so, it's probably not that difficult to adjust the software and start your own node.

Whenever I see Bitcoin as a payment method, but without Lightning, I'm a little more discouraged to do the transaction.

Me too, but that's mainly because Bitpay has "conditioned" me to fear their additional consolidation charges. They've also conditioned me to stay away from any site that uses Bitpay, but I've seen others do it too (and usually those amounts are much bigger than what I pay on-chain).

[DaveF]

Sigh...
I think part of the problem is that there are several different conversations going on here and nobody seems to get the point that I have made elsewhere but am going to go ahead and do it one more time.

Lets start with the basics:

1) I use BTC and run my own nodes and deal with a lot of my own payments.
2) I use LN and run my own nodesand deal with a lot of my own payments.
3) I use altcoins other crypto and may or may or may not run my own nodes and may or may no deal with a lot of my own payments depending on the coin.
4) I am and we are for the most part here rare edge cases.

Over the last 5 or 6 years I have encouraged many merchants to accept BTC / crypto.
I have been successful a few times. Some went to Coinbase Commerce, some went to BitPay, some went to coinpayments.net and others I did a BTCPay server for.
As of now none of the BTCPay servers are active. They just did not want to deal with it.
Businesses are in the business of doing business. NOT worrying about payments. They have to take payments to do business and just about all of them want it quick and simple with NO or minimal interaction on their part.
So BTC / LTC / ETH / Lightning /  Dave's itchy left testicle coin they don't give a shit. Because 99% of the time they just convert to fiat and move on.

People like us here, care about BTC.
If we want massive adoption, guess what most people will not give a flying fuck about bitcoin any more then Visa / Master Card / AMEX / Discover. It's a means to an end for most people to conduct commerce.
What we talk about here  about holding and invest or just save or convert to fiat are the rare edge cases.
There are several large businesses you can read about in the press section of this board that are now accepting BTC / crypto.
They all are using 3rd party processors and they all are getting fiat. Do you think they are about BTC / LTC / ETH / Lightning / Dave's itchy left testicle coin? No they don't they just want their fiat. and don't care how it gets to them.

Stop giving people FUD to talk about and push for acceptance of all of it. The rest will take care of itself.

-Dave

[suchmoon]

Not from a merchant's POV. There is more hassle involved in receiving LN payments for no tangible benefit.

Isn't your customers' satisfaction a tangible benefit? Whenever I see Bitcoin as a payment method, but without Lightning, I'm a little more discouraged to do the transaction. For instance, I don't want to broadcast another transaction every month for the $10 of Spotify.

Also, if I had made all those transactions on-chain the merchant would have a ton of UTXOs. I've saved them money in fees.

What percentage of online purchases are paid for with Bitcoin? What percentage of those are paid for with LN? At merchants who have both those options along with fiat payments.

As much as some customers might be satisfied paying with exotic payment methods, there is a threshold were such options are too costly and cumbersome for the sales (and satisfaction) it could possibly bring in. Most businesses would happily pay the extra 20 cents per UTXO or whatever it is, if they can avoid  maintaining yet another service and dealing with all the other crud - imagine training customer service reps on troubleshooting LN payments. They might be enticed to utilize LN payments if it's offered as a custodial hands-off solution so there's probably a business opportunity for someone here.

I have been successful a few times. Some went to Coinbase Commerce, some went to BitPay, some went to coinpayments.net and others I did a BTCPay server for.
As of now none of the BTCPay servers are active. They just did not want to deal with it.

Similar experience here. I still have some clients running self-hosted payments but only because I support them for free basically, and even take the bitcoins off their hands if they want to.

[franky1]

millisat payment

Would you be more okay with Bitcoin LN if the minimum amount would be 1 sat? If so, it's probably not that difficult to adjust the software and start your own node.

seems even now with your post being the 71st post of this topic
you and certain people want to pretend everything in LN it bitcoin format, where you want to brand tag an altnet as being bitcoin. by also saying LN is permissionless contracts that all can broadcast because 'its bitcoin'.... but then.. yep you slip up and make contradictions by admitting LN does handle millisats payments which are not blockchain compatible.

can you all stop the flip-flop(aka contradictions) and learn
1. difference between bitcoin locked value on the blockchain vs the 1:1000 pegged millsat LN payment
2. learn the unbroadcast commitment that use channel peers pubkey vs LN millisat payment using destinations payment_hash
3. LN millsat payments(aka invoices aka htlc aka sphinx onion encrypted payments) (whatever buzzword of the week you please) is not the same as a bitcoin broadcastable transaction
4. learn the bitcoin protocol does not have LN dns, peer handshaking, channel create code

if you can learn that there is no separate 'bitcoin LN network' and separate "litecoin LN network" and realise the LN network is its own network of its own protocols that allow channels with different pegged coin.

if you actually learn the differences of why LN is not bitcoin. then you can learn to actually PR campaign based on the differences, and give people some reason to want to use LN for the niche use cases where bitcoin doesnt fit their need.

trying to call it bitcoin lightning network as if the LN network is the bitcoin network. is just misleading

EG
you shouldnt say "dollar visa payment network" or "pound visa payment network". instead its just the visa network that can handle different currencies where visa is not "dollarL2", nor "dollar network"

if you continue to say "visa is dollar" people will laugh at you

[Rath_]

but it is funny how you are using bolt2 (Peer Protocol for Channel Management).
and avoiding yet again:
bolt4: (Onion Routing Protocol)
bolt11 (Invoice Protocol for Lightning Payments)

Let me repeat again. bolt11 describes only how a payment invoice should be encoded/decoded. As for the bolt4:

This document describes the construction of an onion routed packet that is used to route a payment from an origin node to a final node.

bolt4 describes how the onion packet is constructed and how it can be validated by each node. It does not describe how it is passed around. Here's a piece of information from bolt2:

Code: (https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc)

The format of the onion_routing_packet portion, which indicates where the payment is destined, is described in BOLT #4.

    type: 128 (update_add_htlc)
    data:
        [channel_id:channel_id]
        [u64:id]
        [u64:amount_msat]
        [sha256:payment_hash]
        [u32:cltv_expiry]
        [1366*byte:onion_routing_packet]

The "onion_routing_packet", which contains encrypted instructions for each hop, is a part of "update_add_htlc". So, Carol doesn't know anything about Diana unless Bob sends her "update_add_htlc". Bob can't send it unless Alice replies with "commitment_signed" and they finish exchanging revocation keys. Why? Again:

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

Forwarding HTLCs
Requirements

A node:

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

If you still disagree, tell me what kind of message nodes use to forward the "onion_routing_packet" without triggering the update of the commitment transaction.

the millisat payment comes first. and is then rounded up/down into sat commitment as a second part

That's exactly what I have said in my previous post:

The receiving node routes down the value to whole satoshis before preparing and signing the commitment transaction. The sending node does the same for their version of the commitment transaction. If either of them doesn't do that, the HTLC can be failed.

payment_hash (same for all parties involved in a route).. and its payment _secret (same for all parties of a route) is for the msat payment.

separetly the localpubkey remotepubkey(just between channel peers) and revoke keys(just between channel peers) are buzzwords for the channel commitment

Payment secret and payment hash are also used in the locking script of the HTLC output in the commitment transaction.

payments are done as a separate HTLC(in msat) and once E has received the payment_hash from D, who got it from C, who got it from B who got it from A(who got it from E). then E knows to send payment_secret to D, who passes to C, who passes to B who passes to A. and then A and B make the commitment where B is deserved the value

You still haven't answered my question. How do all of these nodes communicate? How do they forward the onion packet?

Is there anyone here who is following our discussion?

[franky1]

gotta love how you admit

the construction of an onion routed packet that is used to route a payment from an origin node to a final node.

but then backtrack to avoid discussing the payment, to then recite the channel management.
yep you went straight back to referencing bolt 2.

try to read a bit more of bolt 4
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#legacy-hop_data-payload-format

The hop_data format is identified by a single 0x00-byte length, for backward compatibility. Its payload is defined as:

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

Field descriptions:

    short_channel_id: The ID of the outgoing channel used to route the message; the receiving peer should operate the other end of this channel.

    amt_to_forward: The amount, in millisatoshis, to forward to the next receiving peer specified within the routing information.

https://github.com/lightning/bolts/blob/master/04-onion-routing.md#basic-multi-part-payments

Basic Multi-Part Payments

An HTLC may be part of a larger "multi-part" payment: such "base" atomic multipath payments will use the same payment_hash for all paths.

Note that amt_to_forward is the amount for this HTLC only: a total_msat field containing a greater value is a promise by the ultimate sender that the rest of the payment will follow in succeeding HTLCs; we call these outstanding HTLCs which have the same preimage, an "HTLC set".

payment_metadata is to be included in every payment part, so that invalid payment details can be detected as early as possible.
Requirements

The writer:

    if the invoice offers the basic_mpp feature:
        MAY send more than one HTLC to pay the invoice.
        MUST use the same payment_hash on all HTLCs in the set.
        SHOULD send all payments at approximately the same time.
        SHOULD try to use diverse paths to the recipient for each HTLC.
        SHOULD retry and/or re-divide HTLCs which fail.
        if the invoice specifies an amount:
            MUST set total_msat to at least that amount, and less than or equal to twice amount.
        otherwise:
            MUST set total_msat to the amount it wishes to pay.
        MUST ensure that the total amount_msat of the HTLC set which arrives at the payee is equal to total_msat.
        MUST NOT send another HTLC if the total amount_msat of the HTLC set is already greater or equal to total_msat.
        MUST include payment_secret.
    otherwise:
        MUST set total_msat equal to amt_to_forward.

what you need to learn a local inchannel HTLC for the in channel 'commitment uses the partners pubkey

Ln payments along routes use a pubkey of the destination(payment hash) and along the route or if part paying across multiple routes the same payment hash(destination pubkey) must be used

LN payments sent along the peers (separate from channel commitments) are measured in msat
..
still laughing how you rushed back to bolt2 and ignored the other bolts.
it seems you are stuck in the 2015 LN protocol and dont want to move forward to the 2018 "micropayment" update to the protocol when they added more bolts when they finally got LN to be fund peggable after segwit.

oh and fun fact LN first usecase was on testnets, thus not bitcoin network specific
oh fun fact, LN done atomic swaps from different blockchains before anyone even used Ln to purchase real products with bitcoin pegged funds

[philipma1957]

I create this topic because I challenged franky1 to join a civil discussion with all arguments in one place:

@franky1: If I create a self-moderated topic (Lauda called me Switzerland for being neutral; I won't delete any of your posts, but I will call you out if you go off-topic), are you willing to engage? I expect it will be "you vs a couple of other users", but from what I've seen, you can handle yourself. I would like to discuss your points on LN that I've seen in far too many different topics, and it would be nice if we can reach consensus on at least part of the discussion.

My invitation was accepted by franky1:

i can engage.
and out of respect i will even take my own advice and step back from the computer between posts and take some breathing time between posts, and avoid (as i see other do)just hitting reply to rage reply.
 
if others can do the same. and answer without shining their bias/advertising PR stance of utopia, and respond rationally and thinking outside their small box. then great

it could actually lead to some proper dialogue.

Anyone else than franky1: I will delete unfriendly posts, and I will delete off-topic posts. See my unedited archive when that happens.

Rules Guidelines:
Please keep this topic civil.
Please keep the discussion only here, and not in other topics.
If there's something worth reading in another topic, quote it here instead of posting a link.
Try to limit the scope: don't throw 30 different arguments in one post, it will lead to endless replies. Update: separate posts in a row aren't allowed, so making different posts for each argument won't work. BlackHatCoiner expressed intentions much better:

I want to add this as a condition: We'll speak of one topic at a time. Scalability? Scalability. Lightning's protocol? Lightning's protocol. Consensus? Consensus. This way we can clarify which are our interlocutor's disagreements and constructively (& friendly) correct them.

Read everything before responding. Try to avoid duplicate replies.
Newbies: read more, post less, and create an informed opinion.
To consider: I removed franky1 from my ignore list. I think that's only fair considering the topic I started.


To start: I use on-chain Bitcoin, and I use Bitcoin LN. Bitcoin can work with or without LN, LN can't work without Bitcoin. I don't like high fees, as it limits adoption. I would like to see Bitcoin grow in value, userbase and number of transactions per second, and I think we need all three of those for Bitcoin to grow. How, that's up for debate.

LN is a different network for a reason. it has its own usecase and niche and utility that differs from bitcoins.

Nice work .

I am glad you did this.

At franky1 if btc writes code to alter from 0.00000001 to 0.0000000001 and it is voted on via miners do you concede that to be okay.

note  I said sats to 1/100 sats

or eight digits to ten digits.

[franky1]

At franky1 if btc writes code to alter from 0.00000001 to 0.0000000001 and it is voted on via miners do you concede that to be okay.

note  I said sats to 1/100 sats

or eight digits to ten digits.

bitcoins reward math. bitcoin transaction data is not 0.X.. its actually measured in sats.
to make the smallest unit subdivide even further requires breaking and bastardising many bitcoin rules.

if you look at the byte data(raw tx) of a tx of 1000sat,  its not 0.00001000  its actually 1000

EG if a legacy UTXO had 1000sat locked to the key. and a BStard transaction format was measured in msats
the then code would think that the 1000 unit of legacy is only 1sat (1000msat)

also the block reward. its not 6.25/2/2/2/2/2/2/2/2
its actually 625000000 /2
or more technically, in binary:
100101010000001011111001000000
were the end bit is dropped every 210,000 blocks

if a new BStard transaction format of msat protocol viewed:
100101010000001011111001000000
it would convert is to not still be 6.25btc but instead appear at GUI as 0.00625btc because the unit of measure has shifted by 3 decimals at GUI level

this means to cludge the code with more code to fix that. the current
100101010000001011111001000000  (6.25bt legacy)
which has 30 halvings left (30 bits to drop)
would need to be changed to
1001000110000100111001110010101000000000
with 40 halvings. meaning it also breaks the 20140 year cut off. and changes it to be 2180 before supply depletes

and also more code ontop to recognise old legacy/segwit formats and convert a legacy/segwit utxo value from
100101010000001011111001000000
to
1001000110000100111001110010101000000000
and if someone wanted to go back to a legacy utxo. the reverse (4bit varient to 30bit varient)
in short, alot of cludgy code and alot of bug risks of translating bytes and crap

..
also with 1000x more sharable units. that can be split and shared around. this also changes the scarcity.
EG no one cares about only 190,000 tonnes of gold. if there is enough gold dust for everyone to have, its not scarce because everyone can have some gold

[Rath_]

but then backtrack to avoid discussing the payment, to then recite the channel management.
yep you went straight back to referencing bolt 2.

try to read a bit more of bolt 4

Again, routing instructions are a part of the onion packet, but bolt4 does not describe how to pass this information around, which is what we were talking about.

Code:

Packet Structure

The packet consists of four sections:

    a version byte
    a 33-byte compressed secp256k1 public_key, used during the shared secret generation
    a 1300-byte hop_payloads consisting of multiple, variable length, hop_payload payloads or up to 20 fixed sized legacy hop_data payloads.
    a 32-byte hmac, used to verify the packet's integrity

"hop_data" is a part of "onion_routing_packet". It is a piece of data that each hop receives in an encrypted format, which tells them who they should forward the HTLC to (via "update_add_htlc"). You don't send just "hop_data" to the next destination. You need to send the whole "onion_routing_packet" through "update_add_htlc".

You still haven't answered my question. How do nodes forward the "onion_routing_packet"? You have just learnt that they need to forward it because it contains (encrypted) instructions for every hop. How do they do it, though?
I keep asking that question because you insist that nodes do not sign a new commitment transaction before communicating with the next node in the routing path, which is not true.

I am not sure why you keep bringing the msat thing over and over again. I have already admitted that one side asks the other to add an HTLC denominated in msat and expects signatures for the commitment, HTLC-timeout and HTLC-success transactions denominated in satoshis as a reply. If the other side does not reply with valid signatures then the HTLC is failed.

[BlackHatCoiner]

Is there anyone here who is following our discussion?

I'm following, although I struggle understanding how franky corrects you. His technical writeups make it infeasible to read and understand.

if you can learn that there is no separate 'bitcoin LN network' and separate "litecoin LN network" and realise the LN network is its own network of its own protocols that allow channels with different pegged coin.

How's that true? Can't you verify if the channels you're routing transactions exist in the Bitcoin blockchain?

As much as some customers might be satisfied paying with exotic payment methods, there is a threshold were such options are too costly and cumbersome for the sales (and satisfaction) it could possibly bring in.

Sure. But, if one out of the ten merchants starts accepting Lightning he makes the difference. The rest have an inferiority when it comes to payment methods. I honestly don't know if the elasticity of demand from such change gives greater profits than the extra costs. I suspect that if the merchants like Bitcoin they will get involved with it and handle it properly. I mean how much dedication do you need to maintain your channels?

[franky1]

your trying to set a narrative that channel partners update a commitment and then send a "onion_routing_packet"
what you are not realising is what i said a few posts back. with the colourful image cycle of 1-9 alice to eric

you do know that users along a route cant create a commitment update until they have first received a LN payment. else how will they even know what they have to update the commitment by. (oh wait is LN now featuring psychic powers?)

also at the update_add_htlc, they dont update the commitment. they create a LN micropayment promise

this update_add_htlc is a private message between channel partners that update their own micropayment promise.
this micropayment promise is measured in msat and includes the destinations payment_hash as the 'output'

its not the channels commitment that uses the channel partners pubkeys. its a "micropayment" msat format using the payment_hash

once an payment succeeds then they update the commitment. because then and only then has B deserved been paid by A.
if there is a route fail. then the Ln micropayment promise just gets dropped

please take some time to read ALL the bolts. and try not to fear moving away from your adamant desire to only read bolt 2

..
actually.. seeing as you love bolt 2

https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc

Adding an HTLC: update_add_htlc

Either node can send update_add_htlc to offer an HTLC to the other, which is redeemable in return for a payment preimage. Amounts are in millisatoshi, though on-chain enforcement is only possible for whole satoshi amounts greater than the dust limit (in commitment transactions these are rounded down as specified in BOLT #3).

The format of the onion_routing_packet portion, which indicates where the payment is destined, is described in BOLT #4.

    type: 128 (update_add_htlc)
    data:
        [channel_id:channel_id]
        [u64:id]
        [u64:amount_msat]
        [sha256:payment_hash]
        [u32:cltv_expiry]
        [1366*byte:onion_routing_packet]

as you can see "update_add_htlc" is the msat message including the "onion_routing_packet"
update_add_htlc is not a trigger for create new commitment

[Rath_]

your trying to set a narrative that channel partners update a commitment and then send a "onion_routing_packet"

No, one side sends "onion_routing_packet" in a "update_add_htlc" message and then commitment update is expected as per specifications (see last quote in this reply for explanation).

you do know that users along a route cant create a commitment until they have first received a LN payment. else how will they even know what they have to update the commitment by. (oh wait is LN now featuring psychic powers?)

I do know that and that's what "update_add_htlc" does.

this channel update is a private message between channel partners that update their own micropayment promise.

What exactly is that private message in your opinion? That's what I have been asking you the whole time.

please take some time to read ALL the bolts. and try not to fear moving away from your adamant desire to only read bolt 2

Please, take some time before replying to my posts and show me the actual pieces of code from the official specification which back up your statements.

as you can see "update_add_htlc" is the msat message including the "onion_routing_packet"
update_add_htlc is not a trigger for create new commitment

You make me repeat the same things over and over again.

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

Forwarding HTLCs
Requirements

A node:

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

As per specifications, the node which receives "update_add_htlc" MUST commit the HTLC by signing a new commitment transaction (a series of "commitment_signed" and "revoke_and_ack" messages between both peers) before forwarding the payment further (sending "update_add_htlc" to the next hop).

The receiving node knows the next hop because it obtained this information from the "onion_routing_packet" which was included in "update_add_htlc".

[franky1]

HTLC is not a specific term which means commitment

HTLC is basically "complex contract"
a LN millisat format payment has a HTLC ..

just because you see something that says HTLC does not mean it refers to the commitment

AGAIN:
a LNmillisat payment HTLC has units of measure in msat and also uses Erics payment hash for all users (ABCD)
a commitment HTLC(different) uses only the pubkeys of the channel partners and is measured in sats

a commitment is an inchannel management thing that occurs after the out of channel payment of routing packets

please try, for the multiple time of telling you. to learn the differences

last time im going to say this.
a HTLC is not "commitment". it refers to a whole range of transactions and formats that use HTLC
so stop trying to say 'it makes a commitment because it says HTLC.

oh and one last thing
bolts2 (the thing your addicted to) uses examples of old old protocol where its describing examples of 'hub' payments (where channel partner is the destination)
try to read the newer bolts. that explain more of the routing and payments of others in hop models using micropayments.

you cant comit to rounding up a millisat to a sat. until you know the millisat payment is complete..

otherwise if alice is trying to pay Eric.  if it was alice commiting to bob first. bob could then broadcast his win he never asked for.. and because its the latest commitment(in your scenario fantasy). bob cant be revoked. and so bob gets the win. eric doesnt get paid and alice is out of money.

sorry but thats not how it works. bob only gets paid after eric gets paid (ref the image several posts ago of 1-9 alice to eric)

[Rath_]

a LNmillisat payment HTLC has units of measure in msat and also uses Erics payment hash for all users (ABCD)

That's correct.

a commitment HTLC(different) uses only the pubkeys of the channel partners and is measured in sats

A commitment transaction with HTLC outputs uses the public keys of the channel partners, their HTLC public keys and the hash of the payment secret. See the second half of this post again.

a commitment is an inchannel management thing that occurs after the out of channel payment of routing packets

The specs literally say that one should not forward an HTLC unless one can enforce the contract on-chain.

bolts2 (the thing your addicted to) uses examples of old old protocol where its describing examples of 'hub' payments (where channel partner is the destination)

It's exactly the opposite. Direct payments could work just fine without HTLCs. The main purpose of HTLCs is to enable payment routing.

otherwise if alice is trying to pay Eric.  if it was alice commiting to bob first. bob could then broadcast his win he never asked for.. and because its the latest commitment(in your scenario fantasy). bob cant be revoked. and so bob gets the win. eric doesnt get paid and alice is out of money.

franky1, come on. You seem to completely ignore the fact that TWO commitment transactions are signed for each Lightning payment. The first transaction is supposed to prevent the situation you described from happening. The transaction contains additional (HTLC) outputs with locking scripts which I described in the other half of this post.

Bob has no real reason to broadcast his commitment transaction with HTLC outputs unless Carol claims his HTLC and Alice stops cooperating, and refuses to sign another commitment transaction without the HTLC output.

The second commitment transaction is signed once Bob sends "update_fulfill_htlc", which includes the payment preimage, to Alice. It's the transaction you have been talking about all the time.