An idea for a compromise on the scaling debate.

[Wind_FURY]

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.

[1713495354]

1713495354

[1713495354]

1713495354

[1713495354]

1713495354

[1713495354]

1713495354

[Iranus]

Unfortunately Core are not particularly willing to compromise.  Their stubbornness is really not helping us move forward, they just need to make some meaningless promises and then even if mining monopolies don't budge, huge numbers of supporters will flock to Core so that there doesn't need to be a fork, and that'll be enough to force those monopolies to eventually move over and let Bitcoin move on.

[JanpriX]

I believe the problem right now is not the technicalities of scaling debate but the "political" aspect of it. The scaling debate that started few years ago just became a pissing contest and all the sides are not open for any compromises. They just insist that only one side should win and prevail. They will not meet halfway to come up with a more sustainable solution for the community.

[aarturka]

SegWit is already a compromise. But Wu and Ver don't want any compromise they just want to take over Bitcoin

[d5000]

That proposal is similar to what some of us have discussed in the following thread: https://bitcointalk.org/index.php?topic=1817272.0, particularly from here on. It would take the mechanism of BIP 100 but add a "upper limit" for security reasons.

Ideally this limit could move based on internet bandwidth/performance tests. Nielsens Law of Bandwidth has also been proposed as a base for the upper limit, but I think it's too optimistic because the upstream bandwidth growth is slower.

[naughty1]

Segwit has been compromised a lot of times, it's a big topic of public interest, however, the rate required for segwit to occur is too high, so it is difficult and almost impossible. success. Segwit was given many times, but it never won. Bitcoins are very powerful, so they claim that segwit is not necessary. LTC is a weaker currency, so people are aiming for it, and segwit is the way it grows, and they are so stingy, 75% is a reasonable percentage.

[1Referee]

Wu and Ver don't want any compromise they just want to take over Bitcoin

That's a likely thought. I couldn't stop laughing at the time I read a tweet stating the following; Bitcoin Unlimited team on a China tour trying to convince economic majority that economic majority doesn't matter. Next step will be rebranding Bitcoin into RojiCoin, and the "whole" BU crew can sleep well after a cup of hot milk.

Cool dude and worthy of being followed; https://twitter.com/excellion

[franky1]

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

[jonald_fyookball]

SegWit is already a compromise.

lol good one.

Compromise between what? 

People that actually want to scale bitcoin (like the plan was the whole time)
vs people that want to force everyone off the main chain?

"Yeah we won't let you increase the blocksize but we'll
give you this kludge that doesn't even double
the capacity and makes it harder to scale in the future"
 

[Dorky]

Clif High's previous webbot report predicted about China adopting Bitcoin as some sort of national currency.
I wonder if it has anything to do with the post-fork.

[Variogam]

What if the Core developers make a compromise of having dynamic block sizes

If it happens then the market choose the best solution. For now emergent consensus is the best onchain scaling solution with about 50% of miners already using it. I guess it is going to be hard to come with something beter than emergent consensus though.

[Wind_FURY]

I would also like to point out that I made this thread because I am now thinking the pros of Segwit is to fix some issues in Bitcoin like the malleability issue and others that would make it more robust and secure. The scaling part, I could now see some pros in Bitcoin Unlimited's dynamic block sizes but only up to a fixed point. If it is 3, 4 or 5 megabytes, I do not know. That is another argument for another day.

[Lauda]

Segwit is the compromise. A lot of people fail to understand this. The claims that Segwit is "too little, too late" et. al. are complete nonsense. There is no data backing up the need for 2x TX capacity or more right here right now.

Compromise between what? 

People that actually want to scale bitcoin (like the plan was the whole time)
vs people that want to force everyone off the main chain?

Compromise for increasing on-chain TPS. Correction: People who actually want Bitcoin to become Paypal 2.0 (e.g. you, Roger Ver, Andrew Stone, Peter R. Charlatan) vs. people who want a robust, decentralized and uncensored network.

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?

So what are you saying, 4 MB base and 16 MB weight? Good luck with that- 

[franky1]

Segwit is the compromise. A lot of people fail to understand this. The claims that Segwit is "too little, too late" et. al. are complete nonsense. There is no data backing up the need for 2x TX capacity or more right here right now.

Compromise between what?  

People that actually want to scale bitcoin (like the plan was the whole time)
vs people that want to force everyone off the main chain?

Compromise for increasing on-chain TPS. Correction: People who actually want Bitcoin to become Paypal 2.0 (e.g. you, Roger Ver, Andrew Stone, Peter R. Charlatan) vs. people who want a robust, decentralized and uncensored network.

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?

So what are you saying, 4 MB base and 16 MB weight? Good luck with that-  

seriously lauda

the "weight" is meaningless.

its there only for the segwit wannabe's not the native transaction users
the funny part is core have made it 4x more generous to SPAMMERs to spam the 1mb base. but done NOTHING to fix the spam.

the only people that will use segwit are those that want to disarm themselves. but then they will realise they are fighting spammers who have more attack vectors to exploit and also their own volunteers trying to move 40+mill outputs just for the HOPE of ~2mb.

WAKE THE HELL UP!!!!
its been a year and you have yet to show you have learned a damned thing

[Lauda]

