An idea for a compromise on the scaling debate.

[tobacco123]

There are already so many different proposal for scaling and we now left with two condidates: Segwit and BU... Both are not perfect and have pros and cons. I guess we do not need more proposals...

[1715013349]

1715013349

[1715013349]

1715013349

[1715013349]

1715013349

[1715013349]

1715013349

[1715013349]

1715013349

[Vaskiy]

There is no need for an compromise in the scaling debate. Already the support for core is quite good with a limitation in block size increase to the maximum of 32MB. This has been made in mutual understanding with different support communities of bitcoin and popular exchange platforms.

[Xester]

real funny part

core use the quadratics scare as a reason not to do it..
here is the thing.

a tx with ~4000 sigops. take 10 seconds
a tx with >20000 sigops takes 10 minutes.
https://rusty.ozlabs.org/?p=522

This Block Isn’t The Worst Case (For An Optimized Implementation)

As I said above, the amount we have to hash is about 6k; if a transaction has larger outputs, that number changes.  We can fit in fewer inputs though.  A simple simulation shows the worst case for 1MB transaction has 3300 inputs, and 406000 byte output(s): simply doing the hashing for input signatures takes about 10.9 seconds.  That’s only about two or three times faster than the bitcoind naive implementation.

This problem is far worse if blocks were 8MB: an 8MB transaction with 22,500 inputs and 3.95MB of outputs takes over 11 minutes to hash.  If you can mine one of those, you can keep competitors off your heels forever, and own the bitcoin network… Well, probably not.  But there’d be a lot of emergency patching, forking and screaming…

now the funny part
core v0.12 maxtxsigops 4000
core v0.14 maxtxsigops 16000
... (facepalm)


easy fix
consensus.h maxblockhardlimit= 8000000 bytes
policy.h (dynamic adjustable preference) maxblocksoftlimit=2000000bytes
maxtxsigops 2000sigops

What a nice observation you have there. But of course we all know that all developers and owners of codes will dig its way towards having a monopoly or control over the production of bitcoin. Bitcoin means profit and thats why the groups are always on the run to win the big race. But if we look back at Satoshis statements we dont really need some upgrading on the blocksize and scaling since he programmed bitcoin to cope up and can match the huge traffic on todays  blockchain transactions.

[franky1]

There are already so many different proposal for scaling and we now left with two condidates: Segwit and BU... Both are not perfect and have pros and cons. I guess we do not need more proposals...

dynamic concepts can work together.
EG bitcoinEC is acceptable to BU, classic, and many other implementations.
EG BU is acceptable to bitcoinEC, classic, and many other implementations.

even fixed base block increases can work together
EG classic is acceptable to bitcoinEC, BU and many other implementations.

its only core that is holding back.
lastly if its only about the "team" then making another implementation with the core devs who really are independent and not under the blockstream thumb solves that..
.. but hey we wont see that because core are dependant on blockstream management, not independent.

anytime any independent core dev actually shows independence, a REKT campaign follows them

[freedomno1]

There are already so many different proposal for scaling and we now left with two condidates: Segwit and BU... Both are not perfect and have pros and cons. I guess we do not need more proposals...

Well its not like we ever did do a Bitcoin Idol and get to vote for the best Bitcoin update of them all, rather we were presented with two candidates each with flaws one speaking for stability, one wishing to explore a new path.
Either way blockchain compression faction plus a size increase for now.

But those curtains faded to black a long while ago... along with discussion of searching for low reaching fruit.
https://bitcointalk.org/index.php?topic=88208.0
https://bitcointalk.org/index.php?topic=204283.0

Now all that is left on the stage is A and B choose.

[andrew24p]

What if the Core developers make a compromise of having dynamic block sizes but with a limit of up to 4mb and have Segwit activated at the same time? I am sure there would be a need for a block size increase both with and without an off chain transaction layer.

Core does not want to hard fork period. This idea has been proposed before and shut down by them.

[Wind_FURY]

There are already so many different proposal for scaling and we now left with two condidates: Segwit and BU... Both are not perfect and have pros and cons. I guess we do not need more proposals...

Or maybe we need none if it breaks the community apart. There is also the question that asks "Do we really need to upgrade the Bitcoin network by activating Segwit or hard fork to Bitcoin Unlimited?"

Are they really necessary for Bitcoin to work properly? Before the scaling debate we have not seen any problem until someone started spamming the network to create a sense of urgency for an upgrade.