Topic: Does SegWit even increase the block size? (Read 1243 times)

it was never messy,
but core (the 2 blockstream paid devs) backtracked the agreement and decided their soft way was better. by throwing out mindless doomsday theories and fake risks and fake promises

but has now shoot themselves in the foot because although pools get the ultimate vote. and no official node vote.. pools are smart enough to know what pools do can be rejected by nodes. so waiting out (60% undecided either side) for an unofficial node count threshold to be met before risking anything.

the main pools infavour of segwit (slush/BTCC) actually have financial ties to the same VC as blockstream (DCG: VC of coindesk propaganda, blockstream and BTCC)
which is why BTCC jumped on the segwit flag waving train before even thinking of running scenario's or knowing the full list of pro's cons' limitations and realities of segwits 'promises'

Well, not yet there isn't.  But it certainly sounds like some people are now having second thoughts about how great the original soft fork plan supposedly was.  Much like the UK Prime Minister's "hard brexit", it seems some are now advocating for a "hard softfork".  

I'm not sure where they get this idea from that they can blame miners for having too much influence when they left the ball in their court to begin with, though.  SegWit as a hard fork is starting to sound comparably less messy at this juncture.

95% is just about network ORPHAN risk(of ~5%) that is all its about.... reducing orphan risk between the pools.
(separately, user nodes could still reject blocks by recognising a certain block version and reject it and cause more orphans, if they so chose to)

not about getting to 95% new feature benefit.
even after activation segwit doesnt offer any fix.

it requires USERNODES to update to yet another new (not yet released) version.
AND THEN (separate requirement) users to voluntarily move funds from native priv/pub key to segwit priv/pub keys and only use segwit keys for.. wait for it.. for only those segwit KEY users to be disarmed from the issues of those users being able to make sigop bloat/malleated tx.
while still not dealing with those that stay with native keys(even using segwit as just a node)

like i explained at the bottom of post #5 above about if 50% of users using segwit keys causes a 50% possible boost to tx count... but knowing malicious users will not use segwit keys.. wont be even help one bit with sigop quadratic spam/malleation

Which is probably why 95% sustained segwit activation signaling is needed. It's uglier and more dangerous than a coordinated hard fork.

