Segwit2MB vs ?

[stdset]

Recently I took a look at bitcoin-dev mailing list, mostly to check reaction for Sergio Lerner's Segwit2MB proposal. The reaction was mostly negative.

Hey Sergio,

You appear to have ignored the last two years of Bitcoin hardfork
research and understanding, recycling instead BIP 102 from 2015. There
are many proposals which have pushed the state of hard fork research
much further since then, and you may wish to read some of the posts on
this mailing list listed at https://bitcoinhardforkresearch.github.io/
and make further edits based on what you learn.

Then I took a look at some of proposals listed here, and found for example this:

It implements a series of block size steps, one every ~97 days, and ending at just under 31 MB in 2045 April, with each step increasing the maximum block size by 4.4%, allowing an overall growth of 17.7% per year. The initial size limit upon activation depends on when it is activated: for example, if in 2018 January, it would begin at ~356k; or if in 2024 June, it would begin at just over 1 MB.

So my question is: which blocksize related hardfork proposal has most support from core developers?
Also, I would like to remind that some of miners who are currently blocking segwit, explicitly stated, that they won't run segwit without blocksize increase.

[1713538840]

1713538840

[1713538840]

1713538840

[1713538840]

1713538840

[Qartada]

So my question is: which blocksize related hardfork proposal has most support from core developers?
Also, I would like to remind that some of miners who are currently blocking segwit, explicitly stated, that they won't run segwit without blocksize increase.

They're mainly saying that as a way of exploiting the Core team for being stubborn.  They explicitly state that they won't run SegWit without a blocksize increase because they never expect Core to actually cave in and do a hard fork so they can get away with taking a moral high ground.

Obviously no blocksize related hardfork proposal has support from Core devs, otherwise they wouldn't have written SegWit, they'd have written a blocksize related hardfork proposal.

[stdset]

They explicitly state that they won't run SegWit without a blocksize increase because they never expect Core to actually cave in and do a hard fork so they can get away with taking a moral

Proof?

Obviously no blocksize related hardfork proposal has support from Core devs, otherwise they wouldn't have written SegWit, they'd have written a blocksize related hardfork proposal.

Segwit and blocksize increase aren't mutually exclusive. In Feb 2016 they signed this:

We understand that SegWit continues to be developed actively as a soft-fork and is likely to proceed towards release over the next two months, as originally scheduled.

We will continue to work with the entire Bitcoin protocol development community to develop, in public, a safe hard-fork based on the improvements in SegWit. The Bitcoin Core contributors present at the Bitcoin Roundtable will have an implementation of such a hard-fork available as a recommendation to Bitcoin Core within three months after the release of SegWit.

This hard-fork is expected to include features which are currently being discussed within technical communities, including an increase in the non-witness data to be around 2 MB, with the total size no more than 4 MB, and will only be adopted with broad support across the entire Bitcoin community.

We will run a SegWit release in production by the time such a hard-fork is released in a version of Bitcoin Core.

We will only run Bitcoin Core-compatible consensus systems, eventually containing both SegWit and the hard-fork, in production, for the foreseeable future.

We are committed to scaling technologies which use block space more efficiently, such as Schnorr multisig.

[achow101]

There are currently no hard fork proposals being seriously considered by the Core devs. All of the things listed on https://bitcoinhardforkresearch.github.io/ are still in research, theoretical, and may not be accepted and implemented. None have BIP numbers either so they won't be actually considered for implementation and deployment until they get a BIP number.

[stdset]

There are currently no hard fork proposals being seriously considered by the Core devs. All of the things listed on https://bitcoinhardforkresearch.github.io/ are still in research, theoretical, and may not be accepted and implemented. None have BIP numbers either so they won't be actually considered for implementation and deployment until they get a BIP number.

I'm not surprised. So it looks like Segwit2MB is the only proposal up to now, fulfilling the Hong Kong agreement from devs side.

[achow101]

I'm not surprised. So it looks like Segwit2MB is the only proposal up to now, fulfilling the Hong Kong agreement from devs side.

Actually it is not. Luke-jr's proposals are actually the ones that fullfil that aspect of the agreement. Firstly, the group "core devs" did not agree to anything, nor were they represented at that meeting. Rather a couple people who frequently contribute to Core (including luke-jr) were there and those people agreed to propose a hard for proposal which they could recommend. But that does not mean that that proposal would be implemented or accepted by the rest of the Core devs. Luke-jr fulfilled that part of the agreement; he made a hard fork proposal which he could recommend to Core, but the rest of the Core devs did not really like it, so it was dropped.

IIRC Sergio has never contributed to Core not was he at the Hong Kong meeting.

[stdset]

Luke-jr fulfilled that part of the agreement; he made a hard fork proposal which he could recommend to Core, but the rest of the Core devs did not really like it, so it was dropped.

