Bitcoin Scaling Solution Without Lightning Network...

[DooMAD]

5. scaling onchain is not just about raising the blocksize. its about making it more expensive for users who transact more often than those who transact less frequently.
EG imagine a person spend funds to himself every block. and was doing it via 2000 separate transactions a block (spam attack)
he is punishing EVERYONE else. as others that only spends once a month are finding that the fee is higher, even though they have not done nothing wrong.
the blocks are still only collating the same 2000tx average. so from a technical prospective are not causing any more 'processing cost' to mining pool nodes tx's into block collation mechanism. (they still only collate ~2000tx so no cost difference)
so why is the whole network being punished. due to one persons spam.

the person spending every block should pay more for spending funds that have less confirms than others. in short the more confirms your UTXO has the cheaper the transactions get. that way spammers are punished more.
this can go a stage further that the child fee also increases not just on how young the parent is but also the grandparent

in short bring back a fee priority mechanism. but one that concentrates on age of utxo rather than value of utxo(which old one was)

If you just stuck to raising points like this, rather than simply attacking everything that others are trying to build, I wouldn't have to spend so much time arguing with you.  This is one of those rare cases where we actually agree on something.  My only minor critique with this post is that you did a much better job of explaining this concept here:

imagine that we decided its acceptable that people should have a way to get priority if they have a lean tx and signal that they only want to spend funds once a day. where if they want to spend more often costs rise, if they want bloated tx, costs rise.. which then allows those that just pay their rent once a month or buys groceries every couple days to be ok using onchain bitcoin.. and where the costs of trying to spam the network (every block) becomes expensive where by they would be better off using LN. (for things like faucet raiding every 5-10 minutes)

so lets think about a priority fee thats not about rich vs poor but about respend spam and bloat.

lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours.

and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae with was more about the value of the tx


as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain.
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more
if you want to be a spammer spending every block. you pay the price
and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price

I've yet to hear any technical arguments from anyone as to why this isn't a good idea and something we should be seriously looking at.  In fact, I'd even suggest you start a new topic in Development & Technical Discussion just for this point alone.

[1715146692]

1715146692

[1715146692]

1715146692

[1715146692]

1715146692

[franky1]

If you just stuck to raising points like this, rather than simply attacking everything that others are trying to build, I wouldn't have to spend so much time arguing with you.  This is one of those rare cases where we actually agree on something.

i raise many points many times. the thing is, you meander in when the 4 letter word that a center of an apple is called is mentioned. thus you only see that point.

its like if i mentioned "you never see a blue lambo on the road". suddenly you start looking out for it and start only noticing blue lambo's and reacting/get emotional to it everytime you see one. not noticing the lack of observation and lack of emotion of other vehicles

that said the 4 letter word you defend is actually the ones that do type the code and do release the code because all others have been pushed off the network or pushed out the relay layer into the downstream "compatibility" layer of the network topology.

so just running nodes wont change the rules. just mining hashpower wont change the rules. we need actual devs to code rules. which goes against your perception of what devs should be doing. which is what we disagree with.
devs should be listening to the community.

again whats the point of me posting something about a rule change like the second part of your reply. if your side feels that devs should not listen to the community and just do whatever they please.
do you atleast see my point that the network should not have a power house that ignores the community, simply because it doesnt fit "their" roadmap

but seeing as your on their side how about just forwarding the second part of your post to them. you can even say its your idea if it helps. i have thrown many idea's out and let anyone take them and use it as their own idea. like i said a few times im not writing code as a authoritarian demanding people follow me. i never have. i just inform people what could/should be done and hope it wakes people up to see there are other options than just the 4 letter word's roadmap, and that we should not just blindly sheep follow a roadmap as if its the only way

[DooMAD]

we need actual devs to code rules. which goes against your perception of what devs should be doing. which is what we disagree with.
devs should be listening to the community.

