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

[franky1]

in response to darkvortex's social drama post of no substance
(yawn)
not beaten
but just seeing your losing your game, where its the same game, just different day. so its boring, so i have better things to do then entertain you lot with your games

and so i realised more and more with each day that life is too short to care about cheaters playing games, acting cultish.
i have no sympathy for those types of people.

it has been a good laugh watching a group of people trying to play victim as if they want or pretend to deserve respect and sympathy..even after they themselves have been the instigators of their own injured emotions.

but anyways, its starting to sound a bit cultish now. wanting to convert people over to their cause and insulting anyone that does not join their altnet. arguing with anyone that shows the flaws of their utopian religious place of worship.

sorry but im not interesting in joining the cult. its not the promised land, its not the utopia you lot present it as.
but you did give it a nice try pretending bitcoin is at it end of days as a currency. you gave it a good try, trying to make it appear bitcoin is useless for daily use. and you gave it a good try pretending that LN is the next blissful life of promise, beyond bitcoins death.
your group is not the first that tried to insinuate that bitcoin cant cope, survive, grow. your not the first to try cutting the legs off bitcoin to stop it moving forward. so, goodluck with whatever new hobby you try next. just dont try to waste 5 years trying to turn your hobby into a cult for your own personal enrichments of getting people to join your commune

nice try, but you failed.

have fun in your group. but try to play with each other next time instead of against others that you see as the opposition

there is only one thing you have all got right, i dont need friends or loyalty to back up my opinions. i just have to quote the data. even if you dont want to read it.. others can, others do

[Rath_]

and in summary.
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#returning-errors

Thanks franky1 for finally answering my question. There are two problems with your answer.

1)

Notice that the failure_codes are not of the same type as other message types, defined in other BOLTs, as they are not sent directly on the transport layer but are instead wrapped inside return packets.

Here's another interesting fragment:

The association between the forward and return packets is handled outside of this onion routing protocol, e.g. via association with an HTLC in a payment channel.

Let's take a look at HTLCs again then.

Code: (https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#removing-an-htlc-update_fulfill_htlc-update_fail_htlc-and-update_fail_malformed_htlc)

    type: 131 (update_fail_htlc)
    data:
        [channel_id:channel_id]
        [u64:id]
        [u16:len]
        [len*byte:reason]

The reason field is an opaque encrypted blob for the benefit of the original HTLC initiator, as defined in BOLT #4 [...]

    type: 135 (update_fail_malformed_htlc)
    data:
        [channel_id:channel_id]
        [u64:id]
        [sha256:sha256_of_onion]
        [u16:failure_code]

So, bolt04 says that failure errors are returned as a part of HTLCs and bolt02 says that those errors are described in bolt04.

2)

I looked through all failure messages and I couldn't find any that explicitly states that there is no enough liquidity in the outgoing channel.

well a good privacy thing is that nodes dont have to network gossip their fee's and updates to become known on a public map.

By default, Lightning channels are public and they advertise themselves through "channel_announcement" and "channel_update".

You can use Lightning explorers like amboss.space or 1ml.com to see information extracted from the gossip protocol for each public node. Here's my node. You can see all of my channels, including their fee settings which are necessary to construct the routing path. Private channels are generally not used for payment routing as the invoice would have to include routing hints.

Even a lightwallet like Electrum forces their users to wait for the local graph to sync through the gossip protocol if they don't want to be able to connect only to trampoline nodes, which can take care of the path calculation for the user if they are willing to compromise their privacy.


You should take a look at at least one paper describing the probing attack on the Lightning Network.

LN nodes gossip about channels available for routing and their total capacities. To issue a (multi-hop) payment, the sender creates a route based on its local knowledge of the graph. As local channel balances are not public, payments often fail due to insufficient balance at an intermediary hop. In that case, the payment is attempted along multiple routes until it succeeds. This constitutes a privacy-efficiency tradeoff: hidden balances improve privacy but hinder routing efficiency.

You can download the paper and learn how Lightning payments actually work.


Another question for you. I would appreciate if you could interpret my node's debug log.

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

Code:

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

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

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

[DooMAD]

This also demonstrates a lack of basic comprehension.  If a user is swapping their BTC for a coin on another blockchain, that means the user on the other blockchain is accepting the BTC.  It is therefore not possible to have a mass "exit" from BTC if it's 1 out, 1 in.  Someone will always be taking the place of the person who left.

//EDIT:

I have presented a logically fallacious argument.  I accept that I was wrong and withdraw my erroneous assertions above.  Admitting one's mistakes is vital for personal growth and gaining a greater understanding of complicated subjects. 

