SegWit2MB The Forking Compromise

[Killerpotleaf]

SegWit2MB takes the Bitcoin protocol as it stands, but it adds a 2MB block size hard-fork that activates only if Segwit activates.

post your thoughts below and your votes above.

[1714152767]

1714152767

[1714152767]

1714152767

[1714152767]

1714152767

[Killerpotleaf]

I hate it, this crazy 4MB block weight doubled to 8MB effective blocksize just doubles the shittness of segwit IMO. I want malleability fix + EC HF, thats it, thats all.

[Snorek]

Why do we need hard fork for the sake of simply having a hard fork?
Are you trying to please BU community which expects that any change can be done only via hard fork?
It will be trade of this kind: "Oh, look! We will let you hard fork bitcoin if you allow SegWit to activate, deal?"

No, I don't like it and we don't need it.

[jubalix]

Why do we need hard fork for the sake of simply having a hard fork?
Are you trying to please BU community which expects that any change can be done only via hard fork?
It will be trade of this kind: "Oh, look! We will let you hard fork bitcoin if you allow SegWit to activate, deal?"

No, I don't like it and we don't need it.

i guess its an attempt at a compromise?

anyhow it looks like ltc will segwit, which will be interesting

[Sr.Urbanist]

There are transaction delays and unpredictable fees.  The price of BTC is going up and so are transactions. I do not see how slapping on a layerII code will address these problems.  The only thing it will do is increase delays and push funds elsewhere, such as LTC, which has 2MB block sizes and they are voting on #SegWit.  I think it makes more sense there and larger blocks for bitcoin.  

Why would we fundamentally fork - I mean fundamentally, not vía code - Bitcoin when larger block sizes will continue to work as they have in the past?

[Sr.Urbanist]

anyhow it looks like ltc will segwit, which will be interesting

I've been putting all of my BTC miner earnings into LTC ...

[Miz4r]

I don't like it. We should do SegWit first and then first see how the network handles bigger blocks and only then decide based on the new data how we are going to plan ahead with a possible future HF. This is the only logical and sensible thing to do, we can't compromise security for political reasons.

[Sr.Urbanist]

I don't like it. We should do SegWit first and then first see how the network handles bigger blocks and only then decide based on the new data how we are going to plan ahead with a possible future HF. This is the only logical and sensible thing to do, we can't compromise security for political reasons.

You do realize BTC started at 1kb block size and has worked up to 1MB, suddenly a business group of developers with a clever name "Bitcoin Core", are trying to change the fundamentals of Bitcoin. SegWit is a layer 2 bootstrap on how it behaves *on top* of existing BTC.  This bootstrapping can change payment methods in both positive and, potentially, nefarious ways.  It makes transactions less secure by removing them from the blockchain.

[york780]

I like it. It brings the community together. Combine the power of bigger blocks and SegWit sounds better to me than only SegWit or only BU. We must accept a hardfork at december 14. Its not bad for bitcoin when the forked coin dies. Bitcoin has to keep the 21 mln coins philosophy. Why cant we just accept that bitcoin is a mess rightnow lol. Lets fix it and than we moon. I rather moon with a stronger better healty bitcoin that will likely stay there than a bitcoin with technical ill bitcoin with a devided community what results i a pump and dump bitcoin. We need to fix it. Its just one more step in the adoption process.

[Miz4r]

I don't like it. We should do SegWit first and then first see how the network handles bigger blocks and only then decide based on the new data how we are going to plan ahead with a possible future HF. This is the only logical and sensible thing to do, we can't compromise security for political reasons.

You do realize BTC started at 1kb block size and has worked up to 1MB, suddenly a business group of developers with a clever name "Bitcoin Core", are trying to change the fundamentals of Bitcoin. SegWit is a layer 2 bootstrap on how it behaves *on top* of existing BTC.  This bootstrapping can change payment methods in both positive and, potentially, nefarious ways.  It makes transactions less secure by removing them from the blockchain.