the "weight" is meaningless.

False. It is very much important.

its there only for the segwit wannabe's not the native transaction users
the funny part is core have made it 4x more generous to SPAMMERs to spam the 1mb base. but done NOTHING to fix the spam.

You can't fix spam, at least not in the sense that you're trying to refer to it.

the only people that will use segwit are those that want to disarm themselves. but then they will realise they are fighting spammers who have more attack vectors to exploit and also their own volunteers trying to move 40+mill outouts just for the HOPE of 2mb.

As I've told you earlier, miners can easily prioritize Segwit transactions over the standards ones.

WAKE THE HELL UP!!!!
its been a year and you have yet to show you have learned a damned thing

I am not the one who needs waking up. Your understanding of Bitcoin is severely flawed, almost at an level that is irreparable.

[franky1]

the "weight" is meaningless.

False. It is very much important.

even you grabbed some "hopeful" maths from your clan claiming 2.1mb is the hopeful expectation
meaning the 4mb weight is meaningless number to quote.
yes its a number thats wrote in code. but its utility is in question

I am not the one who needs waking up. Your understanding of Bitcoin is severely flawed, almost at an level that is irreparable.

you have admitted you cant read c++
you have admitted your attention span cant go beyond a few paragraphs

many many times i have SHOWN you quotes from your own clan leaders who have shown how things actually work. and i have even highlighted parts of links which you fail to read beyond the first few paragraphs to grasp the whole thing.

you love the 30 second sales pitches but you do not do the research to understand the reality beyond the sales pitch.

you have had so much time to grasp it.

i am really laughing though.
if you think that pools are going to:
1. stop accepting native tx's
2. only accept segwit tx's

your only fooling yourself because the flaws in your utopia are:
1. everyones funds are on native keys now. so stopping the acceptance of native key use is literally killing fungibility and also making the 16mill coins on 46mill native utxo's useless and unspendable
2. the fee is less with segwit. and also it adds more processing time of having to create the 2 area blocks and then having to strip the 2 area blocks into 1 to filter down to native implementations. thus not giving pools any advantage to only accepting segwit tx's.

oh and do you think spam cannot happen using segwit keys. it can. even carlton realises this

[Lauda]

you have admitted you cant read c++

How much C++ have you contributed to Bitcoin? Oh yeah, zero.

you have admitted your attention span cant go beyond a few paragraphs

This is a lie. I have stated that I do not want to read your mumbo jumbo walls of text riddled with false information.

many many times i have SHOWN you quotes from your own clan leaders who have shown how things actually work. and i have even highlighted parts of links which you fail to read beyond the first few paragraphs to grasp the whole thing.

No.

your only fooling yourself because the flaws in your utopia are:
1. everyones funds are on native keys now. so stopping the acceptance of native key use is literally killing fungibility and also making the 16mill coins on 46mill native utxo's useless and unspendable
2. the fee is less with segwit. and also it adds more processing time of having to create the 2 area blocks and then having to strip the 2 area blocks into 1 to filter down to native implementations. thus not giving pools any advantage to only accepting segwit tx's.

There is a difference between native -> native, native -> Segwit, Segwit -> Segwit. This you would know if you, if you understood Bitcoin, but you don't (or are paid not to). Prioritizing one thing != stop accepting the other one.

oh and do you think spam cannot happen using segwit keys. it can. even carlton realises this

Another lie. Are you delusional by any chance?

[freedomno1]

It just leads to more debate unless someone decides to run the new client, although if someone coded a supported implementation that would be good.

[Amph]

i was always for dynamic block, but it seems that the core dev don't want anything that force an hard fork, in fact they decided later against the original plan to hard fork anyway to 2mb + segwit

dynamic block would have been a better solution if no bad impact were found with this way to scale bitcoin, maybe they tested and see that there were bad workaround, or bad result

a dynamic block should have worked simple like, "if the network need x MB of limit you give it only that limit for just the time the network need it"

[franky1]

you have admitted you cant read c++

How much C++ have you contributed to Bitcoin? Oh yeah, zero.

more then you think and can ever know. compared to your spell check just for name glory sake.

you have admitted your attention span cant go beyond a few paragraphs

This is a lie. I have stated that I do not want to read your mumbo jumbo walls of text riddled with false information.

lol goodluck in life. you would do well in a career at fox news

many many times i have SHOWN you quotes from your own clan leaders who have shown how things actually work. and i have even highlighted parts of links which you fail to read beyond the first few paragraphs to grasp the whole thing.

No.

yep the segwit users guide. you only read it partially.

your only fooling yourself because the flaws in your utopia are:
1. everyones funds are on native keys now. so stopping the acceptance of native key use is literally killing fungibility and also making the 16mill coins on 46mill native utxo's useless and unspendable
2. the fee is less with segwit. and also it adds more processing time of having to create the 2 area blocks and then having to strip the 2 area blocks into 1 to filter down to native implementations. thus not giving pools any advantage to only accepting segwit tx's.

There is a difference between native -> native, native -> Segwit, Segwit -> Segwit. This you would know if you, if you understood Bitcoin, but you don't (or are paid not to). Prioritizing one thing != stop accepting the other one.

learn the word fungibility

lauda spend less time sucking up, and more time researching. learning.