sorry but there is only
/Satoshi:0.13.2/   895 (16.22%)
/Satoshi:0.13.1/   1631 (29.58%)
truly signalling for segwit
the 0.13.0 doesnt include the flag..

so its 46%(2526).. which others have said maybe running it just to be "prudent" (eg those just running 0.13.1) just to have minimum requirement to retain being full validation of segwit. but not wanting to get to involved in by continually upgrading beyond that.

some dont even understand what they are downloading. they just want to stay uptodate with whatever is pushed out. so they are not actually fully informed and explicitly voting for it. they are just running a node.

so the communities node uptake of say 30% explicit, 46% implicitly voting and pools explicit voting 18% explicitly, 32% implicitly.. both show that there are over 50% explicitly undecided.

mimblewimble.

easy term to google

randomly grabbing other peoples transactions without needing their interaction*. to mix them together (part of a coinjoin) and then put the funds back into addresses of who is owed what.

Blockstream mathematician Andrew Poelstra is working on it now.
*the concept is to bypass and strip away the old scripts that check signatures (violating bitcoins current security) and instead replace signatures with a CSV revoke code. where mimblewimble can grab unspents.. coinjoin them and put them into new blocks thus able to prune away old blocks because they no longer contain unspents.

at the moment they are playing around with it on a altcoin but conceiving doing it on bitcoin. basically ruining peoples personal security of their own funds purely so some mimble manager can move funds about at will..
but yea blockstream will say you can trust them to repay people..(facepalm, infact double facepalm)

---

as for me claiming things without showing any actual proof. lol i spend alot of time showing proof and even ELI-5 (explaining like your five) the rational logistics of how things work in realistic scenarios. i try to get passed all the convoluted buzzword and sweeping under the carpet of blockstream hype

---

as for saying the majority of people are decentralists.. your right there are millions... but blockstream devs are not decentralists. they are centralists. 12 main devs and 90+ of their unpaid interns (out of millions of users)

remember the devs of 2009-2013 are different to 2013-2017
remember bitcoin core brand took over bitcoin qt - they chose the word 'core' because they want to be at the core(center) of bitcoin. the engine of bitcoin
remember people who now have employment contracts also have employment terms
remember peoples ethics and morals can be tweaked for a price.

so dont trust a dev because of their history.. instead only understand a dev based on current actions.

want to know who is suggesting it most.

yep your favourite team that want to do it as part of a future pruning feature update (not same as current pruning feature)

agreed.
and the only way merchants(businesses) can prepare properly is if they had a proper working segwit codebase. and not just this half-ish release thats just a 'flagger' version0.13.2 (no segwit wallet feature). yep even core are refusing to release the full segwitwallet version. only spoonfeeding a flagger version until they get what they want.

ever wonder why core are going for a pool first user second approach.. especially if everything is suppose to be soft, not dangerous and backward compatible?

here is a mindblowing thought for the centralists

btcc already prioritises its own exchange customers transactions to get into a BTCC block first.
how about blockstream make sure segwit transactions relay to btcc and btcc just add segwit tx's to their block.

after all,
once its in a block, its all *cough* supposedly *cough* backward compatible, right*.. and not going to cause an issue for the network.
so other pools wont reject it and other nodes wont reject it.. right?

wasn't that the promise, segwit blocks being just like legacy blocks. segwit confirmed transactions being passed as ok

so make your damned segwit transactions and get them sent to btcc(and slush) and let btcc(and slush) add them to a block and see what happens.
in blockstreams promise theory. nothing bad, but with the only downside being that segwit transactions have to wait until BTCC(and slush) solves a block. which is roughly once an hour.

atleast then we can see if blocks get orphaned or are accepted as promised. which then shows how soft segwit really is.
that would give confidence to pools more so then proposing an intentional split.

think rationally

*im about a year ahead of most peoples possible scenarios including the anyonecanspend scenario which while they wont admit it, caused core to hold off on releasing a working 'segwit wallet' aspect of a full node until after activation. due to anyonecanspend being an issue

LOL
seriously??
i have emboldened the part where it reveals that you are not actually a dev or have technical knowledge or even basic understanding of bitcoin
you sound like just some webmaster that gets other people to code a website. and have nothing to do with bitcoin code

you seriously want to consider doing an intentional controversial split. and not only that. destroy the security of bitcoin .. purely to force a softfork in.

do you even understand what you have proposed. seriously!!

its obvious you are part of theymos's crew of blockstream loving centralists. where you, just like gmaxwell are getting desperate.
im guessing blockstreams next tranche of financing is dependant on getting segwit green lit to start the commercialisation and make returns to the investors.

how about the blockstream centralists stop thinking about your fiat riches and instead think about bitcoin. get the devs to loosen their control of bitcoin and just let consensus decide.

yes i know you are going to rebuttle that if segwit fails then consensus has failed. when in actual fact it has worked by not allowing something that is not needed.
i know blockstream centralists will double down and proclaim that bitcoin needs a human government of force heading up things because they believe consensus cant look after itself. but yet again the opposite is true

