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

Nevertheless, you are ignoring the fact that you can connect to any Lightning node even without having any active channels and start syncing the map of the whole network. Even if Alice is stuck in the "ABCDE" fraction of the network, she will eventually connect to some outside node. The same goes for every other member of the fraction.

You acknowledge the existence of the initial sync, but you insist that Alice knows only about "ABCDE".

---

Bob can also send a "channel_update" message to disable his side of the channel with Carol. Alice would not be able to send payment in the BC direction, but she could still receive a payment in the CB direction.



You are changing your assumptions again. Now, you are saying that BC channel is public, but B refuses to let Alice use it. Even if Bob doesn't send "channel_announcement" and then "channel_update" to Alice, she will eventually learn about it from other Lightning nodes as you assume that Diana knows about that channel all the time. Diana forwards every Carol's "channel_update" message.


It would be a waste of time for Alice to message Bob and ask if he made any changes. Alice should use the information from her local map as it's the fastest way. Bob has no real reason to postpone sending "channel_update" message, which would reach Alice immediately.

---

I am not breaking any "PR campaign claims" as it is common knowledge that you can learn a lot of information about public nodes; Lightning explorers (amboss.space/1ml.com) are more popular than you think. This does not change the fact that Lightning payments are private.


"channel_update" is usually sent to advertise updated fee rates of a channel. For example, c-lightning has recently introduced a grace period:


So, even if someone uses an old feerate in their "onion_routing_packet", the payment won't fail (for a certain period of time). If the feerates are too old then the payment is failed (update_fail_htlc) and the exact error is reported through this message.

Some error messages, which are always encapsulated in "update_fail_htlc" as per bolt04, might actually include the latest "channel_update" so the sender can try resending the payment immediately.


Again, "channel_update" is not sent across the network when you send someone an invoice or when you are in the middle of routing a payment. If either was the case, what would be the reason? Take a look at "channel_update" again.


Which of these parameters in your opinion change when you send someone an invoice or when you are routing a payment? My answer is: none. If there are no changes to those parameters then the update is not necessary.

---

Watchtowers need only txids of revoked commitment transactions and actual penalty transactions for each commitment, to function properly.


created_at, parts, amount_msat, amount_sent_msat, destination are all known before the payment is sent.

payment_hash is a part of the invoice. payment_preimage is known upon receiving "update_fulfill_htlc". status relies on "update_add_htlc", "update_fail_htlc" and "update_fulfill_htlc" messages.

if you want to deposit gold into a bank vault to then have a bank note promising to be backed by that amount of gold. fine. vault it up first. ensure its locked and witnessed. and ensure its signed to get a promissory note..
but then if the bank starts offering bank notes not backed by gold.. dont trust the bank note. its not backed

---

as for saying insults.
you might want to use some word finder tools and actually look at this topic. find who uses the most insults and which words were the worst words used... it may surprise you

when five repeated people of a group throw many insults(of varying degrees) in my direction, i laugh, i yawn. i facepalm..
when i call those 5 in the group "fangirls" they act as if its a savage attack and they have been murdered

you can play the victim card. but that card is a blank bit of paper of no substance, wave it all you like. saying your a victim does not make you a victim

Wait for a sec, franky. Do you think that including this into parentheses will make it look less significant? Okay, so what does it mean that a bunch of services decided to open channels without having the necessary confirmation(s)?

I'll take Exodus as an example, which is a closed-source Bitcoin wallet. What does it mean if its developers decided to not allow you double-spend your transactions using RBF? That Bitcoin is faulty or that Exodus is a bad choice?

This is definitely not the case. I don't believe that the map of the network remains the same nor the its nodes are always up-to-date of all details. Some even go offline, but they must not be many. If you provided me some valid statistics, we could negotiate this.

Let's assume that we do, which is not true but let's say that we do. You insult all the time. How does that differentiate you from us?

I'm sure Bitcoiners know that everyone isn't honest nor they want their good. That's why they're using Bitcoin.

You just opened a can of worms. You've no idea how many franky's nonsense posts will follow if you decide to continue this further.

actually the logical limit is 4200tx a block. about 7tx/s (which was stated even back in 2010)
we have never had a single hour, day or month where its had an average of 7tx/s

the most we actually get on average is under 2500tx a block(4.16 tx/s)
https://api.blockchain.info/charts/preview/n-transactions-per-block.png?timespan=3years.

this this limit has been purposeful prevented from being lifted. for multiple reasons.
the main excuse is the pretence we still work with 1990's tech (dial-up and floppy disks)
where 4mb every 10 minutes has been deemed too slow (facepalm)..

but with that all said. thank you for proving my point that you too want to propagandise the narrative that bitcoin cant scale, just to hide that certain people dont want it to scale.

i know you also want to propagandise that you believe bitcoin needs to be 100mb a block this year to 'scale' to this years daily use. but thats just exaggeration on the part of the group you also cling to.

on average. a human only buys (in life) 1-3 things a day. so if we take LN's 1Ml stats(rath believes is complete public view of all LN users) thats 33,000 nodes. (some are sybil nodes of same user)
but lets take this 33,000 as a exaggerated userbase (i know the user numbers are lower due to multiple nodes per user, but ill go with the number to actually give a number that helps LN feel comfy with high users)

