Q? (OP)
Newbie
Offline
Activity: 15
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/question.gif) |
February 07, 2017, 10:52:35 AM |
|
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?
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 07, 2017, 10:54:43 AM |
|
Yes
Adding an extra 3MB for signatures only
3MB
|
Vires in numeris
|
|
|
Q? (OP)
Newbie
Offline
Activity: 15
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 07, 2017, 11:03:36 AM |
|
Adding an extra 3MB for signatures only
Care to elaborate how? or at least give me a resource that I can read about it?
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 07, 2017, 11:15:27 AM |
|
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.
|
Vires in numeris
|
|
|
franky1
Legendary
Offline
Activity: 4326
Merit: 4661
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 07, 2017, 11:20:26 AM Last edit: February 07, 2017, 11:40:53 AM by franky1 |
|
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)
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
Blawpaw
Legendary
Offline
Activity: 1596
Merit: 1027
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 07, 2017, 12:15:29 PM |
|
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
|
|
|
|
earonesty
Newbie
Offline
Activity: 42
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 06:11:12 PM |
|
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. ))
|
|
|
|
AngryDwarf
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 06:25:30 PM |
|
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?
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 06:46:49 PM |
|
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.
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.
|
Vires in numeris
|
|
|
unamis76
Legendary
Offline
Activity: 1512
Merit: 1012
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 07:03:53 PM |
|
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.
|
|
|
|
AngryDwarf
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 09:20:05 PM |
|
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.
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. 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?
|
|
|
|
franky1
Legendary
Offline
Activity: 4326
Merit: 4661
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 09:40:51 PM |
|
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?
there is no "user activated soft fork" in short soft=pools only hard= NODES then pools save repeating myself: below these umbrella terms is what could happen.. in both hard and soft it can either continue as one chain. or bilateral split softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead softfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains
hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead hardfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains
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
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
AngryDwarf
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 09:46:37 PM |
|
native nodes are no longer full nodes..
Is this not the problem (potentially) with both BU and SFSW solutions?
|
|
|
|
AngryDwarf
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 09:48:08 PM |
|
having a proper hard consensus that puts everyone on the same level playing ground
Sounds like the correct way forward on my limited knowledge.
|
|
|
|
franky1
Legendary
Offline
Activity: 4326
Merit: 4661
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 09:57:27 PM |
|
native nodes are no longer full nodes..
Is this not the problem (potentially) with both BU and SFSW solutions? 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.
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
AngryDwarf
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 10:00:23 PM |
|
native nodes are no longer full nodes..
Is this not the problem (potentially) with both BU and SFSW solutions? 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. but it opens up new attacks too. 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. Which is probably why 95% sustained segwit activation signaling is needed. It's uglier and more dangerous than a coordinated hard fork.
|
|
|
|
franky1
Legendary
Offline
Activity: 4326
Merit: 4661
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 10:05:59 PM Last edit: March 06, 2017, 10:17:43 PM by franky1 |
|
Which is probably why 95% sustained segwit activation signaling is needed. It's uglier and more dangerous than a coordinated hard fork.
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
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
DooMAD
Legendary
Offline
Activity: 3892
Merit: 3179
Leave no FUD unchallenged
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 10:45:40 PM |
|
there is no "user activated soft fork"
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". ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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.
|
|
|
|
franky1
Legendary
Offline
Activity: 4326
Merit: 4661
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 06, 2017, 10:58:30 PM |
|
there is no "user activated soft fork"
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". ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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. 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'
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
|