segwit started as an altcoin(elments project) with its own genesis block
segwit also rewrote thousands of lines of code just to become bitcoin compatible
segwit requires moving people away from native tx addresses to get segwit benefits
segwit requires banning and moving nodes around and orphaning native blocks

where as
BU is just a tweak to bitcoin code and people dont need to move funds just to get BU benefits
BU treats blocks under 1mb just as valid


so segwit should start a new genesis block

segwit is not the compromise

activating segwit solves nothing.
moving people to segwit keys after activation is then a 'percentage of solution'

never a complete 100% solving bugs, or never 100% fixing or never 100% boosting. because even after activation segwit will still be contending against native key users

also the 4mb segwit weight is not utilised.
AT VERY BEST the expectation is 2.1mb.. the other 1.9mb would be left empty.
segwit cannot resegwit again to utilise the 1.9mb extra weight.

the extra weight would be (from reading core/blockstream plans) with bloat data to include confidential commitments appended onto the end of a tx. (not extra tx capacity) to bloat a tx that would have, without confidential commitments been alot leaner

---

segwit also turns into a 2 tier network of upstream 'filters' and downstream nodes. rather than a equal network of nodes that all agree on the same thing.

for the reddit crew.. in simple terms. segwit fullnode = full data.. downstream= 'tl:dr' nodes

to answer your question is..

basically that BU and core already have the variables..

nodes: consensus.h policy.h
pools: consensus.h policy.h

and that all nodes have 2 limits although not utilitised to the best of their ability.. meaning at non mining level core does not care about policy.h

and the punchline i was going to reveal to Lauda about my example of dynamics.
BU uses
consensus.h (...) as the upperbound limit (32mb(2009), then 1mb for years and in the future going up as the hard limits EG 16mb)
policy.h (...) as the more fluid value BELOW consensus.h that if the node is in minority. can be pushed by EB or the user manually without needing to wait for events. which is signalled in their useragent eg 2mb and dynamically going up

core however, require tweaking code and recompiling to change both each time)

time to move these many topics about ETF price drop speculation.. to the economics speculation category.
agreed?

time to move these dozens of ETF price speculations over to the economics speculation category
agreed?

summary of 44 pages

trainscarwreck "bitcoin needs to stop development to stablise value.. b'coz nash nashafide it in his nashpaper"

.. but halting value(utility) will decrease value(desire) and decrease value(usefuleness) so im guessing you mean stabalise value(price)
which
"ETF denied" (unrelated to real bitcoin utility or blocksize,etc) but value(price) tanks

how about stop caring about value(price) and allow value(utility) to grow naturally.

you cannot make Apple Inc have more stable value(utility, desire, price, usefulness) by telling them to stop making anything better than 2001's apple ipod  
you cannot make Nintendo have more stable value(utility, desire, price, usefulness) by telling them to stop making anything better than NES

all you'll end up doing is killing the projects slowly.

predicting rebuttle
"guess you didnt read nash"

i think its time trainscarwreck. came to a conclusion.

he should write a summary of the last 44 pages (without streams of nash quotes or sprinkling his name) and just made one post with the ultimate summary of judgement and definition of 'value'.

oh and no insults

lol

blockstreamer: segwit solves quadratics, its a must, its needed. quadratics is a big deal and segwit promises to solve it
community: malicious users will stick to native keys, thus still quadratic spamming even with segwit active.. meaning segwits promise=broke
blockstreamer: quadratics has never been a problem relax its no big deal

i now await the usual rebuttal rhetoric
"blockstream never made any contractual commitment nor guarantee to fix sigop spamming" - as they backtrack earlier promises and sale pitches
or
personal attack (edit: there we have it, p.S personal attacks aimed at me sound like whistles in the wind)

i just quickly opened up microsoft excel and added some 'insert shape' and lines..
i use many different packages depending on what i need. some graphical some just whatever office doc i happen to already have open

1mb blocks allow a max blockchain growth of ~52gb a year
over the last 8 years (mainly the very first 6 years) blocks were not full which is why right now 8 years of data is not ~420gb
EG before 2013 blocks were less than half filled

however because demand is at a constant 1mb full now. expect ATLEAST 52gb growth/year
-whereby it would be ~52gb a year if we just stay stuck at 1mb blocks.
-whereby it grows beyond 52gb/year depending on demand with more than 1mb blocks being allowed

soft consensus (pool only)
or hard consensus (node or pool)

both actually need node approval. otherwise its orphan hell.(yep after activation segwit will stop native blocks bing built ontop of segwit blocks)

going soft just means only pools get to OFFICIALLY vote. but pools will UNOFFICIALLY wait for safe number of nodes even if nodes dont get OFFICIAL vote