so 33,000 * lets say.. hmm 5 payments a day. lets be generous
thats 165,000 payments.

bitcoin at an average of say 1700tx a block * average 144 blocks a day=244800
bitcoin has the bitcoin Dev consent that 4mb is ~acceptable(if uncludged by other limits) which could allow 1-2.4m/day

which is more then whats needed.
so please stop thinking bitcoin needs to scale to 1.7mill transactions a block(244m a day) this year just to cope with the presumed LN advertised usage.(LN group rhetoric of needing 100mb blocks to scale(facepalm))

because even my exaggerated usage is actually is not even 1mill a day, definitely not needing to scale to 244m a day.

emphasis: bitcoin scaling. not LN narrative bitcoin leaping.

as for other networks that peg locked funds(LN included) they can have their niche services for certain features. as long as they advertise them HONESTLY and actually mention what makes them different to clearly advertise their unique usecases and the risks users may encounter.

emphasise: stop pretending bitcoin is dead, cant grow.. to pretend that altnet pegs are the only way forward

Wait, you think the Bitcoin blockchain scales? We basically have a hard limit of transactions per second of around 20.
12 thousand transactions per block (10 minutes) means 20 transactions per second and some pocket change. This will never suffice without off-chain (or other? sidechain?  ) scaling mechanisms.

Franky, you're always going deep into implementation details that half of the people here can't even understand; let's see it from a high-level perspective: how do you think Bitcoin adoption should work on a large scale purely based around the blockchain? Recording every little transaction, every micropayment, every in-game purchase, everything on the almighty blockchain? It will clog up bad.