again whats the point of me posting something about a rule change like the second part of your reply. if your side feels that devs should not listen to the community and just do whatever they please.
do you atleast see my point that the network should not have a power house that ignores the community, simply because it doesnt fit "their" roadmap

It might be worth considering that if all you ever do is verbally abuse them, they might not be very receptive to what you're saying.  It's not just about having a good idea, it's about how you present it and (particularly in your case) how you conduct yourself while doing so.  

I could have the best idea in the world, but if I spent the entire time slagging off the people who I'm trying to convince to adopt it, it stands to reason that's not going to go the way I'd like it to.

It's overly simplistic to talk about whether developers "should" or "shouldn't" listen to the community.  It's not that black and white.  Each and every single idea has to be treated on a case-by-case basis.  What this is really about is that each developer and dev team is naturally going to produce the code which they believe is most likely to lead to Bitcoin's overall long-term success.  It's not practical for them to implement every random idea people throw out there.  Many of the ideas people suggest (or demand) are not viable.  So they have to be selective and focus on the few decent ideas.  But how can they know your idea is decent if they can't even hear it over all the conspiracy theory babble and outright FUD you constantly spout?  If you want the community to take your idea on board, the onus is on you to present a reasonable argument to support your case and convince them that your idea is actually worth implementing.  Then, with community support, developers are more likely to listen.  If they are then convinced your idea has merit, they are more likely to implement it.  Or, as always, feel free to skip that process and either pay someone to code it, or code it yourself and see how the community reacts then.

But don't just demand shit like an entitled child and then insult the developers when they inevitably ignore you.  When has that attitude ever worked for you in the real world?  That's not how you get what you want.  Try being an adult about this.  Yes, I think you have a good idea, but you really need to work on your people skills.  All you've earned for your efforts so far is negative feedback from a developer.  If you had been more reasonable from the offset, things could have been very different.  Seriously re-think your posting habits and mannerisms in general.  You only have yourself to blame if people aren't taking you seriously.

All that put aside, I will start a topic about fee priority for you if you don't think you can conduct yourself appropriately.  But I think it would be healthy for you to start one, while taking on board what I've said above and really watching your tone.  Maybe even open with an apology for your behaviour to date.  It's not too late to change.

[franky1]

It might be worth considering that if all you ever do is verbally abuse them, they might not be very receptive to what you're saying.  It's not just about having a good idea, it's about how you present it and (particularly in your case) how you conduct yourself while doing so.  

...wall of text of accusations and insults.....

  Maybe even open with an apology for your behaviour to date.  It's not too late to change.

maybe instead of defending them. realise they release code BEFORE community input/conversation.

EG
they had segwit roadmap plan from 2014. before community input
they had code before community got to download.
the comunity had a november 2016-spring 2017 decision and devs lost.
but that was not acceptable to devs. hense the mandatory august 2017.. (no conspiracy. check it all out (i wont use the R word.))

it was not a concept of taking in random community idea's and going with the best one. it was them build thier road map and sway the community to adopt.
you might want to check it all out (i wont use the R word.)

as for me insulting . thats the bear biting the poke. not me poking the bear.
same went for your social drama involvements
if you word count actual insults i give against. say insults you give. you will be surprised by the result

all i said to you before as REPLIES was to re***rch(i know you dont like the word) .. check it out.
you were the one that resorted to flame wars.

anyways. things wont change no matter how much i kiss ass of a dev. the only main issue is that devs should change to be a more OPEN community. and not REKT things that are not their plan..

sorry but letting them lead and control, and require kissing the royal ring is not what decentralisation is about

[aliashraf]

5. scaling onchain is not just about raising the blocksize. its about making it more expensive for users who transact more often than those who transact less frequently.
EG imagine a person spend funds to himself every block. and was doing it via 2000 separate transactions a block (spam attack)
he is punishing EVERYONE else. as others that only spends once a month are finding that the fee is higher, even though they have not done nothing wrong.
the blocks are still only collating the same 2000tx average. so from a technical prospective are not causing any more 'processing cost' to mining pool nodes tx's into block collation mechanism. (they still only collate ~2000tx so no cost difference)
so why is the whole network being punished. due to one persons spam.

