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

seeing as you want to limit yourself to a DNS uptopia and a 3 messages scenary of network wide channel update, and the only in channel partner private message share of update htlc and commitment signed.
but let me just show you a few things outside of your box.

the ping pong message:
first you claim that unknown message types are just rejected, yet
https://github.com/lightning/bolts/blob/master/01-messaging.md#lightning-message-format

first, im guessing you didnt read the bolt about pruning the map(i call it cutting off branches of the tree)


its funny because not only are you trying to make a narrative that its all public, al channels, all nodes, always listed unless channel close is announced formally..
but you also contradicted yourself before even making your narrative by your own admission that "private channels are channels that have never been announced to the network".. i guess the DNS philosophy must be psychic then.. having the listing without it ever being announced. amazing. much like your make a payment without sniffing the route or knowing whats available on the route.
yea, seems like utopia best-case guess and exaggeration of psychic understanding of the network without sniffing the network is your narrative.(YOUR philosophy of not needing to ping to see if route is all active, just sign a commitment and wait for fail to learn(facepalm))

where as reality is more like nodes only know about their map(tree branches) of the peers within their tree. and only get announced updates when a node wants to announce. and that ping and pong messages can happen inbetween such formal announcements to test a peer is still active and also to arrange regular key changes and updates of fee's

..
but your philosophy of only relying on network wide(facepalm) formal announcements could leave your map outdated
https://github.com/lightning/bolts/blob/master/01-messaging.md#rationale-4

oh and yea, i know you think that the messages of amount, fee, cltv are only handled in htlc updates(your 3 message type limit box). but take some time about the thoughts of ping-pong payloads and their ability to have TLV's (payloads) of hundreds of types..

P.S
and my hints are not of anything new, its stuff i have already said. but things you have failed to have "make the connection with"(pun intended) yet

Again, about that fantasy....


Private channels are channels that have never been announced to the network. Disabling a channel does not make it private. All nodes still have that channel on their map, but they know that they can't temporarily use it for their payment.


That's possible. However:



Even the ping/pong messages? Are you sure that we are looking at the same specifications? You might as well put a picture of your cat inside of your "ping" message, but the recipient won't know how to handle it correctly as it's non-standard.

---

If you actually looked at my logs and posts, you would know that my payments failed either at some further point in the route or due to no liquidity in my second channel.



Imagine that B, C, D, E updated the parameters of their channels and didn't broadcast the changes as "it's spam". Alice would have to query every single one of them to be able to send the payment. By the way, how would Alice know that all of her information is out-of-date? Asking each hop individually would consume a lot of time.

If the payment fails due to outdated "channel_update", "update_fail_htlc/update_fail_malformed_htlc" can actually return an error message along with the latest "channel_update". Still, the payment would fail 4 times in the above scenario.


I don't think that any implementation behaves this way as it would complicate routing a few different payments at the same time. The sender can actually obfuscate both.

CLTV:


Fees:

In the "onion_routing_packet", the sender can intentionally set "amt_to_forward" to a lower value. As a result, the fee paid would be bigger than the one that can be calculated from publicly known parameters.

your word games of "no one can change the code" and "anyone can change the code" are contradictions. done so purely to avoid mentioning the actual events that actually happen.

i know your contradictions, you have said them for 5 years. now stick to the facts of the actual code and the actual bips. the actual events

are you now denying 148/91 happened or are you accepting 148/91 happened

segwit activated on 24th of august. .. not the 1st
it did not require majority to run segwit on the 1st to trigger the segwit grace period

at that date of august 1st it required legacy node users of pools to just change a bit flag in a header. that is all. or have their blocks rejected. again nothing to do with segwit block template formats causing rejection.

the threat was not of 10,000 nodes rejecting blocks where those nodes are all random users. unable to understand segwit format templates.
the threat was from 50 prominent economic nodes(merchant services, exchanges, pools(NYA)) rejecting blocks without the flag. meaning opposition pools(not flagging) cant then spend their value.

again you forget that its not a opt-in to activate. it was a opt-in or else get your block ignored.
where the block count after then triggered segwits grace period due to lack of opposition.
again witout any pool needing to run segwit code that could create segwit block templates

