Bitcoin Forum

So as we all know the Lightning Network is supposed to be the big bad thing that solves Bitcoin scaling.

Is it just me or does it seem that Lightning Network is only one piece of what Bitcoin needs to scale?

Here's my thinking:
Lightning Network you have to open and close payment channels on the blockchain. Your funds are stuck in the payment channel until you close it. So if you are a company using the Lightning Network to get paid you are gonna probably have a bunch of different payment channels open and occasionally close them in order to actually get your money. And as a company selling things you're not going to be sending that money back out through the payment channel, so there is no reason to just keep the payment channel open to make payments, you're just gonna close them to get the money every once in a while. Let's say the company closes a payment channel on average once a month, though likely i think it'd be a shorter period than that.

For consumers, you're gonna open a payment channel with some funds, now occasionally you might get more money from people sending you money like how people use venmo. But generally if you're using LN to buy things your funds are gonna run out even if your friends occasionally send you money venmo-style, so you need to close the payment channel in order to make a new one with new funds. Lets say the typical person funds there payment channel for a month, so you can pay your monthly costs and then you make a new one.


Now for the math:

So if we assume for simplicity sake every payment channel closes after a month, this means a new corresponding payment channel must be opened as well, so two onchain transactions per month to open and close a channel. Lets just lump companies and people into one group called users, and so give each user two onchain LN transactions per month. With segwit fully adopted lets say Bitcoin can handle 6 transactions per second on average. 6 txs x 60 sec x 60 min x 24 hrs x 30 days = ~15.5 million LN payment channel opening and closings per month. Now lets divide that by two since each user has two channels open/close operations each month and we get about 7.75 million users.

Less than 8 million users can use LN! Don't we want Bitcoin to scale to a global level in which it can at the very least handle hundreds of millions of users, if not billions. And with the current Bitcoin network we're limited to less than 8 million with LN. That is a very significant problem to consider. And of course I haven't even mentioned actual onchain transactions, which will compete with LN channel openings/closings for space on the blockchain. And since in december 2017 during that mania phase the BTC fees went over $50 because the blockchain was so clogged we can certainly assume that onchain txs in the next couple years (not even counting LN) will far outstrip the blocksize even with segwit fully adopted. This means that the blocks will likely be full with high fees even without LN channels being added to the blockchain. So the actual number of LN users that are likely is far far lower than 8 million.

Doesn't this show pretty obviously that Bitcoin needs larger blocks or else even the LN is gonna be pretty useless when it costs either a lot of money or a decent amount of money and a several day wait just to open or close a payment channel? Especially when you consider most use cases for the LN simply aren't current Bitcoin use cases. LN is more economical for small purchases. But Bitcoin usage for small purchases right now is probably near zero. So LN doesn't lessen demand for onchain txs, it just opens up new use cases for bitcoin, which means it does open up new use cases for allowing Bitcoin to be a payment network, but it doesn't really do anything to solve the current scaling problem. Onchain txs will continue to grow and LN doesn't do anything about that. And segwit only doubles the throughput. Bitcoin needs many times more onchain scaling that what segwit provides to make onchain txs and LN usable as usage grows.

Thoughts about this?

I have two main thoughts about this:

1. Blocksize can't be realistically increased to hundreds of megabytes (or even tens of megabytes) that it would take to make Bitcoin scalable to global mass market participation. It would make the network run horribly and make it highly centralized which would lead to the failure of the coin. However Bitcoin does need some sort of manageable blocksize increase to say 4mb or 8mb just to handle the demand in the next couple of years. But this is a temporary solution.

2. Side chains - is this the only real solution? I don't know much about side chains, how it would work exactly or their technical feasability. But if you have some network of child sidechains that handle a set of txs and everyonce in a while square back up with the main bitcoin blockchain that would seem to solve the problem. I imagine each tx from a sidechain would be very large since it moved a bunch of money around. So let's just say the bitcoin blockchain can on average handle one sidechain tx (the sum of all sidechain txs) each second and sidechains square up with bitcoin once each block (once ~10 min). Sidechains you have much quicker blocks so their txs get confirmed much faster, though i guess a tx would still need the main blockchain confirmations to be truly confirmed. Anyways, at a rate of one sidechain squaring up with bitcoin per second you can have about 600 sidechains. If each sidechain can handle the throughput of the original bitcoin blockchain (1mb every 10 minutes) then it would allows bitcoin to scaled by hundred of times its current ability. This is global scaling ability. The exact numbers are just guesses of course, maybe one sidechain squaring up with bitcoin would actually take up more than one second worth of txs on the main blockchain. But this seems theoretically the only doable way to truly scale bitcoin.