the person spending every block should pay more for spending funds that have less confirms than others. in short the more confirms your UTXO has the cheaper the transactions get. that way spammers are punished more.
this can go a stage further that the child fee also increases not just on how young the parent is but also the grandparent

in short bring back a fee priority mechanism. but one that concentrates on age of utxo rather than value of utxo(which old one was)

Multiple layer of confusions over there:

1- Spamming is bad for bitcoin but not a serious threat right now, besides transaction malleability which is was a flaw and essentially have  improved after SW, other spamming practices come with a cost. Making bitcoin more resistant to spam is good but not an urgent agenda neither a relevant issue to on-chain scaling.

2- It isn't reasonable to consider it kinda "punishing others" when you make frequent txs. You pay fees, you utilize the service, that simple.

3- And it would be insane to encourage people to keep UTXO more occupied! Actually I'm working on a totally opposite direction. By any measure we need to keep UTXO as light as possible, UTXO is the problem and not the chain, chain always could be pruned, UTXO couldn't. I think people should pay even more when their balance is kept for a longer time than others. It occupies space!

Let's discuss an alternative approach:

Suppose as a decentralization measure we incentivize wallets to run a full node and participate actively in consensus by a replace-fee-by-work schema. In this schema wallets are free to do some work (solving an ASIC resistant hash function) and include a nonce plus the hash of the most recent block they are ready to commit to. By confirming such transactions, miners could enjoy a tiny discount for the difficulty they need to approve their block and ready to be more generous with the fee they expect. Let's call it Direct Commitment By Transactions.

For such a schema to work we need to give more weight to commitments to newer blocks and stop giving such a credit to transactions when they are committing to blocks older than 100 or so. More interestingly we could discourage hoarding and occupying the UTXO too long,  by means of another complementary technique which is even more disruptive and deserves to be called Indirect Commitment By Transactions.