again it was not a normal system where those who dont upgrade would get forked off purely due to them not understanding accepting a new format after activation.
it was those not showing willingness to allow a new feature to even enter a pre-activation grace period will be forked off.

it didnt require everyone to upgrade. to activate. it just required a flag to say you dont want to be forked, which also was the same flag used to allow segwit to enter its 3 week grace period to activate segwit

ok ill make it simple

1. which version of events happened in 2017
A[ ] mandatory fork(148/91) before aug 24th.. then segwit graceperiod leading to segwit(141) activation on aug 24th
B[ ] segwit graceperiod leading to segwit(141) activation, without 148/91 flag event prior

2. what bip/code required nodes/pools to upgrade software upto august 1st to cause a segwit activation

3. what bip/code required nodes/pools to upgrade software upto august 24th to cause a segwit activation

Guess we're not done.    



No.  Not just the core devs.  Any devs can change code.  And what I "want" is irrelevant.  I'm not telling you what I want, I'm telling you how it is.  Facts of life.  Neither my desires nor yours count for anything.  This is simply how it works.  I'll repeat again:

You know what I'm saying is accurate.  Don't go twisting my words to deflect from the part where you don't have an answer.  



Unless enough people run the software.  Again, please stop with the needless hyperbole and distorting what I have said.



I don't deny their existence.  You are yet again misrepresenting my words.  And again, it still required enough of the people securing the chain to run code to make it happen.



You haven't debunked anything, they did need to run code to change the rule.  Do I really have to say "BIP91 bit 4 flag" again?

//EDIT:


For that to be my word game, you would first have to provide evidence that I've said "no one can change the code".  Otherwise you're being dishonest again.  And I have already described events as they happened.  I'm not repeating myself again.



I'm saying your understanding of what happened is flawed.  You stated:

This is false.  The paltry number of people running the UASF client would have resulted in a minority chain split had BIP91 not superseded BIP148.  BIP91 happened.  BIP148 failed, although the threat of BIP148 did result in the unilateral announcement and subsequent enacting of the BCH fork.  Please get it right going forwards.


//DOUBLE_EDIT:


If all you have to teach is tyranny, it's not surprising no one heeds your "lessons".    



And the delusional want to stick with their delusions.

Thanks for playing.

i know you want to let the devs of core just change things as they please..
i know deep down that you know that they have done it even without users needing to upgrade to vote.

so why play games of denial acting like upgrades cant now happen unless everyone runs the software
again you deny the existence of the backward compatibility that ensured those not upgrading didnt count at the protocol
validation level.
(debunking your 'those securing the chain run the code to change that rule' - no they didnt need to)
and the block rejection of non voters ensured the opposition pools didnt count at the block level.
(debunking your 'those securing the chain run the code to change that rule' - no they didnt need to)

so why keep saying that things can only upgrade if majority vote for it.
consenus should be. if there are 10 pools the vote should be 9/10. but what actually happened. before pools even downloaded the actual software to even make segwit formatted blocks. pools using legacy code. had to (by threat) just flag a bit in a header. or have their legacy block rejected

EG if 7/10 pools vote yes. it wont activate. so the bips used would reject the 3 opposition to then have a 7/7. before then activating

you are pretending there was no threat, when deep down you know that the new trick is to just reject the opposers, and slip a stripped block to the abstainers.

seems you just want to pretend that everything should only work the way core want it. with a FAKE pretence that users should just take the centralised point of failure as a feature. and that core should continue as they please

But only if those securing the chain run the code to change that rule.  And yes, I know you won't acknowledge that part, given your past comments that you think all users are "sheep" and just blindly follow, but okay, whatever.

Consider us sufficiently "aware", even if we're still not in agreement about your interpretation of events or morality in general.  I acknowledge that softforks have the potential to be controversial, however, I maintain that they are permitted and, provided they find sufficient support levels, they absolutely can happen.  Neither I, you nor anyone else can change that.

Are we done?

Okay, that's it. I can't continue this further. I don't make any sense and I can't stand the mood of the discussion with this unwholesome person. There's no discussion at all, it's just franky spitting nonsense perpetually trying to psychologically project himself.