I mean, even with the super controversial SegWit introduction we only went from 10 tx/s to 20 tx/s... I would be very interested how you envision scaling to the required hundreds to thousands range (of tx/s... that's 1-2 orders of magnitude) without going off-chain, purely on a high level.

(until you learn about turbo and other services that open channels with msat balance without the 6confirm funding lock)
(which cannot then commit to anything because the 'locking' utxo is not actually confirmed to have a block number.)

buy hey, i guess people dont want to know things, and instead want to shout insults if anyone tries making users risk aware.
but hey, you can instead believe the utopia of network maps being always full and uptodate of all details to not need to check nodes.
you could instead believe that everyone is honest and symbiotically wants whats best for you.
you could believe its permissionless (even though it requires TWO signatures(someone elses authorisation))
you could instead believe that LN is 100% successful. and all other utopian adverts are true. but then you are putting yourself at risk.

---

when i show bips that prove there are over 500 messages types. and even some of those have dual purpose.. yet someone else says everything is only done via 3 messages. you can see who is hiding things the most.

but hey if you think that there are only 3 messages types and those 3 messages are blockchain formatted transactions.. you keep dreaming that. enjoy your sleep

---

it would be better if those promoting LN actualy showed how and why its different to bitcoin. then it may reveal real niche usecases they can actually promote. rather then the usual "bitcoin is broke and wont scale, everyone should use this alternate network instead" game.

if anyone is still unsure. lets use Lightning-C. () asadvertised by Rath
https://github.com/ElementsProject/lightning#sending-and-receiving-payments
https://lightning.readthedocs.io/lightning-pay.7.html

there are other things about monitoring the progress of payments (inflight)
and there is even juicier stuff if you have the time about how 'payments' are stored locally. spoiler its not in a blockchain formatted transaction.
even things like feature to allow watchtowers to hold onto a 'revoke' payment to use when one side cheats. the watch tower does not get/store blockchain format transactions

If only it was that simple. You have to make your point with arguments. Even if I consider franky a troll, I can't just say to everyone that he's a liar and I'm right. The whole point of the thread is to show why and where he's right/wrong.

Also, there's no way newbies reach the 10th page of this mess.

This topic reminds me of my debates with franky1, but this topic is on steroids. BUT let’s make it simple. Newbies, whatever the trolls say to disinform you, whatever the trolls post to gaslight you, YOU only need to know that those coins in channels are signed transactions that have not been broadcasted and included in the blockchain yet. No one in Lightning is sending something worthless in the network. They are literally BITCOINS.

1. you mistook my saying of YOUR mindset that YOU still think update_add_htlc is a command to changes blockchain format transaction output (which i facepalmed)
here is some clarity to your grammarism game



2. ok so below is you again thinking everything is done by a network map everyone has publicly.. i did laugh, ill explain my laughter after the quotes



notice all the wants, decides, if's, cans..
try not to imagine the utopia of a central mempool(DNS server) for all nodes to access, showing all nodes channels of the whole network.(like you have been suggesting, then contradicting and then suggesting again, as if its the sole source of information ever needed)
 and instead imagine each node with its own mempool of only data it can see from its peers which its peers has allowed it to get

i know you want to emphasise a quote of andreas saying "whole network" but thats not the reality. its actually local built based on only the peers with direct path to you publicly. (there may be other peers on path that are private or just decide to go silent on such queries)

example of small map
EG imagine your own scenario of your small box direct payment to bob.. where its only in your view ever a alice-bob negotiation..
guess what. alice doesnt know zoe and in your scenario bob doesnt know carol.. so in your map. based on your small box scenario you try deviating back to your map is just 1 branch of bob.. not a tree of thousands of branches..

example of missing branch map
EG imagine the ABCDE  where your alice and im bob. i can be public with BC meaning carol can tell diana all about me and becasue i told carol about you(alice) diana knows this too.. but here is the thing. i can just refuse to reply with my BC channel when talking to you.

you do realise that there are many messages that happen separate to the initial sync map build.. right?
and the map is only as good as the peer connections allow.

---

i know you think that the only way for bob to dissuade alice from using bob as a route to carol is for bob to rack up his min fee to 1btc a hop. .. where bob has to stay public all day but with a large fee to prevent alice using his BC as a route path..
(an old trick people told each other years ago)

but you can actually just break the branch in the map and tell alice that the BC channel is not available by responding to a query without mentioning BC channel. or even just telling alice your BC is shutdown/offline
meanwhile carol can tell diana it is available and online, which tells eric

.. alice can later just query bob and bob can decide to respond. or bob can send an update message to alice to change this.
it does not require alice having to turn off-on her app to trigger another gossip challenge. or patiently wait for an invoice to trigger a map update.

---

oh and seeing as you want to break the PR campaign about privacy not being private, to fit your narrative
are you now trying to break the "instant payment" PR campaign of needs to wait for map updates, to fit your narrative

because in your view payments can only be made when network maps are updated, which only happen infrequently, which cant happen IN YOUR VIEW 'on the hop'(adhoc) by messages during a payment, but instead IN YOUR VIEW by waiting for nodes to announce to update a map. which are themselves delayed during their own payments being 'inflight'(pending)

so if you want to say that a payer cannot make a payment while another node is 'inflight' with a different payment for their different reason, because its not yet updated to tell YOUR map.

just know that YOU are really calling out that LN is not 'instant' and not 'fast', just to fit a narrative to your opinion

Alice doesn't need to send any messages as she should be able to extract all the information she needs from her local network graph.


Thank you for finally admitting that "update_add_htlc" enforces commitment update.


Again, all the data she needs to prepare "onion_routing_packet" should be obtainable from her local network graph.

---

As both of us are probably getting tired of the "contradiction game". I invite you to play the "quote game".

I am quite sure that you know Andreas Antonopoulos and you must have read "Mastering Bitcoin" at some point. Let me introduce you to "Mastering The Lightning Network".

The gossip protocol:


You said that Alice has only B, C, D, E (completely ignoring that BC is a private channel) in her local map of the network.

i mentioned private channels as one example, due to your assumption everything is public as if there is a central 'mempool' of ALL channels that all nodes has access to. so that in your view commitments can be signed without checking with peers or recipients.

infact each node has a different 'tree' layout depending on their particular pass the parcel game with their particular tree. where some branches of said tree are broke off for multiple reasons

i simple used an example of where:
1. its a pass the parcel game, not central mempool all nodes talk with
2. due to not only private channels,(other examples apply('turbo' shouldnt announce while unconfirmed)) not all channels are passed back to a node (pass the parcel game)
3. parameters do change. fees, cltv, many other parameters

i would have mentioned many other examples, but seeing as for pages of posts you have had particular issues getting yourself out of the 'direct payment to channel partner' scenario.. i thought i would take things slowly on you. give you a chance to gently come out of your box.
EG one step, realise its not just commitment signings but actually lots of messages
EG two step, messages are in msat and not blockchain formatted transaction templates
EG three step, not all nodes psychicly know everything when they open the app or minutes/hours later(things change)
EG four step, show more messages and scenarios that contravene your commitment signing thoughts of how LN work

your fluctuating between step 1-2, but your trying to pull it back to step minus 0
your not at step 3 yet

EG YOUR "update_add_htlc forces commitment update'. where YOUR thinking the only messages are update_add_htlc (again facepalm)

here is something for you to think about outside of your box

take a second. and think.
an incoming HTLC... hmm....  how is that formed(what data is inside this incoming htlc).
next
how is the data in that incoming HTLC collated/determined/checked/viewed before alice sends it to bob
(before bob sees it)

yep before alice even sends bob an (incoming to bob) alice needs to do stuff, which requires lots of messages.

i know you think that there are only 3 times a node gets gossip.
1. app opening initialisation to get a map
2. invoice received. to add a node and then add to map (60 seconds later)
3. when a node within the map updates due to a successful payment or a shutdown

but you are wrong. nodes can actually send query messages and respond to queries aswell.
nodes also can change their fee anytime they please. they are not arm-strung into sticking with the same fee at app-open or channel creation. they can change the fee regularly, at their whim.

even the cltv can be changed so that its not a default of 9, but instead random per attempt.
but alice would need to know these changes to then commit to bob

lots of messages happen before a commitment is signed.

i know you want to endlessly quote the in-channel commitment stuff of a direct payment.(alice to bob only)
but thats just you wanting a 'alice pays bob' scenario. where messages and variables are simple for you

there is alot more involved that happens before alice even signs to bob on a route payment

* this is not not just formulated from a network map. for many reasons

...
also there are many reasons(not just private channels) as to why branches of a nodes map(tree) differ from other nodes map(tree)
...

theres other things like
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#legacy-hop_data-payload-format
if you read the entire chapter of legacy hop payload format.
NONE of it is about commitment editing or signing. its about MESSAGES
and showing how MESSAGES should fail/reject if parameters are not as expected.
commitments are done after checking the messages and seeing the contents meet the parameters
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#returning-errors
these are messages, not commands to un-edit/re-edit a commitment
there is no reason to write and sign a commitment if the parameters are wrong


update_add_htlc is not a command locally, its a message to remote peer
it only initiate changing a blockchain formatted transaction output if the parameters are good

..
a node has hundreds of message types,
i know you want to only discuss 3 (channel_update and update_add_htlc and commitment_signed)
but you are stepping back into your bolt 2 direct payment box

here is some more stuff
https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#rationale-5

for instance. if i have a bitcoin funding locked channel(bitcoins chainhash) the network map only shows PUBLIC bitcoin channels that are only my peers, my peers of peers and their peers of peers

but i can also query a peer and find out updates of the parameters anytime i want. including seeing which peers have, say litecoin channels to see if i can atomic swap

Nice try franky1. A few posts ago you were not talking about private channels at all, so I assumed that all channels are public, which is the most common case. You are trying to prove me wrong by changing your assumptions. That's no bueno, my dear.


Read my reply again.


From the very beginning, I have been saying that you need to send "update_add_htlc" message which includes those instructions AND forces commitment update as per bolt02:



Routing hints are included in the invoice which Alice needs to receive (outside of the LN) before she tries to send the payment. It does not contradict with what I have been saying about HLTCs as it's a separate process.

---

You seem to forget that Lightning explorers, which obtain data through the gossip protocol, exist. All Lightning nodes should have exactly the same information as those explorers.


No, my view is that "channel_update" is sent whenever some node makes changes to one of their channel parameters (most commonly the fees). You don't need to send "channel_update" when you give someone an invoice or when you sign a new commitment transaction with someone. You can also send "channel_update" when your peer goes offline so that no one tries to route a payment through this channel. In other words, you can disable the channel.


Change what exactly? If liquidity is not public then there is nothing to change in this case through "channel_update".


You don't need to spam the network with "channel_update" messages. Here's an easier way to improve one's privacy:


You need to read bolt07 more carefully:


No, Eric still doesn't know anything the BC channel. Neither Alice's nor Diana's network map contain any information about the BC channel. The same goes for Eric. You can't make only one side of the channel private; the whole channel must be private.


If that happens then the payment attempt simply fails. Channels don't change their parameters frequently. It should take a couple of minutes for the message to propagate across the whole network. Alice should receive it fairly quickly as she's just a few hops away.

minus a few contradictions you made, you have actually took a few steps forward

so lets summarise:
contradictions

invoices are not htlc updates to a blockchain formatted transaction output. but thank you for now recognising the messages that go between nodes, especially beyond the initial network map gossip
you have been narratting for pages that payments are blockchain formatted transaction(commitment) changes
where you have been thinking all HTLC are the outputs of a commitment

anyway, lets reply to the other points.
you like games, but do you know the game pass the parcel
if alice does not know diana or eric. then diana or eric cant tell alice about the bob-carol channel
bob has been told by carol not to tell alice about the bob-carol channel.
bob can tell alice about other public channels bob might have with different peers. but ot about carol. which is where alice does not know about diana and eric. and so alice cannot get the EDCBA back path from eric.. because bob is not passing the parcel of eric and diana.. and alice is not connected to eric

thus alice does not know there is a route to eric via bob-carol-diana-eric via a map

bob however is ok with being public to carol. so bob knows of alice. and carol knows alice-bob and carol is ok to send to diana and diana sends to eric. meaning eric knows of alice route. but eric is not node peer handshaked to alice to tell alice

messages are sent pass the parcel. not to some uber mempool map everyone is connected to.
its like bitcoin. there is no central mempool everyone uses, each node has a mempool only of the stuff it gets relayed by a peer. different nodes will have different maps(mempools) if certain peers are not connected to their peer or peer of peer

which is where you get a better map view if you have lots of channels with lots of peers and those peers have lots of channels to increase the chances of mapping everyone. (if they are all public)
its called the 6th degree of separation(kevin bacon)

exactly. because alice has not been given details of carol, diana, eric. she cant get a copy of a eric->alice path unless eric connects to alice ((invoice with hints) where invoice is sent in some out of network communication EG blog post or a DM on a social platform)

its a pass the parcel game.. not everyone connects to everyone randomly

again if you know the pass the parcel game you could turn that into a positive about how it avoids DDoS of random nodes

in a BC private channel set by carol.
carol is refusing to tell bob about diana.. meaning alice and bob dont know about diana which mean alice and bob dont know about eric on the map

again in the pass the parcel game. your not connecting to all nodes and interrogate their channels. your being passed parcels from a peer who gets data from a peer thats allowing said data to be passed or not


so now your saying LN is not private and has no privacy.. wow the tables have turned.
the channel announcements are not broadcast to all nodes.. all nodes are not connected to all nodes.
as that would be a waste of bandwidth!!
its a pass the parcel game peer to peer. where a peer in the middle can refuse to pass
a node only knows of the map of its peers, peers
and so on. meaning its not one tree of everyone.. but several trees where one node in one corner wont have the same trees as another node in another corner.


ill thank you with one step forward for admitting that its not all done in the network map. oh and yea invoices are not commitment edits(pre-empting you your narrative twist i can predict you will make)
oh and invoices are messages in msat denomination, not a blockchain formatted transaction template


ok then if LN is now public. the privacy advert needs to stop.
seems bitcoin has privacy. because it does not reveal partners of partners to show all possible places to pay.
Ln has now become public and can show all possible people to pay

EG. if my network map is where ABCDE only have A and E with 1 channel and BCD with  2 channels

then the only network map ABCDE has is only of ABCDE. because they are peered to pass the parcel

because E is not connected to Z or M or T elsewhere. ABCDE wont know about all the other channels. it only knows about the ones peered to it

again needing an invoice or message outside of the network map. outside of a route parcel game

seems you again want to avoid the point and jump back to private channels, but hey lets go with it..


note: this is not a change to a commitment. this is not a network map view. its a message. measured in the denomination of msats


wait. but for a few posts you have been saying everyone knows everything... and now you admit that alice would have no way of knowing about eric via the network map..
.. finally another step forward

---

finally it appears your getting it. alice doesnt just use a network map and then constructs a commitment and signs it to bob. to initiate a payment(your narative all along) there are alot more messages that happen. before a commitment is edited/signed

also update messages(msat) are not just sent once at a network map initialisation of opening an app. or once at the invoice send

updates happen after invoices and also update again when things change, including along a route
EG even after alice knows of a route to diana by invoice(not map). alice then needs to
send message which then update the cltv so that alice can then once the route is established and everyone is accepting messages.
channel updates are not forced to only happen at 3 times:(your view)
network map initialisation
invoice send
commitment signed

channel updates can happen all the time
EG if alice is preparing to pay carol using say map or invoice. but during that preparation crol wants to pay her partner zoe, carol then has to change stuff.
EG if while alice is preparing to pay carol. bob(for his own reason separately) pays someone else for something else. he too has to change something.
EG if alice is preparing to pay diana, where diana sent an invoice with a hint path through CBA at each transaction BCE can change their cltv per transaction to add some privacy. meaning random numbers change every few seconds and updates occur


again updates are not done just 'sometime in the past' (your view of just 3 times they occur)
i can right this second change my min dust, fee, cltv. anytime and update, without having to wait for a map gossip or invoice message or a payment.
when routes are built alice needs to know the latest total of msat and the cltv of the entire route. which can change from the app opening initialising network map view. and change from the invoice sent 5 minutes ago. because bobs circumstance has changed in the last 2 minutes


thank you for admitting its not about commitment editing/signing..  and thank you for admitting is about sending messages (messages denominated in msat)

feels we have made some progress. even when you have contradicted your self in some small ways inbetween.. dont step back now

What you are describing is a really edge case scenario as most payment are probably routed through public channels. The only effective way to achieve that would be to include routing hints in the payment invoice, but that would require the cooperation of the sender. Usually, senders include only private channels that are directly connected to them. You also mixed up a few things.

If the BC side is private it doesn't mean that CD is private and that Alice doesn't know anything it. The CD channel is public. The gossip is advertised not only to people who you have a direct channel with, but also to other Lightning nodes that randomly connect to your node. Alice must have learnt about that channel at some point from her other peers.
If the BC channel suddenly goes public, the gossip will eventually reach every single node in the network. There would be no need for Alice to ask B for any details. However, If the BC channel was private all the time:

You can't ask B to temporarily tell you about C. You can't assume that B will have any way of forwarding your payment. In fact, Eric doesn't know it as well.
What would be the point of having a private channel if literally anyone could send a gossip message to your peer to reveal the existence of your channel? You would waste a ton of bandwidth and time trying to guess which node might have a private channel that could be used in your route.

If the channel between Diana and Eric was private, Eric could tell you about it through the payment invoice.


Yes, it is default for LND, c-lightning and Eclair nodes which make up the vast majority of the network. All of them open public channels by default.


It seems that your main argument now is that you can use private channels. Here's what routing hints look like in invoices:


So, if DE channel was private, Eric could give you all the information you need about that channel to construct the "onion_routing_packet". You wouldn't need to request any additional information. If either BC or CD channel was private, you would have no way of learning that you can use either of them to reach Eric.

---

Of course, you can. "cltv_expiry_delta" is a part of "channel_update" message, so Alice knows all the information she needs from her network map if all channels in the route are public.

If you want to assume that BC channel is private and Carol is the destination then Carol needs to include routing hints for her BC channel in the payment invoice. This way, Alice has all the information she needs to construct "onion_routing_packet".

I also really like how you quoted this routing example and talk about some weird update messages when the example clearly uses only two messages: "channel_update" which Alice received at some point in the past and "update_add_htlc" to send the payment.


No one is relaying signed transactions. Commitment updates are local. Nodes relay instructions which tell them how they should update their local transactions.

Franky, you're trying to convince us that Rath is wrong, but due to your awful writing character, you're constantly failing. How about posting how you think the current system works? Just like Rath did.

How do you explain the force-close channel option then? Once I make a Lightning transaction, both of our nodes update and add the HTLC, I send the commitment_signed and the other node revokes and acknowledges. I wish I had more free time to get involved into the discussion. Again, tell us the way you think the system works, but do it summarily.

rath's narrative was that LN payments were done not by messages of Msat data but by actually editing outputs in a blockchain format transaction template and signing them. and then sending thoses signed transactions to the peeres to sign and complete the payment.

..
his more recent and changed view now atleast admits there are messages. and those messages have things in them but he still misses some things


in (2) he thinks that alice constructs a path just from network gossip. and tries the cheapest route to bob,
and then (3) signs a commitment to bob..

but here is the thing.
again using the example (its only a 1 hop instead of 3 hop to avoid lengthy example)
https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#routing-example

alice wants to pay Carol 499999 based on carols details

but if alice paid bob to pay carol. bob would not get a fee. and also bob has his own defauly CLTV of 9 meaning carols cant begin because bobs has the 9

so instead alice has to request some update messages where by bob and carol talk. and alice gets an update of
as you can see the fee and calculated amount_msat and the cltv have changed based on the numbers that need to change to fulfill the route..
this is only done via alice talking to bob talking to carol and carol talking back to bob who talks back to alice.

this is not all just found at the network map on initial opening of an app.

it is only then that alice knows it will cost her 5010198msat to pay carol 4999999
by which alice can try to see the amount of other routes.. and then choose the route to actually take.

and then on taking the actual route then comit to the channel of that route direction

again for emphasis. because network map does not hold all info. such as CLTV amount_msat of active available balance, nor any other personal parameters like adding a bit of shade to each CLTV. making each one unique.
you cant just create a route in A using just A network map and just commit to bob. for an amount A guessed based solely on the network map

there are reasons why onion messages are a thing. and its not to transmit signed commitments..

seems rath_ has now managed to get n0nce mixed up.
one more time for clarity

LN is not a network of relaying signed transactions like the bitcoin network
it is instead where peers relay messages of little pieces of information that nodes gather up. to eventually put info into a blockchain format transaction template LOCALLY. and then sign their copy.
if all goes perfectly the other per should have also gathered its info similarly to build its own blockchain format transaction template LOCALLY. for it to sign. and then they both swap signatures.
once verified the signatures respond to their local builds it shows they both successfully commited.

again (to save me having to make another post to say the same thing. ill say it again here)
its not like tx bitcoin relay of signed transactions in full tx data in a blockchain acceptable format.
its instead lots of different messages relayed, in msat value..(and other info) that is then locally built and converted into a blockchain acceptable format locally. and locally signed and then just sending the signature to peer as a message. which should match both sides build to verify they both comply to the same terms.

once rath and others realise LN does not relay blockchain formatted transactions as payment, but instead lots of small different messages of things measured in msat. he will realise the differences between LN and bitcoin

Damn, 910 pages in just a few days Let's have a look.

This all looks correct to me. The various peers on the route are basically waiting for Diana to 'open' the secret to then update their balances. It's not very complicated, to be honest. Just a network of payment channels, where e.g. A sends amount x to B in a shared channel, then B sends x (minus fee) to C in a channel BC, all the way to the destination.

Unfortunately, it seems like a pattern with franky1.

---

That's fortunately completely wrong. Lightning is simply a network of 'channels' which are just people sending real Bitcoin transactions back and forth, but simply not publishing them on the blockchain. They can however do that at any time, which gives it the 'realness' and full security of Bitcoin. The only risk is a person publishing an old 'state' (old transaction where e.g. they owed you less than in the latest state), so your node needs to be online pretty much all the time to keep an eye on it and in case of fraud attempt, publish the 'latest state' transaction. There is a time lock though on all these exchanged transactions, so you got time to do so.

So yeah it's simply normal Bitcoin, just without submitting the transactions to the blockchain all the time.
Meanwhile, WBTC is just an Ethereum token. That's a whole other thing. I can't just take a 'WBTC transaction' or utxo or whatever and publish it on the Bitcoin blockchain to get my coins confirmed (mined) forever within 10 minutes and see them immediately in my normal Bitcoin wallet.

It's IOU indeed, but can be 'claimed' at any time since it's again, just an unpublished transaction. Publish it, pay the mining fee and you got the money. Just like that. You're constantly holding signed transactions from the person 'owing you' with the full amount owed.

Well one thing's for certain: in Bitcoin v22.0, without second layer, right now, it cannot become the main global payment system. The throughput is just too small. With Lightning, it would be possible. Today. We shall see which scaling method will prevail, but so far LN's the best we got.

That's an interesting anecdote, but probably due to people still not used to Bitcoin's volatility. When they use Tron, not only do they see the 'USD' symbol they're used to (official currency until last year) but also it doesn't change in USD-denominated value which gives them a sense of security. Of course, the purchasing power goes down the drain over time but yeah the number stays the same, I guess. What I'm trying to say: they're not not using Lightning, because they believe that Lightning is not Bitcoin or anything like that; I doubt that many people are so deep into the topic to actually think or discuss about this.

and multiple times i have been saying you cant update a HTLC until you know the amounts, and details to put into a HTLC
alice is not psychic.

i know you want to play the whole 'everyone is seen online, there is no privacy, all the data is found when people start their node/app.. because gossip network map'
but this is not the case.

you say that the transparent network map is on by default and requires an opt out to become private. but its actually the opposite. its an opt-in process of being private first and deciding to go public
https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#the-announcement_signatures-message

in short, nodes dont announce, and can reject requests and not announce, unless they choose to go public.
nodes are not forced to announce and then choose to go private

even while private they can still be routes to only the channels they want to accept

EG if i was C in ABCDE
i can keep my BC side private. thus A wont know about me or my channels with CD through network map. because i wont send an announcement to B of my D channels

but set my CD as public and so E can see me on the network map. because i am announcing to D my channels
E could use network gossip to build a route to A
but if A wanted to build a route to E. A would need to do channel requests to B to see that B is actually connected to C.. (and then i can choose(opt-in) to temporarily tell A about D (SEPARATE from the network map)

this if you learned it could actually become a positive privacy feature.. allowing payments to be made without having to be public.
but as always you want to deny it happens because it doesnt fit your narrative.('everything done in htlc')

.. which is starting to seem like your not actually interested in promoting LN for its positive features for the niche service it offers. but just want to cause debate and misinformation to fit a narrative where you thought that everything was done via commitment changes and only done by commitment changes(facepalm)

so please. try to learn about the messages. the HUNDREDS of different messages that happen before a HTLC is even changed.
because you cant change a HTLC unless you first know the data to put into the change.

here i will give an example.. of when actually routing (not rath_s psychic make a route without talking to peers on route)
https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#routing-example

as you can see they need to receive and see and then change the CLTV. aswell as update channel with some other details at the route stage(fees total, amountsat, cltvexpory ). where the can also reject such request.. before they can even make a HTLC to input the data(if they accept)
update_add_htlc is node a inside your node trigger to just add a htlc. its actually a message from a peer of data


ill emphasise this. and make it bold and colourful. maybe then take some time and think about these words:
you cannot change a HTLC unless you know the data that needs to be put in it, to change change it

so now are you ready to look at all the messages (not just the limited ones you want) that all involve how to get the data

I see that you have completely ignored my answers and remarks to your statements, again. Never mind.

You seem to forget that "update_add_htlc", which forces commitment update, always includes "onion_routing_packet" which contains routing instructions. That's how both peers know how to update the channel.

Actually, you can tell if Eric is online from the network gossip. Either of the peers can disable their side of the channel through "channel_update" and that's what all implementations do if their peer goes offline. Disabled channels are ignored during payment path construction. Carol doesn't need to know if Eric is online as she interacts only with Bob and Diana. If Carol or any other hop beside Alice knew that Eric is the final destination, it would be a huge privacy concern.

I have never said that the gossip protocol (bolt07) is used to reply whether or not there is enough liquidity in the channel to forward the payment. You keep saying that you need to send bolt04 payloads in a bolt01 format, but I have already proved you in my previous post that bolt04 error messages need to be associated with HTLCs from bolt02.


The only HTLC related messages that can return bolt04 errors are "update_fail_malformed_htlc" and "update_fail_htlc". Your peer cannot send them unless there is an HTLC commited to the channel ("update_add_htlc" + "commitment_signed" + revocation keys exchange).

---

Here's your view as far as I understand:

1) Alice constructs a path based on the information from her map. If she doesn't have some information about specific node, she requests it through the gossip protocol.
2) Alice sends just "onion_routing_packet" in a bolt01 format to learn if all nodes in the route have enough liquidity.
3) Each node in the path forwards that packet in the same way
4) Once the packet reaches Eric, he replies whether or not he can accept the payment.
5) All hops reply to their partners in the backwards order.
6) [Here should be the commitment part, but I have no idea how you want to handle it with a different secret for each hop and trustlessly without HTLC outputs in the commitment transaction]

