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

[Rath_]

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

Code: (https://github.com/lightning/bolts/blob/master/01-messaging.md)

1. type: a 2-byte big-endian field indicating the type of message

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.

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

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.

Code: (https://github.com/lightning/bolts/blob/master/01-messaging.md)

    Setup & Control (types 0-31): messages related to connection setup, control, supported features, and error reporting (described below)
    Channel (types 32-127): messages used to setup and tear down micropayment channels (described in BOLT #2)
    Commitment (types 128-255): messages related to updating the current commitment transaction, which includes adding, revoking, and settling HTLCs as well as updating fees and exchanging signatures (described in BOLT #2)
    Routing (types 256-511): messages containing node and channel announcements, as well as any active route exploration (described in BOLT #7)
    Custom (types 32768-65535): experimental and application-specific messages

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

[hop_data]
this is the 4 aka w of (1(4) aka (v(w)

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

[...] so you can quote 1 usage found in bolt 2, where that single usage is about direct payments to partner

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

[franky1]

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.

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

The type field indicates how to interpret the payload field. The format for each individual type is defined by a specification in this repository. The type follows the it's ok to be odd rule, so nodes MAY send odd-numbered types without ascertaining that the recipient understands it.

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

[Rath_]

hmm really?

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.

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

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.

bolt07 messages: announcement_signatures, channel_announcement, node_announcement, query_short_channel_ids/reply_short_channel_ids_end, channel_update, query_channel_range/reply_channel_range

Their types are: 259, 256, 257, 261, 258, 263, 264 respectively.

find route(node gossip), access fee's accept particular route(channel gossip). have destination accept. hops response back down the path... then commit

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.

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 to then commit to bob

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.

[franky1]

Why would she need to learn the total fees? Each "channel_update" message contains "fee_base_msat"

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

find route(node gossip), access fee's accept particular route(channel gossip). have destination accept. hops response back down the path... then commit

You can remove "find route(node gossip), assess 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.

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]

[Rath_]

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

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.

Code: (https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#bolt-7-p2p-node-and-channel-discovery)

Node and channel discovery serve two different purposes:
*Channel discovery allows the creation and maintenance of a local view of the network's topology, so that a node can discover routes to desired destinations.

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.

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

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.

[franky1]

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

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.

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)

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.

(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

[DooMAD]

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.  

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://bitcointalk.org/index.php?topic=5380215.msg59001987#msg59001987

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

It's all well and good saying that the community should have a bigger say on what the code is, but then you have the chicken and egg problem where users can't agree or disagree with code until it actually exists and then they can all see what that code does.  Then you have the small, but insurmountable, obstacle where Bitcoin is not some sort of committee or parliament with points of order and rules governing social conduct.  There is no way for anyone to enforce a rule that says people can't write code with an arbitrary activation date.  There's no way to enforce a rule saying we aren't allowed to have softforks.  It's just people writing and running code.  If you want to write some code, go ahead.  If you want to run some code, go ahead.  (...)  That's about the extent of your influence here.

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:

dont cause a fork before a consensus change.

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.

we need to get back to a level playing field where multiple pieces of full node full validating full archival software all have equal level as core.

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.    

core, if it wants to be a reference client should only run current rules.

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.  

he stated that bips91 and 148 were never used.

False:

My stance is, and always has been, that BIP91 bit 4 flag is what activated Segwit with 90+% of the hashrate

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.  

[Rath_]

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?

[franky1]

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

It's all well and good saying that the community should have a bigger say on what the code is, but then you have the chicken and egg problem where users can't agree or disagree with code until it actually exists and then they can all see what that code does.  Then you have the small, but insurmountable, obstacle where Bitcoin is not some sort of committee or parliament with points of order and rules governing social conduct.  There is no way for anyone to enforce a rule that says people can't write code with an arbitrary activation date.  There's no way to enforce a rule saying we aren't allowed to have softforks.  It's just people writing and running code.  If you want to write some code, go ahead.  If you want to run some code, go ahead.  (...)  That's about the extent of your influence here.

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.

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.

My stance is, and always has been, that BIP91 bit 4 flag is what activated Segwit with 90+% of the hashrate

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. 

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

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?

read!

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

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]

[DooMAD]

but i atleast know it happened and blockdata bips and quotes from the devs back up my version of events

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.  

even if you didnt run the software doesnt mean it didnt happen

BIP91 bit 4 flag did happen.  

Doomad: "changes to the protocol only happened in my opinion

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

mindset

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.

[franky1]

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

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.

This BIP will have a start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout on midnight November 15th 2017 (epoch time 1510704000). This BIP will cease to be active when segwit (BIP141) is locked-in, active, or failed

Historically we have used IsSuperMajority() to activate soft forks such as BIP66 which has a mandatory signalling requirement for miners once activated, this ensures that miners are aware of new rules being enforced. This technique can be leveraged to lower the signalling threshold of a soft fork while it is in the process of being deployed in a backwards compatible way.

By orphaning non-signalling blocks during the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment.

[DooMAD]

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

Historically we have used IsSuperMajority() to activate soft forks such as BIP66 which has a mandatory signalling requirement for miners once activated, this ensures that miners are aware of new rules being enforced. This technique can be leveraged to lower the signalling threshold of a soft fork while it is in the process of being deployed in a backwards compatible way.

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.

[franky1]

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)

This is the BIP148 possible split point, which is what motivated all of the Aug 1 hubub. But due to BIP91's successful activation about a week ago, it is most likely that nothing of note will actually happen. It is however possible that the unexpected could occur.

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.

At the risk of pissing on your parade, UASF was technically obsoleted by the miners activating BIP91 and in turn, shortly BIP141.  The only way UASF can still play a role now is if miners suddenly change their mind and back out at the last second, which I see as being beyond unlikely.  This is categorically in the territory of MASF, not UASF.  

That said, one could certainly argue that the miners wouldn't have activated BIP91 if UASF hadn't put the gun to their heads first, but the sting in the tail is that some of the miners are still looking to support the '2x' part of SegWit2x, which I know not all of you approve of.  Perhaps celebrations now might be premature.  Best to wait 'til November to see for certain.

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 <your random dream> not the 148/91 activity

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

[BlackHatCoiner]

The technical discussion is over, buddy. It's clear that the problem you have with Lightning is much deeper than just its function. If you want to continue supporting your position, better just dive into this:

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.

If you decide to start talking more socially than technically, the thing changes. We'll probably end up to a point where we simply disagree, ideologically, but this is still good as we'll have cleared up our confusions. If you deny this discussion proposal, then there's really nothing you can do to convince us for your sayings.

Try it.

[DooMAD]

This is the BIP148 possible split point, which is what motivated all of the Aug 1 hubub. But due to BIP91's successful activation about a week ago, it is most likely that nothing of note will actually happen. It is however possible that the unexpected could occur.

maybe you need to spend 5 years arguing with theymos

Nope, no argument necessary.  That post from theymos appears to be accurate and supports what I have said.  

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

Impossible.  If UASF nodes had started rejecting blocks which other Bitcoin nodes were accepting, they would have forked themselves off the Bitcoin network and formed their own chain.  That never happened.    

Honestly, this might go better for you if you don't automatically assume the evidence you are providing supports your argument, when in fact, it completely undermines it.  Try to understand what the evidence really means first, before you jump to the incorrect conclusion that it proves you right.  

franky1 speaks very confidently about his opinion regarding ckpool, solo-mining, pool-mining, nonces, and extranonces.  Please do not mistake confidence for knowledge or understanding.  He's got some facts wrong, and his concept of what it means to be solo mining vs pools mining is not the widely accepted and understood concept.

I think along with solo-mining, pool-mining, nonces, and extranonces, we can also add consensus, forks, Lightning, routing and freedom.

[franky1]

This is the BIP148 possible split point, which is what motivated all of the Aug 1 hubub. But due to BIP91's successful activation about a week ago, it is most likely that nothing of note will actually happen. It is however possible that the unexpected could occur.

maybe you need to spend 5 years arguing with theymos

Nope, no argument necessary.  That post from theymos appears to be accurate and supports what I have said.  

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

Impossible.  If UASF nodes had started rejecting blocks which other Bitcoin nodes were accepting, they would have forked themselves off the Bitcoin network and formed their own chain.  That never happened.    

Honestly, this might go better for you if you don't automatically assume the evidence you are providing supports your argument, when in fact, it completely undermines it.  Try to understand what the evidence really means first, before you jump to the incorrect conclusion that it proves you right.  

as your own words have been saying for years (2018+) that bitcoin never used any mandated activation..
(pretending you have no knowledge that 148/91 were used)
contradicting your 2017 stuff

you even said how you were unaware because you never personally used mandated software so you believe it didnt happen.

then in recent hours you contradict yourself by saying that the bips were used, but however only activated after segwit activated.. by which you are saying 148/91 activated on august 24th

but theymos and many others, and the blockchain data actually show 148/91 activated in late july and august 1st (before segwits august 24th activation.)

as for saying im wrong.. your evidence appears to be just quoting others in your friendship group that say im wrong.. .. and thats it.
thats social drama. not proof.

anyway. this topic has bored me again tonight. seems the certain group doesnt care about facts or data they just want to argue and contradict for the sake of arguing. maybe they should have a private get together with each other and talk amongst themselves and play around with each other, as they seem to like games soo much.

[darkv0rt3x]

As far as I'm concerned and from what I read, you're the one ignoring facts, evading replies to questions (while others replied yours), not acknowledging you are wrong about quite a few aspects, convinced that you have the absolute truth, insulting others, claiming that others are doing social drama when you're the one doing it, driving/deviating all your posts towards what you want others to believe, trying to brainwash people with inaccurate technical info, playing games with grammar/English language/synonyms/phrase construction/etc.

Well, let me tell you this (facepalm as you like to type countless times): you are wrong in many aspects and everybody here already got your game. Saturation, brute-force, confusing people with inaccurate technical terms and statements, swapping your own contradictions and fails towards other people. This is what I call some kind of cheap reverse psychology. And yet, you convinced no one whatsoever. What this means is that by all means, you have no solid data and facts about what you're saying, otherwise I know that people would recognize your knowledge and would recognize their faults/mistakes, which was not the case.

So yes, lock yourself in your shelf, live your own self believed truth and be happy with it!

[OgNasty]

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

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

[franky1]

i have no issues if people want to use sidechange, custodial wallets or LN
they should just, if they want to act like advertisers for those niche services. actually explain why and how its different from bitcoin. (which could actually create positive PR for the niche service). and give an honest view of the risks so users are risk aware and know of the pitfalls and issues.

the attempts to say it is bitcoin it does what bitcoin does but better. and trying hard to put bitcoin down by tempting people over to these niche services like its the utopian solution. well thats bad PR

even with these 160posts in this topic. the amount of contradictions played by a certain group, doing every game in the book to try getting people to not highlight the differences, issues, flaws. is just callous actions by that group
which is why i lost respect for them. and dont sympathise for them when they play victim AFTER their own callous acts

if they actually wanted a good niche service, they would actually be proud to look for flaws and learn the differences and try to get it to work. rather then trying to shut up people that are highlighting the bugs and differences.
those working on bitcoin from 2009-2015 actually inspired desire to point out flaws/bugs. to fix them in bitcoins
now it seems they want to highlight issues to push people into different altnets and services.
those working on LN want to shut up anyone highlighting bugs/flaws/issues with LN, trying to push people into using a less secure network

as for those thinking i jump across many subjects in this topic. well when there are more then a couple different people asking me different questions. all asking me for answers. crying when i dont answer them, then yes my answers will be on different subjects.. but each answer is on the subject the person wants
EG
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

so yes in the last 2 pages i have jumped from talking about LN to then answer doomads consensus stuff because he cries that i ignore him. then rath wants LN answers because he cries that i ignore him.(its like tennis, and im the ball in their game)

yea its one of their games. and it bores me
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

heck i tried to get a summarised view on a certain subject but even that was too much to ask for the main few of the group.
yes LoyceV gave a respectful try at answering the questions. the others, well they just game played to play contradiction/grammar games.

it got boring. and all i could see was their narrative games of just playing tennis with each other, thinking i was the ball.
i dont care for these games. it solves nothing.
so im going to let them go play with each other in their own little worlds.

night!

[darkv0rt3x]

i have no issues if people want to use sidechange, custodial wallets or LN
they should just, if they want to act like advertisers for those niche services. actually explain why and how its different from bitcoin. (which could actually create positive PR for the niche service). and give an honest view of the risks so users are risk aware and know of the pitfalls and issues.

You're so oblivious that you can't even see what you say is false. There is no advertising. No one is being paid to advertise, therefore, there is no such advertisment. But you insist in that non-sense!

the attempts to say it is bitcoin it does what bitcoin does but better. and trying hard to put bitcoin down by tempting people over to these niche services like its the utopian solution. well thats bad PR

That's what you say. But it hasn't to be true just because you said it. Your words don't hold the absolute truth just because you spit them out! You're being egocentric all the way.
You say false things about what we say. No one is putting down Bitcoin when we say that LN is good and solves some problems within the Bitcoin network. That's just you making up words/statements as it fits you.

even with these 160posts in this topic. the amount of contradictions played by a certain group, doing every game in the book to try getting people to not highlight the differences, issues, flaws. is just callous actions by that group
which is why i lost respect for them. and dont sympathise for them when they play victim AFTER their own callous acts

You have been caught in contradictions yourself over and over but yet, you can only see supposed contradictions in other people. Typical of someone like you.
You talk about a group that you invented. There is no group. You're the only one making up groups out of the blue!
You have respect by anyone else but yourself. That's it! Egocentric again!

if they actually wanted a good niche service, they would actually be proud to look for flaws and learn the differences and try to get it to work. rather then trying to shut up people that are highlighting the bugs and differences.
those working on bitcoin from 2009-2015 actually inspired desire to point out flaws/bugs. to fix them in bitcoins
now it seems they want to highlight issues to push people into different altnets and services.
those working on LN want to shut up anyone highlighting bugs/flaws/issues with LN, trying to push people into using a less secure network

You even contradict the reality. LN implementations are open source. Anyone is free to make PRs to fix bugs, add functionalities, etc but you say that people working on LN are not proud of what they do when they fix bugs and add functionalities and let the code open for everyone to engage.
How many PRs have you committed? How many functionalities have you added to the LN over the years? Yet you're moaning all over the place about the flaws, about the bugs, issues, bla bla bla bla... That's what you're good at. Criticizing and bringing other people down by trying to brute-force all your non-sense and insults and whatever!

as for those thinking i jump across many subjects in this topic. well when there are more then a couple different people asking me different questions. all asking me for answers. crying when i dont answer them, then yes my answers will be on different subjects.. but each answer is on the subject the person wants
EG
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

so yes in the last 2 pages i have jumped from talking about LN to then answer doomads consensus stuff because he cries that i ignore him. then rath wants LN answers because he cries that i ignore him.(its like tennis, and im the ball in their game)

yea its one of their games. and it bores me
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

Yet, you're the one with all these crying. But you can only see the crying in other's eyes... Typical once again. Egocentric behaviour.
You have done so many social drama as everyone else. You just can't admit it. Typical of you. Egocentric. It's all about the wrong in other's, never in yourself! Egocentric!

heck i tried to get a summarised view on a certain subject but even that was too much to ask for the main few of the group.
yes LoyceV gave a respectful try at answering the questions. the others, well they just game played to play contradiction/grammar games.

We all gave you a bit of your own game! That's what you get! The buzzwords, the social drama, even the technical part was given to you... All you tried, was given back, still you fail to recognize it! Self-denial...

it got boring. and all i could see was their narrative games of just playing tennis with each other, thinking i was the ball.
i dont care for these games. it solves nothing.
so im going to let them go play with each other in their own little worlds.

night!

So, you got beaten at your own game. F..... FINALLY! lol. Get some sleep!