Traditionally, in bitcoin and its clones, ordinary transactions use a txid:[#ouput] format as their inputs. Although this approach has some benefits and provides a level of convenience  for users it has drawbacks too. For instance, reply attack in forks wouldn't be possible if wallets was committing to the branch they are making the transaction for.
In Direct method above we have established such a possibility, now suppose we go even further and let transactions to refer to outputs by their relative position in the blockchain and give another bonus (difficulty discount) to miners for including transactions that spend younger outputs from the correct chain as by this reference they are indirectly committing to the right chain, helping security.

[LeGaulois]

@franky1
This is what we call being proactive and anticipation. The example you give about the SegWit roadmap from 2014 is one example. Are we forced to use SegWit? As DoomAD says, they cannot integrate everyone's wishes, but they anticipate to make Bitcoin usable with various convenients solutions. It's like complaining because someone is working to improve Bitcoin and talk about consensus. A consensus from the mass could turn in a 10 years old kid decision.

[bones261]

@franky1
This is what we call being proactive and anticipation. The example you give about the SegWit roadmap from 2014 is one example. Are we forced to use SegWit? As DoomAD says, they cannot integrate everyone's wishes, but they anticipate to make Bitcoin usable with various convenients solutions. It's like complaining because someone is working to improve Bitcoin and talk about consensus. A consensus from the mass could turn in a 10 years old kid decision.

  No, we are not forced to use Segwit. However, if someone chooses not to use Segwit, you are penalized by paying higher fees. This may only amount to pennies at the moment, but it can add up. If BTC starts to get used even more, many casual users will then be compelled to use LN, to avoid prohibitive fees.

[LeGaulois]

@bones26
Perhaps, but since @franky1 regularly tell us how Bitcoin is dying since there are "fewer transactions". The case you mention is not supposed to happen so, or just randomly (during the Christmas month with all people buying the gifts lol). There is no problem anymore with the fees or congestion by following him

[bones261]

Perhaps, but since @franky1 regularly tell us how Bitcoin is dying since there are "fewer transactions". The case you mention is not supposed to happen so, or just randomly (during the Christmas month with all people buying the gifts lol). There is no problem anymore with the fees or congestion by following him

   We just want to give people a better alternative to using the banking system. If we are just going to try and herd people into using lightning network, is that system really any better? If BTC ever gets wide adoption, it won't even be affordable for many to open a LN channel for themselves. They will just have to rely on some gateway service to open channels, and your "share" of the channel will just be kept track of by the gateway service. The casual user will just need to rely on some third party, and hope that they are not "hacked."
    To get back somewhat on topic a little. I think if BTC can implement some kind of system where a node can validate each and every transaction without having to initially devote enough hard disk space, that would be great. My understanding of pruning is that you initially have to devote the required hard disk space before you can prune. I'm not certain the OPs proposal is the best way to go about this with the sharding.

[aliashraf]

Perhaps, but since @franky1 regularly tell us how Bitcoin is dying since there are "fewer transactions". The case you mention is not supposed to happen so, or just randomly (during the Christmas month with all people buying the gifts lol). There is no problem anymore with the fees or congestion by following him

 ... I think if BTC can implement some kind of system where a node can validate each and every transaction without having to initially devote enough hard disk space, that would be great. My understanding of pruning is that you initially have to devote the required hard disk space before you can prune. I'm not certain the OPs proposal is the best way to go about this with the sharding.

I have discussed it a couple of times before and you are welcome to check this post for instance. AFAICT what you are asking for is totally possible and it leads to a new generation of full nodes which are light enough to retire current spv nodes.

By the way, hierarchical or not, sharding as an on-chain scaling solution is not something we could ever ignore.

[franky1]

anyway, back on topic.

the scaling onchain
reduce how much sig-op control one person can have is a big deal.
i would say the sigops limits alone can be abused more so than the fee war to victimise other users. and needs addressing

as for transactions per block. like i said (only reminding to get back ontopic) removing the witness scale factor and the wishy washy code to realign the block structure into a single block that doesnt need stripping is easy. as the legacy nodes are not full nodes anyway

but this can only be done by devs actually writing code. other teams have tried but found themselves relegated downstream as "compatible" or rejected off the network. so the centralisation of devs needs to change
(distributed nodes does not mean decentralised rule control.. we need decentralised not distributed)

as for other suggestions of scaling.
others have said sidechains. the main issue is the on-off ramp between the two

a alternative concept could be whereby a new transaction format. (imagine bc1q.. but instead SC1) which has no lock
bitcoin network sees a
bc1q->SC1 as a go to side chain tx (mined by both chains)
and
SC1->bc1q as a return to main net(mined by both chains)

mainnet will not relay or collate(mine to blocks) any sc1 -> sc1 transactions. (hense no need to lock)
sidechain will not relay or collate(mine to block) any bc1q -> bc1q transactions. (hense no need to lock)

this way it avoids a situation of "pegging" such as
bc1q->bc1q(lock)                                sc1(create)->sc1

having bc1q->sc1 is not about pegging a new token into creation.
its about taking the transaction of mainchain. mining it also into a sidechain. and then only able to move sc1 addresss->sc1 the sidechain until its put back into a bc1q address which are then only able to move on mainnet

i say this because having a
bc1q ->bc1q that has a lock. can have openings for abuse based on timing and also loss of key for the bc1q address.
where as moving funds to a sc1 address is obsolving loss/risk from the mainnet as value is not in a bc1q address no more(as its spent). and moving the value with the transaction to the sidechain.
(thus solves the UTXO issue on mainnet of not having to hold 'locked' value)

allowing value to flow without time lock allows the auditing of funds to show its still one value moving. instead a locked value in main chain and new value in sidechain

i do have issues and reservations about sidechains too but the original "pegging" concept of sidechains really was bad and open to abuse. (not having the BTC side seen as "spent" while spending was actually happening)

[DooMAD]

they had segwit roadmap plan from 2014. before community input
they had code before community got to download.

Which means someone made a compelling argument about the idea and most of the developers in that team agreed with it.  Ideas can come from anywhere, including from developers themselves.  Saying that developers shouldn't work on an idea just because a developer proposed it isn't a mature or realistic stance.

I don't know where you get this perverse notion that developers need permission from the community before they are allowed to code something.  And crucially, if you start making the argument that it should work that way, then you will totally destroy any opportunity for alternative clients to exist.  Would the community have given the green light to the developers of that client you're running right now?  I find that pretty doubtful.  You think "REKT" is bad?  See how much you complain if no one was even allowed to code anything unless the community gave their blessing first.  That's how you ruin decentralisation.

Be careful what you wish for.  You really aren't thinking this through to conclusion.

[franky1]

here we go again  you poke, i bite.
shame you are missing the point of decentralisation

they had segwit roadmap plan from 2014. before community input
they had code before community got to download.

Which means someone made a compelling argument about the idea and most of the developers in that team agreed with it.  Ideas can come from anywhere, including from developers themselves.  Saying that developers shouldn't work on an idea just because a developer proposed it isn't a mature or realistic stance.

^ their internal circle agreed. before letting the community have a say
i guess you missed the 2014-5 drama.

v not letting the community be involved is prime example of centralisation
 

I don't know where you get this perverse notion that developers need permission from the community before they are allowed to code something.

do you ever wonder why i just publicly give out idea's and let people decide yay or nah. rather than keep idea's in secret and make code and then demand adoption. again before trying to say im demanding anything. show me a line of code i made that had a mandatory deadline that would take people off the network if not adopted.
.. you wont. there is no need for your finger pointing that im an authoritarian demanding rule changes. because there is no demanding rule changes made by me

i find it funny that you flip flop about community involvement.
my issue is that they plan a roadmap. code a roadmap. release it and even if rejected, they mandate it into force anyway

emphasis.. MANDATE without community ability to veto

again the point your missing
having code that allows community vote/veto (2016, good)
having code that mandates activation without vote/veto (2017, bad)

you do realise that core could have had segwit activate by christmas 2016 if they just actually went with the 2015 consensus(early variant of segwit2x). which was a consensus compromise of the wider community finding agreement
which gave legacy benefits too.
but by avoiding it. and causing drama all the way through 2016 of how they want it only thier way(segwitx1).. pretending they couldnt code it any other way
they still didnt get a fair true consensus vote in their favour in spring 2017. so had to resort to the madatory activation and swayed the community is (fake) option of segwit2x(nya) just to then backtrack to segwit1x once they got the segwit part activated

[DooMAD]

here we go again  you poke, i bite.
shame you are missing the point of decentralisation

Shame you are missing the point of permissionless.

And again, you would only make Bitcoin more centralised if the community had to approve code before anyone could write it.  Don't dodge the argument by telling me I'm missing the point when you're deliberately evading the point.  You can't insist on a handicap for one dev team and then claim you want a level playing field.  It's already level, because anyone can code what they want.  Clearly what you want is an un-level playing field where the dev team you don't like have restrictions on what they can do, but everyone else is free to do whatever.  In the past, others have demanded the same un-level playing field, except stacked against alternative clients.  They argued (wrongly) that the developers of alternative clients needed permission from the community to publish the code they did.  I defended the alternative clients. 

How can I be the one missing the point of decentralisation when my argument defends the right of everyone to code what they want?  That means we get multiple clients.  You're the one arguing that developers need to have permission from the community to code stuff and alternative clients would simply not get that permission.  That means we would only get ONE client (and it wouldn't be the one you want).  You should be agreeing with me on this, not fighting me. 