Yes, Bitcoin will need more changes in order to have more transaction capacity. No one is claiming that the Lightning Network is the end all be all of scaling solutions nor is any claiming that we won't need to do anything else. Those who are don't understand how Bitcoin or the Lightning Network work. It would be naive to think that the Lightning Network would magically solve all of our problems.

Not necessarily. If you are a merchant, then you probably have a lot of channels open. So this means that you can act as part of a route for someone else's payment. People can route payments through you and when you need to pay for something, you can route payments through one of your customers.

Not necessarily. You can make a single on chain transaction to someone who offers a rebalancing service. So you would pay some amount in an on chain transaction and then the service would send money through the Lightning Network to you so that your payment channel shifts money back to your end of the channel so you can continue to spend it. This would be cheaper than closing and opening the channel as there would only be one transaction fee to pay instead of two.


Yes. People who directly work with the technology know this and are constantly thinking of ways to increase transaction capacity. Increasing the block weight limit is not the end all be all solution either. Many other things can be done to increase transaction capacity as well. It is a known issue and is even directly addressed in the Lightning Network paper.

Sidechains are one of the known methods to increase transaction capacity. However there are still methods that have not yet been discovered, and still methods that we know about that have not been implemented yet. Things such as Key and Signature aggregation will increase transaction capacity by decreasing the size of transactions. It's not just about making blocks bigger or faster or having more blocks; we can also do things to make transactions smaller or transactions to occur less frequently which will help Bitcoin have a higher transaction capacity.

The problem is calculating actual Bitcoin usage... as we saw in past occasions, the mempool was full, and everytime the mempool is full, the conspiracy theories begin: How do we know if it's just Roger+Jihad using periods of actual organic growth (say a mainstream FOMO moment) making it x1000 times worse with transaction spam, then claiming it wasn't them, just all organic growth from people seeing Bitcoin going to the moon on national television?

I just don't see a way to properly estimate what Bitcoin usage is and therefore if it's worth scaling it to said usage. For a person like me which barely transacts, I couldn't care less, but for others it's an issue... and again we can't know how legit these peaks of full mempool are.

What I do know is, blocksize increases are out of the question... it will NEVER happen. A blocksize increase will always result in 2 Bitcoins basically... the original one, and the new one which claims to be Bitcoin. There will never be consensus about it.

For the first part:
hmm that is a pretty good solution. Do you know if there are actual plans by any company to make this service. Though this would only cut the txs down by half, instead of opening and closing a payment channel yourself you'd just send one transaction to a service that funds your LN as you say. But yeah sounds like a good solution to help things a bit.


The second part:
Agreed there can also be things which reduce transaction size further. I'm not sure what things you're talking about for making transactions occur less frequently, unless you just mean batching by online services like online wallets and exchanges and whatnot, which will definitely help there be less transactions onchain, but that doesn't do anything for when people are using their own wallets.
Also reducing transaction size or even batching can only help so much. Bitcoin needs to be able to handle all onchain transactions plus all LN channel openings and closings without being clogged so that onchain txs (including LN channel open/close) get confirmed in an hour and maybe the fee is a dollar or two, to do this on a global scale would will probably take Bitcoin handling a few hundred times what it does now, and then LN will handle the rest up to however many thousands of txs per second. That WILL require either a huge increase in blocksize, which isn't feasible, or some other solution like sidechains.


