hard=node and pool vote
soft =only pool vote..

what you dont realise is soft can also cause splits. and hard can also keep the chain united.

for clarity

soft and hard is simply:
soft: pool only vote
hard: nodes and pools vote

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

go check out cores bip9 orphaning blocks and node to get their 95%=100%.. oh and they can lower the trigger below 95%.
go check out cores UASF orphaning blocks and node to get their 100%.. oh and they can lower the trigger at any level

^ such basic understanding that has been known for over a year and it seems even now some cant grasp it

you still dont understand. if you think nodes only job is a data store. then please go read some code

alex.btc, a nice fresh well wrote post. and to highlight one point you made


segwit promises: 2mb-4mb block promise when activated.
segwit reality:at activation.. nothing.. people using standard UTXO (native/legacy tx keypair) will have their data stuck in the base block limit of 1mb (no gain for them). only segwit utxo spenders(users who have funds on segwit tx keypair) will have part of the tx data outside the base block.
meaning it requires people to spend their native utxo and move the funds into segwit keys.. and then when they spend the segwit UTXO then they are helping with the ratio inside and outside the base block.*

segwit promises: malleability fix promise when activated.
segwit reality:at activation.. nothing.. people using standard UTXO (native/legacy tx keypair) will have their data stuck in the base block and can still do malleability. only segwit utxo (segwit tx keypair) will move part of the tx data outside the base block. meaning it requires people spend their native utxo and move the funds into segwit keys.. and then when they spend the segwit UTXO then they are helping with the not malleating because they are disarmed.*

segwit promises: quadratic sigop fix promise when activated.
segwit reality:at activation.. nothing.. people using standard UTXO (native/legacy tx keypair) will have their data stuck in the base block and can still do sigop spam. only segwit utxo (segwit tx keypair) will move part of the tx data outside the base block. meaning it requires people spend their native utxo and move the funds into segwit keys.. and then when they spend the segwit UTXO then they are helping with the not sigop spamming because they are disarmed.*

*the issues:
trying to move 46mill native UTXO.. is a laugh to think will be 100% accomplished, especially in any rational time or ability to achieve
thinking 100% of users will voluntarily use segwit keys and stick to segwit.
thinking that malicious spammers/attacker would voluntarily use segwit keys, voluntarily disarming and de-spamming themselves.. is the opposite of the motives of said malicious spammers.

infact segwit opens up new attack vectors for these spammers. which will make it even harder for people to move funds across. and all this having to move funds just to try disarming themselves will be ADDING to the mempool spam

dont expect to get anywhere near 2mb of 'capacity' just like we didnt get 7tx/s in bitcoin 2009-2017 even when maths estimations suggested it was possible

segwit promises: keeps node costs down
segwit reality: 2mb of data is still 2mb of data for a full node no matter if the signatures are in the middle of a tx or end of a tx.. yea you can claim enabling prunned or no witness mode.. but then your no longer the upstream tier of a full node. and just part of the downstream lower tier cesspools of not full data nodes, thus might aswell just be spv/litenodes. they are not counted/treated as "full nodes"

segwit promises: keeps node counts up
segwit reality: enabling prunned or no witness mode.. they are no longer the upstream tier of a full node network. and just part of the downstream lower tier cesspits of not full data nodes, thus might aswell just be spv/litenodes. they are not counted/treated as "full nodes"
moving non segwit nodes off the network. again drops the full node count.

holliday
the BTC.Top statement of:
"We have prepared $100 million USD to kill the small fork of CoreCoin, no matter what POW algorithm, sha256 or scrypt or X11 or any other GPU algorithm. Show me your money. We very much welcome a CoreCoin change to POS."

is in response to cores threat of killing pools ASICS. he is stating he has $100m of funds to fight whatever ALGO CHANGE core nuke the network with.

its a defense not an attack.

as for gavins and Peter R
those too are again if dynamics get consensus and AFTER the grace periods they will do things before pushing the blocksize up. as the best ways to get the other implementations to pull their fingers out of their asses and be part of the PEER network of many diverse nodes.