Pure bullshit BU propaganda you are spewing here. Bitcoin Core is not trying to change the fundamentals of Bitcoin, they are trying to keep them. And your SegWit complaints are just ridiculous, you don't seem to understand what it does and how it works at all. Pretty much everyone who does understand SegWit is very positive about it.

[franky1]

moving the goalpost is just doing nothing more than delaying another DEV control debate later on when 2mb needs to move again and the community pleading to devs to push the boat out again.

if dvs are going to do a hard change to 2mb.. make it dynamic so USERS at runtime can go into an options and set a limit which is then shown in their useragent to then be used as a poll for pools to see the users preferences are.

EG nodes have a speed test that says 2017: 8mb is safe. but 2mb is super safe.. users nodes flag 2mb..(some flag 3mb some flag 1.5).. but majority are at 2mb..
thus pools pools go up in increments from 1mb to 2mb in smallers 0.25mb allotments(less or more) testing and looking out for bugs/orphan risks. much like the rise from 1kb-1mb. which although the rule was 1mb. pools prefered 0.25mb increments.
meaning pools stay below what nodes big rule is(8mb) and below the majority of small rule(preference)

thus can be done by using
consensus.h for the big rule of speed tests that can be added to a node (eg 2017 8mb)
policy.h for the small DYNAMIC/user preference rule(eg ~2mb)

however just kicking a mile stone down the road is just going to end up with sore feet trying to get dev's to do something.
it needs to be decentralised and not reliant on devs decision/control.

[kiklo]

SegWit2MB takes the Bitcoin protocol as it stands, but it adds a 2MB block size hard-fork that activates only if Segwit activates.

post your thoughts below and your votes above.

SegWit 2MB

There we go, much better. 


 

[Lauda]

It seems that in almost all of these threads, there is a group of 'individuals' that are anti-Segwit and subversively praising BU (whilst claiming to be pro-decentralization). Where is Jonald in this thread?

I hate it, this crazy 4MB block weight doubled to 8MB effective blocksize just doubles the shittness of segwit IMO. I want malleability fix + EC HF, thats it, thats all.

Stop with this false narrative already.

[franky1]

It seems that in almost all of these threads, there is a group of 'sheep' that are anti-decentralisation and subversively praising a corporation (whilst claiming to be independent). Where is their logic? Where is their understanding of code where is their praise for anything not corporation sanctioned?

FTFY

[d5000]

... anti-decentralisation ...

"Decentralization" doesn't belong to one of the antagonic groups. Both are trying to solve a centralization risk.

As of now, however, my opinion is that the BU approach has more centralization risks, because it depends very much on a strong internet bandwidth growth and a fast storage/technology evolution. LN, on the other hand, depends on connectivity or "internet stability" (it is potentially more decentralized if more nodes are online 24/7). But other 2nd layer solutions like extension blocks and side/drivechains don't depend on neither of the two. That's why I'm tending to affirm that "da truth(TM)" is closer to Core's concept.

@OP: Wondering why participation in your poll is so low? There is already another poll about exactly the same solution. It was started much earlier than Sergio's proposal was delivered, because the concept is already a while around here.

[franky1]

... anti-decentralisation ...

"Decentralization" doesn't belong to one of the antagonic groups. Both are trying to solve a centralization risk.

As of now, however, my opinion is that the BU approach has more centralization risks, because it depends very much on a strong internet bandwidth growth and a fast storage/technology evolution.

NODES flag what they can cope with.. so pools actually do stay within some limit. but that limit is adjustable BY THE NETWORK consensus OF NODE CAPABILTY not by devs wearing crowns screaming "thou shall not pass"

secondly core are the ones wanting only their implementation to be the upstream of a TIER network. but then dilte the node count
with a cesspit of downstream nodes that are not relaying certain tx's not abl to sync to each other due to being "stripped" "prunned" etc