It's good to know the LN white paper mentions that bitcoin needs onchain scaling. I didn't know that. But bitcoin core seems ideologically against this, when is is so obvious that it is needed. Due to the limits of onchain scaling it too is only a limited solution, but it is technically by far the easiest solution to say all at once boost transaction capacity by say 4 or 8 times with a very simple change. And every scaling solution builds on every other so everything needs to be put on the table. Likely it will be the combination of several solutions that will truly scale bitcoin. But onchain HAS to be one. The blocksize is the bottleneck, working around the bottleneck to increase the number of txs you can put into it with segwit and LN and other things is great, thats optimizing the space you have. But then at some point you have to increase the size of the bottleneck, and when you increase the size it multiplies by the factor of all those optimizations. So an optimized 1mb being increased to 8mb block is a much bigger deal than a non-optimized (the original blockchain) 1mb to 8mb increase.
Right now seems like the perfect time to hardfork bitcoin for a blocksize increase because we are in a lull of interest right now. Hard forking during a bull run when there is so much attention on bitcoin is much more dangerous. How nice would it be if by the time the world starts going crazy for bitcoin again they find out that oh not only did segwit get adopted for 2x scaling, and LN get set up to open up the common everyday and instant transactions use-case, but bitcoin also scaled another say 8x so that it plus segwit created a 16x scaling plus LN. At that point we're talking about actual decent scaling. Segwit, blocksize increase, LN, Schnorr, MAST, sidechains, batching from online services, it all needs to be on the table and taken seriously or else bitcoin WILL NOT scale. Right now I don't feel that the quickest and easiest of those solutions - blocksize increase - is even considered, even though this would be the perfect time during this lull in interest and media attention to implement it.

And this is what I'm pointing out. With this attitude, the thing that will NEVER happen is bitcoin being able to scale to a global demand. NEVER. There is only so much you can stuff through a 1mb bottleneck every 10 minutes. If you take increasing that entirely off the table, anything else you do are just half-measures that won't ever solve the problem. Even if with a bunch of scaling solutions they could somehow get onchain txs up to say 100/sec, that probably isn't nearly enough considered people will still do plenty of onchain txs plus opening/closing LN channels. But if you then add an increase to 8x increase to the blocksize, which is probably doable without risking decentralization and whatnot, that 100 txs/sec turns into 800 txs/sec!! Whatever non-blocksize increase solutions are implemented, adding to the blocksize multiplies them all! If you discount that you very likely discount the future success of bitcoin.

Why would you take a serious scaling solution off the table?? Scaling is the biggest problem and bitcoin will fail or succeed based on it. To say the most obvious part of the solution is off the table forever is saying you don't want bitcoin to succeed. It's the most dangerous to the market sure, but that's why you build a consensus for it before you do it. The segwit2x didn't have a consensus so it was very dangerous, but probably the only reason it didn't have a consensus is that bitcoin core was against it and therefore some other team had to say they were gonna do it. The bitcoin team should be building a consensus right now because a lull in the market is the perfect time to make a hard fork with less danger while most of the world is not paying attention.

The Lightning Network is an example of this. It makes onchain transactions occur less frequently because transactions are moved elsewhere but still use Bitcoin.

This is categorically false. Segwit is an onchain block size limit (redefined to block weight) increase that allows for more transactions.

What Bitcoin Core is ideologically against are changes (especially hard forks) that are controversial and whose effects are unknown. There's more to a block size limit increase than just the number of transactions that can fit in a block. There are considerations such as the computational power required to validate a worse case scenario block, the amount of network bandwidth it takes to transmit a block, the effect that having large blocks will have on the UTXO set, etc.

Bitcoin Core is opposed to changes that reduce the decentralization aspect of Bitcoin. And a hard fork changing the block size limit is one of those things.

This is also untrue. Increasing the block size limit is actually very difficult. First of all, the change is not just a one line change or very simple. It requires deployment code which can be very complex and has to handle various edge cases. It involves testing code to make sure that software don't break. It requires convincing everyone to agree that the change is necessary and good (which can be difficult) and convincing everyone to upgrade to the latest software (because actually increasing the limit requires a hard fork so everyone must upgrade).

First of all, the block size limit is not 1 MB, it is 4 MB. This is due to segwit.

Secondly, increasing the block size by 8 times will likely have a worse effect than you can imagine because you are not considering edge cases, worst case scenarios, and all of the nuance involved in block validation and propagation. And of course, increasing the block size limit inherently increases the centralization of Bitcoin because it increases the cost required to operate a full node.