This thread is pointless. Neither we nor he will accomplish anything.

point is. that people should be aware of actual events and the risks that come with things.
i know your "a pretend it didnt happen and shut anyone up that wants to discuss it" type of person
i know your a "deny it happened and argue with people that want to discuss it" person

but how about you stop contradicting yourself to cause debate and stop calling people a liar because they say something that goes against your view.

basically, LEARN actual events, and then be consistent in your memory of those events
in short.. stop the contradictory social drama of trying to hide discussions about risks and issues people want to discuss/know.

by making people aware. makes people risk aware if these things are attempted again.
by you wanting to hide the risk, deny the risk, you want people to aimlessly let the risk happen again.. which is not a good or helpful thing on your part.

EG LN: making people aware of the pegged asset, and the payment systems different denominated token, and how the payment system can allow unpegged tokens.. is making people aware of how the 19th century bank system moved away from the gold standard.

EG consensus: making people aware of a mandated activation done via opposition rejection pre-activation to fake 100% for activation. shows that devs could repeat the same thing again if they ever wanted to break a rule that should not be broke

We're going round in circles.  Let's pretend that you somehow managed to convince us to accept your version of events and, by some miracle, we all decided to accept your assertion that:

• softforks = immoral
• activation dates = immoral

(I don't accept that, clearly) But what is the next step in your plan here?  

There have been 11 pages in this topic (and countless pages in others) and we're still no closer to establishing what it is you actually want.  

What are any of us supposed to do about it?  What actions can be taken?  There isn't a single person on this entire planet who can promise you that the stuff you're moaning about won't happen again.  None of us have that kind of power (and that's a good thing).  I am 100% convinced that what you are asking for is not remotely feasible.  

Say, for example, you somehow managed to convince every single current developer to agree never to code another softfork or another arbitrary activation date ever again (which isn't realistic, but let's pretend).  What is to stop any of those developers from changing their mind later?  What about new developers who haven't agreed to those terms?  

No human being on planet Earth can stop someone from creating code in an open-source environment.  Ergo, what you are asking for is impossible in Bitcoin.  Either prove that it is possible, or kindly give up.

proof of threat, proof of wanting someone removed
well
https://bitcointalksearch.org/topic/ban-request-for-user-franky1-5380036

and who made this threat.. ohhh it was you

but i do like your quote of what you deem my abusiveness comes down to

