[POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)

[dinofelis]

Good point. Now you're starting to get it; if internet resources became seriously inhibited, 4MB could be crippling to Bitcoin. It's not the such a great compromise when you consider that possibility

Why stop there? 1 MB might be way too much as well. I don't like this argument one bit.

So that's what you would you do if such a situation occurred? Complain directly to reality itself?

I know you don't like the argument, that's why you're trying to wish it away. But political developments of all sorts could cause such drastic things to take place, and who knows how long for, and that's not at all implausible. The worst aspect is exactly how uncertain we can be about the severity or duration of such a possibility. But 12MB blocks though, right?

That kind of argument is a fallacy (I think it is called "fallacy of catastrophic expectations"), because, even though unlikely, the hypothesis is not impossible, the hypothesis makes that the problem at hand is not an important problem any more.

This is like "one shouldn't put a roof on a house, because when there's a meteor impact like the one that killed the dinosaurs, the roof will not resist".  If there's a meteor impact like the one that killed the dinosaurs, the problem of the solidity of your roof is not a problem worthy of attention any more.

If society is so fucked up, by technical or political reasons, that computing and internet connectivity falls drastically backwards, "crypto currencies" are not something to worry about any more. (trying to survive from the dictatorship or trying to find food, is).

[1714016182]

1714016182

[1714016182]

1714016182

[1714016182]

1714016182

[Carlton Banks]

No, you're exaggerating

Good engineering practice involves planning for marginal cases, and what I presented represents a LIKELY possibility, not the HIGHLY UNLIKELY scenario you used. Please use rational arguments, not hyperbole.

[dinofelis]

Good engineering practice involves planning for marginal cases, and what I presented represents a LIKELY possibility, not the HIGHLY UNLIKELY scenario you used. Please use rational arguments, not hyperbole.

You think that it is likely that in the coming years, internet capacity goes down ?   Without some big cataclysm ?  Seriously ?

[Carlton Banks]

Not following geoplitics then I take it?

No cataclysms, super-giant meteorites or alien invasions necessary: all it could take would be something like the Philipino president or the North Korean president provoking a serious conflict with the US. That sort of thing happens constantly, the US establishment is always "policing" states that present them with an opportunity to do so.

The danger is that China would step in to help. And that's a very real danger; the South China Sea is strategically prized by the Chinese government, they already have an independent dispute both with the Japanese and the US over the various islands in that area.

And guess what strategic assets traverse the sea bed of the South China Sea and in the Pacific Ocean surrounding the Philipines? And no, it's not shapeshifting lizard creatures from outer space

[franky1]

Not following geoplitics then I take it?

No cataclysms, super-giant meteorites or alien invasions necessary: all it could take would be something like the Philipino president or the North Korean president provoking a serious conflict with the US. That sort of thing happens constantly, the US establishment is always "policing" states that present them with an opportunity to do so.

The danger is that China would step in to help. And that's very real danger; the South China Sea is strategically prized by the Chinese government, they already have an independent dispute both with the Japanese and the US over the various islands in that area.

And guess what strategic assets traverse the sea bed of the South China Sea and in the Pacific Ocean surrounding the Philipines? And no, it's not shapeshifting lizard creatures from outer space

america are hating china.. not because there is some chinese guy sleeping on the american peoples door steps. but because america has been watching too much fox news.

while we had the "everyone hate russia" moment for the last decade.. america was actually doing trade deals with russia.. literally giving russia the front door key to the international space station and a taxi licence to charge americans to be taken to the door and open the door for america to access the space station.

you can buy apple iphones, mcdonalds, and thousands of other american things all in russia.. all while fox news was spewing out to hate russia..

bringing politics back on topic:

and now we have core who gave the pools the vote and bypass node consensus. core changed the fee estimation, relay and allowance lines of code..
but good old coindesk (barry silbert: DGC: blockstream) is using the media band wagon to try swaying people to blame china for bitcoin issues...