........
however core is not a wait and let consensus happen and then rock the boat.
core have bypassed node consensus - error 1 they know it but instead of admitting it. they are now crying that its the pools fault
core have set a deadline which if not met is then FORCED on the community (bip9 and UASF)= still no free community choice
and core too have their attack the opposition code, but core want to utilise it before consensus. not after. meaning attack not defence

yet core are not going to back off if the community dont want it. core are happy to wait until November as it helps push tx prices up to get their commercial hubs utility ready. (blockstream are $70m+ in debt afterall)

where as other dynamic nodes set no deadline made no first strike threats to initiate pre activation... and if any diverse/dynamic peer node wanted to split the network without consensus they would have done so already.

core poke the bear hoping bu/dynamic implementations throw the first stone.. just so core can play the victim card.
yet dynamic implementations will wait for consensus before doing anything.... unless core try attacking with pool ASIC killing algo changes.

whats funny though. if core actually did change the algo. all that PoW hardware will happily jump to the side that allows PoW. as theres no point letting good hardware go to waste afterall.. instantly making core super weak with whatever algo they choose.

sorry but core cannot play the victim card by poking the bear

core: day one "fear splits they are bad they will destroy bitcoin
core: day two "you shold split off"
core: day three "please amicably split but you have to runoff"

meanwhile for the last two years+ all different diverse nodes that want to keep the decentralised PEER network alive have made no threats and added no nuclear detonation split button.

if core want to split they need to press their button because they are the only ones with them.

the answer is simple there is no actual "worth" of bitcoins by measuring the cap vs price...

simply you dont base bitcoins infrastructure and economy on the market cap.
i can make an alt tomorrow with 5trill coins. put just 1 coin on an exchange and sell it to myself for $1.. and suddenly my alt has a $5trillion market cap, all for the cost to myself of 1cent(1% exchange fee of the $1 trade)

you base bitcoins "value" on its UTILITY
but that involves not using stupid todler level maths. but actually look at the bigger things like monetary value of combined asics. the real audited worth of companies actively in bitcoin and other things.
but thats too complex for some people to understand/measure

1. miners make more money by competing and find any excuse they can to reject their competition..to have as many ACCEPTABLE blocks on the chain that the nodes can accept to see the rewards so that pools can spend their 'winnings'.. so following what nodes allow = able to spend winnings
2. pools can build any length height of blocks they want(privately). but if nodes reject them.. then places like coinbase and bitfinex are not accepting those blocks. and so the pools are not going to get paid because the exchange nodes dont see their(rejected) blocks

EG
NODES rejected this block of 1.000250mb in 3seconds.

and just like all other orphans that happen weekly(for many different reasons).. that work done to produce that non accepting block. is not acceptable to nodes. meaning pools wont be able to spend the rewards... once its in the reject/orphan trash.. its gone and forgotton

pools can continue building ontop it all they like(privately).. but if the node network reject it.. then pools cant spend it. pools end up wasting time playing hot-potato privately between themselves and exchanges never have to accept it. so its wasting the pools time for them to play silly games in their own little corner, because once its time to cashout.. they cant

miners are not given that power or limitless control
EG.
2009
upper limit 32mb.. lower limit was 250kb
2013
upper limit 1mb(consensus.h).. lower limit was 500kb(policy.h)
2015
upper limit 1mb(consensus.h).. lower limit was 750kb(policy.h)
2016
upper limit 1mb(consensus.h).. lower limit was 999kb(policy.h)

dynamics is for instance (dont knit pick the numbers just see the concept)
2017
upper limit 4mb(consensus.h).. lower limit was 1.25mb(policy.h)
2018
upper limit 4mb(consensus.h).. lower limit was 1.5mb(policy.h)
2018
upper limit 4mb(consensus.h).. lower limit was 1.75mb(policy.h)
then a rethink about the network speed capability
2019
upper limit 8mb(consensus.h).. lower limit was 2mb(policy.h)