[suchmoon]

This also demonstrates a lack of basic comprehension.  If a user is swapping their BTC for a coin on another blockchain, that means the user on the other blockchain is accepting the BTC.  It is therefore not possible to have a mass "exit" from BTC if it's 1 out, 1 in.  Someone will always be taking the place of the person who left.

Come on, you're handing this to franky1 on a platter. There is a buyer for every sale. But that doesn't make it impossible to have more people exiting than coming in, or create price pressure, etc.

[franky1]

If a user is swapping their BTC for a coin on another blockchain, that means the user on the other blockchain is accepting the BTC.  It is therefore not possible to have a mass "exit" from BTC if it's 1 out, 1 in.  Someone will always be taking the place of the person who left.

i guess doomad never learned anything from 19th century economics of the gold/bank note scenario

heres a joke:
2 bitcoiners enter a bar. A has funding locked bitcoin and funding locked litecoin, B has only funding locked bitcoin..
.. 2 men leave a bar, A has 2x confirmed bitcoin, B has litecoin

in bitcoin thats called 'thunderdome: 2 may enter, one may leave'
in litecoin thats called '1 in 1 out'

oh and to pre-empt another social game.
even doomads favoured service 'thor' can create channels without needing both partners to fund(have coin) on both sides.
so doomad is aware its not a 1 in 1 out

and thats the punchline that makes me laugh. doomad knows, but pleads ignorant to set a narrative


and to rath_
seems to again forget, to edit/change a htlc in a commitment or update/edit/change/sign a commitment . they need to know what needs changing.
he forgets the messages that communicate the information.

he also thinks alice or bob or carol know erics htlc right at the start.
he also thinks alice or bob or carol know erics is online just from network gossip
he also thinks alice or bob or carol know diana is online and liquid to forward just from network gossip

he thinks the deal is complete as soon as alice looks at network gossip and signs a commitment with bob


to blackhatcoiner below
i didnt avoid the consensus stuff, i even stated bips related to how devs changed its parameters. mandate(148/91) before sw active(141)

the stuff about anyone free to use any software is not about consensus. its about freedom to use any software.
whether its a lite wallet, spv, a altnet, wallet
consensus should only change when majority of nodes have an agreed framework to obide by.
consensus should not change by pre block rejecting before the new feature activates

EG
deciding to lite wallet  is a freedom but has nothing to do with consensus
your free to use this forums software or just write aimlessly on microsoft word.. nothing to do with consensus

[BlackHatCoiner]

Lightning is Bitcoin like WBTC is Bitcoin.  There's little difference in my opinion.

WBTC is backed by Bitcoin. LN-BTC is backed by a cheating discouragement. Both are IOUs, but in the former there's trust involved. Try cheating me on my channel (AKA: Refusing to pay your debt) and I'll prove you how idiotic it is to consider it a promise.

doomad wants mainly consensus talk but mostly social drama
darkvortex wants social drama/emotion
rath wants LN talk but some social drama, and to play contradiction mind games
darkhatcoiner, picks and chooses. but mostly social drama

Yeah, everyone's wrong and evil while you're an honest angel. Misleading, nonsensical, insulting and psycho drama queen. You keep avoiding the consensus questions. It's not favoring you.

[darkv0rt3x]

in response to darkvortex's social drama post of no substance
(yawn)
not beaten

Absolutely beaten by the evidences... But you'll never recognize that!

but just seeing your losing your game, where its the same game, just different day. so its boring, so i have better things to do then entertain you lot with your games

To me and apparently to everybody else, the losing game is the one you're doing over and over!

and so i realised more and more with each day that life is too short to care about cheaters playing games, acting cultish.
i have no sympathy for those types of people.

Looks like you expect to have sympathy from anyone? lol. I can see the sympathy you're getting.

it has been a good laugh watching a group of people trying to play victim as if they want or pretend to deserve respect and sympathy..even after they themselves have been the instigators of their own injured emotions.

I certainly laugh at you, because all your attempts to convert people via demagogy, failed. That's a good laugh.

but anyways, its starting to sound a bit cultish now. wanting to convert people over to their cause and insulting anyone that does not join their altnet. arguing with anyone that shows the flaws of their utopian religious place of worship.

That's been your game. We just started playing it. Convert people to your unproved beliefs and quotes that were not properly backed as others did.

sorry but im not interesting in joining the cult. its not the promised land, its not the utopia you lot present it as.
but you did give it a nice try pretending bitcoin is at it end of days as a currency. you gave it a good try, trying to make it appear bitcoin is useless for daily use. and you gave it a good try pretending that LN is the next blissful life of promise, beyond bitcoins death.