My comments:

I have already shared most of my concerns before. I still don't know what message each node would use to say "I can forward your payment". I also didn't mention HTLC outputs here as you clearly ignore that they exist or say that they could be claimed with just payment secret, which is not true. Without them, if Eric claims the payment in his channel with Diana and Carol disappears, Diana can't claim the coins she was promised as the promise was not enforceable in any way.

---

Here's my current understanding of how the system works:

0) Lightning nodes constantly use the gossip protocol (bolt07) to forward/receive "node_announcement", "channel_announcement", "channel_update" messages and maintain a local view of the whole network.
1) Alice receives a payment invoice from Eric which includes information like: Eric node's public key, payment hash, amount, expiry (date) and cltv expiry.
2) Alice constructs a path to Eric using her local map of the network. She tries to find the cheapest and the shortest route. The longer the route, the higher the risk that funds will get stuck during routing.
2a) She prepares "onion_routing_packet" which includes encrypted routing information for each hop.
3) Alice sends "update_add_htlc" message to Bob, which includes the "onion_routing_packet" (which is the same for all peers), the amount, the payment hash and cltv expiry.
4) Alice and Bob sign a new commitment transaction with an HTLC output.
5) Bob sends "update_add_htlc" to Carol with the same "onion_routing_packet".
6) Carol and Diana, Diana and Eric do the same.
7) Eric sends "update_fullfil_htlc" message to Diana, which includes the payment secret.
8) Eric and Diana remove the HTLC output and update balances by signing a new commitment transaction.
9) Diana sends "update_fullfil_htlc" to Carol with the same payment secret and they update the commitment transaction.
10) Carol and Bob, Bob and Alice do the same.

