Topic: An idea for a compromise on the scaling debate. (Read 1771 times)

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.

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

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://bitcointalksearch.org/topic/ultimate-blockchain-compression-w-trust-free-lite-nodes-88208
https://bitcointalksearch.org/topic/fundraising-finish-ultimate-blockchain-compression-204283

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

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

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.

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.

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

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

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

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


learn the word fungibility

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

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"

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.

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

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

No.

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.

Another lie. Are you delusional by any chance?

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




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

False. It is very much important.

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

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

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

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

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

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

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.

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.

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.

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"
 

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

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