most are just grammar nazi's editing copyright dates or words in the documentation/comments/readme files..
and most are just hoping one day they can get a line of code in somewhere to get noticed enough to get paid by blockstream

but when you look at who is moderating the IRC/tech discussion forums/mailing lists/bips

those 100+ unpaid guys dont have much sway unless they kiss ass first

with all that said.

if you stop reading the reddit FUD drama scripts. you will see that the implementations that are not blockstream endorsed DO NOT want to split the network

they were even offered to split the network many times and refused to take the offer.
they want to stay with a united diverse peer network.

the only group making threats of PoW changes, mandatory dictatorships with deadlines and threats. are the blockstream teams.

non blockstream endorsed implementations are just plodding along waiting for consensus. REAL consensus (node and pool)

the real funny part is. the blockstreamists cry that network splits are bad, but under the same breath are begging non blockstreamist to F**k off.
its all empty drama

bitcoin is bigger than "pools have the power"
bitcoin is a symbiotic relationship between nodes and pools

non mining nodes are not just database backups. nodes provide a crucial security mechanism too. which ensures that a simple 51% attack wont cause control issues. and pools have a security mechanism that prevents node sybil attacks wont cause control issues.

thats the beauty of bitcoin.

anyone saying non-mining nodes are meaningless are only saying that because they want to get you to shut down your non-mining node so that it sways the protection of that symbiotic relationship.

pools can have 30000000000exahash and make every block(that pool makes) in a certain funky format very quick.
but if nodes are rejecting those blocks in 3 seconds. they just look for another block from another source that does meet the rules

pools can make new blocks every 4 seconds and build ontop of themselves all they like (within their own local server) but if the network is rejecting that pool. they just wait for the other pools and accept a block that meets node rules..

meaning merchants never see the 30000000000exahash blocks reward because that pool trying to spend its reward had its block rejcted 100 blocks ago.
that pool realises its wasted all its hashpower making 100 blocks that merchants are not seeing.. so the pool cant spend it. thus the 30000000000exahash pool has a choice

continue wasting time making literally orphans in the hope nodes download a new version to accept 30000000000exahash pools blocks.
or
go back to make blocks that do fit the node consensus rules so merchants see the block as normal and the pool can spend its rewards

if there is going to be a hard consensus to move to adaptive /dynamic blocks. then there would not need to be the 1:3 ratio of a block inside a block.

instead at a point where all the nodes are ready to accept adaptive blocks, validating segwit can be part of standard consensus.. meaning it can be just a single block format that allows
(TX input)(sig)(TX output) - native/legacy tx
and
(TX input)(TX output)(sig) - segwit
all in the same block area

thus allowing a CLEAN single merkle block where people that want to use segwit tx's can.. and those who want to remain with native tx's can and then that unites the community because there is no cludge of tier networks of stripping blocks apart and compatibility issues between different nodes.

---

---

also

this would cause orphan risks of when nodes rescan the block chain

if 2016 blocks were X then the next time 2016 blocks were y(=x-0.01)  with the rules being Y.. all the X blocks would get orphaned because the 2016 blocks that are X are above the current Y rule.

there is a symbiotic relationship.

full nodes exist, not just as a data backup, but as rule checkers too
nodes(non-mining) do have a an important role to play too..

thats the beauty of bitcoin..

yes there is a risk of sybil attack.
hense the need for diverse decentralised nodes

yes there is a risk of 51% pool attack.
hense the need for diverse amount of pools

i mean ALL nodes

pools can if they wanted, push out a block in any funky fashion.. but if nodes dont accept it.. it gets rejected

look at the 2013 saga
although pools thought 1mb blocks were acceptable.. as soon as they made a block that went over 0.5mb
half of the network (non-mining) nodes were not accepting the block.

this caused lots of drama of merchants not seeing certain blocks, and many things. and lots of orphan drama occured.
pools learned a lesson to not just push forward unless the nodes would accept the blocks meaning the merchants would see the blocks for pools to be able to spend their rewards.

this caused decisions to be made to get the nodes to unanimusly upgrade to a version that would accept a certain block formation. and they even altered the DNS seed to only list nodes that would accept a certain block formation, which is why there is no DNS listing of <0.8 anymore and no nodes on the network running <0.8 anymore..

because (non-mining) nodes of <0.8 would reject blocks of over 0.5mb data

at the moment
34% sgwit flag https://blockchain.info/charts/bip-9-segwit
49% dynamics flag https://blockchain.info/charts/bitcoin-unlimited-share
=17% abstaining

lets say there was 100% dynamics flag for pools.. but at node level
only 10% nodes would accept a block over 1mb.. if a pool actually make a block any different than native rules. it would get rejected in 3 seconds

lets say there was 100% segwit flag for pools.. but at node level
only 66% nodes would accept a block in a segwit format. if a pool actually make a block any different than native rules. it would get rejected in 3 seconds by the nodes that dont have a segwit node to 'filter' 'bridge' them a stripped version.