never accept what has been spoonfed for you by script writers. even if 100 people repeat it.. instead do you own research.
blockstream changed the fee mechanisms, blockstream changed who gets to vote. but blockstream didnt expect 50% undecided resistance and 25% opposition. they thought it was a easy domination with soft strokes of peoples asses.. but now realise they didnt get it soo easy.. so now they wanna ram the ban hammer hard and blame it all on the pools or other nodes for causing a split..
either playing the victim card of the fake first strike defense tactic as a way to stroke asses to pretend they are protecting bitcoin when really its about gaining domination of bitcoin.

if anyone dares reply that they want to avoid consensus and happy to have blockstream control it and no one else can or shoot keep them on their toes... then just reply "centralising is ok"

[AliceWonderMiscreations]

Good point. Now you're starting to get it; if internet resources became seriously inhibited, 4MB could be crippling to Bitcoin. It's not the such a great compromise when you consider that possibility

My grandma told me to learn to calculate with paper and pensil, because if all pocket calculators would one day fail I could still do my sums with paper and pencil.

My slide rule doesn't need batteries.

I don't think it is very fast at hashing though...

[d5000]

@Carlton Banks: Well, then we in South America take over Bitcoin. We've resolved the last conflict on our continent and you can all die, but Bitcoin will survive

Seriously, the Internet is decentralized, there will be a network ready to manage 12 MB blocks. Mesh wi-fi networks also could be a solution. And even if a extremely catastrophic event causes the Bitcoin network to stop processing blocks for a while, then we eventually could start it again.

@Lauda: I have thought about starting a new thread. For now, I'll wait a bit more and see, because I'm reading currently a bit about Bitcoin's consensus and how one could avoid miners given too much power, so my conclusions could be discussed in the new thread. Here, for example, I discussed a possible counter-measure (proposed by another user in the German language forum) in case miners ignore completely the majority's wishes - it shares the "spirit" of UASF.

[Carlton Banks]

@Carlton Banks: Well, then we in South America take over Bitcoin. We've resolved the last conflict on our continent and you can all die, but Bitcoin will survive

Seriously, the Internet is decentralized, there will be a network ready to manage 12 MB blocks. Mesh wi-fi networks also could be a solution. And even if a extremely catastrophic event causes the Bitcoin network to stop processing blocks for a while, then we eventually could start it again.

Is it me, or does that sound incredibly reckless? Don't you understand how fragmented and bottlenecked a widespread mesh-net could be if it wasn't very carefully planned and diligently protected? I'm in favour of that kind of solution, but your casual description is not capturing the full extent of the problem, a successful neighbourhood or town level mesh-net is a whole different ball game to covering an entire land mass with interconnected mesh nets. How are we going to use mesh nets to cross the oceans? (which was the crux of my point anyway)

And what is your ACTUAL RATIONALE for wanting 12 MB blocks? I've not seen anything in this thread that isn't a circular argument

[Lauda]

-snip-
And what is your ACTUAL RATIONALE for wanting 12 MB blocks? I've not seen anything in this thread that isn't a circular argument

Some people just want more on-chain capacity and secondary layer solutions. As I've mentioned earlier, it is quite possible that Bitcoin Core will go in the direction of a dynamic block size or flex caps (unless the individuals silently changed their opinions on this), see here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

[d5000]

How are we going to use mesh nets to cross the oceans? (which was the crux of my point anyway)

It's very, very difficult to imagine an event like you're pointing out (e.g. where most of all trans-oceanic cables are broken). It's even more difficult to imagine that the Bitcoin transaction volume would stay as high as before the catastrophe. So even if all what you imagine comes true, block size would be almost for sure much smaller (and block propagation temporarily faster). But I don't want to profundize here as I consider that event highly improbable.

And what is your ACTUAL RATIONALE for wanting 12 MB blocks? I've not seen anything in this thread that isn't a circular argument