policy becomes more fluid and adjustable based on MAJORITY nodes useragent display of their LOWER limit. but consensus.h stays static, pools see where a MAJORITY of nodes prefer their policy limit. and the MINORITY get a message that their policy.h needs changing or will be surpassed due to the minority having too low a policy.

but pools will not surpass the real main consensus.h limit

a few dynamic implementations are actually looking into having speedtests in the node to actually know what the node is actually capable of. to make nodes more self reliant on setting their limits without devs in a different county having to guess whats 'safe'

meanwhile it still means that ~25% are still abstaining either way.

trying to make jihan of 16% be the reason of 62% veto/abstaining against cores segwit. makes me laugh

get your grandchildren to ask again in 100+ years, and tell them to relax.. even then in a century they will still have a couple decades to prepare for the answer

core cry that splitting the network is bad.. sooo
core propose to split the network

laughing soo much

meanwhile many different dynamic implementations continue plodding along without making threats and just letting real consensus find its way.

---

core cry that setting deadlines are bad.. sooo
core propose a deadline

laughing soo much

meanwhile many different dynamic implementations continue plodding along without making threats and just letting real consensus find its way.

---

core cry when the price moves up and down and try making it sound important
meanwhile exchange move from $935 ⇘ $933 by a user with just $302(324mbtc)
meanwhile exchange move from $933 ⇗ $935 by a user with just $50(54mbtc)