First bolded part:
okay you're just playing dumb to try to argue with me here. I was obviously talking about blocksize increase. As I mentioned optimizing what can be fit into current blocks plenty of times. Bitcoin core IS against onchain scaling by increasing the blocksize. Segwit is not an example of that, it just optimizes what can be fit into that 1mb block.

Second bolded part:
The block size is not 4mb, it is 1mb. It would take a hard fork to increase this. Segwit did not increase the block size one bit (or byte  :P), it is still 1mb. Segwit moved stuff around so more txs can be put into that 1mb. It's block weight is 4mb I believe, but block size is still 1mb just as its always been.

Third bolded part:
This whole idea that increasing the size a bit would lead to unimaginable problems takes the assumption that Satoshi had some divine knowledge that 1MB was the perfect blocksize and anything larger would lead to the network unraveling. It's just a freakin number for crying out loud! Yes at some point the negatives of an increasing blocksize outweigh the positives. But its not like Satoshi figured out 1MB is some magically perfect number and the blockchain won't work if its a different number. If Satoshi had chosen 500KB instead of 1MB you'd be arguing how an increase to 1MB would be disastrous since 1MB means more centralization than 500KB. We need to get way from this religious view of anything Satoshi did is perfect and can't be changed, especially since its not even true, bitcoin code is changing with every new update. It's just as dumb as the BCH people who say Bitcoin is no longer Bitcoin because Segwit is a change from Satoshi's code. This bizarre religious obsession that Satoshi's ideas (or even just people's own takeaways from Satoshi's ideas) can never be broken is what is truly broken in the bitcoin community.
Obviously at some point increasing blocksize would become more negative than positive, so Bitcoin core should be working hard on that (along with the other upgrades) to come to a conclusion as to what is the largest blocksize that is still manageable for the network. Since 1MB has been working fine for 9 years I can guarantee you it is not the limit for blocksizes. Very likely 2MB would be fine, likely 4MB would be fine, maybe even 8MB would be okay, and maybe even a little bit higher than that. But SOME increase in blocksize is absolutely needed. Without it you're just bottlenecking bitcoin for no reason, the only outcome of bottlenecking bitcoin is that it makes it less usable, and therefore less used!


Anyway, I wasn't trying to just talk about blocksize, though that seems to be the solution that some people for whatever strange reason get so upset about when what is needed is a clear plain discussion about building a consensus on increasing the size and what is the largest size possible that won't have serious negative affects.

I'm more interesting in what solutions outside of LN have been proposed or do people think are possible to make bitcoin scale, because segwit and LN alone don't even come close. Blocksize increase is absolutely necessary but it too is only one solution that alone doesn't come close to solving things. I've heard of MAST and Schnorr but I don't really know what they do. I've heard of side chains which seems like a great solution but I don't know how practical or feasible they are. Anyone have details or opinions about these things or know of other solutions? The bottom line is we need as many solutions as possible implemented (absolutely including blocksize increase) if bitcoin has any chance of scaling to keep up with the growing demand in the long term.

Segwit doesn't optimize anything. If anything, it actually makes transactions physically larger if you use P2SH-P2WPKH. Segwit redefined what block size meant by removing it entirely. The actual size of a block message that is received over the wire can be up to 4 MB. Of course you can (and yo are) argue that the block size hasn't changed because the MAX_BLOCK_SIZE variable did not change, but at the same time, that variable also no longer exists in the code.

No one ever claimed that.

We would be, because 1 MB means more centralization than 500 KB. In fact, some people (luke-jr) argue that we should decrease the size of blocks because that will lead to greater decentralization and that the status quo is too centralized. But the number itself doesn't matter. What matters is the current status quo and how that would be changed. If Satoshi had chosen 2 MB and people were trying to increase that, then the same argument would be happening whenever that limit was hit.

The developers of Bitcoin Core are not arguing for a specific magic block size. What we are arguing for is a block size that is no worse than the status quo. The baseline is what we currently have. Whatever we do in the future cannot be any worse than what we have. If the cost to increase the block to some size were negligible, then we would be for it. However the cost to increase the block size limit to some size greater than what it is now is considered to be non-negligible and thus we are not for increasing the block size yet. Once computing power, network bandwidth, etc. have increased to the point that an increase has negligible cost, then it will probably happen. The current size of blocks are already what is believed to be the most that the network can currently handle if all blocks were absolutely full. While we wait for that day, we will continue to think of other solutions that allow more transactions to be shoved into the same amount of space.