the node network is slowly reconnecting and becoming a tier network, of the segwit nodes being directly connected to pools to allow the whole filter(gmax buzzword) bridging(luke jr buzzword) to help with the 'backward compatible' pretense.

its still not a perfect network setup and can still cause orphan drama.. so pools wouldnt try it if there was more then a few percent orphan risk.

this is why i said to gmax.. if segwit is so 'backward compatible' as promised. go get btcc to make a block thats segwit on mainnet and see how acceptable it is to give pools confidence to flag it..

gmax now knows that segwit is not as 'soft' / compatible as he/they promised in 2015 (before having production ready code..)

but in short
only counting pool flags is meaningless,

pools can display a preference at any time. but unless they see that the orphan risk is low. they wont actually create a new block formation of new rules unless the risk of orphan is low.

EG a pool can happily write "i want 2mb" ... but they wont actually make a 2mb block unless they were assured a good node consensus would accept the blocks

pools can collate data in any fashion they like.. but if nodes see it doesnt follow node rules that block is likely not to get accepted by the network..
because just making a block that doesnt follow consensus rules means nodes reject itin seconds then wait a few seconds for another pools that has a solution that does fit the rules and accepts that one instead.

thats what the consensus/orphan security feature is all about.. thats what makes bitcoin better than just a mysql database..

pools who see that nodes are not at a consensus level to ensure the risks of orphans is only a few percent max. are not gonna change the rules so easily.

people can make as much social drama on forums as they like but unless there is good node consensus smart pools wont push forward. even if they are waving flags of adoration..

in short
NODES DO MATTER

what is
yep mandatory changes, nuking pools, dis-communicating with the natives, does very much sound like government agency talk.

ok guys put aside all the biased rhetoric and biased defense arguments.. and think real hard
who in late 2015 decided to make the vote pool only.
who bypassed the security of node consensus
who decided that bypassing nodes, which if not bypassed would have ensured a good full node count first to elevate pool orphan risk to then give pools more confidence to change the rules wouldn't hurt their change of winning blocks

pools didnt have the power of vote/veto until someone gave them that power.

this is why a node consensus first, then a pool consensus second would have worked better.

core shot themselves in the foot before they even started walking with segwit

whats the deal with:
https://bitnodes.21.co/nodes/?q=xbadprobe:1.0

xbadprobe:1.0
seems theres near 100 of them on amazon servers

who's the ones with the PoW nukes?
who's the ones with the absurd banscores?
who's the ones with the manditor dictatorship deadlines?

meaning non-blockstream endorsed nodes make no threats and just plod along offering a free choice. no threats, no deadlines, no asic killer agenda

can someone please pass lauda the reality stick, i feel he needs to hit himself with it

segwit is the compromise..

in terms of making it easier to trojan horse in new features softly by compromising the security and decentralisation of the network

compromise= weak/break security
not
compromise= agreement to end debate

lets just wait for another brand to use the 'soft exploits' to add features.. but this time something not blockstream endorsed.. and then see lauda rage that going soft is bad..

then he will be a hypocrit for his going soft is good stance.. when it hits him in the face

OP is on about double spending with services that accept ZERO confirms..

EG
TX A
send out a TX with a crap fee that you know will delay the Tx for an hour..
direct that TX toward the zero confirm service you want to scam..

then
TX B
when you get the instant service you were hoping for.
send the same unspent input(because its not confirmed) again.. but direct the output back to your wallet with a great fee.. (this is called RBF)

also prep the next tx(TX C) spending the (TXB)(still unconfirmed) to again go back to your wallet again with a great fee.. (this is called CPFP)
to really amp up the pressure for pools to accept txB and reject and never confirm TX A..

then you just wait for TX B to confirm and then TX C to confirm..
while the zero confirm service you want to scam.. gets scammed

yep even segwit does not solve this.
funny part is. core pretended removing malleability would fix double spending zero confirms... yet core then added RBF and CPFP.. making double spending still a big issue that remains unsolved

YOU WERE saying by taking people away makes the time double, triple quadruple.. not me

but now you are switching so now you are proving my point
my point is that everyone is independant and there is only one winner.. i never said its cumulative.. it was you that said it was cumulative by suggesting take 90% away and people will be waiting hours..

they wont..
AGAIN
have an olympic 100m race of 10 guys.. the winner gets to the end in 10 seconds..
now imagine if he was shot..
the runner up WONT!!!!!! have got to the other end in 20 seconds.. he would have got there in about 10seconds (plus a few miliseconds)

shoot all 9 runners so there is only 1 runner.. that last runner. again would still reach the end point in ~10 seconds.

based on YOUR scenario of everyone having 10% of hashrate. ill show you what i mean
YOUR (wrong) scenario:
"In other words, if this pool has 10% of all the hash rate, when his peers have mined 90 blocks on the new chain, he will have mined 10 blocks on the old chain. "