What proposal are you talking about? The one which proposes to shrink blocks to ~300kB or to keep them at 1MB for 7 years?

Firstly, the group "core devs" did not agree to anything, nor were they represented at that meeting.

OK, I understand, core devs are numerous. It's nearly impossible even to gather all of them in one meeing. So how one could negotiate with them? Saying that they were not represented at the meeting is an excuse for doing nothing. I'd say that there were enough influential, prominent devs there to properly represent their party and make the agreement meaningful.

But that does not mean that that proposal would be implemented or accepted

OK, if we read the agreement carefully, it's not very binding. Core contributors present at the meeting must only recommend a hardfork. And miners must run segwit in production only after hardfork is released in a version of Bitcoin Core. But we all know what both parties want: one party wants segwit, another party wants capacity of about 2MB for non-witness data. And I personally think, that it's far better to try come to already specified compromise than to do something potentially destructive such as UASF or to do nothing engage in trolling while observing how Bitcoin looses it's leadership, network effect, etc. And if something like Segwit2MB is released and miners still don't adopt it (what I doubt), then we can lay the blame on them and start preparing for a UASF of some kind.

IIRC Sergio has never contributed to Core not was he at the Hong Kong meeting.

But currently he's apparently the only one among segwit supporters who tries to resolve the conflict in conformity with the agreement.

[achow101]

What proposal are you talking about? The one which proposes to shrink blocks to ~300kB or to keep them at 1MB for 7 years?

Yes, that one. It does more than that as it actually grows on a fixed schedule.

OK, I understand, core devs are numerous. It's nearly impossible even to gather all of them in one meeing. So how one could negotiate with them? Saying that they were not represented at the meeting is an excuse for doing nothing. I'd say that there were enough influential, prominent devs there to properly represent their party and make the agreement meaningful.

No. The Core devs at that meeting did not represent Core. As I understand it, they made it very clear at the meeting that they only represent themselves as contributors, not representatives of the project itself.  Furthermore the only statement binding them to do something hard fork related is

The Bitcoin Core contributors present at the Bitcoin Roundtable will have an implementation of such a hard-fork available as a recommendation to Bitcoin Core within three months after the release of SegWit.

Notice how it does not say that the Bitcoin Core project will adopt said proposal, only that the contributors present will make such a proposal which they can recommend to Core.

But currently he's apparently the only one among segwit supporters who tries to resolve the conflict in conformity with the agreement.