If we really want mass adoption (>1 billion users), we would need >12 MB blocks even to enable LN users to open one payment channel per year. And LN needs to enable its users to close the channels when they need it (one on-chain transaction more per user), because otherwise the counterparty could steal the money. Imagine if a hub tries to steal Bitcoins from their users. We would have instantly millions of unconfirmed transactions because of all users wanting to close their channels.

So your "maximum of 4 MB" would mean Bitcoin user base being capped permanently at about 50 million users, even if all the transactions were done in a second layer/off chain manner.

As already said, I don't want 12 MB now, but a gradual plan to move towards possible mass adoption.

[Carlton Banks]

How are we going to use mesh nets to cross the oceans? (which was the crux of my point anyway)

It's very, very difficult to imagine an event like you're pointing out (e.g. where most of all trans-oceanic cables are broken). It's even more difficult to imagine that the Bitcoin transaction volume would stay as high as before the catastrophe. So even if all what you imagine comes true, block size would be almost for sure much smaller (and block propagation temporarily faster). But I don't want to profundize here as I consider that event highly improbable.

It would help your credibility a great deal if you weren't putting massively exaggerated words in my mouth. I specifically did not say "most or all" trans-oceanic cables are at risk of breaking, I gave a specific (and HIGHLY PLAUSIBLE) political scenario where some important cables could be broken. Your arguments are still circular, you proved me wrong by saying "it's improbable, because I say it's improbable"

Again, why are you planning for optimistic scenarios when we're supposed to be treating this like an actual engineering problem, where that approach FREQUENTLY AND DEMONSTRATIVELY LEADS TO FAILURES NO-ONE FORESAW. Where is your safety margin?

And what is your ACTUAL RATIONALE for wanting 12 MB blocks? I've not seen anything in this thread that isn't a circular argument

If we really want mass adoption (>1 billion users), we would need >12 MB blocks even to enable LN users to open one payment channel per year. And LN needs to enable its users to close the channels when they need it (one on-chain transaction more per user), because otherwise the counterparty could steal the money. Imagine if a hub tries to steal Bitcoins from their users. We would have instantly millions of unconfirmed transactions because of all users wanting to close their channels.

So your "maximum of 4 MB" would mean Bitcoin user base being capped permanently at about 50 million users, even if all the transactions were done in a second layer/off chain manner.

Your imagination for transaction rate increases seems strangely limited to the block size only, considering I asked for an ACTUAL RATIONALE.


Why not improve the efficiency of transaction encoding FIRST, which is also a hard fork

Why not explore the possibility of decreasing the block interval target FIRST, which is also a hard fork

Why not explore the possibility of separating tx and coinbase blocks (and making the tx block interval more frequent) FIRST, which is also a hard fork

Why not do everything that isn't the most dangerous option FIRST?


With some combination of ALTERNATIVES, WHICH EXIST, the x3 increase in tx rate from 4MB could achieve the same exact effect that your inherently more dangerous suggestion does. Why not play it safe, like an ACTUAL ENGINEER. It's only a highly important development in human progress, after all

[d5000]

I specifically did not say "most or all" trans-oceanic cables are at risk of breaking, I gave a specific (and HIGHLY PLAUSIBLE) political scenario where some important cables could be broken. Your arguments are still circular, you proved me wrong by saying "it's improbable, because I say it's improbable"

Is it more circular than your argument "I think it's plausible, so it's plausible?"

Your imagination for transaction rate increases seems strangely limited to the block size only, considering I asked for an ACTUAL RATIONALE.

I haven't said that I'm against an alternative to an increase of block size and I think it's good that you mention them. If these alternatives exist and are capable of solving the problem, why aren't they more thoroughly discussed in the scalability debate? (Serious question.)

Why not improve the efficiency of transaction encoding FIRST, which is also a hard fork

Why not explore the possibility of separating tx and coinbase blocks (and making the tx block interval more frequent) FIRST, which is also a hard fork

These two look interesting. What is the combined potential, in transaction capacity per MB, of these two measures? (Is the second one Bitcoin-NG? Why was it not explored?)