do you ever wonder why i just publicly give out idea's and let people decide yay or nah. rather than keep idea's in secret and make code and then demand adoption. again before trying to say im demanding anything. show me a line of code i made that had a mandatory deadline that would take people off the network if not adopted.
.. you wont. there is no need for your finger pointing that im an authoritarian demanding rule changes. because there is no demanding rule changes made by me

You're demanding a change in the way developers act.  You don't have any code to show because it isn't possible for code to achieve what you're demanding. 

emphasis.. MANDATE without community ability to veto

You're using your veto right now by running a non-Core client.  If enough people did that, consensus would change.  The problem you appear to be having is that most people on the network have no desire to use their veto.  They don't want consensus to change. 

Cue Franky1 deflecting from all of these points instead of countering them in 3... 2...

[aliashraf]

@franky1, @doomad

Let it go guys. You are arguing too much about devs. Who cares about devs? Devs come and go, bitcoin stays and right now it needs your productive technical contribution.

Once there is a brilliant idea it will find its way to history. I don't care about politics involved, in a worst case scenario, if a group of devs could be proved to resist the truth too much, I'll personally help abandoning them.

[franky1]

again another offtopic poke from that certain person.. one last bite

i make a point. and then you say i am missing and deflecting my point

thats like me speaking english. you speak german. i say a point about english and you get upset and then waffle on that my point is about german and how im missing a german point.