(note trades measured in mBTC (0.001btc)

less than $302(324mbtc) to drop the price from $935 to $933⇘
yep $302 to make the market cap change by $32,470,200.00

then ~$50(54mbtc) to ramp the price from $933 to $935⇗
yep $50 to make the market cap change by 32,470,200.00

price movements are not a sign of any "community consensus" due low funds being used and also the high increments per orderline causing the volatility($1 gap per increment)... making it easy to make the market volatile without needing large community/whales

core crew gave THEIR votes to pools.

now trying hard to blame others.

so funny.

meanwhile many different implementations continue plodding along without making threats and just letting real consensus find its way.

while core are shooting themselves in the foot and pointing towards the anyone they can see to blame for it. and all finding the excuses they can to launch the nuke which they pretend others will fire first.

 

CK... you should know better
shame on you trying to make scare stories fud and propaganda..

even you know if NODE consensus does not exist, then whatever gets made which does not follow node consensus gets rejected in 3 seconds.
need proof:

try sticking with facts next time

cant even get your numbers right
there are only 16m coins in circulation

and if everyone was kissing his ass it would have been running by christmas

blah blah blah OP just reads reddit doomsdays rhetoric..

..
now to correct him with reality.

pools do not control bitcoin..
pools just collate data.

if they do not collate it in a way that NODES accept.. its rejected in 3 seconds..
need proof?

there... gone in 3 seconds.
need more proof?
https://blockchain.info/orphaned-blocks

as for thinking node consensus is not needed.

its core who have bypassed a node vote. remember its just a vote. nothing more.
pools didnt create the vote, pools did not create the code. pools did not beg to bypass node votes.
core and only core done that.

pools are 71% abstaining/vetoing. because nodes are not ready.
infact pools could vote. but pools even with 100% VOTE still would not actually MAKE new blocks unless they knew NODES would accept it. so pools are holding off and waiting unofficially for node consent.

if core want to resolve things.. there are 2 options

1. PROVE how backward compatible things are by getting their partner BTCC to make a segwit block with a segwit confirmed tx in it.. worse case rejected in 3 seconds.. best case nothing bad. and it instills confidence.
2. make it dynamic segwit. that way when people realise segwit activation day solved nothing(due to needing users needing to do other things beyond segwit activation).. atleast people are then able to move on with dynamics rather than waiting another 2 years for core to make more excuses

you are the centralist!!

how about just add a few lines of code to be dynamic with segwit.
get your own desires of being god/mommy removed.. and bring yourself down to being on a level of PEER. not the TIER network you want

P.s dont reply commenting about your own mommy complex..
only reply about:

GMAXWLL: if core want to resolve things.. there are 2 options

1. PROVE how backward compatible things are by getting their partner BTCC to make a segwit block with a segwit confirmed tx in it.. worse case rejected in 3 seconds.. best case nothing bad. and it instills confidence.
2. make it dynamic segwit. that way when people realise segwit activation day solved nothing(due to needing users needing to do other things beyond segwit activation).. atleast people are then able to move on with dynamics rather than waiting another 2 years for core to make more excuses

he has a point about forget the price and instead concentrate on the infrastructure..
as the concentration on the infrastructure will take care of the price as a side positive effect anyway..

but his understanding of the debate seems to be more of reading the reddit doomsday scripts, rather than the reality.

its core that have all the splitting the network crap. (bip9 that can activate below 95%) (UASF) (PoW algo changes).
core are the ones with wanting the TIER network not the decentralised diverse PEER network

if core is having issues getting consensus they need to NOT press their red button doomsday bombs but instead THEY need to compromise with the community.

the community was going with 8mb base block then lower then lower. and now even dynamic where (heres the truth) the nodes set the limits and pools follow what nodes prefer as a majority.(nodes have 2 limits. pools follow and adjust the lower limit not upper limit)

core can level themselves and unite their side with a few lines of code. rather then get everyone else to rewrite everything for cores half promises

..
as for the arguments of 'giving pools the power'
again only core have done this when they went soft.

...
the consensus was segwit would be accepted if a baseblock increase was part of the deal. core renigged that deal by pretending what they signed meant about just as much as asking their evening carpet cleaner to turn up. pretending they had no power.

core need to take a step back and do something the community want.

dynamics and segwit seems the only compromise which was the original late 2015 debate. so they need to reagree to do it. not hold the network hostage with their doomsday red buttons. while pointing the finger else where blaming everyone else.

they know they cant blame bU. because be has not big red button. they shouldnt blame pools because no matter what pools make, without consensus it will get dropped in 3 seconds.

core need to realise going soft and avoiding the community was CORES mistake, stop acting like gods, admit they are human and realise that the community is more important then devs god complex

---

Mr Madbitcoins and vinny think its a "roger vs" debate.. its not..
when will those blockstreamists wake up that there are many more people against cores dominance then just roger.
seems they are repeating that rhetoric to feel like core should win. by pretending there is no community divide by pretending its just a 1 man vs

they are both trying to say anyone against segwit is impatient..
yet its core making dadlines and threatening the doomsday buttons while trying to play the victim card.

the solution is simple.
core add just a few lines of code and give users more control and devs less control.

all the dynamic and base block increases are patient and not set deadlines..

---

im about half way through the video while writing all this.. and all i can see is 2 guys deep in the blockstreamist camp that have no clue about what segwit really does and actually works beyond cores 30 second elevator pitch.

all they care about is getting core activated without actually understanding it.
they pretend core are going slow.. yet core have all the deadlines and red doomsday nuke buttons. they only thing they are slow on is what was actually asked at the consensus meetings.

saves me rewriting...

its not about panic.. its market manipulation by the markets own programming and order limits.

if the only orders you can make are in $1 increments.. then thats $16m-is market cap change every time an order line is filled. even if that order line only contains 1mbtc (0.0001)

the fix is to allow more increments
EG not 0.934-0.935
but
0.93401-0.93402-0.93403-0.93404-0.93405
that way the price doesnt move by the whole dollar (volatile with no pressure needed/much coin needed).. but instead in cent amounts more smoothly

Whales??
lol

remember the prices and bitcoins are measured in mBtc (1 thousandth's)


it took only ~99btc (99,392mbtc) to move the price from $931 to $926

for all you fake market cap lovers out there..
under $100k to turn
$15,114,878,100 market cap
down to
$15,033,702,600 market cap

thats a drop of $81,175,500 using under $100k

---

edit few minutes later


less than $302 to drop the price from $935 to $933⇘
yep $302 to make the markt cap change by $32,470,200.00


then ~$50 to ramp the price from $933 to $935⇗
yep $50 to make the market cap change by 32,470,200.00

---

edit hour later


0.013btc ($12.13) to move the price from $950 to $948

thats $32m off the meaningless market cap..  yep $12.13 caused that