Comments:

3) The amount Alice sends is actually bigger than the one in the invoice as she must account for the fees. Each hop forwards the HTLC with a smaller amount and keeps the difference. If some hop tries to claim higher fees than Alice expected, the next node in the route will fail the payment as the routing instructions say how much one's node is supposed to forward.

If Bob doesn't have enough coins to forward the payment on his side of the channel with Carol, he must send "update_fail_htlc" message and Alice needs to try sending the payment through another route.

All channels use the same payment hash. It is safe because HTLC outputs require both the payment secret and HTLC signatures, which can be produced only by channel partners, to be spent. See this post for explanation.


I can back up my statements by showing you my node's logs and quoting research papers and other resources, but you will totally ignore them as always.

segwit(141,144) didnt activate on august 1st. the mandatory threats did (148/91)

in normal consensus, incompatible nodes only fork off when they are receiving a new format they do not understand (block containing a new merkle tree for instance).
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#specification

what you learn is the 'backward compatible' is not that a segwit blocktemplate is the same as a normal legacy block. its that segwit upgraded nodes understand a segwit formatted block, and then strip it down and rebuild the blocktemplate without the segwit parts so that its formatted like a legacy block, for non-upgraded nodes.
https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki#serialization
whereby the trick of the 'anyonecanspend' rule is to just not evaluate or look for a signature(witness) of such transaction (because they got stripped out anyways), but treat as accepted even without a signature being validated, verified or stored by old nodes
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#backward-compatibility