ill make it real clear for you. although there are dozens of topics that repeat the word enough

mandatory mandatory mandatory

you cannot rebut the mandatory. so you are deflecting it.

they had segwit planned back in 2014 and had to get it activated ($100m was at stake)
no matter what the community done/said/want/didnt want. they needed it activated THEIR WAY
they didnt get their way 2016-spring 2017
so they resorted to mandatory activation

my point is about mandatory.
i should know my point. because im the one making it.

point is: mandatory

if you want to argue against my point then you need to address the point im making.

again
for the dozenth topic you have meandered off topic with your pokes. my point has been about the MANDATORY

if you cannot talk about the mandatory not being decentralised.. then atleast hit the ignore button.

as for the whole no community permission.. re-read your own post i gave you merit on. and see your flip flop

as for your deflection of the writing code. its not that they just write code they want. its that they avoid community code/involvement. as it doesnt fit their internal circles PLAN they had as far back as 2014..

yea anyone can write code.. but making it mandatory.. no. as thats anti concensus

also i said if they actually listened to the community and went with the late 2015 consensus agreement of a early varient of segwit2x they would have got segwit activated sooner. and the community would have had legacy benefits too.

but again they mandated only their pre existing plan which is what caused such delays /drama and still causing drama today as we are still discussing scaling even now 3 years later.

[franky1]

hurray. back on topic.. hopefully we can stay on topic.

franky1 & DooMAD, both of you starting going off-topic again

bc1q ->bc1q that has a lock. can have openings for abuse based on timing and also loss of key for the bc1q address.
where as moving funds to a sc1 address is obsolving loss/risk from the mainnet as value is not in a bc1q address no more(as its spent). and moving the value with the transaction to the sidechain.
(thus solves the UTXO issue on mainnet of not having to hold 'locked' value)

This is interesting idea and oddly it has similarity with proposal Superspace: Scaling Bitcoin Beyond SegWit on part moving between main-chain and side-chain.
But thinking about UI/UX, introducing another address format is confusing for most user. Even 1..,3... and bc1... are plenty confusing.

its not that difficult. its like if you never intend to use a side chain. you wont have to worry. because you wont get funds from a SC1 address. and never need to send to a sc1 address

as for the UI. well again a UI can be designed to have an option eg

File   Options
          display segwit features
          display sidechain features

if you dont want it. you dont select it / dont realise it exists as the UI wont display features.
again you wont get funds from a SC1 or send to an SC1 unless you want it. so easy for average joe


