Compromise between SegWit and BU

[adam440]

Hello,
I have only a little knowledge about these scaling solutions so I want to ask if it's possible to somewhat combine these two solutions. Like, change the transaction protocol according to SegWit to allow off-chain solutions (Lighting Network) while letting the miners choose a size of the block. Is this possible?

[Foxpup]

Lightning does not require SegWit, and SegWit already is a compromise on block size by increasing it to 4MB.

[achow101]

Because those who know segwit well enough to implement it and change it do not like BU and thus do not know BU well enough to implement both Segwit and BU in a client. Nor do those people want to because they think that BU is a stupid idea.

Those who know BU well enough to implement it and change it do not like Segwit and thus do not know Segwit well enough to implement both BU and Segwit in a client. Nor do those people want to because they think that Segwit is a stupid idea.

[HCP]

Sadly, it has got to the point where personal pride and stubbornness appears to be getting in the way of what is best for the network and it's users...

Neither side wants to admit "defeat" and both think they have "The Best Solution"™ to the issues currently facing the network.

In my opinion, SegWit isn't really trying to compete with BU directly... is it an attempt to fix some other issues (transaction malleability etc) and the increase in blocksize is more of a side effect than the main goal. BU seems to be solely focused on increasing the blocksize.

Meanwhile, the mempool has been well over 30K transactions for almost a week... and everyone is "suffering"... hopefully, one side or the other will prevail soon so at least we'll find out if one of the solutions works (if not, we can always just try the other I guess )

[JackH]

There is no need to compromise with BU. It is a broken implementation that gives miners power to decide block sizes and is nothing but a political tool invented by those that want to see Bitcoin become centralized. Why would anyone compromise when the solution that is ready is superior in every way and also increases block size?

[DannyHamilton]

- snip -
I want to ask if it's possible to somewhat combine these two solutions.
- snip -
Is this possible?

You are dealing with a very political problem, not a technical one.

You can see this in that 5 people all responded to your thread already and NONE of them answered your question.  Instead, they ALL gave you answers about why they think it shouldn't be done, or why they think nobody will do it.


The simple answer to your question is:

YES.  It is technically possible.  There is nothing about SegWit that makes it technically impossible to also implement Unlimited, and there is nothing about Unlimited that makes it technically impossible to also implement SegWit.

If anyone eventually choose to do so, we will probably just fragment the system even more. You'll some some users that hate SegWit and will ONLY run Unlimited, some users that hate Unlimited and will ONLY run SegWit, some users that hate BOTH and will refuse to upgrade beyond Core version 0.12, and some users that don't care and are willing to run your "compromise".

This isn't a problem that is going to be fixed by introducing more options to fight about. Bitcoin is quite possibly destined to tear itself in half. Either there will eventually be a fork with two chains each trying to call themselves the REAL bitcoin, or a very charismatic person will show up that convinces an overwhelming majority to agree on something. All the trolls and zealots in all the discussion forums only make the fork with two chains each trying to call themselves the REAL bitcoin more likely.  They'll all blame "the other side" if it all falls apart, it's always easier to be angry at what someone else did than feel responsible for one's own actions.

[Carlton Banks]

You are dealing with a very political problem, not a technical one.


The simple answer to your question is:

YES.  It is technically possible.  There is nothing about SegWit that makes it technically impossible to also implement Unlimited, and there is nothing about Unlimited that makes it technically impossible to also implement SegWit.

Then why not say that, then shut your mouth?

Every other part of your post is simply subtle politicking, as if you're somehow the voice of reason if you say "I'm the only one who says this is political", when in fact at least 2 other posters have made the same essential point already (demonstrating you're manipulating the narrative to make yourself appear trustworthy, pah)


Danny's post is covertly political, he publicly states that BU is actually an attempt at a genuinely intended dynamic block sizing concept, but really it's just a dressed up way of allowing miners to entirely control the blocksize, and to cut the honest hardworking professional software developers out of Bitcoin development. Danny never addresses any of this, he simply says "I don't do politics" when invited to discuss the technical "merits" of BU


If Danny was really interested in the technical argument, he would be mentioning the serious technical attack vector that BU represents. But of course, because no real Bitcoin users are actually interested in having any aspect of what should be a system with limits becoming unlimited, Danny has no choice but to continue the social engineering attack on Bitcoin instead (currently the only effective attack against it)

[LabaDaba]

Exactly chinese miners and miner mafuf. trying to take over BTC. Main traitor Bitmain.

[mwizard]

Lightning does not require SegWit, and SegWit already is a compromise on block size by increasing it to 4MB.

Couple of comments.

SegWit does not change the actual block size.  It stays at 1 MB.  That is why SegWit is a soft fork.  Nodes running older versions will still accept it.

