Topic: Segwit2MB vs ? (Read 1487 times)

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

What?

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.

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

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???

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.

 
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.

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.

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.

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?

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.

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.

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.

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

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
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.

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

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.

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.

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

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.

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

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.

Proof?


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

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.

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.

Then I took a look at some of proposals listed here, and found for example this:
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.