i usually say those things multiple times per post.
but lets be generous and pretend its 1 "abuse" per post and just call it 1055 posts. (its actually far far less)
well i have made 22,000 posts
where by, even at exaggeration of extending some generous stretching, thats only 4% rate. (reality is more like 0.5%(but who's actually counting))

but if those words are so abusive in comparison to 'autustic, liar, troll, angry man, mental case, ban him"
then its probably worth you realising, that im not the harshest abuser. and you picked the wrong bear to poke.

and if you think im more abusive than you, then please show me where i have demanded you be banned

heck ill be generous, and admit a word i have highly over used and deemed as abusive

fangirl: 39
oh and some context, i have been talking about a certain group of like minded people since 2015
16,000 posts ago. yet 39 of 16000 is 0.24% abuse rate

but hey lets be generous lets post count from the date i first used "fangirl"
5840 posts ago (2019) is still only 0.66%

so if you want to pretend im abusive in every post, or abusive in majority of posts.. please do try harder

now how many times has blackhatcoiner "abused" the word wrong:203

now how many times has Doomad "abused" the words
wrong:507
ignore:114
troll:100
lie:75

This is a lie, I'm not that kind of person. Quote me wherever you think I did this and I can give you a reasonable justification.

This doesn't make any sense.

Neither this makes sense, you started the nonsense again. I've never threatened anyone if that's what you mean.

funny that you now want to ignore that 148/91 happened(again), and pretend it didnt happen, because.... i said it did happen so it must be wrong..

you have the very oddest gauge of deciding an opinion.. you base what is in your reality, not by evidence like block data and bips.. but by who is telling you it, and are they kissing your ass or debating you.

your opinions seem to be based on social bias where you ignore evidence just to stay loyal to your friends opinion, or to say the opposite of evidence if some one is debating you or your friends.

you use friendships of like minded people as your backup... not evidence.
i see many people like you, the conspiracy nutters on the P&S category are much the same.

EG if you were a court judge, you happily would take here-say statements from friendly people, and ignore any documented evidence from brash people.
you sir, would be the type of person that gets innocent people locked up and turn them vengeful, to then use their anger of wrongful conviction as a reason to never overturn the conviction. 'keep him locked up, he is angry i dont want him in society'
and if you ever did decide to release the innocent. you would blame the brash evidence giver for not being an ass kisser as the reason for the conviction. not your ignorance and personal social preference

oh well, your boring me. if you want to forget ignore that 148/91 happened. thats ignorance is on you.

and blackhatcoiner does not want proof, he just wants me to shut up.
he thinks absence of opposition by removing opposition, then becomes the proof that blackhatcoiner opinion must be true.

no wonder doomad and blackhatcoiner like each other.. they both DONT want evidence. they just want a lack of evidence that disproves their opinion, by trying to shut up anyone providing any evidence.

seems familiar.
like threatening to remove the opposition unless they pander to your mandates. and anyone still not falling inline, you just reject them and not count them... so that all you can then see and count on, are those who agree and have your like minded chain of events. thus you activate your mindset as fact based solely on that game

hmm..

---

as to rath.
here is the code for LND that shows that channel data is stored not in binary rat blockchain format template. but in variables of keys and values. where 'amount' is saved in millisats

https://github.com/lightningnetwork/lnd/blob/master/channeldb/channel.go
the first several hundred lines of code are the variables..

and it does NOT just have a simple 'sent to file (raw tx)'
where rawtx is a blockchain formatted transaction template in sat denomination

oh and if in any line of code it says "btcutil.amount", this is not a reference to sats in btc form..
its actually
https://github.com/btcsuite/btcutil/blob/master/amount.go#L13

Bottom line:  Even if we accepted your version of events (and I'm not convinced anyone does), you have still yet to propose an alternative that doesn't amount to "devs can't code things I don't personally approve of" (and also split the network).

That's not a "rhetoric".  That's you failing to provide a compelling argument.

You ignore him and demand from the rest to ignore him too, because you think he's a troll. You're suddenly sounding like franky. If you want to shut him up, better do it with arguments. This is the hard way, I know, but it turns out it's the only way. Ban requests or ignorance will do more harm than good.

The fact that we've made 11 pages in this thread and another 5 on my ban request proves that this case isn't simple.

But it is that simple, because he is trolling you. Remember when I was alone debating him, and it only annoyed everyone because many topics became “Wind_FURY and franky1 show”? Someone actually said that.

I have limited technical knowledge, but I tried debating him alone, without help except from DooMAD, because I knew he was lying, only to learn weeks and months later that he was gaslighting the NEWBIES who will read through without technical knowledge themselves. He is also trolling you now, and he will post long technical stuff to confuse you. It’s better not to debate franky1, it’s also better to educate newbies.

Man, what's wrong with you? He's talking to you as politely as one possibly can and you behave with complete lack of courtesy. People talk to you calmly and you either insult them or snob (?) them.

You're constantly complaining about the off-chain solution (which works brilliantly IMO) and want to persuade everyone with demagogue that the block size increase will do the job while history has shown that it simply flusters the network.

And again;

aaaanndd domad has gone back to ignorance of the consensus stuff of 2017 all over again
pretending it didnt happen.

i though finally 2022 will be the year doomad remembers and accepts the 148/91 stuff.. understanding what happened. the real sequence of events.
but looks like he instead has retreated back to his other rhetoric of ignorance again..

im not even going to redeem him by suggesting that he does know what actually happened and is just trolling a different narrative just to be argumentative.. instead ill just go with what he is trying to pretend himself as, someone ignorant and forgetful. (well he wants to present himself as this, so illl go with it)

i thought it would take him 3 weeks to retreat back to his foggy memory.. he managed it in 3 days

---

alice can connect to bob(only bob in this faction example) without a channel, to sniff bobs channels, or create a channel with bob. but alice can only get a route tree(map) of only the data bob has access to(wishes to disclose), which is in the case of ABCDE faction.. only ABCDE (only if all ABCDE are public(allowing disclosure) and only if bob wishes to disclose)

you then pretend alice pings the entire network or a central mempool/repo/dns (whatever fantasy variable your have tried to add in) for the rest of the network

you than back down and say another fantasy, that alice magically must connect eventually(facepalm) to some outside node.
..
sorry but your statements are utopian hope. not actual fact at opening the node to have a entire network map of all nodes everywhere within seconds so she can simply make a payment "instantly" 100% success..(in your view) to anyone without sniffing with regular messages
.. sorry that just doesnt happen

---

FTFY

thank you for agreeing that channels can be made private/publicly at a whim any time..
(after your multiple post saying its not)
thank you for agreeing that alice cant send to carol. but eric-diana-carol can send bob or to alice when bob goes private


funny part is. my quotes "tell alice that the BC channel is not available" is not me changing my assumptions. it is not me saying that BC channel is or is not public. its that there is more then 1 way to dissuade alice from using BC as a route.
im clearly still using the narrative that bob isnt telling alice about BC. so the assumption is the same. im highlighting there is more than one way to do so.
im saying more than one way, because you think that there is no way, because before this evening you were adamant that the nodes are all default to public from the start.. and all have a global map of everyone.. so im just showing you that its not true.

its not just by setting the disable_bit, it can also be done if bob is also public, but when alice queries bob(different messages) , he can also:
time out the query
respond by missing out details of a channel

there is absolutely nothing FORCING bob to submit to alices request, when she asks for a list of channels.
there is nothing FORCING bob to have to list all channels.

---

in your utopia of a network map showing all channels all updated in 0.001seconds, yea sure, waste of time, go ahead built your route and send your payment.. .. i think i now see how you got your 70% fail rate.

because payments are private. and not on the map.  even by using limited info from the 'map' alice still does not know how many 'inflight' payments (pending) bob,carol, diana has.. this means alice does not know the liquidity of the route. and so alice can 'walk the route" to gain details like cltv and fee's aswell as see if a route is viable.
you know. because users may want to update their fee's and cltv for every payment to add some obfuscation.

the process is lots of messages happen before-during and after. [pre-flight] [in-flight] [post-flight]
is not like one initial sync and then nothing for minutes-hours.
nodes can talk to each other using query messages.
its not just to get updates but also to make sure they are still online.
i know (in your view) you think there are only 3 messages structures and all involve update channell update htlc and commitment signed..
but there are hundreds of messages.. heck even the simple ping/pong messages can include updates to the fee's cltv's and such..
its not some mass harmony of network gossip that makes everyone public right from the start. its lots of messages happening before during and after payments, which make payments happen


i know you are obsessed with just 3 messages. but there are other query messages to get fee amounts and cltv amounts.
also i was not the one setting a narrative of a full network broadcast where everyone gets the information for everyone to have a global map of everyone, thats always uptodate... YOU WERE

each node has a different map tree of their connected(directly and peer of peer indirects). and thats all they have.

your the one that thinks a node knows everyone or just needs to initial sync or get a invoice and everything is ready to just commit.

funny part is an invoice doesnt always include 'possible route' hints.
why. because when someone makes an offer to sell something and has their LN uri to show a users were to send payments to on a forum post/blog post or private communication DM on other platforms.. that recipient does not know who wants to pay him to have even sniffed the network map or his routes to find a payer.

again time travels in one direction. you cant know everything before someone decides to pay,

its getting more obvious why you have had 70% event fail rate. and why your still unclear as to why


if eric sent me an invoice. he would want to obfuscate some details for each payment even the ones not for me. so his last 5 parameters may be different for my invoice from him, compared to an invoice he sent to someone else 2 seconds earlier..

also
an invoice is just an offer.. its not a thing that has a 'network map' of insight of all possible routes. because invoices could be static uri with offers, where the invoice is posted to a forum as the way of saying 'pay me'

you still then need to look for a route or other routes before just paying the invoice giver
again your forgetting about all the messages inbetween.

for instance if eric is handing an invoice saying he wants 1000msat..
you still need to know about bob, carol, diana.


also eric might have changed them parameters in the 5 minutes of me getting the invoice and deciding i definitely want to buy something from him..

for instance since the last 'network map' update via bob of carols 'state' carol could have changed her fee 100 times. this is because carol might want to use different fee's per payment for some obfuscation. or change her cltv value instead of keeping the 9 default.

she may have updated other channels..
         t
       /   
a-b-c-d-e
       \
         z
..other channel partners(t&z) where she has inflights(pending payments) with z or t
but because for last 5 minutes she has not sent or received a payment from bob, she has no reason to update bob
nor would she want to 'network map rebuild gossip' bob every payment she gets from d, e, z or t as thats alot of messages to update to b even when B is not doing anything.

and eric too could have changed his parameters too depending on his other payments with others.

if you really think that all channel updates result in keeping an map tree uptodate, you are thinking of spam.
and yes nodes do want to change things like cltv and fee to add obfuscation per payment even with out publicly announcing it everywhere..
because whats the point of advertising it to (your view of a network map) to add obfuscation, if the point of adding obfuscation is to hide from the network map
..
i really am starting to understand your 70% fail rate now. seems you have been coding in some stuff that doesnt use logic or checks.

---

something even more surprising for you.
most node software dont even store their own commitments in a binary form of a blockchain transaction format.(raw tx)

they actually store it in variables of value input output signatures and keys. much more similar to the messages i have been talking about.
heck i know you want to imagine LN only store blockchain format transactions. and only sends messages containing updated commitments already signed or to be signed..
but thats not how it works

there are no messages sending blockchain formatted transaction templates. even the hard 'backup' doesnt store blockchain format transaction in raw byte array.

the messages are not like that, the storage is not like that

yep they dont store blockchain transactions. just bits of data that they compute a signature in ram by temporarily building binary arrays. to sign. and then store the signature plus the amounts and keys. (not a full raw blockchain tx)

(but ill get more into that later, im not sure your at that point yet. maybe a month, or more.)
(you took a few steps forward so your on your way, but you seem to want to drag it backwards so im not predicting your going to cotton on to LN's real differences just yet)

---

anyway this topic is getting boring with the contradictions and dancing back and forth thats happening
im not even going to bother to try pegging people down to one narrative using simple questions.. (tried that, they declined)

so, maybe i will skip a few steps ahead rather than wait for rath to dance back and forth

so here goes..
imagine i was carol(C)..
A>B>Cmy node1                             Zmy node3

                            my node3  C>D>E

(A)lice can pay (Z)oe even though A only has a network map tree of B>C(if i(via node1) decided NOT to respond about my node3 paths)

yep i dont actually need to have a tree linking all channels via a peer pass the parcel of linked peer channels from start to end.

yep DEWXYZ can all pay A. even if the Z does not have a network map tree of
ABCWXYZ.

ill let you have a little think about that.
hint my node 1 has no 'channel' to my node 3.. yet via my private messages i can allow A to pay z or A to pay A without either of them having either of them on THEIR maps.

(i know your not ready to be out of the 'direct payment to channel partner' box, and think that nodes dont need to sniff routes when making a proposed payment.. but.. i hope you get out of the box soon)

[moderator's note: consecutive posts merged]

I mean, that's certainly one opinion.  Another opinion would be that those securing the network, right now, as we type here, could easily amend their code to increase that limit, but they are choosing not to do that.  Why do you think that is?  Perhaps your view is that there must be a conspiracy of some kind.  Maybe that seems like the most rational explanation to you.  But I would suggest the real picture is altogether less sinister:  

What if (and please consider this carefully) some people do want the same thing you want, however, at the same time, some of them don't want the same thing you want?  

So, if the thing you want requires a hardfork (and naturally it does, because you've gone to great lengths to express how much you despise softforks), that likely results in splitting the network if we don't have a significant proportion of people in agreement.  It's difficult to paint that as a positive outcome.  That wouldn't achieve anything good.  So that's probably a pretty reasonable explanation as to why it's not happening.  Do you see the sense in that?  
  


Again, that's certainly one opinion.  Another would be that people generally want to scale responsibly and aren't in any particular hurry.  Also, hate to break it to you, but you're sharing a network with those people.  You can't exactly make them go away.  They have as much right to exist as you do.  But as much as you might disagree with their views, the fact remains you are all agreeing on the current rules every single time you use Bitcoin, so you continue building a network together.  

The status quo is easy to maintain.  Change is much more difficult.  

If you want to change something, the onus is on you to convince everyone else that it needs to change.  And to date, it's fair to say you haven't really had much of an impact there.  If all the things you've been demanding for the last 5 or more years really were as brilliant as you suggest they are, do you honestly not think that there might be a small but noticeable swell of grass-roots support made up of people who are just as angry and vocal as you are?  Where are they?  Where should I be witnessing the same level of outrage in others that I see in you?  It's just not there.  Let's be real here.  I can't think of anyone on this entire forum who has a more intense disposition about this issue as you.  No one else here is as relentless or persistent.

Then again, I suppose it's fair to argue there would be more vociferous support for on-chain scaling if the BCH fork hadn't happened, but they made their choice.  It's likely most of those people no longer care what we do, because they just went ahead and made the changes they wanted to make.  And that's valid.  They didn't try to force everyone to agree with them, they just did it.  That's probably the most effective way to get stuff done.  But it still remains to be seen that they've made the "best" choice.  It doesn't seem to be working out all that well for them.  The outlook long term doesn't look encouraging.  Perhaps if BCH and the other myriad forks continue to weaken and eventually die off, those users might return to BTC.  Then you might see that swell of support for on-chain scaling.  

Honestly, when enough people want it as badly as you do, greater on-chain scaling will happen.  It will.  But not right now.



I don't see anyone saying LN is the "only" way forward.  Your inference that people are saying that appears to be embellished for dramatic effect.  I think everyone would welcome a little less hyperbole.  Please let's try to keep things in perspective.  Again, further on-chain scaling will almost certainly come at some point, but we're trying some other stuff first which doesn't have as much overhead in terms of cost.  Please try to be patient.

Only because at the moment the mempool is not clogged up, is not proof that a blockchain scales. A blockchain does not scale by definition / design. It's not made to do it and it's perfectly fine. It allows us to run it on a multitude of devices, at affordable prices and with pretty quick setup time (less than a week in most cases) which is essential for decentralization and security of the whole Bitcoin network.

For the record though, I'm not a promoter of big blocks, of faster blocks or of shitcoins as a scaling solution.

I'm instead a promoter of performing real Bitcoin transactions, but keeping the majority of them off-chain, that's a pretty simple and logical concept in my eyes.

You think I'm a propagandist? I'm just giving you obvious facts. Yeah, it's also a fact that Bitcoin is at under 4tx/s at the moment, but how is this proof that the number won't change? And do you want it not to change? Because I do want the number of Bitcoin users to go up; it's in my and their interest. So I try to look into the future optimistically and assume / hope we will soon have the need of 40tx/s, one day 400tx/s and maybe in a very far future 4000tx/s. That's why I'm trying to start building the infrastructure for such a future now, not when it's too late and the 'demand' for more transactions/sec. is way higher than the 'supply' Bitcoin can deliver.

Wait, the second step is wrong. At the moment, I showed you before, you can put a theoretical maximum of 12195 transactions per block, which is 1,756,080 transactions per day. Not sure how 2.4m would be possible. Fact of the matter is, Visa for example, does 100 millions per day in just the U.S. alone. That's 50x, just Visa, just U.S. If you add Mastercard and all the other countries in the world, you'll be at 1000x or more. Since you can't go from a 4MB block to a 4000MB (4GB) block every 10 minutes, you cannot feasibly scale on-chain. Simple as that...

The same disanalogous example... Again... And again... While I've told you it's not the same kind of IOU... Sorry, but I won't repeat it. You want to not understand me.

I've never insulted anybody if they hadn't insulted me first. I challenge you to search my posts. You're the only person who I've really insulted in this forum.

Half truth: You're doing this every time someone corrects you. You don't want to get better, you just want to seem correct.

Please sit down and realize that all of the users in this thread (besides foulmouthed suchmoon) never insult no one. You're the only one who feels insulted for having his sayings corrected.