Why not explore the possibility of decreasing the block interval target FIRST, which is also a hard fork

That one will be most probably been rejected by most of the community because it modifies the original reward schedule and has its own dangers (more orphans). And it would not solve the problem of a large blockchain (that also applies to the Bitcoin-NG proposal), but could improve the propagation and validation of individual blocks.

Edit: Don't forget that the original intention of the proposals we're discussing here is to achieve approval for Segwit by miners of the "big blockers" fraction to get rid of the stalemate. I for myself, for now, would be perfectly happy with Segwit alone for now and then let the Core devs decide further scaling measures.

[kiklo]

So, assuming technology allows us a certain size on-chain post-Segwit, you still wouldn't accept any kind of increase (regardless of BIP, author, implementation)?

You're attempting a false premise right off the bat


There is no guarantee that internet infrastructure will be sufficiently capable to deal with on-chain scaling to begin with.

Instead of designing changes around a medium or best case scenario that hasn't happened yet, we should plan for the worst case scenario instead


You're making a super huge assumption that global internet connectivity does not deteriorate over the next 5 years of your "scaling" plan


What happens if the global internet infrastructure deteriorates in bandwidth or connectivity over that timeframe?

Internet was originally designed to withstand a Nuclear War.

However advancements in technology are such that a Targeted EMP Pulse designed to destroy an entire Country Electronic infrastructure is not out of reason.

So lets say China uses one on the US,
what happens their is no electricity , no internet , hell, Fiat is not even worth a damn, so who will give a shit about BTC.

However if you save your private keys on paper and can escape the aftermath to a friendly country and are not killed on site for being an american.
Then you can renter this other country and use BTC , because the rest of the world was left untouched and continue living and BTC continued normally.

However the US has safeguards in place to prevent an EMP pulse from China or anyone else, even from that little space weapon they think the US does not know about.  




The Odds of BTC dying from being not being able to process a transaction or the price of processing a transaction is a Bigger Direct Threat to BTC that what you are worried about CB.  

Good Book on EMP , is One Second After by William R. Forstchen .


 

FYI:
If only this magical bandwidth issue that keeps you you at night,
the easy solution is this, when large blocks start causing too many orphans problems.
Decrease the size of the blocks and move to a faster block speed.  
ie: https://bitcointalk.org/index.php?topic=1827943.msg18206691#msg18206691

 

[Carlton Banks]

I specifically did not say "most or all" trans-oceanic cables are at risk of breaking, I gave a specific (and HIGHLY PLAUSIBLE) political scenario where some important cables could be broken. Your arguments are still circular, you proved me wrong by saying "it's improbable, because I say it's improbable"

Is it more circular than your argument "I think it's plausible, so it's plausible?"

The 2nd strawman argument that you've made against me.


My argument is that diplomatic tension is rising between the states that adjoin the South China Sea. One of those states (Phillipines) has switched allegiances from one major military superpower (US) to another (China) just recently. The president of The Phillipines has denounced international organisations strongly (threatening to burn the UN assembly building to the ground, for instance), and is being investigated by the International Criminal Court for crimes against humanity.

Separately, the US, China and Japan are all having a stand off between one another over disputed islands right in the middle of the exact same region.

And if that wasn't enough, one highly unpredictable, volatile nuclear armed state (North Korea) is exhibiting increasingly bellicose rhetoric towards ALL parties.

If that doesn't sound like a plausible tinderbox ready to catch fire, I don't know what sort of scenario you would actually consider potentially dangerous. It's a serious threat, and it's only 1 out of many possible serious threats. It's likely there are even threats to the internet's operation that no-one could have imagined, hence my focus on margins of safety and risk analysis.


Now, how is any of that either implausible or a circular argument

Your imagination for transaction rate increases seems strangely limited to the block size only, considering I asked for an ACTUAL RATIONALE.

I haven't said that I'm against an alternative to an increase of block size and I think it's good that you mention them. If these alternatives exist and are capable of solving the problem, why aren't they more thoroughly discussed in the scalability debate? (Serious question.)