Here is your narrative again. The narrative you want to make everybody believe that was ours, in the first place. But you're the only one mentioning those non-sense of Bitcoin not having use cases and whatever!
Don't make up words and scenarios out of the blue and transport them to the rest of the people. That game works with infants, kids! Not with grown people, ffs!

your group is not the first that tried to insinuate that bitcoin cant cope, survive, grow. your not the first to try cutting the legs off bitcoin to stop it moving forward. so, goodluck with whatever new hobby you try next. just dont try to waste 5 years trying to turn your hobby into a cult for your own personal enrichments of getting people to join your commune

nice try, but you failed.

have fun in your group. but try to play with each other next time instead of against others that you see as the opposition

Clock is repeating, as expected. You decided to make up a group out of nowhere. And you're trying to brute-force the existence of that group into other's minds. Not gonna work once more!

there is only one thing you have all got right, i dont need friends or loyalty to back up my opinions. i just have to quote the data. even if you dont want to read it.. others can, others do

HFSP and lonely then.

You don't need friends nor loyalty to backup anything. You need proof, you need facts, data, which you were unable to properly provide when you were requested.
Done!

[franky1]

by now everyone should know(including Doomad) that 148 and 91 were used and both involve mandatory rejecting non-segwit flagging blocks before segwit even activated(141) on 24th august 2017.

so lets recall some messages from a certain person who spent years denying it ever happened, even contradicting himself

first lets see him admitting it was used.. right when it happened.

Definitely not worth buying the popcorn for, heh.  I had a pretty strong feeling that it wouldn't exactly be fireworks, but I thought there might be something happening.  So much hype and drama for so little action.  Oh well, onto the next big drama, I guess.

Nothing has happened yet, apart from BIP148 having locked in.

Either you've got your BIP numbers mixed up or you've been listening to the wrong people.  BIP91 has been locked in, BIP141 is currently on course to lock in, but isn't there just yet.  We have to wait for the 1208 blocks currently remaining in this signalling period to complete the lock in for SegWit.  Once that happens, BIP148 will become completely redundant and won't be required.  Some might argue that it has already served its purpose in forcing an ultimatum to begin with, though.

For those who have been reading the announcements, it should be noted that the first post is based on circumstances that changed not too long after.  Initially, there was a chance that BIP148 could result in a split, but this was mostly negated by BIP91.  Today was going to be boring from the offset until BitcoinCash reared it's ugly head, but as it turned out, that's pretty boring too, heh.


//EDIT:  "The Bitcoin network has forked as of block 478559".  BitcoinCash splutters into life... just.

as you can see. on august 1st 2017 he was happy to admit 148 led to 91 which would in 3 weeks lead to 141(segwit)
and admits the split occured on the day everyone said it would due to the actions of the 141 91 stuff

heck there are other posts where he also admits that due to the split BCH had to change its magic to actually be an altcoin rather that a reject block orphaner fighting against bitcoin. heck he even mentions how gmaxwell had to plead to BCH to add some changes, heres one: (note the date, ill explain later)

Indeed.  BCH had to make a few important changes.  First and foremost was updating their network magic, so that they would not be following the BTC chain, then they needed the EDA to compensate for the lower-than-anticipated hashrate their chain had.  

Either way, it takes two to tango.  But I'd personally still argue that BCH announced their fork prior to agreeing to change their network magic, which is why Core responded by implementing the code they did.

the reason why they had to change the EDA, was because it wasnt its own altcoin, just borrowing blockdata. it was a split based on the 148/91 and so the split of bch begun at the same difficulty as bitcoin
(a true altcoin just copying blockdata but wanting to go-it alone without the mandatory cause, would start at a near 0 difficulty(EDA))

and then.. here he is denying things happened. (as you can tell in 2017- april 2019 date shows how he knows it happened in 2017 . and admits it in 2019.. 2 months later, below = contradicting himself)

dont feed the troll.
Is obvious that he is trolling

yep doomad is trolling
even he knows that luke JR invented the code for the mandatory split crap MONTHS before bitcoin cash was even a brainfart

Back to the point on Luke Jr, though, individual devs can do things that other devs don't support.  One person's actions does not necessarily represent the views of an entire dev team.  It's not a conspiracy, you flailing fruitloop.  All that happened is that someone coded something you don't like and now you apparently have to spend the rest of your life bitching about it on the internet, because that's what butthurt sadcases do.  You are the only person who still cares about this "mandatory" code that wasn't mandatory in the slightest because not enough people were running it.