but yea it will help the UTXO set stay down
unlike some sidechain concepts and definitely unlike LN (as locks means keeping the funds as UTXO for a locked time(facepalm)

.. anyway.. superspace project... (hmm seems they missed a few things and got a few details misrepresented) but anyway

the specific No_op code used to make segwit backward compatible cant be used again.
this is why

imagine a transaction in bytes, where a certain byte was a option list($)
***********$*******************
in legacy nodes
if $is: (list in laymans eli-5 so dont knitpick)
     0= ignore anything after (treat as empty, meaning no recipient meaning anyone can spend)(no_op)
     1= do A
     2=do B

in segwit nodes the 0 option was changed to become do segwit checks
they also added a few other opcodes too. as a sublist
so now with segwit being the active fullnodes. there is no 0='ignore anything after' at that particular $ byte
as its now
EG
***********$%******************
if $is: (list in laymans eli-5 so dont knitpick)
     0= do segwit if %is: (list in laymans eli-5 so dont knitpick)
                            0= ignore anything after (meaning anyone can spend)(no_op)
                            1= ignore anything after (meaning anyone can spend)(no_op)
                            ....
                            11= do A
                            12=do B
     1= do A
     2=do B
theres actually more No_ops now for segwit(%)

so if someone was to want to do what segwit did. they would first need to find a new no_op thats not been used.
and then they would need to ensure pools didnt treat it as a no_op at activation. (yep not really as soft as made out)
which would be another 2016-2017 drama event.

what the link does not explain is that the summer 2017 was actually a hard fork as nodes that would reject segwit needed to be thrown off the network. and pools needed to treat the no_op as not a 'anyonecanspend'

which means another hard fork would be needed. (hopefully not mandated this time)

[Wind_FURY]

@franky1
This is what we call being proactive and anticipation. The example you give about the SegWit roadmap from 2014 is one example. Are we forced to use SegWit? As DoomAD says, they cannot integrate everyone's wishes, but they anticipate to make Bitcoin usable with various convenients solutions. It's like complaining because someone is working to improve Bitcoin and talk about consensus. A consensus from the mass could turn in a 10 years old kid decision.

  No, we are not forced to use Segwit. However, if someone chooses not to use Segwit, you are penalized by paying higher fees. This may only amount to pennies at the moment, but it can add up. If BTC starts to get used even more, many casual users will then be compelled to use LN, to avoid prohibitive fees.

Or be forced to use Bitcoin Cash. I believe that was their idea of why they split from Bitcoin, right? But apparently, not that many people in the community believed that bigger blocks for scalability were a good trade-off on decentralization.

The social consensus remains "Bitcoin is Bitcoin Core".

[bones261]

@franky1
This is what we call being proactive and anticipation. The example you give about the SegWit roadmap from 2014 is one example. Are we forced to use SegWit? As DoomAD says, they cannot integrate everyone's wishes, but they anticipate to make Bitcoin usable with various convenients solutions. It's like complaining because someone is working to improve Bitcoin and talk about consensus. A consensus from the mass could turn in a 10 years old kid decision.

  No, we are not forced to use Segwit. However, if someone chooses not to use Segwit, you are penalized by paying higher fees. This may only amount to pennies at the moment, but it can add up. If BTC starts to get used even more, many casual users will then be compelled to use LN, to avoid prohibitive fees.

Or be forced to use Bitcoin Cash. I believe that was their idea of why they split from Bitcoin, right? But apparently, not that many people in the community believed that bigger blocks for scalability were a good trade-off on decentralization.

The social consensus remains "Bitcoin is Bitcoin Core".

Why should anyone be forced to settle for something which is less secure?  So far LN is still in alpha testing stage. Risk of loosing funds is too high ATM. Maybe when they improve their network, I'll want to use it. BCH has always had less hash rate and is therefore less secure. I think people should be able to utilize the most secure network out there in an affordable manner and not be forced to settle for some less secure stuff. Even if lightning network gets its act together, a second layer solution will be second best when it comes to security. So I guess the BTC blockchain will only be secure vip2vip cash. The riffraff can settle for less secure crap.  

[hulla]

The OP was right about increasing of bitcoin blocksize to also be one of the solution to bitcoin scaling because big block size promote more nodes but we also have to put into consideration the side effect of the block increasing which I presume could lead to  the 51% attacks and if Lightning does not which I believe it will another solution will arouse.