Why not improve the efficiency of transaction encoding FIRST, which is also a hard fork

Why not explore the possibility of separating tx and coinbase blocks (and making the tx block interval more frequent) FIRST, which is also a hard fork

These two look interesting. What is the combined potential, in transaction capacity per MB, of these two measures? (Is the second one Bitcoin-NG? Why was it not explored?)

If you're actually interested in responsible scaling, maybe you could investigate them too? But I doubt that you are, you've spent far too long defending your entrenched and dogmatic position, when you don't really have any good arguments to support it.

Why not explore the possibility of decreasing the block interval target FIRST, which is also a hard fork

That one will be most probably been rejected by most of the community because it modifies the original reward schedule and has its own dangers (more orphans). And it would not solve the problem of a large blockchain (that also applies to the Bitcoin-NG proposal), but could improve the propagation and validation of individual blocks.

Edit: Don't forget that the original intention of the proposals we're discussing here is to achieve approval for Segwit by miners of the "big blockers" fraction to get rid of the stalemate. I for myself, for now, would be perfectly happy with Segwit alone for now and then let the Core devs decide further scaling measures.

Which part of "explore the possibility" do you not understand?

The orphan rate has been improved vastly now we're at version 0.13 - 0.14. The amount of slack that frees up COULD be used to safely reduce the block interval, but that would have to be proven on a test network before any proposal could even be made.


And maybe you have something to remember; Segwit itself is a blocksize increase, of 4x. A 4x increase is NOT to be underestimated in impact, increasing resource use by a factor of 4 is very large for a peer 2 peer network.

[kiklo]

And maybe you have something to remember; Segwit itself is a blocksize increase, of 4x. A 4x increase is NOT to be underestimated in impact, increasing resource use by a factor of 4 is very large for a peer 2 peer network.

Segwit => DeadWIT

Miners will never allow it to activate,

If you know anyone dumb enough to work and send their paychecks to someone else.
Because that is what you are asking the miners to do.


 

[d5000]

My argument is that diplomatic tension is rising between the states that adjoin the South China Sea.

OK. I don't believe it will happen, but let's explore the possibility. Which cables - apart from some regional connections - are threatened by that possible conflict? The rest of the world is pretty well connected. If the Philippines, because of the "intelligence" of their president, are temporarily disconnected, the rest of the world would not even notice. Seriously threatening the connectivity of China and the rest of East Asia will be a LOT more difficult, there must be a >WW2-like scenario for it. And even then the rest of the world could continue to use Bitcoin.

And: What problem do you see arising? Block propagation or IBD? If it's the first one - I seriously don't believe that a 12 MB data packet every 10 minutes or so is too much for even a low-bandwidth connection of today's standards. And we are talking about >4 years from now and about the absolute worst case - if a large part of the transactions were multisig, for example.

Why not improve the efficiency of transaction encoding FIRST, which is also a hard fork

Why not explore the possibility of separating tx and coinbase blocks (and making the tx block interval more frequent) FIRST, which is also a hard fork

These two look interesting. What is the combined potential, in transaction capacity per MB, of these two measures? (Is the second one Bitcoin-NG? Why was it not explored?)

Where is your answer to this question? You're trying to trick me into a rhetoric labyrinth to sustain your maximalist position.

If you're actually interested in responsible scaling, maybe you could investigate them too? But I doubt that you are, you've spent far too long defending your entrenched and dogmatic position, when you don't really have any good arguments to support it.

Hey, stop a bit. I'm discussing various possibilities here and even gave you room to explain your favoured alternatives, but all you say to me is "investigate yourself". You have brought in the proposals, so please point me to the relevant discussions. Don't forget this sentence:

Don't forget that the original intention of the proposals we're discussing here is to achieve approval for Segwit by miners of the "big blockers" fraction to get rid of the stalemate. I for myself, for now, would be perfectly happy with Segwit alone for now and then let the Core devs decide further scaling measures.