segwit going soft is more about segwit alligned at the top of the network as the upstream filters(already set up (FIBRE).
segwit nodes will also white list other segwit nodes to receive segwit blocks blacklisting non segwit nodes(thus no old node being upstream)to then white or blacklist non segwit nodes downstream of who segwit wants to filter a block to. into a sesspool of nodes where some have been pruned. some have witness some dont. why by those nodes wont really communicate with each other due to lack of full data and other things.
(hense sesspool)

meaning the only true real validators are the upstream filters.
leaving the other nodes downstream as just unnecessary nodes, faking the true FULL VALIDATION node count. right up and to the point where the upstream nodes just blacklist all native nodes because their "old, pruned non full validators".. to then force native nodes to upgrade to segwit or be dropped out. (much like nodes refuse to talk to anything prior to v0.8 )

however because a bigger blocksize node uses normal block formation that doesnt need to be translated. doesnt need nodes to be in a certain order doesnt need to intentionally ban nodes nor does it need to PREVENT relaying new style unconfirmed tx's to old nodes to avoid new attack vectors.

the network of nodes allowing bigger blocks are all on an even playing field.

and all of this could have been achieved years ago in either GUI as an new options tab where users could adjust acceptable blocksize or a new RPC call in the debug console to change settings. thus users wouldnt need to beg devs after that for constant tweaks everytime the size increases because users could have done it themselves to stay on the network rather then becoming unsynced if a blocksize change occured

---

basically if segwit activated now
their would only be 3000~ true full validation nodes, other 3000 deemed as non full validation relay nodes
and also 75% of pools blocks would get orphaned and 75% of pools own nodes would be banned
..
if segwit waited for 95% pools(where by node count didnt change). 5% of blocks wold be orphaned and 5% of pools would be banned
and still only 3000~ real full validation nodes.. other 3000 deemed as non full validation relay nodes

the funny part is.

making bigger blocks doesnt need rocket science.
as you say its just a couple lines.

so when you hear "its just a clone of core with some tweaks" turned into "they cant code"
the real mindset should be

simple fixes dont need complete re-writes.

so although aliceWM you may run a core client with support of bigger blocks . your essentially making XT or classic.
if you make it dynamic. thats essentially BU

and instead of people seeing it as 'simple solutions dont need complete re-writes'. you will be hit with the same 'you cant code' rhetoric
and if you did rewrite ever line.. youll then be hit with 'not peer reviewed by king gmaxwell'

..
what you want to do is exactly what has been done.. take core tweak it and release it.
but all its been met with is doomsday rhetoric because king gmaxwell has not approved it

LOL

well if everyone just stuck with "core"
there are still many versions

0.8-0.14
all with different lines of code settings and rules(i would mention 0.1-0.7 but then the rules really do get funky... thank you sipa for the levelDB bug)

some have mining settings in them to only make blocks of 0.75mb
some have fee priority. some have different relay fee limits
some have good some have bad fee estimation functions

but oh wait.. you will backtrack and defend different versions suddenly. but then argue all you worry about truly is that its not created by king maxwell.

do you know why satoshi disappeared. because everyone 'depended' on satoshi as king.. and he wanted it to be an open source project with no king.

P.S if your stance is only core should be on the network then admit your a centralist, get it over with

^ failing to stroke the sheep to sleep

if spammers fill the base block with native keys. there is no "extra" room

the witness is just a ratio of the base.
its not like the whole segwit tx can sit in the 1mb witness area safe as a separate room of a house.

its analogically more like more footspace on a plane, rather than needing to buy 2 seats to put ur feet up
(base=seats, witness=foot area, other weight left=baggage area (for future features that can append onto the witnes later but useless now)
the issue is:
1.stampede for seats fills the plane
2.the new tx's doesnt reduce mempool utility (full txdata and witness still take up mempool space)
3. if fat natives buying up 2 seats to put their feet up, then anorexic segwiters have to wait longer at the terminal

seems CB thinks he can just not worry about the seats (base block) and just have his entire body on the floor (witness area) or sit in the baggage area (empty weight)

not even sure why he brings up the 4mb number as thats just an un-utilised buffer that cant be filled with anything for a long while.. at best hope is ~2mb
the 4mb weight is not 4mb of capacity. its just extra baggage space for future features

basic maths already done of 2 months(if everyone moved at same time).
but as CB said due to normal transactions wanting their space too . it will be more than 2 months.

oh. and need we forget malicious spam attackers WILL stick with native keys. after all why would they give up their weapon and disarm themselves

mhm
dont think 7billion by midnight.

think rationally. like 1billion over decades.. then your fears start to subside and you start to see natural progression is possible

bitcoin will never be a one world single currency. it will be probably in the top 10 'nations' list. with maybe 500mill people. and it wont be overnight. so relax about the "X by midnight" scare storys told on reddit.

be honeest, if you dont know, just try not to act lik you know.

the reason they havnt added the ability. is the risk of an 'anyoncanspend' attack if segwit keys were used prior to activation.
the delay of weeks is to ensure enough segwit blocks are produced to avoid deactivating. and also to get the native nodes reset as downstream by banning the upstream nodes to ensure other attacks cant be played out


46million unspent outputs

learn consensus.

oh did you know that segwit at activation bans certain nodes from being upstream and bans certain blocks that are not in a segwit format.

its worth learning these things.

soft doesnt mean safe. soft just means node bypassed

id love to see you in a super market, be told a stick of gum was a few cents..
you reach in your back pocket and take out what you think is a dollar and say keep the change.

then realise... it was a $100 bank note.

trying to be my very unbiased

no point running v0.14
... unless you want to do tests on testnet. as thats the only way to really play with segwit.

if you want a node just for normal usage on bitcoins mainnet, no point running v0.14

and lets say sgwit activated later. it does not fix anything at activation.
however WEEKS after activation core will release a version that includes the segwit wallet (yep segwit keys cannot be used in 0.13.X or 0.14).
v14 only includes native key usage on mainnet.

normally best to wait it out. for that post activation version to save you hassle of redownloading twice in x months

0.13.2 shows the 'support' if thats what your hoping. and 0.14 doesnt support any less or more the 'vote'
all im saying is if your just a normal user and not looking to do tests on testnet involving segwit. no point downloading an update now to just download again another later if your hope was to use segwit on the mainnet

imagine a case where there were 2 limits.(4 overal 2 for nodes 2 for pools)
hard technical limit that everyone agree's on. and below that a preference limit (adjustable to demand of dynamics).

now imagine
we call the hard technical limit (like old consensus.h) that only moves when the NETWORK as a whole has done speed tests to say what is technically possible and come to a consensus.
EG 8mb has been seen as acceptable today by all speed tests.
the entire network agrees to stay below this, pools and nodes
as a safety measure its split up as 4mb for next 2 years then 8mb 2 years after that..

thus allowing for upto 2-4 years to tweak and make things leaner and more efficient and allow time for real world tech to enhance.
(fibre obtic internet adoption and 5G mobile internet) before stepping forward the consensus.h again

---

then the preferential limit(further safety measure) that is adjustable and dynamic (policy.h) and keeps pools and nodes inline in a more fluid temporary adjustable agreement. to stop things moving too fast. but fluid if demand occurs

now then, nodes can flag the policy.h whereby if the majority of nodes preferences are at 2mb. pools consensus.h only goes to 1.999
however if under 5-25% of nodes are at 2mb and over 75% of nodes are above 2mb. then POOLS can decide on the orphan risk of raising their pools consensus.h above 2mb but below the majority node policy

also note: pools actual block making is below their(pools) consensus.h

lets make it easier to imagine.. with a picture

black line.. consensus.h. whole network RULE. changed by speed tests and real world tech / internet growth over time (the ultimate consensus)
red line.. node policy.h. node dynamic preference agreement. changed by dynamics or personal preference
purple line.. pools consensus.H. below network RULE. but affected by mempool demand vs nodes overall preference policy.h vs (orphan)risk
orange line.. pools policy.h below pools consensus.h


so imagine
2010
32mb too much, lets go for 1mb
2015
pools are moving thier limit up from 0.75mb to 0.999mb
mid 2017
everyone agree's 2 years of 4mb network capability (then 2 years of 8mb network capability)
everyone agree's to 2mb preference
pools agree their max capability will be below everyones network capability but steps up due to demand and node preference MAJORITY
pools preference(actual blocks built). below other limits but can affect the node minority to shift(EB)
mid 2019
everyone agree's 2 years of 8mb network capability then 2 years of 16mb network capability
some move preference to 4mb, some move under 3mb some dont move
late 2019
MINORITY of nodes have their preference shifted by dynamics of (EB)
2020
MINORITY nodes manually change their preference to not be controlled by dynamics of (EB)
late 2020
MINORITY of nodes have their preference shifted by dynamics of (EB)
2021
MINORITY nodes manually change their preference to not be controlled by dynamics of (EB)
mid 2021
a decision is made whereby nodes preference and pools preference are safe to control blocks at X% scaling per difficulty adjustment period
pools preference(actual blocks built). below other limits but can shift the MINORITY nodes preference via (EB) should they lag behind

p.s
its just a brainfart. no point knit picking the numbers or dates. just read the concept. i even made a picture to keep peoples attention span entertained.

and remember all of these 'dynamic' fluid agreements are all extra safety limits BELOW the black network consensus limit