There are currently known transaction capacitiy increases that are being worked on. The three most active ones are Key and Signature aggregation (previously known as Schnorr signatures), MAST, and Sidechains. Key and Signature aggregation and MAST both make the size of transactions smaller while retaining Bitcoin's security and with the added benefit of additional privacy. Sidechains are more similar to the Lightning Network (but sidechains are not the Lightning Network nor is the Lightning Network a sidechain) in that it moves transactions off of the main blockcahin.

Key and Signature Aggregation allows for one signature to be the combined signature for several different public keys and messages. This means that a transaction with many inputs only needs to provide one signature that covers all inputs instead of a signature for each input. Furthermore, multisig transactions can then have one signature and possibly even just one public key while still allowing for a threshold of signatures (combined into the one signature) be required. In the case of multisig, key aggregation hides how many participants were in the multisig and how many were required to sign the transaction. With only one signature, transactions with many inputs will be smaller.

MAST allows for large scripts to be compressed. The branches of a contract that are not relevant are compressed down into a hash when such a script is spent from. The ideas of Graftroot and Taproot expand this further. All of these also provide additional privacy by hiding information (in the form of a hash) that is otherwise unnecessary for validating a transaction. While MAST, Graftroot, and Taproot can make transactions smaller, they are only really effective with large complex scripts which are not all that frequent. Their primary purpose is privacy. However they are also useful in the Lightning Network because the Lightning Network uses large complex scripts in commitment transactions so these three can be used to shrink those scripts.

Sidechains move transactions off of the main blockchain into individual blockchains that are connected to the Bitcoin blockchain but not everyone needs to know about them. They are similar to the Lightning Network in that transactions occur off of the main blockchain and thus free up space on the main blockchain for other transactions.

And of course there will be solutions that have yet to be discovered. Like the Lightning Network, these solutions are not the end all be all of solutions to Bitcoin's transaction capacity issues. There will certainly be more, people just need to think of them and design them. Those solutions have not yet been discovered.

There must be a misconception, looking at the code:
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h
/** The maximum allowed size for a serialized block, in bytes (only for buffer size limits) */
static const unsigned int MAX_BLOCK_SERIALIZED_SIZE = 4000000;
/** The maximum allowed weight for a block, see BIP 141 (network rule) */
static const unsigned int MAX_BLOCK_WEIGHT = 4000000;

Thanks for your discussion on some of the scaling solutions.

"No one ever claimed that". You did! You said increasing the blocksize would have a worse effect than I can imagine! I'm saying Bitcoin Core should be doing lots of research on exactly how larger blocks will affect the network, test it out on a test network, and figure out what's the largest possible blocksize the network can reasonably handle and stay highly decentralized. I promise that number is not 1MB, 1MB is just a size that was picked a long time ago.

"We would be"......EXACTLY!! That's my point. The size is arbitrary. There is no reason to say the current size is perfect and anything bigger would be bad, as you just admitted if it started at a smaller size you'd be arguing against the current size! Nothing more clearly shows that the whole argument against increasing blocksize is purely just for the sake of arguing!
Like I said, bitcoin core SHOULD be working on and testing out different sizes in test networks to figure out what the largest size that can reasonably be handled is, and then build a consensus around hard forking to that size in order to scale bitcoin as much as possible while keeping the network working well. Instead, for years they have opposed any talk of increasing the block size. This is VERY BAD for bitcoin's future. I get that hard forks are dangerous, I get their aversion to them. But at some point you have to realize that Bitcoin as it was constructed almost a decade ago cannot handle mass scale, and changes must be made, within the confines of keeping the spirit of bitcoin unchanged,  in order to scale the network. Every possible scaling solution needs to be implemented because none of them come close to what we need, only by adding them all up (ALL OF THEM) can bitcoin maybe scale to global usage. Larger blocksizes are on of those scaling solutions that is being arbitrarily dismissed because simply for the sake of arguing that 1MB was the perfect size and anything larger, as you say, would lead to unimaginable bad effects!

