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

[d5000]

Update: For those new to the topic: There is already a precise proposal with a patch ready to be tested that implements this compromise solution, called "Segwit2MB", by Core security auditor Sergio Demian Lerner.

I have read this compromise proposal from "ecafyelims" at Reddit and want to know if there is support for it here in this forum.

Compromise: Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF)

Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF) into a single HF (with overwhelming majority consensus).

Since Segwit changes how the blocksize is calculated to use weights, our goal with the merger would be 2MB of transactional data.

Segwit weighting system measures the transaction weight to be 3x(non-witness base data) + (base data with witness data). This weight is then limited to 4M, favoring witness data.

Transactions aren't all of base or witness. So, in practice, the blocksize limit is somewhere between 1MB (only base data) and 4MB (only witness data) with Segwit.

With this proposed merger, we will increase Segwit weight limit from 4M to 8M. This would allow 2MB of base data, which is the goal of the 2MB HF.

It's a win-win solution. We get 2MB increase and we get Segwit.

I know this compromise won't meet the ideals of everyone, but that's why it's a compromise. No one wins wholly, but we're better off than where we started.

It's very similar to what was already proposed last year at the Satoshi Roundtable. What is the opinion of the Bitcointalk community?

[1713529007]

1713529007

[1713529007]

1713529007

[1713529007]

1713529007

[DooMAD]

I'm all for compromise, but still feel that any static, fixed size is a clumsy and crude solution.  As many have argued previously, it's merely kicking the can down the road.  SegWit plus a modified hybrid of BIP100 and BIP106 would be more flexible, adaptable and future-proof.  Not only that, but a sudden, arbitrary one-time surge in space leads to uncertainty and the possibility of abuse by spammers.  The change is healthier being gradual and predictable.

[d5000]

@DooMAD: What you say surely is valid - it's a short-term fix, but it would fix the current bottlenecks and already would enable Lightning and other offchain methods to be tested and in 2-3 years we can then switch to a more flexible variant.

And I think it would be very difficult in the actual situation to reach an agreement that includes some kind of "vote" by the miners for a certain block size, although your proposal seems to be much more moderate than BU (I have read it only superficially, though).

[Gimpeline]

You have a good point, but I'm pretty sure that there will be no compromise.
The BU side thinks that the Segwit side are idiots, and the Segwit side knows that the BU side are idiots.
There is no compromise

[Sundark]

We can say for sure that anything SegWit related is no longer gonna be accepted. Anti SegWit movement is too strong.
Naysayers will just conclude that this compromise is a simply backdoor for SegWit and 2MB blocks is just smoke and mirrors.

[AgentofCoin]

Unfortunately, I think we are about to head into the next evolution of Bitcoin
blockchain theory, in which what will occur has not really happened before
and we will learn new lessons about how Bitcoin truly functions.

Some will lose greatly and others will win, but the current community and
economy will suffer as a whole. When certain actors are no longer properly
incentivized, they will split the single chain premise because you can. For
someone to take such a risk with confidence, it is either clairvoyance or
absolute madness.

This is mostly due to communication failures, misunderstandings, ideologies,
and egos. Compromises are likely over. Now is the quiet before the storm.

If something doesn't happen soon, all out war will begin.
But, maybe that is the only answer to this question, sadly.

Extremism is malicious, within a Consensus system.

[-ck]

Code them up together, but allow each component to be activated *separately* thus allowing clients to choose which component they wish to support... I suspect support for BIP102 will be a lot higher now (yes I know about quadratic scaling issue.)

[AngryDwarf]

Is it not the case that segwit coded as a hard fork would mean that all UTXO's can be spent with segwit? No stupid network topology introduced like with the soft fork mechanism? If so, then yes I think it would be accepted, unless someone things there are reasons why it would be a bad idea. Although my worry then would be that we would be fighting for the next capacity hard fork with no leverage.

[hv_]

Given that dev fraction ( blockstream core) solution  SW looks rejected by miner fraction, compromise should be proposed from second fraction, not first one again.

And we might need a third, merchants?, to moderate in case.

[AgentofCoin]

Is it not the case that segwit coded as a hard fork would mean that all UTXO's can be spent with segwit? No stupid network topology introduced like with the soft fork mechanism? If so, then yes I think it would be accepted, unless ...

Given that dev fraction ( blockstream core) solution  SW looks rejected by miner fraction, compromise should be proposed from second fraction, not first one again.
And we might need a third, merchants?, to moderate in case.