SegWit moves some data out of the block so that more transactions can fit into a 1 MB block.

The various versions of Lightning need SegWit to fix transaction malleability.  It will be very difficult to introduce a version of Lightning if this is not fixed.  

[HostFat]

@DannyHamilton
I think that I can say that mostly all BU supporters agree on enabling all the things of Segwit does as hard fork, after the block size hard fork.

You can already find the specifics to do this
https://bitco.in/forum/threads/buip037-hardfork-segwit.1591/

There is also a proposal from BC:
https://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki

So you can be sure that LN and all other good things that segwit is promising to enable, you will still have after a block size fork.

[cellard]

After reading a lot about BU and segwit, the problem with your proposition is the fact that BU just doesn't work. There is not a single "flexible blocksize" approach that properly works without opening nasty cans of worms. Therefore, the conservative approach is still the preferred one.

[andron8383]

After reading a lot about BU and segwit, the problem with your proposition is the fact that BU just doesn't work. There is not a single "flexible blocksize" approach that properly works without opening nasty cans of worms. Therefore, the conservative approach is still the preferred one.

Better would be hard limit increase. But now we have to deal with block size.
solution like:
-we group blocks into superblocks like 5000 packages every node have to keep last 3 superblocks
-every time when we create superblock we create balance sheet for all adresses
-superblocks have to have conections between each other that you could use all from day 0 and be sure that you use good one superblock
- in such sytuaction blocksize doesn't matter so much and we can grow in size and transaction time.

2nd solution would be 3rd party layers to blockchain

[seradj0]

So we are facing a HF I guess no !?

[by rallier]

If Chinese miners don't want to accept SegWit because of possible network issues, still we dont need to Bitcoin Unlimited.
Bitcoin Developers can develop new adaption like bitcoin block timing reduce to 2 minute (now 10 minute) and bitcoin block bounty can be reduced  %50^5 percent. Doesn't change on ecosystem

edit: I opened a thread discuss to my suggestion : https://bitcointalk.org/index.php?topic=1827943

[Carlton Banks]

edit: I opened a thread discuss to my suggestion : https://bitcointalk.org/index.php?topic=1827943

You're late to your own discussion by several months, this is not an original suggestion.

The block interval target is 10 minutes for important reasons: orphan rate, inherent latency of TCP/IP networks etc. It's also a hard fork change, and so much more could be done with any hard fork that relegates the importance of reducing the block interval target.

It's not the worst idea, but you're not really contributing anything useful by bringing this up for the Nth time.

[BitUsher]

Hello,
I have only a little knowledge about these scaling solutions so I want to ask if it's possible to somewhat combine these two solutions. Like, change the transaction protocol according to SegWit to allow off-chain solutions (Lighting Network) while letting the miners choose a size of the block. Is this possible?

Miners can and already and do set the size of the block with soft limits , users set the upper end of the hard limit though . Giving miners control of the blocksize would centralize mining , set a bad precedent that the miners control validation rules and not economic users, and not account for externalities like the cost of nodes on processing the blocks leading to node drop off and centralization. Essentially creating paypal 2.0 with a mining cartel , where everyone eventually is forced to trust third parties instead of validating their own txs.

So , no thank you.

[hv_]

Hello,
I have only a little knowledge about these scaling solutions so I want to ask if it's possible to somewhat combine these two solutions. Like, change the transaction protocol according to SegWit to allow off-chain solutions (Lighting Network) while letting the miners choose a size of the block. Is this possible?

Miners can and already and do set the size of the block with soft limits , users set the upper end of the hard limit though . Giving miners control of the blocksize would centralize mining , set a bad precedent that the miners control validation rules and not economic users, and not account for externalities like the cost of nodes on processing the blocks leading to node drop off and centralization. Essentially creating paypal 2.0 with a mining cartel , where everyone eventually is forced to trust third parties instead of validating their own txs.

So , no thank you.

What is your very balanced counter offer ?   SW + 2nd layer where 2nd layer will turn out to be the very same you not want?

[Balthazar]

It's a natural resistance against Chinese coup d'état. No compromise should be made in such situation, no sane person would make a deal with terrorists.

[hv_]

It's a natural resistance against Chinese coup d'état. No compromise should be made in such situation, no sane person would make a deal with terrorists.

It's a natural resistance from (Chinese) miners against blockstream terrorists.

Just two ways of view. (Hard for many here to see both, since most just are simple users and don't care about miners investments)

BTW: Miners do safe the blockchain and your bitcoins. They play it well as we see.

[mezzomix]

Miners Pools ... play it well as we see.

SPV Mining is the opposite of playing well!