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

bip91 is not segwit.
bip is the rule of threshold and evaluation of blocks.

bip91 ceases to be active when segwit(141) activates

it was the 148 nodes that rejected blocks which got bip91 to its threshold and beyond which then activated segwit(141)


maybe you need to spend 5 years arguing with theymos

the split of old style blocks by miners refusing to flag for segwit, were rejected and 'nothing to see' on bitcoin of old blocks because they instead mined for BCH

the mandatory flag did work. and got its thresholds within days of activating the bips(148 and 91)

if you still want to deny that bips 148 and 91 were used. first go cry your blindness to theymos and pieter wuille and many others.
then try to read some block data of the flags noted during july and BEFORE august 1st

i know you want to pretend it all happened after segwit activated on the 24th of august. but thats just a laugh that you think there was no 148threat, there was no91 activity before august 24th.


yea remember 141, the actual segwit activation.. which happened on august 24th..
yea remember you admitting 148 threat happening and caused bip91 to activate affirming the threshold needed to get 141 BEFORE segwit activated

..
yea you forgot all that and later from like 2018 YOU went on a tangent that there was no split(BCH not exist in your mind) and how you pounded your chest saying segwit(141) was activated by not the 148/91 activity

not sure why you went contradictory but you did, and you continued for years

Yes.  Key words "once activated".

You keep describing "mandatory" as "users get forked off before rules change".  That is inaccurate.  It goes on to describe "the process of being deployed in a backwards compatible way".  i.e. Does not fork users off.  Would only fork off miners producing invalid blocks after the consensus rules have changed.  