AGAIN only winning 1 block an hour does not mean your X* slower than anyone else.. it just means your competing against X number of people and 1 of X times you happen to be milisecond faster that anyone else.

you wont find runner 1 =10seconds
you wont find runner 2 =20seconds
you wont find runner 3 =30seconds
you wont find runner 4 =40seconds
you wont find runner 5 =40seconds
you wont find runner 6 =40seconds

you will find they are all close by each other yes a difference in hashrate can make a difference .. BUT so can LUCK of the randomness of the solution

take your example again
"In other words, if this pool has 10% of all the hash rate, when his peers have mined 90 blocks on the new chain, he will have mined 10 blocks on the old chain. "
if 9 pools went off and mined on chain X and 1 pool remained on chain A

after say 900 minutes
pool1chainX =~10 blocks taking ~10 minutes EACH block
pool2chainX =~10 blocks taking ~10 minutes EACH block
pool3chainX =~10 blocks taking ~10 minutes EACH block
pool4chainX =~10 blocks taking ~10 minutes EACH block
pool5chainX =~10 blocks taking ~10 minutes EACH block
pool6chainX =~10 blocks taking ~10 minutes EACH block
pool7chainX =~10 blocks taking ~10 minutes EACH block
pool8chainX =~10 blocks taking ~10 minutes EACH block
pool9chainX =~10 blocks taking ~10 minutes EACH block
(totalling 90 blocks with average 10minutes)

and
pool1chainA =~90 blocks in ~900 minutes
pool1chainA has no competition to lose by, by seconds

check out the orphan timing
https://blockchain.info/orphaned-blocks
the runner ups are SECONDS behind each other not minutes/hours


465722    
Timestamp    2017-05-10 08:19:11
Number Of Transactions    2752
Relayed By    Bixin
   
Timestamp    2017-05-10 08:19:10
Number Of Transactions    2726
Relayed By    GBMiners

your not getting it at all!!

ok try this..

imagine the olympics 100m

5 guys.. they all run
average is 10 seconds to get to the other end, and only 1 guy wins

now then, you ask the 5 guys to run the length 6 times..

out of those 6 times there is a guy that only wins once..

does that mean if he was the only runner it would take him 60 seconds.. no

because the game is run for 10 seconds and reset.
all the guys run within milliseconds of each other but there is only one winner, the timings of the other 4 guys per race are not multiples of the first guy, but miliseconds behind the first guy.

blockstreams tier network

vs

node consensus per network using consensus to grow without blockstream spoonfed limits...

you think the tier network is less centralised??

here is a lesson
1. unless nodes (important) are there and united and same level playing field to save off large orphan risks... pools wont do anything.

this means nodes have to unite around a consensus first. then pools will follow.
that is where blockstream went wrong.. trying to bypass nodes by going soft.
smart pools wont do anything unless nodes are there..

pools have said many times they wont do anything if theres more then a few % risk of orphans as that will hurt their income.
they can wave a flag or a hat to say they support something but they wont actually create it at any activation date if ther is orphan risk.

so its nodes that matter most.

solution.. ASK THE COMMUNITY FOR A SHOPING LIST OF FEATURES EVERYONE WANTS. and all unite in building a version of the protocol in all the different brands/langages that fulful that list.

call it planB
EG core v0.15B
EG BU vX.xB
EG classic vx.xB
and so on.

yep that means stop using these several roundtable meeting to be used as bribes and ass-kiss events.. but to actually use their EARS to listen and actually settle on features that will actually unite the community and solve the issues

things like
limiting tx sigops to 4k or below IN CONSENSUS.H
allowing a hardish rule for blocksize of 8mb (long term debate ender (even core devs and others know 8mb is network safe))
and allow NODES to set a secondary preferential limit amount below that, starting at say 2mb. that is dynamic. (yep EC)

thus keeping POOLS inline with majority below preference and way below consensus.
(imagine it like nodes having a lil more sway over when/if pools should have moved beyond 0.5mb in 2013, even while the 1mb consensus existed)

thus letting nodes have a little more say in when pools increment up without actually causing real orphan stress/drama
other features like xthin and compact blocks finding a united way to communicate across the network between the different brands and get the data they need.
where by the core devs WORK WITH other implementations (OMG did i just say core devs should try being independent and help the network.. yes i did)

probably from your groupy reddit scripters wondering how to hide adam backs CEO puppetry and barry silberts VC extra strings.. by then pretending other implementations have strings..

TL:DR;
dont look at the blockstream puppet strings, look over there we can see everyone else is tied up. but please dont look at blockstreams puppet strings

ever ask yourself.. why within the same month of samson promoting UASF. organising a bounty, declaring a winner and delivering the bounty to the winner, samson also got a new job with blockstream..

let me guess your answer, because his job is just to be a janitor, sweeping the floor.
much like luke Jr pretending not to be a developer at the hong kong agreement but just an individual with as much power as a janitor

P.S
lauda stop defending blockstream employee's.

whats on his head. is that a badger?? nope its a UASF cap