I was responding to
No one is assuming that Satoshi had divine knowledge or that 1 MB is the perfect block size. Nor did I say that 1 MB is the perfect block size. That is not what the argument is about. It is about the status quo and how changing the block size changes the status quo to something that is worse than now. And such changes have effects that many people do not consider.

Do you think that people aren't doing that?

Did you not read anything else I said? It is not for the sake of arguing. Do you think that the Bitcoin Core developers are just saying "NO" and then sitting on their asses doing nothing? It isn't because "we don't feel like it" or "we just want to argue". There are reasons for not increasing the block size, it is not just for the sake of arguing.

That is simply untrue. Again, segwit increases the maximum size the block message can be. That is, by definition, a block size increase. Furthermore there has been extensive discussion about this topic in the development IRC channels, on the Bitcoin-dev mailing list. There is no opposition to any talk of increasing the block size, Not only that, but several Core developers have proposed their own block size increase BIPs, none of which have gotten consensus. The opposition is to the constant rehashing of the topic. This has been discussed so many times and the same things are said by both sides that it is, at this point, pointless to continue discussing the same things. If you are going to say that the Bitcoin Core developers are censoring the topic, that is also simply untrue. The Bitcoin Core developers are not involved in the moderation of any forums where the topic is discussed.

Yes, there are a lot of scaling issues with Bitcoin but, I guess even Ethereum also have scaling issues. Both of them are very famous but, when it comes to real life product development both of them will fail due to its scalability. Here i want to mention this project which is currently under development called Smartmesh Ecosystem. They are trying to solve the scalability issues using Mobile Raiden. (programmed in Go language instead of Python as its highly optimizable). When this project is completed then there will be no issue of Scalability. The main idea of their project is "Off-internet Communication and Off-internet micro-payments". To implement this project Globally its must for them to solve the issue of Scalability which they are doing it efficiently.

Here is the detail of SM-Chain
https://medium.com/smartmesh/testnet-of-smartmesh-public-chain-smchain-is-online-on-march-15th-bee4a53dc998

LN is similar with Raiden on Ethereum, isn't it?

I'm sure there are some finer differences between Lightning Network and Ethereum's Raiden when you get in the guts of it, but in essence, yes.

Both use hash-locked transactions to create a network of full-collateral, bi-directional payment channels to enable near-instant off-chain transactions with on-chain settlement.

Most of the argument against Lighting Network as a real scalling solution come from frequent closing and opening channels at rate of one monthly per user. What if user keep his channel open forever and closes it only if a older state transaction is trying to settle on Bitcoin blockchain?

The incentive for keeping his channel open forever to a well connected hub might be high onchain fees actually. Any excess or shortage of Bitcoin in a channel could be solved by exchange services using Lighting Network where you sell or buy Bitcoin to your channel state without actually any need of Bitcoin blockchain settlement transaction. I guess thats the endgame where everone just uses changing states of their Lighting Network channel and there is no point in using Bitcoin blockchain settlement transactions anymore because these become expensive.

You don't seem to understand how Bitcoin works. My "attitude" is irrelevant, so is yours to be honest. What you want and what you get are two very different things. If you want bigger blocksizes, but there are enough people with enough resources that want to leave it as it is.. it means there's no consensus to change Bitcoin, and who would be reckless enough to change Bitcoin without consensus? unless you are ok with an altcoin (see BCash).

The value proposition of Bitcoin is that it cannot be easily changed, otherwise it would be worthless. If there's people willing to transact on it, pay the fees, and buy Bitcoin to do so, then it hasn't failed at that, it just failed as an everyday currency, but digital gold features are still there, and again, a digital gold that someone with "the right attitude" can change would be worthless and stupid.

Even if Bitcoin Core said "yes", there are many whales that would have said "no", it's easier said than done.

To sum it up, I want to see Bitcoin viable as a form of everyday payment, but not at the expense of ending up with 2 coins and more drama as everyone claims their Bitcoin is the real Bitcoin, all of this while the price crashes and we have a decrease in hashrate in all chains as miners start fucking around and speculating with the hashrate (see BCash for a taste of that).

I think we will see a block weight increase in the future.