here he is saying that no one used those bips. and the bips were not mandatory (facepalm+laugh to his own contradiction)
and for years after he was saying
"it never happened", "there is no mandatory", "bips didnt activate until after 24th aug 2017", "there was no split".. just so he can be a social drama queen showing off loyalty to some core devs

there are many many more posts where he says there was no split (although the world can see BCH exists),

 yea i removed some insults from his post but they were just his usual boring ramblings. but as you can tell he is the one thats being uncivilised and contradictory. which then prompts me after years, to bite back.
again i dont feel sympathy for him playing the victim card now, because he was the instigator by doing his contradiction games just to play debater and cause reason for him to act uncivilised as part of his game.

but hey. ill give it a month and he will again forget about 148/91 before 141 and instead go back to insisting 141 activated without any mandatory bips. just so he can cause social drama for his new friends to hug him.

(not his first time with that tactic(forgetting he got debunked when he pretends nothing happened, forgetting his own admissions of what did happen))

yea all boring social drama.

his latest point of wanting to ask about devs can write any code. is to narrate that no one should/can stop core.
(something he is passionate about not wanting people to stop core from being the authority)
he then tangents to pretend that core cant mandate (due to lapse in his memory of events(the contradiction)).
but when circling back to the facts and not his narrative.
they did mandate and they got segwit activated without miners or users needing to upgrade software to actually use segwit.
because all they had to do was edit a couple bits in a block to signal something without needing to upgrade software.. "due to backward compatibility". pools were threatened to change bits because the 'limited' user that did use 148UASF were the main NYA agreement group that included some pools, merchant tools, payment services and exchanges. meaning they were the economic majority nodes of importance. .. which is why the threat worked. and on august 1st the rejected blocks caused the fork resulting in BCH, which core devs demanded they either stop, or change their 'magic' to not disrupt bitcoin

so any time you see a consensus upgrade described as "backward compatible", it means that it does not require majority to upgrade the software.

because bip148, 91, 141 did not need general users to upgrade software to cause activations of segwit. it worked by the threats of the economic nodes(exchanges/payment gateways)

[DooMAD]

by now everyone should know(including Doomad) that 148 and 91 were used and both involve mandatory rejecting non-segwit blocks before segwit activated on 24th august 2017.

I see, so you're blurring the lines between the date when the required activation threshold was reached and the lock-in date and attempting to make some sort of moral case about what miners "can" or "cannot" do during that period?  This should be interesting.  Please continue.

[franky1]

by now everyone should know(including Doomad) that 148 and 91 were used and both involve mandatory rejecting non-segwit blocks before segwit activated on 24th august 2017.

I see, so you're blurring the lines between the date when the required activation threshold was reached and the lock-in date and attempting to make some sort of moral case about what miners "can" or "cannot" do during that period?  This should be interesting.  Please continue.

i know memory escapes you. but if your unsure about the bips. go read them.

your rhetoric for years was that there was no mandatory split. and that the only time there would be a split is if people run incompatible software when segwit activates and starts making segwit template format blocks. (after aug24th)
yet the bips 148 and 91, and BCH split prove that a fork happened on august 1st (the dates of the bips) not based on segwit activation data and segwit actually being used.

i know you now want to play games pretending you mis understood 'threshold, vs 'activation' to pretend, in previous yours you meant that segwit started making different block formats on august 1st. but you are just playing bad grammar games trying to claw yourself out of the hole you dug yourself

there was no segwit(141) code or detail in bips to start making blocks of segwit template format, or include segwit transactions on august 1st..
the split was due to 148/91... not 141

[LoyceV]

especially when "switzerland" has not tried setting the topic of the day or mediated on the cross talk, to try to get to the crux of a certain topic, one at a time like he wanted

I've been to busy to keep up, and unfortunately this topic requires more time than I can spend at the moment.

[DooMAD]

and BCH split prove that a fork happened on august 1st (the dates of the bips) not based on segwit activation data and segwit actually being used.

Forkcoins like BCH and others are a prime example of how a BIP is not a necessity for a fork to occur.  Sometimes a simple announcement on a blog or other website is sufficient.  That's how BCH came to exist.  They probably had their own equivalent of a BIP in their own code repository, though.

My recollection of the 2017 timeline is:

February 25th, 2017:  Shaolinfry proposes the "user activated soft fork" BIP148 approach
Some time in June, 2017 (I forget the exact date):  BCH devs announced their intention to fork on August 1st, 2017 regardless of whether SegWit had activated or not.  
Mid-to-late July, 2017 (I forget the exact date):  SegWit reached the required activation threshold (BIP91 bit 4 flag) and superseded BIP148's August 1st deadline
August 1st, 2017:  BCH forked off exactly as they said they were going to.
August 24th, 2017:  SegWit successfully locked in.