he is probably drinking it up with the other centralists in miami

have you even read segwit code
have you even run scenarios
have you understood the reality.

...
or have you just looked at someone else who said it was great and trusted them because you think they know whats best, so you simply took it on faith

when sheep follow sheep all they see is the woolly ass infront of them

i dont mean to attack you personally but hopefully it will prompt you to research and see beyond whats been placed infront of you

easiest reply is

while people cry about bitcoins electric which is spread out across the world.

think about the amount of lightbulbs and neon signs on the streets
the lights and aircon in hotelrooms and casino's

being wasted to try making poker chips something of value in las vegas

oh and to put it into perspective 400,000mw/year for one city. VS 94,900mw/year for bitcoins international protection.

or think about american banks. 90,000 american bank branches with 10pc's per bank branch = 3,942,000mw/year
and thats before including all the HQ's, call centres, clearing houses, ATM's, the mint, fed reserve, nasdaq, and all the security firms offices.

bitcoin international: 95k
las vegas: 400k
american banks: over 4mill

pools wont vote for either side unless they know nodes can handle it.. pools are smart enough to know about the risks of having nodes that cant validate data.

thats what the 65% undecided are waiting for..

it should have been a node consensus first, pool consensus second strategy.
not a pool first, node second.

you mean instead of aircon/fans to cool the asics..

eg
have a chimney that sucks the heat up and away from the asics and through a pipe that then goes to a generator or to heat water.
yep that can gain some efficiency, but not much.

---

as a side note people need to know. that power stations are already producing a minimum amount of electric. even if not being used they need to be running. so electric gets wasted.

at the moment the world is trying to convert Mongolia into a developed country. so having a power plant producing X, but while the area is not developed only 0.001% of X is being used, so 99.999% of X just gets wasted and unused.

letting asic farms use 0.y% of X on the cheap helps the asic farm and also helps the power plant from just wasting X, while the region grows and develops its residential, industrial and retail to then utilise X aswell.

and this CV who will it be handed to when these devs want a job and move away from working on bitcoin?
and ALL the money(fiat) where is it coming from.

yep
core devs are getting paid by bankers and want jobs working with bankers.. look at blockstream getting into bed with hyperledger.
look at all the unpaid blockstream fanboys working as interns showing off their loyalty to blockstream hoping for a job with blockstream and the banks.

this is what LN is about. but with one extra feature the OP has missed.  multisigs

Bob and Alice both transmit an public key to each other of both a bitcoin and litecoin format.(empty address contains no funds)
1bobsbitcoinaddress
1alicesbitcoinaddress
these are both combined to create the bitcoin multisig
3bobaliceBTCmultisigaddress

Lbobsbitcoinaddress
Lalicesbitcoinaddress
these are both combined to create the litecoin multisig
3LbobaliceLTCmultisigaddress

alice puts the altcoin into 3LbobaliceLTCmultisigaddress
bob puts the bitcoin into 3bobaliceBTCmultisigaddress

now the funds are inside locked. the funds need both sides to sign each multisig. meaning not one person can move the funds alone
because both the multisigs have CLTV and CSV both parties have a mutually agreed destruction penalty if they dont agree to sign

now your twisting things again.
the pools are not the government but the pools are the ones that collate the data for the nodes to validate to confirm or reject. the pools need to know what is the acceptable format and flag their acceptance of that format.

your twisting consensus. please learn consensus

yes consensus  of 5000+ nodes and yes pools are a node too decide what format is acceptable.
but its the nodes that decide the general agreement of what format is acceptable .. then the pools pools flag to agree on producing that format. and the nodes then validate it, accepting/rejecting what the pools produce. ofcourse if 5000+ want on thing the pools will follow, or risk losing their income while wasting electric for nothing. but the pools need to wave their hand in their air to show when they will begin. so that the nodes are ready.

again think about consensus

kind of strange how you desired 12 devs and 90 interns to be the government. but then twist consensus into myths, ifs, and maybe's of non dev collusion.
please put your rational hat back on. you had a good 24 hours hours of thinking rationally, dont go putting your fanboy hat on again

moving from 1mb to the scenario of 1.3mb over a few days is a natural and risk averting logical thing. jumping from 1mb straight to 1.3mb in minutes is not logical, rational or risk averting.

check out my post above.. where gmaxwell calls anything not segwit an altcoin. yet its segwit that is currently not activated on the mainnet.. yet other implementations he wants to fight against. including old bitcoin nodes are altcoins in his mind.

screw it here you go, saves you scrolling

yes he wants to call bitcoin0.8-bitcoin0.12 nodes an altcoin if a pools wanted to stick to those old nodes and refuse to upgrade to bitcoin0.13 just to flag desire for. and refuse to wait for the actual segwit node 0.14 that will only be released after activation.

funny part is an altcoin is something thats not actively running on the network..
in short.. how can something not on the network affect the network its not on.

EG how can ltc block an important bitcoin improvement on the bitcoin network.. it cant.

