SegWit vs Bitcoin unlimited

[DooMAD]

The biggest difference is: who controls the Core project, and who controls the Unlimited source code. That's what the whole fight is about, who controls the reference code.

I'm still not sold on this point.  Different devs teams don't (and can't) take "control" of the other team's code.  No single dev team owns or controls Bitcoin, nor should they.  Any developer can publish any code they want and any user can choose to run any code they want.  It's not as if one team suddenly absorbs the other if network rules change.  Whatever code consensus decides on, Core and Unlimited can still continue to publish whatever code they please, providing they ensure the code conforms to the network rules as defined by consensus.  No one can take away their right to do that. 

And if the network rules do change, it's not because a developer made it happen, it's because the users did.  People keep talking about "hostile takeovers" and "power grabs" as if they simply can't comprehend this fact.

[1714758357]

1714758357

[1714758357]

1714758357

[franky1]

The biggest difference is: who controls the Core project, and who controls the Unlimited source code. That's what the whole fight is about, who controls the reference code.

And if the network rules do change, it's not because a developer made it happen, it's because the users did.  People keep talking about "hostile takeovers" and "power grabs" as if they simply can't comprehend this fact.

by going soft they went against node consensus.. thus its only having to convince 20 pool managers into a limited consensus, instead of 5600 node users..

this is another reason pools think soft is wrong because its pushing something nodes are not ready for, and it can change the network dynamics. but because its the pools that decide.

the devs however can take the glory if everything works, saying 'see soft is better'
BUT devs can blame it on the pools if it goes wrong. saying 'well they consented to it, they activated it'

[DooMAD]

The biggest difference is: who controls the Core project, and who controls the Unlimited source code. That's what the whole fight is about, who controls the reference code.

And if the network rules do change, it's not because a developer made it happen, it's because the users did.  People keep talking about "hostile takeovers" and "power grabs" as if they simply can't comprehend this fact.

by going soft they went against node consensus.. thus its only having to convince 20 pool managers into a limited consensus, instead of 5600 node users..

this is another reason pools think soft is wrong because its pushing something nodes are not ready for, and it can change the network dynamics. but because its the pools that decide.

the devs however can take the glory if everything works, saying 'see soft is better'
BUT devs can blame it on the pools if it goes wrong. saying 'well they consented to it, they activated it'

Miners will wait to see if the nodes are in support before activating.  It's hardly a nefarious plot.  And again, the same argument applies, whether you personally agree with the code or not, Core can release whatever code they choose, Unlimited can do the same.  Users can run whatever code they choose.  If users opt for the SegWit softfork, cool, if they opt for a hardfork and a larger blocksize, also cool.  Neither option precludes the other from happening at some point.  We can easily do both (and probably should).  Also, neither option is beyond reversing if it doesn't work or causes adverse effects.  It really isn't the crisis people make it out to be.

[JayJuanGee]

I am also of the understanding that seg wit is a much better solution for a lot of matters and should be the next step, rather than rushing into BU when there does not really appear to be a need for it, not at the moment.. and seg wit is a better next step (at this time).

What problems does segwit solve?

I have brought my response over to this thread because I do not claim to be any kind of expert in seg wit versus bitcoin unlimited, and I was also participating in that wall observer thread because that is my area of interest (prices, etc).

My understanding is that seg wit solves a variety of problems in regards to maleability and scaling without having to add bloat to the bandwidth or the overall size of the blockchain data.

I partly am relying on the technical expertise of a variety of technical folks who were really behind seg wit when it was first introduced in December 2015, and there was no real opposition to seg wit and a bunch of praise for it.

Most of the subsequent criticisms that I have been hearing about seg wit seem to be fabricated by various big blockers who are ultimately seeming to want create division and have other agenda matters, such as governance concerns.

From my understanding, seg wit is clean, pretty well tested and really should get implemented in order that we can see how it plays out (in terms of further developments, etc).

Today, you can already drop the signatures from your storage layer after validating them if you want to.

I don't know.  I thought that seg wit was cleaner in this regard, and ended up removing more than 50% of the storage space because of the separation that it allows for.

Even if there are some advantages to segwit, implementing it as a soft fork is dangerous.  It lets old clients think they are fully validating when they aren't.  

I don't understand why so many folks seem to have such a hard-on for hardforks.. it seems stupid, especially if the hardfork would be likely contentious.

Surely, if you have a situation in which 95% or more folks are behind something because it is a really obvious fix and it is non contentious, then a hard fork would likely be cleaner and faster.

My understanding of part of the preference for a soft fork is based on the matter being currently contentious and no fork is done at all until a certain high level of consensus.. currently set at 95%, but maybe at some point there could be a decision to either increase or decrease that number depending on whether there seems to be any kind or risk of two forks (like what happened with ETH/ ETC or something like that)

If you are going to require 95%, you might as well hard fork and force outdated clients off the network.  

You may be correct, but the matter is not even close to 95%, yet... so why do I even give a shit... sure a hardfork may be better than a softfork, once a certain level of consensus is achieved.... There are certainly folks that know the topic much better than me, and I just go along with the majority anyhow.. especially if it were to get to that level of consensus and if I was not sure about the difference between the two.

Of course, the first time an old client mines a block that spends a segwit transaction under the old definition of the anyone can spend opcode you'll have a hard fork anyway (which will again just be an orphaned block since the segwit network will easily outpace the non-segwit network).

I thought that there is always some potential for issues during transitional periods, and probably, once seg wit is implemented (assuming that it is some day) then at that point there is already a proscribed way of transitioning that almost turns it into the same thing as a hardfork, even though before reaching the threashold consensus it was not really live, yet.

[JayJuanGee]

You may be correct.. no harm, no foul.. but my understanding is that there is a reason for blocksize limits, and some of it has to do with bloat and bandwith, etc etc..

The reason for the blocksize limit is that at the time it was implemented, bitcoins were worthless and blocks were easy to generate with a CPU.  Anyone could build huge blocks for no cost.  The blocksize limit was added as an antispam measure since it was basically free to spam.

I find nothing wrong with looking at original reasons etc, but in the end of the day, we still need to look at what situation exists at this particular time, and then what is a feasible next step based on what situation exists today.

Also, my understanding is that if there were a problem with block size limits, then there would be an issue with long transaction times and high fees, but currently, we have neither of those problems.  So in that regard, there is no real emergency reason to make a hard increase in the blocksize limit, at the moment.

But at the same time, seg wit does indirectly address the issue, and would likely give several more years of capacity while also improving the ability for some technologies like lightning network, which would take some transactions off the blockchain while at the same time allowing for fairly decent syncing with the blockchain.

Some folks claim that we currently do not have spam problems, but we do see spam problems from time to time.  Of course, the exact source of the spam and or the evidence for the spam is not always apparent to lay persons; however, from time to time we witness sudden 10x spikes in the mempool backup, and likely some of that is due to spam attacks.  I doubt that increasing the blocksize limit is going to be a good trade off.

Today, if you want to build a big block, you risk that the rest of the network will reject it.  If that happens, your block is orphaned and you lose the block reward (subsidy + fees).  In order to spam a large block, you have to take the risk that your block will be orphaned, costing you about $11,250 (12.5 btc/block * $900 / btc).  Not to mention, that larger blocks take longer to propagate than smaller blocks, so in a race condition, the smaller block will always win and the larger block will be orphaned.

O.k. great.. so there is a disincentive to mine large blocks... still does not mean that it is a good idea to just implement some untested increase in the blocksize limit.

Even at the time the blocksize was introduced, Satoshi himself intended for it to be increased at a later date (via a hard fork):
https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

Yep... it can be done.. does not mean that it should be done.  Satoshi wrote that in 2010.  A lot has happened in bitcoin since 2010, but it does not necessarily mean that the next best step is a hard increase in the blocksize limit - especially when it seems that seg wit is the next best step... to do next.. and then if necessary down the road, there may be a need for a hard increase in the blocksize limit.

[Warg]

My understanding is that seg wit solves a variety of problems in regards to maleability and scaling without having to add bloat to the bandwidth or the overall size of the blockchain data.

I don't understand why so many folks seem to have such a hard-on for hardforks.. it seems stupid, especially if the hardfork would be likely contentious.

Maybe those who cheers unlimited just want bitcoin to fail. If they have short possitions. Or they may be paid by gov to discord the bitcoin community.

[JayJuanGee]

My understanding is that seg wit solves a variety of problems in regards to maleability and scaling without having to add bloat to the bandwidth or the overall size of the blockchain data.

I don't understand why so many folks seem to have such a hard-on for hardforks.. it seems stupid, especially if the hardfork would be likely contentious.

Maybe those who cheers unlimited just want bitcoin to fail. If they have short possitions. Or they may be paid by gov to discord the bitcoin community.

I continuously claim that I am not really that familiar with a lot of technical intricacies, but in the end, the bitcoin unlimited folks seem to be coming from the same stream of folks that supported XT and then classic, and now they merged to bitcoin unlimited.

The agenda seems to be the same - to argue for the sake of argument over a blocksize limit  that is not as emergent as they want to make it out to be and to oppose seg wit for the mere sake of opposing something that is actually a good thing for bitcoin... even though it could take a year or longer for seg wit to gain a sufficient quantity of consensus.. .and maybe it is also possible that if some of these anti-bitcoin folks can continue to be obstructionists and ultimately handicap bitcoin because it is not able to implement a robust and powerful change (namely seg wit).

[jacaf01]

SegWit for me, I know the core team have their own bad side but they have proven overtime that they can be trusted and can get the job done, unlimited team has nothing to offer to space but to block the block size increase they are advocating for. Unlimited development team keep clamouring for hard-fork because they don't have the technical know of how to scale Bitcoin using soft fork.

[DooMAD]

Both for me.  Either SegWit then Blocksize, or both at the same time.  Even 1.25MB would put my mind at ease at this point.  Anything to set a precedent that 1MB is not set in stone and the network hasn't ossified to the point where change can't occur if needed.  Once that happens, only a small proportion of hardliners will still find something to argue about.  Then we can focus on more interesting things for a while. 

[JayJuanGee]

Both for me.  Either SegWit then Blocksize, or both at the same time.  Even 1.25MB would put my mind at ease at this point.  Anything to set a precedent that 1MB is not set in stone and the network hasn't ossified to the point where change can't occur if needed.  Once that happens, only a small proportion of hardliners will still find something to argue about.  Then we can focus on more interesting things for a while. 

Nonsense.

You seem to be arguing for a change for the mere sake of change, and you somehow seem to be buying into the argument that bitcoin needs to be more easily changed.

The fact of the matter remains that making bitcoin difficult to change is a feature and not a bug, and yeah, it might be be nice if there were some kind of a hard increase in the blocksize limit, but there has not been anything approaching consensus on the matter, and there are not any proposals that have been considerably tested on testnet in order to go through vetting and be adopted.  Segwit is the only software implementation that has been vetted and tested and is currently on the table that is also meant to make some improvements in scaling, too.

In other words, we do not need change merely for the sake of change, that is a nonsense argument, even though some folks have been putting a lot of lipstick (and other make up) on that pig.

[Wilhelmus]

The main difference lies in the fact that SegWit aims to restructure the block space to allow more transactions per block, while Unlimited aims simply to raise the blocksize to allow more transaction.

[digaran]

This is all the banks doings, tell me something, what happens if network could handle 400 transactions per second? who really gets hurt?
I know the answer: banks. our masters are controlling and limiting bitcoin as well, satoshi failed big time.

[JayJuanGee]

The main difference lies in the fact that SegWit aims to restructure the block space to allow more transactions per block, while Unlimited aims simply to raise the blocksize to allow more transaction.

You seem to be misstating your summary.

Bitcoin Unlimited attempts to change consensus thresholds.  That's no minor or inconsequential change.

This is all the banks doings, tell me something, what happens if network could handle 400 transactions per second? who really gets hurt?
I know the answer: banks. our masters are controlling and limiting bitcoin as well, satoshi failed big time.

What the fuck are you talking about?

Bitcoin already, in its current status, is a pretty robust challenge to status quo banks, considering how you use it .. but powerful indeed... even in its supposed "limited" state of affairs (I assume you are referring to the current 1 mb hardlimit in the blocksize).

[DooMAD]

You seem to be arguing for a change for the mere sake of change, and you somehow seem to be buying into the argument that bitcoin needs to be more easily changed.

The fact of the matter remains that making bitcoin difficult to change is a feature and not a bug, and yeah, it might be be nice if there were some kind of a hard increase in the blocksize limit, but there has not been anything approaching consensus on the matter, and there are not any proposals that have been considerably tested on testnet in order to go through vetting and be adopted.  Segwit is the only software implementation that has been vetted and tested and is currently on the table that is also meant to make some improvements in scaling, too.

In other words, we do not need change merely for the sake of change, that is a nonsense argument, even though some folks have been putting a lot of lipstick (and other make up) on that pig.

If I flipped it round and said you were making the argument that bitcoin needs to be more difficult to change, then I would be misinterpreting you as much as you are me.  That's not the argument at all.  The concern is that while optimisations like SegWit are welcome, that's not going to be enough over the long term.  People calling SegWit a scaling "solution" are completely overselling its potential.  It will help, but the problem doesn't magically go away after it gets implemented.  It's merely the first step among many to address the scaling issue.  Eventually, we'll need SegWit, Lightning, sidechains, atomic cross-chain transactions, a larger (preferably adaptive) blocksize and whatever else proves effective at easing the mempool load whilst not sacrificing node decentralisation or the open and permissionless nature of the network (i.e. not forcing everyone off-chain).  People get so myopic about SegWit like it's the only thing we'll ever need.  If you honestly think that, you are mistaken.  Arguing that the blocksize should not be set in stone is not "nonsense".  

[Andromaque]

The main difference lies in the fact that SegWit aims to restructure the block space to allow more transactions per block, while Unlimited aims simply to raise the blocksize to allow more transaction.

You seem to be misstating your summary.

Bitcoin Unlimited attempts to change consensus thresholds.  That's no minor or inconsequential change.

Mate, could you please explain me ? What he said is false you said. You did not talked about SegWit so his description is right, isn't it ? And for Unlimited, they want to change how much is required to apply an hardfork or a softfork ? That is what I understand by consensus thresholds.

[leopard2]

I think both sides are over complicating the issue and this leads to confusion. Satoshi would most probably just up'ed the block size a tiny bit,

and addressed all the other issues on their own. Now Blockstream added all these extra features/fixes to make it more attractive, and people

got confused. Most developers make this mistake.... over engineering the solution.   ....The answer is simple, keep the protocol clean and

secure and do off-chain payments for scalability... Oh, but that is what Blockstream is trying to do, or not... see, now I am also confused.  

I am 100% with you

1MB blocks stuffed? Make then 2 or 4MB, work on the other issues separately, and when 2-4MB are too small again, have another discussion

Realistically BTC will be worth 2000-4000$ when that happens so it is nothing to worry about at all 

[JayJuanGee]

You seem to be arguing for a change for the mere sake of change, and you somehow seem to be buying into the argument that bitcoin needs to be more easily changed.

The fact of the matter remains that making bitcoin difficult to change is a feature and not a bug, and yeah, it might be be nice if there were some kind of a hard increase in the blocksize limit, but there has not been anything approaching consensus on the matter, and there are not any proposals that have been considerably tested on testnet in order to go through vetting and be adopted.  Segwit is the only software implementation that has been vetted and tested and is currently on the table that is also meant to make some improvements in scaling, too.

In other words, we do not need change merely for the sake of change, that is a nonsense argument, even though some folks have been putting a lot of lipstick (and other make up) on that pig.

If I flipped it round and said you were making the argument that bitcoin needs to be more difficult to change, then I would be misinterpreting you as much as you are me.  

There is no flipping around.  You cannot just take an argument and flip it around and say that it is equally valid.. that is retarded.

We have a status quo which currently includes a 1 mb blocksize limit, and in order to change the status quo, the burden of production of evidence and the burden of persuasion is on the folks who want to make the change - not the other way around... there is no burden to maintain the status quo unless and until the proposer of the change meets both their burden of production and burden of persuasion, then the burden shifts to the status quo.

In this case, the burden of production would be evidence to show that there is some kind of problem with 1mb blocksize limits such as showing high fees or slow transaction times.  The burden of persuasion would be showing that the proposed solution adequately addresses the problems without creating new problems.  The proponents of hardlimit increases don't seem to have satisfied either burden.

That's not the argument at all.  The concern is that while optimisations like SegWit are welcome, that's not going to be enough over the long term.  

You are trying to frame the argument into something that is convenient for you about some hypothetical long term that is pie in the sky.

The fact of the matter is that we have what we have now, and then we have various proposals.  When seg wit was publically proposed in December 2015, it largely had no opposition, and even various XT and classic supporters, such as Gavin Andressen and Jeff Garzik were largely in agreement that seg wit was a good path forward, and accordingly, seg wit continued to be vetted and tested and got to various levels of going live, including going live for the purpose of signaling in mid November 2016.

So yeah, we don't know what the fuck seg wit is going to bring until it actually becomes a practice, and there are a lot of scaling issues that it addresses that may cause no need for further changes for a considerable time into the future.

Seg wit is actually on the table and those other various hardlimit increases are merely points of whinery  - that have not been officially tested and implemented... apparently BU is being tested in a live way, rather than being put on the test net first.

People calling SegWit a scaling "solution" are completely overselling its potential.  

It is currently on the table, and would likely bring bitcoin forward in a variety of ways, including some addressing of scaling... good enough and largely noncontroversial... except whiners seeming to want to sabatoge it without any real good reasons.

It will help, but the problem doesn't magically go away after it gets implemented.

Who is arguing that all the problems are going to go away?  Let's get seg wit implemented, and then go from there.. rather than saying there is something better out there without actually having anything on the table..

 It's merely the first step among many to address the scaling issue.  Eventually, we'll need SegWit, Lightning, sidechains, atomic cross-chain transactions, a larger (preferably adaptive) blocksize and whatever else proves effective at easing the mempool load whilst not sacrificing node decentralisation or the open and permissionless nature of the network.  

"eventually"?  O.k.... so you are conceding that nothing is really needed?  

Why throw the baby out with the bathwater?  You want to wait with seg wit for some reason?  What is your proposal?  Seg wit is already there. and  already ready to make bitcoin more robust.  You have something against making bitcoin more robust?

People get so myopic about SegWit like it's the only thing we'll ever need.  If you honestly think that, you are mistaken.

Who is myopic?  Seg wit is on the table, and if it does not solve matters then more proposals can be made.  From my understanding bitcoin development remains a pretty dynamic place with lots of things going on, and seg wit happens to be one of the bigger and greatest things, but it is not the only thing going on... I am not a technical person so I do not play around in those circles... but I do review some of their activities from time to time... which seems quite dynamic, interactive and inclusive and there are a lot of very smart folks involved in a variety of ways.

[JayJuanGee]

The main difference lies in the fact that SegWit aims to restructure the block space to allow more transactions per block, while Unlimited aims simply to raise the blocksize to allow more transaction.

You seem to be misstating your summary.

Bitcoin Unlimited attempts to change consensus thresholds.  That's no minor or inconsequential change.

Mate, could you please explain me ? What he said is false you said. You did not talked about SegWit so his description is right, isn't it ? And for Unlimited, they want to change how much is required to apply an hardfork or a softfork ? That is what I understand by consensus thresholds.

I am a layman too in a lot of this, but I do recognize that frequently people who are selling Bitcoin Unlimited are of the same camp as the XT and Classic folks.. and they are continuing with their various attempts to change bitcoin's governance.

They are obsessed with it.  So they try to frame a lot of technical arguments and appeal to folks that change is good, blah blah blah... but in essence, what they are proposing would undermine bitcoin in a lot of ways.


They have hardons for hard forks, and making all kinds of proposals and threats to hard fork and also they want to do these kinds of hard forks with levels of consensus that are much smaller than 95%.. I doubt that folks are going to follow them, but they do succeed, to some extent in their ability to block improvements to bitcoin by suggesting that you are either for or against seg wit which is opposite BU.. blah blah blah. 

If you change the consensus thresholds to 75% or some amount that is much lower than 95%, then you run a considerable risk of producing two chains.. and yeah, probably once you do 75% consensus then you would set precedent and continue to make decisions with relatively low consensus.. which makes changes much easier (but not a good thing for something, such as bitcoin, that is so potentially undermining of various status quo financial institutions).

[aarturka]

The main difference lies in the fact that SegWit aims to restructure the block space to allow more transactions per block, while Unlimited aims simply to raise the blocksize to allow more transaction.

Unlimited aims to split Bitcoin. There was a hint from Roger Ver that it'd be good

[jujugoboom]

SegWit is far more progressive solution and it solves several problems not just scalability. Besides SegWit is softfork and Unlimited is hardfork. Remember what happened with Etherium after hardfork?

Yeah, hardfork means not decentralized any more, look ETH dumled hard in recent months, ETH will be killed IMO. Softfork is much better than hardfork.