The "dogmatic positions" are actually BU and Segwit/1MB maximalism, not the exploration of a compromise!

Segwit itself is a blocksize increase, of 4x. A 4x increase is NOT to be underestimated in impact, increasing resource use by a factor of 4 is very large for a peer 2 peer network.

That's why the last proposal is gradual and has a grace period where the base size would not be changed for one year, so if there was an actual danger the code change can be reverted. The 12 MB would only be possible after 4 years - 4 years where the developers at every time could revert the change if there is a catastrophic scenario which makes impossible such a high block size.

And it's NOT a final proposal, it's only the result of the discussion of some users in this thread. It can be changed.

[Lauda]

-snip-

Regarding your recent mention of reducing the block generation time, I asked on IRC. Apparently even with all the relay improvements, they are not adequate to reduce the generation time safely to e.g. 5 minutes claimed Maxwell. There were a few more people giving their opinion at the time, but I forgot to save a copy of the chat. This is quite unfortunate though, I'd definitely like to see 2017 data for this kind of expertiment. Maybe a testnet with constantly full 1 MB blocks and 5 min block interval.

[hv_]

-snip-

Regarding your recent mention of reducing the block generation time, I asked on IRC. Apparently even with all the relay improvements, they are not adequate to reduce the generation time safely to e.g. 5 minutes claimed Maxwell. There were a few more people giving their opinion at the time, but I forgot to save a copy of the chat. This is quite unfortunate though, I'd definitely like to see 2017 data for this kind of expertiment. Maybe a testnet with constantly full 1 MB blocks and 5 min block interval.

Thx for doing this. To me a 5min interval (halving the reward) would be a sign of flexibility and step into right direction. It would also reduce waiting time - win win.

I do not really understand why this is a real issue since we see some bigger shit coins work mostly ok with less time.... Hmmm

[Carlton Banks]

My argument is that diplomatic tension is rising between the states that adjoin the South China Sea.

OK. I don't believe it will happen

You're shifting the argument, and it's dishonest

My point is not to argue the finer details of whether this scenario or that scenario is sufficiently problematic to cause impact X on the network.

What I'm saying (and which you did not address) more broadly is that there are multiple possible situations like the scenario I presented that are becoming more likely because of the rising trend of polarised diplomatic relationships between strategically important states, all over the world.


Lie to us, tell us that polarised diplomacy between major states doesn't carry the serious threat of conflicts that could disrupt the internet very badly

Why not improve the efficiency of transaction encoding FIRST, which is also a hard fork

Why not explore the possibility of separating tx and coinbase blocks (and making the tx block interval more frequent) FIRST, which is also a hard fork

These two look interesting. What is the combined potential, in transaction capacity per MB, of these two measures? (Is the second one Bitcoin-NG? Why was it not explored?)

Where is your answer to this question? You're trying to trick me into a rhetoric labyrinth to sustain your maximalist position.

I am not sure how much can be achieved using those on-chain scaling methods, but that wasn't the point. I'm proving that different ways to scale exist that do not carry the dangers that blocksize increases do, and that also constitute actual scaling, instead of just using more resources at the same scale.


Again: the sensible engineering approach for a peer-to-peer network is to use sensible margins of safety and precaution, IN PARTICULAR when it comes to the resources the network needs to operate

If you're actually interested in responsible scaling, maybe you could investigate them too? But I doubt that you are, you've spent far too long defending your entrenched and dogmatic position, when you don't really have any good arguments to support it.

Hey, stop a bit. I'm discussing various possibilities here and even gave you room to explain your favoured alternatives, but all you say to me is "investigate yourself". You have brought in the proposals, so please point me to the relevant discussions. Don't forget this sentence:

Don't forget that the original intention of the proposals we're discussing here is to achieve approval for Segwit by miners of the "big blockers" fraction to get rid of the stalemate. I for myself, for now, would be perfectly happy with Segwit alone for now and then let the Core devs decide further scaling measures.