But I also think that this should not be rushed.

The first step was to get Segwit which is essential for lot of future improvements including lightning.

But I guess lot of people did not understand that it's not done by just activating Segwit.
It's important that people and companies also use Segwit so it can show it's benefits.

And I think the only way it was possible to force companies to implement Segwit in their services was to reject the Segwit2X fork.

Companies usually first think about their money.
So what is cheaper for them?
Increasing the block weight where they don't have anything to do or hire some developers to implement Segwit in their software.

Of course the companies decide to go the easy and cheap way.

With the Segwit2X I think we would have temporarily solved the full blocks end of last year but I'm quite sure that nearly no company would have implemented Segwit on their side as everything is fine even without using Segwit.
Without the overfilled mempool end of last year (which might be caused by attacking the network with spam transactions), I also think that Segwit adoption by the big companies did not happen that "fast". Because of high transactions fees they were forced to implement Segwit and batching transactions to maintain their businesses.

Therefore I can completely understand that lot of people (including lot of Bitcoin Core team members) were against a block weight increase for now.
But I don't see this rejection of the 2X as "they are against an increase forever".

So in short. Segwit need to get adopted which would be much slower if also a block weight increase happened.
After adoption of Segwit and other soft fork scaling solutions I'm sure we will see also an increase of the block weight (maybe not in the near future, but it will come).

I don't see how. Please explain how consensus around increasing the blocksize is ever going to happen? Because again, it will only lead to 2 things:

1) Bitcoin will continue with 1MB as there will still be people mining and transacting on it
2) There will be a 2MB or whatever blocksize hardfork, which companies and exchanges will claim it's Bitcoin, even if Core team agrees, it doesn't make it Bitcoin

So you will have the legacy chain existing and the new chain existing, and we already have this (Bcash).

The blocksize cannot be increased, it will always lead to a new altcoin, which some may call Bitcoin. Bitcoin is basically impossible to hardfork at this point (without again, ending up with 2 coins).

This is circular reasoning.

If a majority can agree not to increase the blocksize limit, then that is a consensus decision by definition. The logic wasn't "no increase, because Bitcoiners say no to everything, always". The logic was "no increase, because it's the wrong decision at this point in time, for design reasons".


When a case is made that makes sense to the majority of Bitcoiners, they'll accept a blockweight increase. For instance, Segwit was an increase in blockweight, and Bitcoiners accepted it. So it's already happened, saying "it's never going to happen" is a difficult argument to sustain given this reality.

Its already above 1MB.
https://blockchain.info/block/00000000000000000038e39017b9a8aa944ae0016b9e3d1639128f20f035bbb1
Just 1 block that is around 1,7MB blocksize.

Consensus means, that the majority of the participants are willing to follow those rules.
And I'm quite sure that at some point in time the majority will agree with a block weight increase.

Let me think about the different roles who are part of the bitcoin network.
The following list is just my opinion of what the different roles could think. I might be wrong, so feel free to correct or extend this list.

• Miners
  Most miner would be for an increase of the block weight as they could pack immediately more transactions into one block which would increase their collectable fees.
  Some miners with a bad internet connection might be against it, as they would have a disadvantage as bigger blocks would get broadcasted a bit slower which means they have a bigger delay to start mining a new block.
• Full Nodes
  Depending on how big the increase will be, the people who run full nodes will need to check if their current CPU power is high enough to be able to validate incoming transactions and blocks in time, if they have enough disk space to store the blockchain and if their bandwidth is high enough to be able to download and propagate received blocks to connected peers.
  The CPU power will not be a limited factor as even with a x4 block weight increase a Raspberry Pi could still easily handle this load.
  Also disk space is not a problem today with an increased block weight.
  The bandwidth is usually the limiting factor. Not the download speed, it's more the upload speed.
  So, if the increase would be too high this could mean that some people could stop or limiting providing their full nodes.
• Users
  Normal users usually only want a good experience. With increased block weight, transactions would get confirmed faster and that's what is important for them.
• Companies
  Companies, as seen in the past with support of the 2X will be happy with an increase of the block weight. I don't see that they would be against it.
