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

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.

gotta love how you admit

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
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#basic-multi-part-payments

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

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


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



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


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?

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

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.


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.

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

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.

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

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.

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

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.


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.


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.


The logs also include commitment related messages.



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.


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

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

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)

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.


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.


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:



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:


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.

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)

This was years before BTCPay existed. Still works fine.


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

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.

---

Why did you do that? Why can't you just have a BTCPay Server installed and let it undertake your invoices automatically?

Let me correct you; it's a far more efficient way to transact than to update a ledger written in hundreds of thousands of hard drives.

That's a valid point, LN doesn't facility cold wallets. My counter argument would be that it's supposed to be used for smaller amounts, but it is indeed less secure.

I don't know if this is the argument that franky is making, but paying with Bitcoin doesn't technically require funds of either party to be online (in a hot wallet). Sender can sign the TX offline, receiver can give a cold wallet address to sender. Sender needs to broadcast it, receiver needs to verify it, but both don't need to be online at the same time or otherwise coordinated.

Back in the day I was rolling my own payment processing and it was extremely simple, efficient, and safe - pre-generate a bunch of cold addresses and hand them out to buyers. None of this is feasible with LN and it seems to be pushing merchant adoption towards custodial options.

Although technically correct, it's not a strong argument considering the mining fee is much higher than what the LN middleman charges.

True. But how often do you really do that? I don't mind keeping a device online when someone pays me.

But a computer somewhere at the bank must be online.

This seems off-topic.

All true. And I'm fine with that

funny part is bitcoin. the actual and only network called bitcoin(not to be confused with altnets)... bitcoin does not require the recipient to be online. nor does it need to pay middlemen to route and have liquidity and be online.

i can send coin to any address whether they are online or not and they will have it confirmed to them even if they dont look or check or ask for it.

i can wire transfer money to others bank account without them needing to be at their bank to accept it.
i can mail bank notes, gold, or other rare metals to people without them having to ask for it.

LN requires a co-signed agreement. and even after the agreement they need to be online to make sure the other party doesnt cheat.

Why is this even an argument against LN? Most of the internet requires both parties to be online, and billions of devices are online about 99.9% of the time. My debit card also requires both the shop as well as my bank to be online when I make a transaction. That's not a deal breaker.
And even though Bitcoin can work when the receiver is offline, it still requires both parties to be online and verify the transaction to complete the sale (or whatever deal we made).

I can only speak for myself, but I've said it for years: I don't really care how, as long as Bitcoin does scale! I wouldn't mind bigger blocks (I think it was 32 MB per block when Bitcoin started), but that caused a lot of drama. High fees aren't good for adoption, and although I agree with the argument that Bitcoin can't reach mass adoption by storing billions of daily transactions on-chain, I also think it would be a good temporary solution to allow more transactions until a more permanent scaling solution is created.

@Warless: This isn't the place for oneliners without arguments.