The issue here is that if BU community and BU devs are not willing to cap the blocksize
or cap the blockweight, then there can never be compromise. They will fork eventually
since they are extremists. They are not looking out for the future, only themselves now,
in the most perfect form of greed. The greed that kills the golden goose, which is the most
stupid of all greeds.

 - BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization).
This is to bring about a more currency like device now, instead of later.
They do not mind network centralization or do deny/ignore its possibility of occurrence.

 - CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization).
This is to maintain the unregulatibility and other like aspects now and later.
They do not mind slowed user growth or high fees or do deny/ignore their possible impacts.

They are fundamentally opposed. Like a couple that has different interests now and changed over time.
The normal situation would be that the couple would break up and each do their own thing.

If a compromise can be reached, it will be either full capitulation or a masterful answer still unknown.

[AngryDwarf]

BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization).
CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization).

Bigger blocks tend toward network centralisation, but decentralises the user base (more people can afford to send bitcoin).
Small blocks allow greater network decentralisation, but centralises the user base (only a few big actors can afford to send bitcoin).

How decentralised is LN?

It would seem the former of these two options was envisiged by the creator at the time. Nodes centralising around well connected mining nodes and bitcoin service providers, and users using SPV wallets.

[AgentofCoin]

BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization).
CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization).

...
How decentralised is LN?

I am not qualified to answer.
In theory, if designed and implemented appropriately, equal to Bitcoin's.

It would seem the former of these two options was envisiged by the creator at the time. Nodes centralising around well connected mining nodes and bitcoin service providers, and users using SPV wallets.

Yes, but there is one problem that is a constant misunderstanding in the
whole Bitcoin community.

When this belief was stated by Satoshi, Nodes were a single entity.
The miners were validators and the validators were miners.
There was only one. Now, there are two separate systems.

Due to these two separate systems, there are two possible choices now.
Satoshi's original comments (as to Nodes) no longer apply to today's reality.

[tbonetony]

yes I like this idea. If this can be a configuration choice for node operator to vote, that would be even better.

Forget about BU and BC, we need Bitcoin United

[Swimmer63]

I am not technically qualified to comment in detail.  But I am very much for compromise and 2MB with Segwit is an excellent place to start.  Let's see who is serious about moving btc ahead. 

[AngryDwarf]

It would seem the former of these two options was envisiged by the creator at the time. Nodes centralising around well connected mining nodes and bitcoin service providers, and users using SPV wallets.

Yes, but there is one problem that is a constant misunderstanding in the
whole Bitcoin community.

When this belief was stated by Satoshi, Nodes were a single entity.
The miners were validators and the validators were miners.
There was only one. Now, there are two separate systems.

Due to these two separate systems, there are two possible choices now.
Satoshi's original comments (as to Nodes) no longer apply to today's reality.

I don't think the fact that not all nodes are mining nodes changes the fundamental premise. In fact it strengthens it as there are more validation nodes.

[franky1]

BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization 1).
CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization 2).

1 Bigger blocks tend toward network centralisation,
3 but decentralises the user base (more people can afford to send bitcoin).

2 Small blocks allow greater network decentralisation,
4 but centralises the user base (only a few big actors can afford to send bitcoin).

your putting words into people mouths.

1. Bu/bigblockers dont want one brand running anything... most bu/bigblockers are happy with bitcoinj, xt, classic, btcd, etc all running on the same level playing field all using real consensus to come to agreement.. and if core got rid of blockstream corporation. would be happy with core too.(main gripe is blockstreams centralist control)

2. small blockers have shown distaste for anything not blockstream inspired/funded..  (rekt campains agains bitcoinj, xt, classic and bu)

3. correct(people keep funds on thier personal privkeys and use future LN services voluntarily)

4. correct(people move funds to new keys and multisigs where payments need an LN counter party signing. but done forcefully due to politics/fee war games)

[BitUsher]

Changing MAX_BLOCK_SIZE to 2MB + segwit literally means we will see 4-8MB blocks.

No thanks ,

I don't care is this HF proposal comes from core or another repo , I will reject it and stay on the original chain. Developers have no power over what software I choose to run .

4-8MB blocks is too big and I am only interested in HF that include many HF wishlist items and permanently solve the scaling problem instead of kicking the can down the road a few months.