• Core Developers
  Core developers want to keep the network as secure and as decentralized as possible. When they see that an increasing of the block weight does not have a big impact on security and decentralization, the majority will also be for an increase.
  As the infrastructure (CPU power / bandwidth / hard disk storage) increase over time, so they will allow also an increase of the block weight with about the same rate. This will more or less guarantee that the network don't get more centralized

When a fork for increasing the block weight is agreed, I think there will be not only an increase of the block weight but also some other new features which require a hard fork.
As a hard fork is always dangerous, you should get the most out of it to avoid another hard fork after a short time.

Combined with also new features a hard fork might be more interesting also for those people who are against a block weight increase on it's own.
Such a hard fork will also need a preparation from I guess about 1 year. So there is time that everybody get notified about the hard fork and have time to update their software.

But of course there is a big chance that a chain split happens as it's hard to get everyone on board.

There will be a legacy chain and a forked chain. But if the majority was for a consensus change, the most value will be on the forked chain and just a small part will stay on the legacy chain. Maybe the legacy chain will die after some time, maybe it will continue like Ethereum Classic or maybe it keeps the most value. This decision will then be made by the market.

BCash was a fork without overall consent, that's the reason why it just become an alt coin. If BCash would had the majority on their side or if the Segwit2X would have been successful with the majority on their side (which would also be represented by the market value), this winning fork would be the new bitcoin in my eyes.

My point is that there will always be people that don't want to do X, which means the result will be getting an altcoin, and the legacy chain will go on.


Segwit was not "accepted by bitcoiners", it was accepted by some bitcoiners (again my point, total consensus is impossible), others didn't accept it, which resulted in BCash being created, but this was a soft fork. If a way to get segwit via soft-fork was never found, it would have either never happened, or we would have Bitcoin and Bitcoin-segwit in a separate chain (which some would claim to be Bitcoin), and so on.

There's an abundance of evidence to suggest that Bitcoin Cash was a small minority of original Bitcoiners, not least the way the exchange rate of BCH has dived and dived. 95% acceptance or thereabouts is the best that could be expected realistically, and that's about what happened. Saying "100 people out of several 100,000's didn't agree" is not much of an argument.

It's difficult to measure these things, "100 people out of several 100,000's didn't agree" is not much of an argument, but what im sure is, if segwit wasn't done as a soft fork, and it activated, there would be people mining the original chain, and we would have a 2-coin situation.

Also, it's not so much the amount of people, but the skin in the game, namely, people owning a ton of coins ready to dump their share on your chain, crashing the price, and thus forcing miners to mine back on the legacy chain.

one piece of what Bitcoin needs to scale?
For scaling lightning can help a lot. But its not enough, biggest issue is not the transaction number that can be confirmed per minute.

whats even more needed for bitcoin is to be more intuitive and easy to use in real life scenarios.

in the background such random numbers and adresses like=645E0A030230232302032 can be used, ok. but dont let people interact with such.
learn from the internet.

people want to send money to people/businesses/e-commerce shops/vending machines.
they want to be able to easily pay things or get payed.
maybe involve new possibilities with mobiles: near field sensors. btc amounts lower 10 dollar can be directly transferred by pressing one button, if mobile is next to nearfield chip.
Or you can send btc to email adresses (confirmed n registred ones through eth distributed network registry).

etc.
THIS is needed to change our current world to the new money.
otherwise its a technology for tech childs, for holders, for visionary, for traders, for believers. but not for all.

Maybe, but not necessarily. This would still have required a dev team to continue maintaining the legacy chain (ie. non-SegWit, non-blocksize-increase), especially since 2-way replay protection would still be a requirement for both chains to survive on the open market -- otherwise one chain would get cannibalized by the other rather sooner than later, as exchanges wouldn't be able to reliably support both chains. Either way such a scenario would have likely meant that neither chain would have implemented replay protection, leading to a blockchain fight to the death.



The amount of people for the most part directly translates to skin in the game though, doesn't it? Dumping your coins on the chain you disagree with only moves power from you to people that actually believe in said chain. It follows that in the long run its more a question of fiat flowing in, rather than coins being dumped.



Fully agreed. But first Bitcoin needs to get its scaling problem in order, otherwise all would be for nil. Great user experience accounts for nothing if the underlying fundamentals are not ready.