the funny part of SFSW is by allowing native nodes to continue..
not only will malicious sigop spammers continue to make sigop spam with native keys.
not only will malicious malleation double spenders continue to make malleated tx's with native keys.
 but it opens up new attacks too(even with segwit changing the network topology to be upstream filters to stop automated relay of unconfirmed SW tx's to native nodes) MANUALLY grabbing SW tx's from a SW node and pasting it into a native node. can cause issues

basically meaning segwit doesnt 100% fix the issues
basically meaning segwit doesnt disarm everyone
basically meaning segwit doesnt get all the benefits it promised

and it opens new issues.

Sounds like the correct way forward on my limited knowledge.

Is this not the problem (potentially) with both BU and SFSW solutions?

there is no "user activated soft fork"

in short
soft=pools only
hard= NODES then pools
save repeating myself:

yep even in a pool only vote, bilateral splits can happen.

do not take one "teams" fake rhetoric of softs best case scenaro and hards worse case scenario.. as thats just the 'brush it under the carpet' gameplay

---

secondly. segwits soft consensus.. if ever activated. is not true "native node backward compatibility" meaning native nodes are no longer full nodes..
what it means is native nodes need to be handed a FILTERED block (translated by upstream filter nodes(segwit) whereby native nodes are not full nodes. they dont even get to be full relay either because the upstream filters control what nodes connect as true full node peers and what are downstream nodes that only get selective data.
essentially leaving old nodes in a hodge-podge if semi full nodes.(like second class citizens)

EG
native nodes cant sync TO newer nodes because they lack the real full block data.
native nodes cant sync from new newer nodes in pruned mode because they lack the real full block data.
segwit with all its filters and pruning and no-witness modes changes the network into a diluted count of real full nodes. rathre then having a proper hard consensus that puts everyone on the same level playing ground

Call it security or stability if you wish. People want both.
How does User Activated Soft Forks help with this? Miners don't signal for segwit, so impatient users demand soft fork to force miners. Is the network stable or secure now?

SegWit is not going to increase block size... SegWit will "tidy up" blocks better in order to "fit" more transactions into a 1MB block.

Beyond what's already been posted you can get more info here and here. For content regarding advantages/disadvantages from more independent sources you can look up in the forums threads regarding that. Several users, including some that posted in this thread, made pretty good posts regarding the issue.

Good guess.

It's not security, but stability, that informed the choice of a 95% activation threshold. Specifically, stable coherency of the Bitcoin network as a whole.

If the threshold were set lower, there is a risk that those miners running software that cannot handle the fork would reject blocks featuring whatever new feature the fork enables. Regular users also running pre-fork full-nodes could reject the same block too, and an actual ongoing blockchain fork could occur, totally unplanned and unwanted. The idea with soft forks is to make sure older nodes can continue to use the old feature set on the same chain as the new feature set.

The 95% constant segwit signaling required for activation must have been set that high for a reason. I would think it is more for a transitional security reason than for winning a popular vote contest. Anyone know?

Yes, it does.   4MB, but 2.1 "effective" increase based on current traffic patterns.   

We need this block size increase today, because fees are going to become a big barrier preventing adoption as bitcoin price is bloated by institutional involvement in the coming year.

Also, since there's no way we can record every person's coffee and pizza purchases in the whole world in a single block chain, Bitcoin is going to need chained unconfirmed transactions ASAP as well.   

Segwit fixes both of these problems fairly quickly.   There's a cool compression algo coming out that can also triple the rate without bloating the chain at a loss of anonymity... but I wouldn't relay on that vaporware.  Segwit is real and is the only tested solution to date.   (( Bitcoin Classic was probably OK too.. (simple 2MB fork), but it never got off the ground. ))

A block size increase is becoming a necessity that needs to be filled, and the faster the better. Transaction fees are becoming unbearable and to stop the ever increasing fees cost, the only viable solution is to increase the block size. Apart from that, the ever increasing growth of the network and the necessity of having a fast and agile payment network also makes the block size increase mandatory. Even Satoshi himself proposed the Block size increase as a viable solution for the bloating problem

IF 100% of users moved their funds to p2wpkh/p2wsh(segwit keys) then expect at best the 1mb baseblock for their signatureless tx data and 1.1mb for their signature data(in the witness area).

core provided a buffer beyond the 1mb base block of upto 3mb(witness area) totalling 4mb weight(total possible bloat). but its not how CB describes it..
as i said if 100% utilised segwit keys expect the data to achieve 2.1mb (1mb base+1.1mb witness used) leaving 1.9mb spare.

later this 1.9mb spare space wont be used for more transaction count growth (without increasing the base). but will allow core to add in other features. such as confidential payment codes which add an extra kilobyte to a tx.

EG
pre segwit
1mb=~2100tx right now
2009-2016 total =<1mb data for ~2100 tx

if 100% utilised segwit keys and activation by 2018
1mb base=~4500tx at most
1.1mb witness=the signatures
2017-2018 total =<2.1mb data for ~4500 tx

if 100% utilised segwit keys and activation by 2018 and CPC added later
1mb base=~4500tx at most
1.1mb witness=the signatures
1.9mb buffer=space for CPC or other bloat.
2018-20xx total =<4mb data for ~4500 tx

yes they are giving a gesture of upto 4mb of 'blocksize' but not giving 4x CAPACITY

emphasis
if only say 50% of people use p2wpkh/p2wsh keys only expect about 1.5mb blocksize (3300tx due to segwit)
if only say 10% of people use p2wpkh/p2wsh keys only expect about 1.1mb blocksize (2300tx due to segwit)
which when other bloated features are added
if only say 50% of people use p2wpkh/p2wsh keys only expect about 3.5mb blocksize (3300tx due to segwit)
if only say 10% of people use p2wpkh/p2wsh keys only expect about 3.1mb blocksize (2300tx due to segwit)

Segwit would have 2 types of block data: the 1st 1MB is the traditional block structure, and it can accept P2PKH and P2SH transaction types, plus the signatures for those transactions.

The 2nd type of block data would be the additional 3MB of witness block structure, which can accept only the signatures for the new P2WPKH and P2WSH transaction types. The actual transaction data will remain in the 1st 1MB of traditional block space. The fees for P2WPKH and P2WSH will be lower, incentivising their use.

Care to elaborate how? or at least give me a resource that I can read about it?

Yes

Adding an extra 3MB for signatures only

3MB

I am very curious to know "if" Segregated Witness is going to increase block size?

And if yes how is it going to do that?

And by how much?