If anyone can pin these dates down a little more accurately, feel free to chip in.  I feel it's important there's as little ambiguity as possible here.

Given everything you've said, it occurs to me that your overarching concern might possibly be similar to the one raised in this (remarkably prescient for its time) post from 2017?  But correct me if I'm wrong:

Alright, I've been giving this a ton of thought and and both for and against UASF.

No offense meant to the OP, but it absolutely is dogshit, conceptually. Devs on this thread could instantly see that. It took me -slightly- longer.

The worst part, I'm convinced, is what the BU community can do in response. Since UASF tells everyone to pick a side by X date or be left behind in a hostile manner, the BU team has NOTHING TO LOSE by Hard forking on that date. It would be extremely dumb of them not to.

So basically, UASF forces a hard fork (...)

[//EDIT: Above quote pruned for relevancy]

This sounds vaguely similar to the argument you've been making all these years.  Is that the general point you're trying to hammer home?  Or are you saying something else entirely?

unfortunately this topic requires more time than I can spend at the moment.

When you do have more time, do you think the three posts you reserved at the start of the topic for summaries will be sufficient?  

[BlackHatCoiner]

When you do have more time, do you think the three posts you reserved at the start of the topic for summaries will be sufficient?

I think it's possible to sum it up in only one sentence. 

[franky1]

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

[Rath_]

and to rath_
seems to again forget, to edit/change a htlc in a commitment or update/edit/change/sign a commitment . they need to know what needs changing.
he forgets the messages that communicate the information.

he also thinks alice or bob or carol know erics htlc right at the start.
he also thinks alice or bob or carol know erics is online just from network gossip
he also thinks alice or bob or carol know diana is online and liquid to forward just from network gossip

he thinks the deal is complete as soon as alice looks at network gossip and signs a commitment with bob

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 association between the forward and return packets is handled outside of this onion routing protocol, e.g. via association with an HTLC in a payment channel.

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.

[franky1]

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.

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

The announcement_signatures Message

This is a direct message between the two endpoints of a channel and serves as an opt-in mechanism to allow the announcement of the channel to the rest of the network.

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

Thus, A->B's update_add_htlc message would be:

    amount_msat: 5010198
    cltv_expiry: current-block-height + 20 + 9 + 42
    onion_routing_packet:
        amt_to_forward = 4999999
        outgoing_cltv_value = current-block-height + 9 + 42

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

[n0nce]

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

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

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.

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.

Unfortunately, it seems like a pattern with franky1.

For me at least, the Lightning Network does not contain the properties that to me make Bitcoin special.  I don't think it can even be debated whether LN is Bitcoin or not.  It isn't. Lightning is Bitcoin like WBTC is Bitcoin.

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.

There's little difference in my opinion.  Going a step further, I think the LN is just a fancy IOU with some code behind it.

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.

I'm happy if people want to stack sats and transact on the Lightning Network.  More power to them.  Who knows, maybe LN will never have any issues and turn out to be the main global payment system.  I find that unlikely given it's shortcomings, but I think it would probably make a good NFT platform.  

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.

Even in El Salvador, I'm told that transacting in USDT over the Tron network is the preferred method of transfer for various reasons I won't go into because promoting shit scam networks and stablecoins ain't my thing.

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.

[franky1]

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

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

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

   amount_msat: 4999999
    cltv_expiry: current-block-height + 9
    onion_routing_packet:
        amt_to_forward = 4999999
        outgoing_cltv_value = current-block-height + 9

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

   amount_msat: 5010198
    cltv_expiry: current-block-height + 20 + 9 + 42
    onion_routing_packet:
        amt_to_forward = 4999999
        outgoing_cltv_value = current-block-height + 9 + 42

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

[BlackHatCoiner]

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.

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.

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

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)

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.

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

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.

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.

you cannot change a HTLC unless you know the data that needs to be put in it, to change change it

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

Code: (https://github.com/lightning/bolts/blob/f6c4d7604150986894bcb46d67c5c88680740b12/11-payment-encoding.md)

r (3): data_length variable. One or more entries containing extra routing information for a private route; there may be more than one 

r field
    pubkey (264 bits)
    short_channel_id (64 bits)
    fee_base_msat (32 bits, big-endian)
    fee_proportional_millionths (32 bits, big-endian)
    cltv_expiry_delta (16 bits, big-endian)

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.

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

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.

LN is not a network of relaying signed transactions like the bitcoin network

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