His proposal is not in conformity with the agreement. It came way past the deadline (luke-jr's came before the 3 month deadline), he was not at the meeting so his proposal does not count, and his proposal is not recommended by the Bitcoin Core contributors present at the meeting.

Anyways, the Hong Kong agreement is really not in effect and not binding anyways so this is pointless to argue. Technically all parties upheld their parts of the agreement due to the vagueness and loose wording of it.

[stdset]

What proposal are you talking about? The one which proposes to shrink blocks to ~300kB or to keep them at 1MB for 7 years?

Yes, that one. It does more than that as it actually grows on a fixed schedule.

I guess Luke likes to shock others, he himself couldn't seriously expect such proposal to be accepted. Nowhere in the agreement it is stated when actual blocksize increase must happen. He exploited this uncertainty to pervert the meaning just for lulz. If we are playing such games, soon we will need teams of lawyers and our agreements will become tens of pages in thickness.
On the other hand Sergio's proposal follows the spirit of the agreement. It is simple, honest, it gives each side what they want.

[achow101]

I guess Luke likes to shock others, he himself couldn't seriously expect such proposal to be accepted. Nowhere in the agreement it is stated when actual blocksize increase must happen. He exploited this uncertainty to pervert the meaning just for lulz. If we are playing such games, soon we will need teams of lawyers and our agreements will become tens of pages in thickness.

He did not just "exploited this uncertainty to pervert the meaning just for lulz". If you have read any of what Luke-Jr has said about block sizes and capacity, he genuinely believes that the block size is currently too large because it is difficult to start running a new full node. It is also becoming unsustainable to continue to run a full node since it costs so much in bandwidth, processing power, RAM, and disk space. It wasn't proposed "just for lulz" or to troll anyone but rather because Luke-Jr genuinely thinks that decreasing the block size would help Bitcoin by allowing more people to run full nodes.

On the other hand Sergio's proposal follows the spirit of the agreement. It is simple, honest, it gives each side what they want.

It does not give both sides what they want. Many who support segwit clearly don't support the proposal. A lot of that is because they think that having a 2 MB base block size is too large (that means that witness block sizes can go up to 8 MB). Furthermore, that still allows a 2 MB legacy transaction which takes a long time to validate due to the quadratic sighashing issue. Additionally, since it is a hard fork, there are a number of other things that should be included into it as we don't want to have multiple hard forks but rather one with everything that we want that needs hard forking. Segwit2MB does not address that.

[stdset]

He did not just "exploited this uncertainty to pervert the meaning just for lulz". If you have read any of what Luke-Jr has said about block sizes and capacity, he genuinely believes that the block size is currently too large because it is difficult to start running a new full node. It is also becoming unsustainable to continue to run a full node since it costs so much in bandwidth, processing power, RAM, and disk space. It wasn't proposed "just for lulz" or to troll anyone but rather because Luke-Jr genuinely thinks that decreasing the block size would help Bitcoin by allowing more people to run full nodes.

I'm aware of his position, but we also know that Luke is certainly familiar with current situation, and proposing something that has no even remote chance of being accepted, especially in the context of fulfilling such important, unique in it's kind agreement is for lulz at best. How big blockers should perceive this? They thought they are dealing with serious people and got such mockery instead.

A lot of that is because they think that having a 2 MB base block size is too large (that means that witness block sizes can go up to 8 MB).

Big blockers want 2MB base size. If we think that 8MB max total size is too much, it's possible to adjust parameters to decrease it to 4MB according to the agreement.

Additionally, since it is a hard fork, there are a number of other things that should be included into it as we don't want to have multiple hard forks but rather one with everything that we want that needs hard forking. Segwit2MB does not address that.

Then help Sergio to integrate all desired improvements. Announce that we are working on a hardfork which includes increasing base blockse to 2MB and a number of other improvements. Apologize for being late with that.

What do we want? To prove to our opponents that our point of view is the only right one? Or to finally scale?

[jonald_fyookball]

What do we want? To prove to our opponents that our point of view is the only right one? Or to finally scale?

 
Those that can see that 'the Emperor wears no clothes' can tell you that Core clearly does not want to scale.  Otherwise they wouldn't be stalling for years, offering convoluted solutions to simple programs, breaking agreements and refusing to compromise.

At this point, it is obvious Segwit will almost certainly not get the 95% it needs for activation.  Rather than accept 2MB+segwit, they will do more stalling.  UASF in some different BIP maybe.

[Carlton Banks]

What do we want? To prove to our opponents that our point of view is the only right one? Or to finally scale?

 
Those that can see that 'the Emperor wears no clothes' can tell you that Core clearly does not want to scale.  Otherwise they wouldn't be stalling for years, offering convoluted solutions to simple programs, breaking agreements and refusing to compromise.

This is all entirely in contradiction to actual reality.


Core's Segwit solution is the only genuine proposal that involves changing the scale of the Bitcoin blockchain's resource usage. Every other proposal that advertises itself as "scaling" maintains the scale of resource usage as it exists with the current paradigm, including the (3? 4?) various non-scaling solutions you've endorsed in the past few years jonald.

Interesting how you never shut up about scaling, and yet always (and relentlessly) suggest false scaling proposals.


The charge that Segwit is a "convoluted solution to a simple program" is also pretty dubious; not only is Bitcoin itself a fairly complicated concept already, but Segwit is actually a pretty simple change to the complicated original, i.e. the perfect opposite of what you're saying.


And lastly, I think we can all agree that increasing from 1MB to 4MB is a pretty compromising proposal. I don't want 4MB, and yet I support Segwit. Because I'm willing to compromise.

[italianMiner72]

hi all..
i have a simple questio about the fork scenatio.
Now, I have my 10 BTC in my wallet... Core-Wallet exactly.
Tomorrow morning i wake up and i read about fork...
if i understand well, i will find 10btc in all two chain.
The newone and the oldone???

[mda]

hi all..
i have a simple questio about the fork scenatio.
Now, I have my 10 BTC in my wallet... Core-Wallet exactly.
Tomorrow morning i wake up and i read about fork...
if i understand well, i will find 10btc in all two chain.
The newone and the oldone???

Yes, just don't make any transactions until replay attack vector is blocked.

[mda]

It seems that everybody has a preferred block size - from 300KB to 8MB.
I will give it a try too and will use your thread for this if you don't mind.
For bitcoin to function properly an average guy needs to verify real time transactions.
From http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/vni-hyperconnectivity-wp.html an average household has consumed 49GB per month in 2016.
However all that traffic can't be spent only on bitcoin, let's say 25% will be enough.
So here is my preferred block size for 2016: 49GB * 25% / 30.5 / 24 / 6 = 2.8MB.

[Bitcollector]

hi all..
i have a simple questio about the fork scenatio.
Now, I have my 10 BTC in my wallet... Core-Wallet exactly.
Tomorrow morning i wake up and i read about fork...
if i understand well, i will find 10btc in all two chain.
The newone and the oldone???

Yes, just don't make any transactions until replay attack vector is blocked.

What?

[USBitcoinServices.Com]

If all goes well at Litecoin, then Segwit will be implemented as well at other coins. They are just waiting to see how Litecoin handles it. Thus the price of Litecoin is rising these days