The "dogmatic positions" are actually BU and Segwit/1MB maximalism, not the exploration of a compromise!

Prove it.

I'm suggesting, without stating opinions as fact, that Segwit's 4MB IS the compromise solution. You're just using circular reasoning, yet again.

Segwit itself is a blocksize increase, of 4x. A 4x increase is NOT to be underestimated in impact, increasing resource use by a factor of 4 is very large for a peer 2 peer network.

That's why the last proposal is gradual and has a grace period where the base size would not be changed for one year, so if there was an actual danger the code change can be reverted. The 12 MB would only be possible after 4 years - 4 years where the developers at every time could revert the change if there is a catastrophic scenario which makes impossible such a high block size.

And it's NOT a final proposal, it's only the result of the discussion of some users in this thread. It can be changed.

You're not getting the broader point here: there are several ways (and likely several more we haven't thought of) that could be employed to get that kind of transaction density with 4MB Segwit blocks, bigger than that is unnecessary when there are other options.

You're just desperate to keep the conversation on the track of "bigger blocks = only method to increase tx rate possible", when it's demonstrably provable that it's the WORST WAY TO ACHIEVE THAT because it carries the MOST SIGNIFICANT RISKS WHEN DEALING WITH PEER TO PEER NETWORKS.



Please, respond to the actually argument I'm making, not derailing back into defending x=y linear growth in blocksize. It's indefensible, when the same rate of growth could be achieved a less dangerous way, using actual scaling paradigms that multiply the utility of EXISTING CAPACITY, not adding extra burden to the capacity at the same scale.

[d5000]

I am not sure how much can be achieved using those on-chain scaling methods, but that wasn't the point. I'm proving that different ways to scale exist that do not carry the dangers that blocksize increases do, and that also constitute actual scaling, instead of just using more resources at the same scale.

You didn't prove anything still, you only mentioned very vague points, that could be interesting but are not very thoroughly discussed in the actual debate. So if you want to continue this discussion (otherwise, I'm out), then please link me to sources that prove that these are real possibilities to achieve a significantly higher  transaction capacity.

And you seem to have STILL not read the following sentence:

Don't forget that the original intention of the proposals we're discussing here is to achieve approval for Segwit by miners of the "big blockers" fraction to get rid of the stalemate. I for myself, for now, would be perfectly happy with Segwit alone for now and then let the Core devs decide further scaling measures.

I'm suggesting, without stating opinions as fact, that Segwit's 4MB IS the compromise solution.

That's called maximalism. It's one of the two extremes of the positions in the actual debate (if we exclude Luke-Jr with his 300 kB blocks). Even many Core devs are open to block size increases after Segwit. Addition: Remember the Hong Kong Consensus?

there are several ways (and likely several more we haven't thought of) that could be employed to get that kind of transaction density with 4MB Segwit blocks, bigger than that is unnecessary when there are other options.

Again: More precision please. We aren't advancing here. I, for myself, would be perfectly well with a solution like that:

- Segwit
- 50% TX density improvement by better encoding
- Block time reduced to 5 minutes (again, I would be in favour, but I don't think it will come)
- 1 MB base / 4 MB weight.

Please, respond to the actually argument I'm making, not derailing back into defending x=y linear growth in blocksize. It's indefensible, when the same rate of growth could be achieved a less dangerous way, using actual scaling paradigms that multiply the utility of EXISTING CAPACITY, not adding extra burden to the capacity at the same scale.

I'm interested in LN and sidechains like Rootstock, but I have already pointed out that even with a well-functioning LN we need more on-chain capacity. If the solutions you mention (TX encoding, block time) are providing them, then why don't you link me to the relevant discussions of it?

But again, you're missing the point (read the bold sentence again!). The goal was to achieve a solution that could be supported by the hardcore BU miners AND Segwit supporters. I think we've already failed anyway. Fork will come, because of maximalists on both sides (you are one of them, it seems), and it won't be good for Bitcoin. (It won't kill it, though).