Here are some academic papers that reflect how dangerous blocks over 4MB currently are and one reason why segwit limits blocksizes to 4MB max.

http://bitfury.com/content/5-white-papers-research/block-size-1.1.1.pdf

http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf

This is a dangerous precedent giving control to miners or developers without community consensus. Hard forks should be a matter of last resort and when a SF is on the table that offers the same essential blocksize increase as classic we should be greatful and take it instead.

There is significant moral hazard and social hazard in forcing a HF on the community and how that will make us all insecure in the future. If the Developers or miners are viewed as a group that is perceived they can change the protocol without overwhelming consensus of the bitcoin users than they can easily be manipulated and attacked by bad actors like states and others.

There will guarantee be a split where 2-3 coins exist for one thing which will cause short term havoc due to uncertainty, loss of immutability , breaking the 21 million limit promise, moral hazard , social hazard, ect...(Remember Bitcoin is actually used for things unlike Ethereum which is 100% speculation, thus a split is far more damaging to bitcoin)

The ETF follows the most worked chain only, thus if the miners are swayed back to the originally chain after many of us dump our split coins all those ETF investors lose their investment value.

4-8MB blocks will lead to centralization, increase miner and node centralization and force me to shutdown my personal node.

[AgentofCoin]

It would seem the former of these two options was envisiged by the creator at the time. Nodes centralising around well connected mining nodes and bitcoin service providers, and users using SPV wallets.

Yes, but there is one problem that is a constant misunderstanding in the
whole Bitcoin community.

When this belief was stated by Satoshi, Nodes were a single entity.
The miners were validators and the validators were miners.
There was only one. Now, there are two separate systems.

Due to these two separate systems, there are two possible choices now.
Satoshi's original comments (as to Nodes) no longer apply to today's reality.

I don't think the fact that not all nodes are mining nodes changes the fundamental premise. In fact it strengthens it as there are more validation nodes.

No, you missed my point. I thought it was more evident.
Non-mining nodes are not incentivized the way Miners Nodes are.

The point being:
both can have opposite votes now (two sides), instead of the vote
always tending toward the same incentivized choice by Hardfork.
Now there are more possibilities such as Softforks. (User activated
fork is now another one, but is a new theory which is riskier than
either soft or hard.)

All I'm saying is when you cite Satoshi about Nodes, it was before
the Node split and is entirely in a different context that no longer
exists.

[AngryDwarf]

I don't think the fact that not all nodes are mining nodes changes the fundamental premise. In fact it strengthens it as there are more validation nodes.

No, you missed my point. I thought it was more evident.
Non-mining nodes are not incentivized the way Miners Nodes are.

The point being:
both can have opposite votes now (two sides), instead of the vote
always tending toward the same incentivized choice by Hardfork.
Now there are more possibilities such as Softforks. (User activated
fork is now another one, but is a new theory which is riskier than
either soft or hard.)

All I'm saying is when you cite Satoshi about Nodes, it was before
the Node split and is entirely in a different context that no longer
exists.

But non mining nodes are the majority of the network. Miners have to produce blocks that follow the network consensus or they get orphaned. Hard fork consensus means nodes update first, miners follow.

[AgentofCoin]

I don't think the fact that not all nodes are mining nodes changes the fundamental premise. In fact it strengthens it as there are more validation nodes.

No, you missed my point. I thought it was more evident.
Non-mining nodes are not incentivized the way Miners Nodes are.

The point being:
both can have opposite votes now (two sides), instead of the vote
always tending toward the same incentivized choice by Hardfork.
Now there are more possibilities such as Softforks. (User activated
fork is now another one, but is a new theory which is riskier than
either soft or hard.)

All I'm saying is when you cite Satoshi about Nodes, it was before
the Node split and is entirely in a different context that no longer
exists.

But non mining nodes are the majority of the network. Miners have to produce blocks that follow the network consensus or they get orphaned. Hard fork consensus means nodes update first, miners follow.

That doesn't matter. Miners can fork away without node validators
and the minority hash chain's difficultly will be too high (and may not
adjust in time to prevent possible failure). Meanwhile the Miner nodes
are on a new chain, mining & semi validating away. The minority hash
chain, could in short time, have no hash at all, in theory.

Your statement only applies if there is no malicious forking.
When the two node systems split, this possibility came into existence.
Prior to this, they always moved as one, since there was only one.