this meant that those collating/creating/propagating segwit blocks would not cause a fork after the 24th(141/144). but just cause non upgraded nodes to not be full validation full archive nodes. by being given stripped(serialised) version

which has been a debate about the security hole of then the non-upgrading nodes now no longer treated as full validation and archival nodes, because they are missing crucial data and they are not truly validating all transactions.

.. but before segwit even activated, before segwit nodes and pools even done anything with segwit block templates(141/144). there was a split(148/91). this was not due to normal consensus events of old nodes not understanding a new block structure(141/144) and rejecting(because segwit wasnt activated to even allow making new blocktemplates).. but instead the split was due to the 148/91 stuff of mandatory rejection from the side of those wanting segwit to activate by rejecting old blocks that didnt flag for 148/91, BEFORE segwit activated
..
pools still making blocks without the flag (on august 1st only 1-2%) were getting their blocks rejected, but old nodes still accepted them. causing the split 59 blocks after the 148/91 activation/lockin. because it took hours for nonflag-poolers to get a block confirm, now different nodes were seeing two chains of blockheights containing differing blocks.
UASF(148) nodes with their peers who didnt propagate unflagged blocks. (the NYA economic majority)->users
nodes with their peers who received old blocks(non flaggers)->users.

the bitcoin network followed the chain of the exchanges, payment gateways and prominent pools (NYA economic nodes), because the users and pools feared not getting their transactions seen by exchanges, meaning they couldnt spend their value.