thirdly only core are the ones with the crazy banning, mandatory activations and PoW nuke threats. meaning no matter what consensus is, no matter if pools see passed the empty promise, cor will not ask themselves what they could do better to med community need. they just want their tier network.

LN, on the other hand, depends on connectivity or "internet stability" (it is potentially more decentralized if more nodes are online 24/7). But other 2nd layer solutions like extension blocks and side/drivechains don't depend on neither of the two. That's why I'm tending to affirm that "da truth(TM)" is closer to Core's concept.

LN 'could be' decentralised, but playing out scenario's it will become more hub based not spoke based. even if people dream of spoke based due to greed of hoping they get paid. the hope of them getting paid vs spenders paying more to pay each router is the very reason spenders will choose hubs, to avoid paying 5 fee's to route it through 6 people for example

secondly even then LN is not permissionless, due to dual signing of multisigs.

thirdly nothing against LN as a VOLUNTARY side service, but thinking its the only end solution, pfft.

fourthly. side/drive chains are also known as altcoins. so kind of funny for a few reasons:
1. "scaling bitcoin= move people to an altcoin"
2. "bitcoin cant scale but sidechain altcoin can".. strange how they would be happy to have an altcoin with a dynamic block. but not bitcoin
3. think about the node count once people move over to the sidechain/alt that decide never to return to bitcoin

[d5000]

LN 'could be' decentralised, but playing out scenario's it will become more hub based not spoke based. even if people dream of spoke based due to greed of hoping they get paid. the hope of them getting paid vs spenders paying more to pay each router is the very reason spenders will choose hubs, to avoid paying 5 fee's to route it through 6 people for example.

I somewhat agree to a part of the LN skepticism and don't want to see it to be the main method to transact in the Bitcoin network, at least if the outcome is a "centralized" variant with few large hubs. But a decentralized LN is not impossible: In your scenario, smaller nodes that would like to profit from routing would be forced to be content with a very small fee to compete with large hubs. And I think there will be a growing proportion of 24/7 connected nodes in the future (smartphones, home servers, raspberry nodes with pruned blockchains, etc.). So I will wait and see what happens, then I will give my final opinion on LN

thirdly nothing against LN as a VOLUNTARY side service, but thinking its the only end solution, pfft.

Agree, but I think there will never be an obligation to use it. You simply couldn't force it. I think there will always be attractive alternatives.

fourthly. side/drive chains are also known as altcoins.

OK, if you like. But the side/drivechains I mean (like RSK) would be two-way-pegged altcoins, so they would not be diluting Bitcoin's value/price.

1. "scaling bitcoin= move people to an altcoin"
2. "bitcoin cant scale but sidechain altcoin can".. strange how they would be happy to have an altcoin with a dynamic block. but not bitcoin

That are only "problems" because "altcoin" is a kind of insult . Otherwise, it's simply a "sharding" solution.

3. think about the node count once people move over to the sidechain/alt that decide never to return to bitcoin

Where would there be a problem? Wouldn't that be even good, so the main chain could become light and small?

[FiendCoin]

For anyone not paying attention, miners want LN. However, Bitmain Antpool miners don't want SegWit or any improvement that changes the coinbase so they can't use their exploit.

[Sr.Urbanist]

Do you need to comment in order to vote?

I think this was the agreement reached over a year ago.  Core went ahead with SegWit and a "1MB is law" mentality.  Discussions began on a thread here to continue increasing block sizes, as had been done the previous X years, which led to Bitcoin Unlimited.

After seeing the warning sign on my LiteCoin Core node about unknown rules and learning about Ripple in 2004, I am not convinced about SegWit in the real $$$ matter.  I have am running core, but moved out my $LTC to Jaxx until the warning goes away.

In theory, cool!  It's also cool to think about tethering our cell phones, like Lightning, but for some reasons it hasn't worked and we have cell towers. SegWit is placing an old idea on top of a revolutionary technology, in my current opinion.  My opinion does change.

[Sr.Urbanist]

SegWit 2MB

There we go, much better. 

Agree.