only an active bitcoin node on the network can be able to block something different from getting onto the network. meaning the blocker is bitcoin and the blockee is the alt

the 10min rule is an average of a indirect rule.... not a direct rule in itself

some blocks can take an hour+ some can take <2minutes.
changing the difficulty and rewards and halvings and everything else still does not guarantee a 5min expectation.. only an average

this may still be <2min-1hour+. but a higher majority happening in a shorter period.
while screwing with so many bitcoin features that should not be touched.

pools already have issues filling blocks with new tx's if a block is solved in 2 minutes, causing empty blocks.. while its checking the last block. so this 'empty block' result will occur more often
thus its not actually helping to get more transactions confirmed longterm. infact it can make less transactions get confirmed

(facepalm)

i understand the human utility of desire for faster confirms... but
but to do such, has many ramifications and complexity and having to change many things that can affect and risk many other things.
EG it messes with the coin creation metric. difficulty rate. and also difficulty retarget time. and many other things.

for instance. the difficulty retarget (2016blocks in 2 weeks) would become 2016 blocks a week
for instance. the block reward halving(210000 blocks (every 4 years)) would become every 2 years

so then does the decision becomes:
let the reward halvings happen every 2 years meaning 21mill cap stays but cap reached in 66yrs instead of 132yrs
or move the goalposts and end up having more than 21mill coins

to implement it, is not only far more tweaking bitcoin away from bitcoins main rules that should not be changed. but also to implement and activate
is more of a hard controversial fork that could more easily lead to an intentional split.

firstly the 10min expectation is not actually the bitcoin rule..
no tx is guaranteed to be accepted in 10 minutes.

the rule of bitcoin is that 2016 blocks should be produced in a fortnight. no rule that forces a tx into a block. no rule that forces XXXX tx's per block either. so bitcoin could have empty blocks forever and actually meet its protocol rules.
the 10minute per block is dividing 2 weeks by 2016 blocks..

---

now lets get into the details of the transactions..

an average block can only store ~2200tx or max of 1mb of data
check the mempool count.. yep more than 2200tx or 1mb waiting most of the time.
https://blockchain.info/unconfirmed-transactions  - 3blocks of tx's waiting at time of writing this post = ~30min wait for some tx's(using velkro's very simplistic time overview of bitcoin confirms)

yea sometimes the mempool count can be low and all tx's get into a block promptly. other times it can take a couple blocks or upto an hour. depending on demand, and other criteria

id say the data is not bad. its actually accurate.. you just have to understand the context of the data.

---

so here is the context.

not everyone pays excess/top fee to be first inline. some pay minimum fee which then gets outbid by 2200 others who pay slightly higher so that the minimum payer is left waiting lower in the queue..

and yep some pay no fee at all. meaning they wont get accepted for hours. and its things like paying minimum or no fee that push the range of times out. which then affect the average time..

im sure people can go through the data and selectively delete out the tx's of zero fee.. but then getting selective/creative/manipulative over what tx's are deemed worthy of being part of someones expectations. is what starts being 'manipulative' and causing bad data

---

edit
i just checked the couple hundred tx's with 0 fee.. average confirm time was 5 hours 7 minutes 37 seconds

funny part is there were even tx that paid over $100 at the time (last week btcprice over $1k/btc) 0.1btc and the average of these big spenders
were 11mins 32secs (basically bribbed their way to the top of the list) with silly huge fee's

txid: 61d9e2841e462f0a73668bf37601f2c021e9a90a3810ef654a21063b5722840a
txid: 3a5546217b76ae91f0fd113dc7f8c863fd9099ab62abedaa71f2a856ccd48d6f
txid: 2fce0c36505aece2fa77df5f3bc02cf7d5ffe5231e7a41597b51d4a2ffb61383
txid: 3ea07465f19e188535766c1d4f60b6b5b968294212a5778b65ed13889c753636
txid: 0c48281a819ca34ae837297e1ece737dc779d7eee0025c8a46e4e87fc6658696
txid: d8d194e4ae415323a90a56cd999e2e7cca9dfe13258a4e82469223b8f2fbbc8c
txid: d14d0ddbdc269ebe09174a9d02e85b13c9ae97fc27e6e57cba196ef7c46ddab3
txid: 99901d44db56788b74999c0f6b4f3bc1c960fec61761b447be878ae1721ec6e4
txid: e78f3045c8348ff5882da99c0f8555294d889b641c820c82cc6f3ab62df103b0
txid: f6bf8c706fabb59489b1152cac038c69dbd565bd23dfed35d8131a08a655b846
txid: 415856aefeb42a6050abb8ec9b66b8a3688fd24632f36299b5deebf1a16e5c85
txid: e9ad2d09ec5de999b723ce8e74667243ccb7656ce09920c2b76fd91dea8b89ff
txid: 5ce70be2cf3163fad5192daf8356f9819f79622894c510c192929e78a714b332
txid: adf3dccfa9b2e24a5dfe7c997e927f6ac6865780c78f8afed388f34603883033