those who were on segwit flagging chain, during the grace period before segwit activated, didnt like the split, didnt like the orphan drama and the cross transmissibility of nodes. so they asked those accepting the old blocks to change stuff to become a independent altcoin.
(as highlighted in previous posts, which showed doomad knew about this)
..
segwit did not actually make any segwit blocktempates with the witness until after august 24th. meaning in a true consensus unupgraded nodes in a true new consensus (without backward compatibility strippping trick) would have forked on the 24th because they cant full validate and archive segwit blocktemplates.

i think maybe this is why after 2017 Doomad got told segwit didnt fork(aug 24th). which he misinterpreted or lead to his contradictions by saying in later years 'it didnt happen'..
but totally ignoring the mandatory fork(using flags, not blocktemplates) before segwit activation(aug 1st), which caused the later activation(aug 24th), by simply rejecting block flags not flagging for a segwit activation. to get a segwit flag of over 95% before august 2nd

again by using a few tricks. bips148/91 forced the condition to start 141's 3 week 'grace period' to get segwit activated.

---

in summary and answering doomads consensus questions
yea the NYA agreement team (UASF) did run their software even though they were a minority. and no one could stop them (you admit they were a minority of general nodes) but because they were also the economic majority(nodes used by payment services and some pools), other pools listened and followed their lead under threat of not having their transactions seen by the economic majority nodes(payment/exchange services).

this is why average user nodes(not exchanges/ merchant tools) had no vote, and were pandered just flagged blocks or thrown off the network for accepting unflagged blocks(orphan drama of 2 chains)..  depending on what blocks got propagated to them via whatever peer they were linked to.

which all occured because of a mandatory action before segwit even made its first segwit block template including segwit transactions