Mandatory signalling != "Mandatory fork" (because, again, there's no such thing)

But you're just going to accuse me of "grammar" / "games" / "mindsets" / "social drama" again because you can't accept reality or understand how consensus works.

ok half a step forward.
you admit that bip91 was used. so you admit to the words of that bip

Yes, you have proven the existence of BIP148.  It exists.  It doesn't change what actually happened, though.  SegWit was activated via BIP91 bit 4 flag.  That is the correct interpretation of events.  That's what happened.  History has recorded it thus.  Any other "version of events" regarding how SegWit activated is either a baseless opinion or a historically inaccurate version of events.  



BIP91 bit 4 flag did happen.  



BIP91 bit 4 flag activation of SegWit is not an "opinion".  It is a proven fact.



Use whatever mindset you like.  Enough of the users securing the blockchain ran the code which activated SegWit via BIP91 bit 4 flag.  Mindsets don't change that reality.

Mindsets also don't change the reality that any developer can create any code they want and any user can run any code they want.  Once a user is running code, the consensus mechanism will then match them up with all of the other users who are running code with compatible consensus rules.  Those users form a network and build a blockchain together.  That's the reality of the situation.

As such, I would present the argument that it's more constructive to discuss reality instead of mindsets.

contradictions.
i know your plaything the
Doomad: "anyone can run software they code/choose" EG to have colourful backgrounds or store data locally differently
just to game contradict
Doomad: "no one can run software and change the protocol alone
just to game contradict
Doomad: "changes to the protocol only happened in my opinion through bip9 because i never run UASF or 91"
just to game contradict


yea you played this game.
but here is the thing.
mining pools actually got threatened by the NYA agreement of the ECONOMIC NODES (merchants, payment gates and exchanges and some other pools) that were using UASF. and pools fell inline flagging the bit number to activate segwit even if they had not upgraded their own software to run segwit.
blocks were then actively rejected that were not flagging it which then got the red line above its 90%threshold (it achieved 100%)
the fact that it achieved 100% in a week should be revealing as something odd even to you. as you and me both agree there is never 100% agreement in a wide community

it does not need 90% of all user nodes to upgrade their software before a consensus change happens.
the extra difference in 2017 is that it only needed the power players to run software that would reject normal/old blocks on a certain date.. which is what the threat and action was.


already answered.
i  know your saying: yea because you didnt use it you think its not part of bitcoin
well ill use your mindset
i never used LN software so its not part of bitcoin.. (and then you cry pleading the opposite)
but here is the thing
nothing on bitcoin shows anything about LN msats or LN gossip messages or even LN peer handshaking. so in bitcoins data/code and in cores peer handshaking there is no LN in bitcoin.. meaning LN is not bitcoin

but what you do find in bitcoin blockdata and bitcoin cores bips is that there is stuff related to how the consensus change occured in 2017 aswell as devs and many others saying bips91 and 148 were used, where even they are backed up by the blockdata

ignorance because you didnt use software. does not make it ok to pretend there is no proof that events didnt happen.
it just means you lack the ability to find the proof to change your mind, because you want to close yourself off from having proof infront of you

heck i didnt use the software, but i atleast know it happened and blockdata bips and quotes from the devs back up my version of events
even if you didnt run the software doesnt mean it didnt happen

---

read!


and in summary.
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#returning-errors
or even just the expiry of not getting a response
(there are many ways for a route to fail due to lack of liquidity)

..
oh and if you want to loopback to the network map construct of having routes before pay to not need to gossip nodes to find route.
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.

you can still route through them via their partners by sniffing out the fee's when trying routes. meaning they only tell you the fees on the response of a route success which then totals the fees to then let alice know how much to pay her partner if she chose that route

and no finding a route using all the messages and getting a response when there is a path. is not something that needs to edit blockchain formatted transactions. nor needs them signed, it can be done via messages of gossip

[moderator's note: consecutive posts merged]

Further discussion is pointless as you can't show me the message which transmits information about channel liquidity once you construct the path. You quoted some Lightning messages in your previous posts, so what's the problem now?

You're skipping ahead.  Let's get the fundamentals nailed down first.  If someone can't accept that 2+2=4, then I'm not going to acknowledge any opinions they might have on quantum mechanics, because their views are meaningless.  Similarly, if someone can't accept that devs can create whatever code what they want and users can run whatever code they want, then their opinions on consensus are equally meaningless in my view.

There is an important reason why this understanding is crucial.  I'll take the opportunity to repeat something I said in 2018 (with a small portion removed in the spirit of keeping things civil):


I assert that this is how Bitcoin works.  I also assert no one has provided a viable alternative.  If certain individuals could gain leverage over what developers were and were not permitted to code, it opens the door to lobbying.  Lobbying is one of the biggest failures of traditional Democracy.  This is why I have often repeated the stance that Bitcoin is not a Democracy.  It's more robust than that.

---

Another reason we need the fundamentals pinned down is because you have said things in the past which indicate confusion on your part.  Take for example:


This makes no rational sense.  A fork is a consensus change.  Further, no one individual is in a position to determine when consensus can or cannot change.  This should be self-evident.



Who decides what qualifies as "level" or "equal"?  There are no individuals in a position to make that determination.  Further, it can't be enforced.    



There is no way to enforce that.  Along with being a failure to understand consensus, I would also describe this as an egregious assault on freedom.

All of these comments are highly problematic if you wish to engage further about how consensus "should" work or that we're somehow doing it "wrong".  First you have to demonstrate you understand how it does work before we can accept any of your assertions that you know how to make it "better".  So again, before you skip ahead to add new questions, please, at the very least, just answer the first two:


Any developer is free to code what they want.
agree[ ]   disagree[ ]

Everyone will be free to run any code they choose.  
agree[ ]   disagree[ ]


Please demonstrate your understanding of these key aspects of consensus.  

---

False:


BIP91 bit 4 flag is what activated SegWit.  I'm not sure how many more times I need to repeat it.

"Mandatory" BIP148, to the best of my knowledge, was only implemented in the UASF client.  However, I never ran that client, so I don't personally recognise it as part of Bitcoin.  That code never had the opportunity to activate as BIP91 activated first and superseded it.  We could also easily spend the next few years arguing about what "mandatory" means and how I disagree with shaolinfry's use of the word, but it's entirely inconsequential now.  

your making a few steps forward finally.

yes before making a payment gossip messages between nodes occur without having to change a blockchain formatted transaction output and without having to sign a blockchain formatted transaction

congratulations. your now a total of 3 steps forward

i know your trying to say that peers dont need to gossip right before the payment. because they have a map of the data.
but here is the thing. how did they get the map of the data.
yep because they sent and received messages. and when do they do this, before making a payment
i can tell your probably going to try turning this into a 'but not 0.1 second before, maybe 1min.1 hour"
(more lame games, so dont bother)


(facepalm)
and you took a step back into playing games
you do recall i said many bolts.. asking you to read them all. where i stated messages of bolts 1,4,7..
and explaining the onion stuff is done at the 1(4) stage

alice does not get the active liquidity of hops(exact numbers). she gets a summary idea ('is liquid?') based on the acceptance of the route not rejecting due to not having liquidity. (not forwarding)
she can find out they have liquidity by them succeeding in establishing a route. using messages. without needing to know exact capacity
in lame speek its not
"how much can you take"answer: amount
inlame speek its more
"can you take this"answer: forward/reject
where she knows she has a liquid route by getting a response on the return path where there is a route to eric and eric has accepted the offer

i also stated that alice cant know the liquidity if a route would work to even commit to bob at the start.
and alice only knows if a route can work after the peers send messages to each other of
AB  BC  CD  DE   and then on the return ED  DC  CB  BA  where by then alice knows there is a route that has liquidity and she then knows the most uptodate fees she needs to total up to then decide which route to take. and then do the other stuff

..
you play games like 'you can choose a route without messages because you have the network map'
then you play games of 'the network map doesnt reveal active liquidity of non partner peers so you need to message the route to find out if a route will work'

your contradiction games are truly boring.

now go back to the point where you know messages happen before a commitment is signed. and move forward from there, stop dancing around going back and forth contradicting yourself.

can you atleast now state finally. that the messages of payment. are NOT performed purely by
blockchain formatted transaction output edits and blockchain formatted transaction signing

and are infact done by the messages between the nodes involving making offers, testing if offer can have a path, and destinations accepting and the path responding back in acceptance.

because without any messages. there is no payment, you cant edit a blockchain formatted  output unless you know the total value needed, and knowing which partner/direction to commit the accepted payment to

Now, I am not sure whether you don't understand it or if it's just a language barrier between us. Before making the payment, Alice should have an up-to-date map of the network. She can build it by receiving "channel_update" and "channel_announcement" messages from her other Lightning peers. The map includes information like: channel ids, fees, total balance and other parameters required for the payment. You don't request these information at the time of the payment.


If you don't receive a gossip message about a certain node, you can't select it while constructing the routing path because you simply don't know that it exists. If you know about it then you don't have to request any additional information (you keep saying that Alice needs to learn the total fees) and you can include it in the path.


My point was that you don't use routing gossip while making the payment. I have already explained above that you get all the information you need before making the payment.

None of the routing gossip messages (bolt07) can return information about liquidity. I asked you which message is responsible for that (you can quote it along with the rest of the payload), but you don't want to give me the answer for some reason. We can't come to agreement because you insist that you can use it this way.

A. "channel update" is a message from one peer to the other about the variables (dust, limit, fees) its not a edit or signing session of a commit, its not a edit of a output inside a commit.

B. atleast you are now admitting these messages are in LN msat denomination and not a commitment sat denomination (1 step forward for you)

C. alice wanting to pay eric 1000, would know bobs ''fee_base_msat". but she does not know carols or diana's because she has yet to gossip via the hops/nodes.

D. because of the limited knowledge of (C) alice cant commit to 1003 to ensure bobs 1fee, carols 1fee and dianas 1fee is met to ensure eric gets his 1000, because alice does not know carol or dianas fee yet.

E. and these messages to find out this stuff, is all node, route, channel GOSSIP.. not actual changes to commitments
F. and the format of these gossip messages are not signed blockchain transactions.
G. and the value in these messages are msat not sat

---

1. "you can remove"... "lightning nodes constantly send/receive gossip"
so its not removed. but thanks for admitting these messages happen  without needing a commitment edited and before a commitment is even considered for editing

2. if you remove find route assess fees accept route....(at any stage before paying) guess what.. you have no route. you cant pay a destination without knowing about them

i know your going to say the node has a list of stuff it received before making a payment. but.. unless it looks at the gossip messages and assess the fees and then chooses a route, it cant then use it pay.

3. i never said that they used funding locked as messages.
i said they send messages, where there are many different types of messages. and then gave an example for whichever scenario

4. turbo send a 'funding locked' message even without the funding transaction being confirmed.
because LN does not use actual blockchain transaction template edits to communicate. it uses node messages of many types

YOUR the one pretending everything is done via editing a blockchain transaction templates output(HTLC)

[moderator's note: consecutive posts merged]

Yes. Again, "hop_data", "onion_packet" and "hop_payloads" are not 2 byte big-endian values. They do not match the criteria specified in the message structure.

If "onion_packet" is a valid type for a bolt01 message then why "channel_update"' type is 258 and not just "channel_update"? It should be a simple question for you to answer.


I have never said anything like that about gossip messages. They can be formatted as bolt01 messages as all of them have a valid type.



You can remove "find route(node gossip), access fee's accept particular route(channel gossip)" as Lightning nodes constantly send/receive gossip and build a local map of the whole network. They use it to calculate payment paths.

Another simple question for you. How do they response back then? What's the message they use? You used to say "funding_locked", but you now know that it's sent only to signalise that the funding transaction has reached enough confirmations.


Why would she need to learn the total fees? Each "channel_update" message contains "fee_base_msat" and "fee_proportional_millionths". Every node in the network listens for these changes and adjusts their local map of the network. Alice already knows how much she is going to pay before she actually tries to send the transaction. Did you forget that wallets choose paths based on their cost and length? How do hops reply that they have enough liquidity in your opinion?

I am not even going to talk about my node's logs again. I gave you the proof of what's going on under the hood if your node can't route the incoming payment.

hmm really?
https://github.com/lightning/bolts/blob/master/01-messaging.md#lightning-message-format

so nodes do accept many messages. even if they are outside of YOUR limited personal knowledge of bolt2

if you really want to play games that a node never sends onion routing messages or routing gossip messages without being encapsulated in a channel HTLC commit, you can play those games for decades. but you will just be playing with your group
only they would be rewarding you with merit and patting you on the back for playing games..

i know your game is your narrative that the only messages sent are bolt 2 channel management messages.. but guess what. before a channel is even set up, node messages are asked to find out what type of chainhash and channels are available with a peers node. yep how can you assert that all messages are suppose to be encapsulated into a channel message if there is not yet a channel.
how can a peer encapsulate a onion message if it does not yet know which channel the partner wants to utilise for their forward to the next peer

nodes send messages outside of a blockchain formatted template of output+witness.

but hey. it might take you some time to read all of the bolts. , but dont reply if your just going to try to push conversations back into bolt 2.. (there are other bolts, with other messages, learn them)

so go play your backward-of-time-and-logic games elsewhere
i know your thinking alice can psychic predict that she needs to pay bob 1003 for a 1000pay to eric via hops through bob carol, diana.. so alice predictively commits to bob 1003 before even trying to find a route. or before alice even knowing carols, diana's fee.. or before even knowing if carol and diana have liquidity to pay to eric

but here is the thing. alice has to try a route to first know if one can be found, whether hops have liquidity to forward,  and find out the total the fees actually are once eric accepts the offer and the messages return back down the path.. to THEN allow alice to commit to bob with known amounts

its not:
pay first via commit(update_htlc), find route second via channel messages of a signed blockchain transaction.
its is:
find route(node gossip), assess fee's, accepts particular route(channel gossip). have destination accept. hops response back down the path... then commit

the messages of finding route and calculating fees are not in a channels blockchain formatted transaction template output(your update_HTLC understanding)
the dust fee, min fee and the other things are variables that can be looked at without having to change a blockchain formatted transaction templates output.
you dont need to sign blockchain formatted transactions just to see if a channel has liquidity, fee's or other channels with other peers

learn all the gossip messages and packet messages that dont involve updating a HTLC
because alot of messages are used before even updating a HTLC

here is a summary flow
decide to buy something
find destination recipient via a route path
make an offer
recipient accepts the offer
route path messages back
payer commits at payment success
commit can be broadcast to settle

i know you want to only target: (your bolt 2 narrowminded target)
payer commits at payment success
commit can be broadcast to settle

but your missing out on all the 'gossip messages' and node interactions of:(multiple bolts)
decide to buy something
find destination recipient via a route path
make an offer
recipient accepts the offer
route path messages back

bolt04's type is not the same as bolt01's type. See:


onion_data, onion_packet, hop_data don't seem like 2-byte big-endian fields to me.

You will again accuse me of playing grammar games, but it's not my fault that the specs are so strict.


I don't see any contradiction here. In order for the bolt01 message to be valid, you need to set a type which will be understood by your peer.

type: onion_packet is out of question as it isn't a 2-byte big-endian field.

You need to stick to the types listed in the specifications.


As you can see, none of these types reference bolt04. Thus, you need to find another way of sending the onion packet, which is the payload of "update_add_htlc".


Sending just hop_data doesn't make any sense. I have told you that countless of times.



You might need to look up the meaning of "to forward" in the dictionary again as you completely ignore "Forwarding HTLCs" section of bolt02.

i know you only know of the channel and htlc update stuff

and now your narrative is that onion routing is not encapsulated in a bolt 1 format

but then you contradict yourself by saying bolt 4 messages are payloads of standardised messages(as set by bolt 1)

so you are playing grammar games, as your way of ignoring bolts 1,4,7 just so you can quote 1 usage found in bolt 2, where that single usage is about direct payments to partner

...
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#packet-structure
^ this here is the (1) aka (V)

^ this is the 4 aka w of (1(4) aka (v(w)[/color]

^ this is the m of (1(4(m)) aka (v(w(m))

so now, take yourself off of the bookmarked bolts 2& 3 pages. and explore the pages of the other bolts more.
try to think outside of your channel management box, and think about the node functions, node messages between peers outside of a direct payment scenario

I have never said that. You are probably referring to this quote:


I hope that you read it too fast and misunderstood it. Let me repeat again.

bolt04 does not describe any independent messages than can be sent in bolt01 format. bolt04 describes payloads that can be included in other standardised messages.

For example, bolt04 describes "onion_routing_packet". It can't be sent as an individual message. You need to put in the payload of "update_add_htlc" message as per specifications.


Don't forget that we were talking about bolt01's "Routing" type messages. As bolt04 does not describe individual messages, but payloads, they can't be bolt01 formatted.


I am ignoring your (1(4)) message as it is a non-standard message and it would be discarded by other nodes. Again, here's what your message would look like.


And before you say that (4) refers to "onion_routing_packet" and not "hop_data", think about it again. "onion_routing_packet" can't be sent as an individual message as well. You need to send it through a standard message, like "update_add_htlc".

yes which is where he is pulling a doomad

what rath_ is doing is although the fact of the actual writing of the bolts is that bolt 1 sets the type. and inside it are certain messages..
rath wants to narrate that its bolt 4 that then has bolt 1 inside.
its actually bolt 1 that then has 4 inside

i even pre-empted that game HOURS before he tried it by doing the (v(w(m)))
and i have explained it many times now..

he also tried to take some limited points about bolt 7, and pretend i said bolt 7 is purely about onion packets. when infact its bolt 4.

routing (both channel gossip and onion packet messages) are concerning both 4 and 7.

..
raths original game was to only want to narrate the flow of conversation towards the inchannel changes of bolts 2&3 which have nothing to do with the payment messages and forwarding stuff that involve bolts 4 and 7

---

i did answer your question. but without having to play around with blue writing to edit the question, i just wrote some out to get to the real context of the contention/argument/debate
(second half of this post)
https://bitcointalksearch.org/topic/m.59001987
my answers have never waivered, and never been contradictory and i have stood by them for  years. so its more important that you answer them due to your own contradictions and flip flops. that way we can get to the actual opinions you want to stay strong on to actually know which narrative you wish to proceed on .. to hopefully end the contradicting narrative games

anyways
now lets get to the consensus topic doomad wants to discuss.. and ill do so by explaining what "doing a doomad" is

.. for 4 years doomad has been spouting endlessly that there was never a mandatory activation. he stated that bips91 and 148 were never used.
and then deviated to pretend 2 other bips were used and tried to play games about how there is no mandatory wording in his other bips he suggests were used.

the thing is. bips91 and bips 148 were used and both mention about rejecting blocks that dont signal to activate segwit.
he might forget/ignore that the blockchain data actually shows the bit flags in the block data of the bips involved in bip91 and 148.
even pieter wuille and theymos were quoted as saying it was used.
he might keep forgetting just to spin his narrative into his ignorance of wanting to talk about other bips.. but thats just him doing a doomad. (saying something unrelated and then suggest whats unrelated doesnt contain the related things.)

summary

bip91
https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki
"While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected. "

bip 91 is blue line and bip 148 is red line

red(bip91) caused blue(148) to spike to 100%
doomad wants to only discuss things after august 2nd 2017 and avoid the stuff that happened from march-august1st 2017

---

rath wants to talk about channel changes to commitment and avoid all the messages about value movements that lead upto needing to commit

.. im bored of watching these groupies play these games.. goodnight

Except for the part where Rath_ definitely has spoken about bolt07 and bolt04 and explained to you why they don't mean what you think they mean.  Here it is again as you appear to have missed it:



Also, I'm still waiting on a response on my previous post about consensus.  Kindly answer some of my questions before you attempt to add more of your own.  

yep your definitely doing a doomad trick.

bolt 1 involves explaining all messages.. do not now make it be narrated that your opinion is that bolt 1 is purely about HTLC updates.

yea i know you dont want to talk about bolt 7 and 4, because then it means coming out of your bolt 2&3 box

Oh, great. So, you have just admitted that "update_add_htlc" (which can be bolt01 formatted) contains "onion_routing_packet", which includes routing instructions ("hop_data"). Now, read the "Forwarding HTLCs" section of bolt02 again and you will learn that you have to commit that HTLC (for your own security) before you forward it to the next hop. You also admitted that bolt04 describes the payload and not the actual messages that are sent to other nodes, so don't bother mentioning it in this case again.

I am not going to answer your bolt4/bolt7 ramble as it is clearly a trolling attempt, just like the HTLC signatures and payment secret case.

Good night, franky1. It was fun to argue with you again.

you didnt mention all the messages/types related to onion routing and gossip routing. you tried to pin them down to just 6 types.. by ignoring the rest
(you only wanted to mention 6 messages you know of relating to channels stuff.. AS ALWAYS)

also i pre-empted you by purposefully doing the (v(w(m)))
because the V is the type (described in bolt1) which encapsulates (w)channel gossip, or onion route packets

i did not say w(v) aka 4(1) which you are narrating as your narrative to be "bolt 4 does not contain bolt 1"
its actually infact bolt 1 contains bolt 7 or contains bolt 4

but nice try trying to ignore bolt 4 (onion routing) and then state onion routing is not found in bolt (whatever game your playing) and its never quoted by me as 7 being just about the onion packets

payments which require finding routes. and then sending onions packets is the bolt 7(find) with 4 as payload. ..
emphasis again. nice try taking bolt 4 messages and cry that you couldnt find them in bolt 7

your obsessed with the messages that trigger commitment changes. (x(y(z))) aka (2(3))
but you ignore the other types EG (v(w(m))) aka (1(7)) message to find channel and (1(4)) for the onion packet

you just sound like your doing a doomad now