as for the tv series "startup"

the hack the OP refers to is the FIAT funds. in bank accounts. not a cryptocurrency hack, because "gencoin" in the series was not even running/released.. the failure of that series is that all the coin creators are asking for FIAT investments to get started. the stupid thing/myth is that it requires fiat.

if your creating a new money system there is no need for old money. you just create the coin. and sell the coin.. not use fiat just to be able to create it.
if you need old money just to create it..then the new money system has already failed.

yes and thats why the 20% is an opinion poll because the election has not been open long enough to have vote counts. but treating the opinion poll as the metric of activation and most important, is a failure of understanding.

as you say votes should be about 41-42%...... yet votes are at 8%

again blue line=opinion poll.. red line vote count.

there is nothing wrong with discussing opinion poll.. but atleast discuss it in the context of opinion rather than factual status of votes

a majority of organisations using 'the linux foundation'. cared more about 'foundation' than 'linux'

foundations are used as tax havens.
EG
have $100k an need to pay 20% tax($20k)
dont pay $20k to taxman. put $20k into a foundation.
get the $20k wrote off meaning no tax to pay...

and then be on the foundation board to then claim back $20k for expenses/costs of your service to the foundation. and get to privately play around with your whole $100k for anything you please

so when you see banks 'investing' $90mill.. its not costing them $90m. its costing them far far less because instead of $90m going to taxman. its siphoned through a foundation.

check out the clinton foundation or any other rich guy that publicly talks about 'donating' to a foundation.. and then see where the funds went to.. basically a majority ends up back in their own pocket eventually.

and thats why the inux foundations many projects are garbage. because the ones that fail are suppose to fail. just to get a tax break.
however if a project can lead to getting them more back then they put in. then they will fund it and make it happen (small percentage do this)

no

the RULE. the CODE. the BIP is about 95% of 2016 blocks.. (not average of 24 hours)

the important thing is
https://blockchain.info/charts/bip-9-segwit

the other metric of "average" "24 hours".. is not important.. it is just a generalised thing.

much like presidential elections.
the important thing is the vote count. however people can talk about short term 'polls' that change daily to gain some insight as to the 'ifs' and 'maybes' but choosing to think of polls as more important then the actual vote count is ludicrous, especially if the poll changes from 25%-14% 26%-16% at any time. its not a worthy metric.

if anything
use this..
http://bitcoin.sipa.be/ver9-10k.png

and yes its made by the guy that done segwit. that shows the 2 figures together

the "poll" (short term opinion) in blue
the "votes" (actual results that the code/rules look at) in red

in short.

dont expect it by christmas

firstly although segwit increases the amount of possible future BLOAT (megabytes of data) to 4mb.. the UTILITY!!!! of that bloat is not 4x capacity/scalability

what has been asked by the community is the UTILITY of the blocksize to increase.

so while core thinks 4mb is safe bloat.. then the obvious action is
2mb base 4mb weight to get proper UTILITY of the blocksize and segwit both at same time

we all know that core want 1.8mb for complete transaction data, and call that the compromise. but that 2.2mb of spare buffer will be used for arbitrary data for other features, and not lean clean transactions.

core havnt even bothered to put in rules to stop people writing messages in the transactions. meaning that 2.2mb a block could end up being filled up with crappy messages.

if core stopped with the "it takes months to announce a consensus" yet they themselves made an october announcement for a mid november pool consensus with hopes for activation by christmas!!!

now here is the trick..
go back to last years "promises" made at the scaling bitcoin. where dynamic blocks were part of the segwit plan.

that way everyone is happy
not this bait and switch
here have 4mb ... but have it as:
Xmb base Xmb weight dynamically adaptable via consensus
beginning with default of 2mb base 4mb weight for clean, lean transactions and only 0.4mb for arbitrary bloat

NOT

1mb base(limit scaling)+0.8mb witness(move signatures as 'compromise' side effect one time increase)+2.2mb arbitrary data(bloat)=4mb weight

that way everyone is happy

seriously?? your going to:
ignore actual blockcounts
ignore how the activation is measured.

and show a stupid average over a stupid 24 hours.
wow. the other day it hit 24%, then down to 14%, then upto 25% then down to 16% then upto 19%........ LOL

how about use actual count of 2016 blocks and get a number that actually applies to the rule.
hell lets even use segwit creators own stats page
note the red line as thats the only metric the CODE cares about.
http://bitcoin.sipa.be/ver9-10k.png
again note the red line.

as for anything else lauda has said about segwit. im pretty sure lauda has yet to learn C++ to actually know code to actually independently review and understand it. and run it through some scenarios
i did give lauda a few hints months ago to learn it. lets hope lauda took up that chance.

now lets summarise.
malleability does nothing for LN.
say we call a malicious person X and a honest person Y

to open a channel funds need to be confirmed and locked. LN would only recognise a locked and confirmed tx. thus malleability is useless. because LN wont do anything to unconfirmed transactions and would only accept whatever is seen locked into the blockchain.

when using LN a transaction needs to be signed by BOTH X and Y to spend (broadcast back onchain)
if X then wants to malleate a tx to then void the first one hoping he can then sign a second tx to trick funds back to himself he cannot. because Y wont sign the malleated tx. and the second tx without both signatures will never get accepted into a block.
dual signing alone makes malleability useless tool to double spend

secondly. legacy(old) nodes wont benefit from it. also old nodes will have more issues to contend with. such as seeing 'funky' transactions. aswell as still not being able to trust unconfirmed transactions due to RBF and CPFP.

thirdly new nodes wont benefit from malleability. because malleabilities main headache was double spending.. and guess what.. RBF CPFP still make double spends a risk.
yes all them promises of fixing malleability to let people have a bit more trust in unconfirmed transactions falls flat because they basically took away malleability but then implemented RBF CPFP..

fourthly as for the linear/quadratics.. be serious for one moment. think of a rational reason why one person would need to do say 200-10,000 signature operations in one transaction.
just checking the blockchain history. how often has a legitimate transaction actually required lots of signatures to the extent of causing issues.
the funny thing is limiting transactions sigops actually ensures that we never get a situation where one person can fill a block alone..
but instead, not limiting transaction sigops and just making it fast to process. along with offering a discount on signatures, actually makes it easier, cheaper and more rewarding for someone to spam the block with a single transaction. yea it wont cause network delay. but still causes the community to get peed off that someone is filling the block with one transaction.
limiting sigops was/is the obvious route that should have been taken.

fifthly, the 4mb weight. is only going to be filled with 1.8mb tx +witness data. leaving 2.2mb unused. but guess what. people will use it by filling it with arbitrary data. such as writing messages, adverts, even writing a book into the blockchain. what should have been done was allow 2mb base thus needing ~3.6mb weight.. and also adding a rule that 'messages' could not be added. thus keeping the blockchain lean and utilised just for transactions and not novels/adverts/messages. afterall if a communication tool like twitter or SMS can limit how much someone writes.. then so should bitcoin.
we will definetly see people purposefully bloating up the blockchain with passages of mobydick or over nonsense. and core have done nothing to stop it but done everything to allow it.

sixthly, as i slightly hinted before. by not limiting sigops, not preventing arbitrary data being added core have incentivised bloating by discounting it. but have then added the fee's to reduce bitcoins utility of an actual transaction ledger..
this has to be emphasized over and over.. adding bloat is discounted(free) but sending a real transaction is costly

seventhly, now lets get to the feewar. by removing the instant reaction of allowing fee's to drop when there is low demand. to instead use an "average" metric, actually ends up keeping prices high even when empty blocks are showing. this also has a ripple effect on the relay network where nodes wont even relay certain transactions that dont meet a threshold. which during times of empty blocks/low mempools. the mining pools wont even get all transactions to manually add into blocks if they circumvent the "average" setting.. because other nodes have refused to relay them.

this overall ends up with an ever increasing fee, while having blocks either spam filled with messages of a novel bloating a block. or empty blocks while still demanding a high fee because the average doesnt decline instantly, but over many blocks. meaning instead of

block 500,000: 4500tx 1.8mb avgfee=0.00010000fee
block 500,001: 4500tx 1.8mb avgfee=0.00011000fee
block 500,002: 4500tx 1.8mb avgfee=0.00012000fee
block 500,003: 4500tx 1.8mb avgfee=0.00013000fee
block 500,004: 4500tx 1.8mb avgfee=0.00014000fee
block 500,005: 4500tx 1.8mb avgfee=0.00015000fee

you will see
block 500,000: 4500tx 1.8mb avgfee=0.00010000fee
block 500,001: 1tx 4mb avgfee=0.00250000fee - "Call me Ishmael." "Some years ago-" "never mind how long precisely-" "having little or no money"
block 500,002: 0tx 0mb avgfee=0.00019600fee
block 500,003: 0tx 0mb avgfee=0.00019984fee
block 500,004: 0tx 0mb avgfee=0.00020383fee
block 500,005: 0tx 0mb avgfee=0.00020799fee
go on.. i dare you.

using an "average" screws up any chance of having cheap transactions and enforces a fee war, even when there are no full blocks the price does not instantly go down due to there being no demand.

im not sure why your talking about CPU frequency.
bitcoin moved passed that 'CPU limit' in 2011. it moved to GPU.
bitcoin moved passed that 'GPU limit' in 2012. it moved to FPGA.
bitcoin moved passed that 'FPGA limit' in 2013. it moved to ASIC.

we are not stuck in 2011 crying about the limits of CPU frequencies


a single bonsai may only grow 2 foot.
you dont simply cry that a bonsai has limits.
you dont cry that a bonsai takes 30 years to grow 2 foot and has limited foliage
you dont cry that it needs a forest of bonsai to cope with leafcutter ants.

instead you would plant a redwood tree that can grow 300 foot tall and has healthier and extra foliage. where the ants have room to do their
job uninhibited and without needing lots of maintenance to allow the ants to move about.

and laugh at other people for planting fields of bonsai, trying to get one ant to jump from bonsai to bonsai

compare a
4GPU miner of 2012
to a
single ASIC of 2016

2016 asic is:
CHEAPER,
more powerful
more efficient
less heat intensive
less electric wasted

and that will continue. each new generation of asic will be more efficient than the previous.

the blockchain is decentralized. but i think its not diverse enough.
its all by majority handled by one codebase.

i can kind of see what the OP is getting at. but at the same time he is then using that lack of diversity and also fake doomsday rhetoric of bloat worries. to then try advertise the same thing that the banking sector are planning (sidechains on their hyperledger coded by the same guys that are pushing for bitcoin to move to sidechains too)

OP.

"I guess it will be simply impossible to process millions (billions) of transactions daily "
but that mindset is overshadowing this:
"It is almost a given that if the Bitcoin adoption should increase multifold in the coming years"

lets emphasise..
"coming years".

just 16 years ago the largest hard drive someone could have was 4gb. and the largest portable storage was only a few megabytes.
the internet was dialup.

things have changed.
in 2009 1mb blocks were acceptable.
stats done on average internet speeds (even by companies like livestreaming, videocalling services) and by those concentrating on bitcoin have shown 8mb is ok now.
and storage is well over 2 terrabyte for average home cost PC's.

meaning we can grow upto 8x now. no issue..
even core now believe 4x bloat (bloat not capacity) is safe enough within the next month..

and as you say millions/billions over YEARS. (not hours/days) is plenty of time for the hardware and bandwidth to allow more growth.

in short.
put yourself 10-16 years in the past and while on dialup with a 4gb hard drive.... ask your younger self.
"could you see in 10-16 years that just one shoot-em-up game will require the storage space of 20x the largest hard drives available, and people wont even care/think about it and just treat it as ok/normal..
that playing others while talking to others and showing each other your game play would seem normal too. but require internet speeds of over 20x the max available"

your younger self could not imagine that..
much like you cannot imagine the future in 10-16 years time

by the way, if you done some research XT was just a bait and switch for the same guys behind blockstream. R3 and blockstream have been working together for months. go checkout the names of those involved in hyperledger.

oh and before crying FUD about everything that goes against blockstream. research first.
as for segwit. you claim there is large support by mining pools..
um...
https://blockchain.info/charts/bip-9-segwit    7.1%
7.1% at time of posting.

BU. also in the 7% range.
so using your "competitor" mindset.. they are neck and neck

as for you saying there are only 4 options and 2 are dead meaning you are suggesting there are only two options.
im kind of glad you didnt mention knots and bitcoinj. im hoping its because you already know they are already under the umbrella of core.

but there are other implementations too.

but anyway you are acting like its a competition to be reigned in as king. rather than thinking of the bitcoin network remaining diverse. and not having a king

BU has not been making claims that core should fork off to an altcoin. yet core have been making claims that BU should fork off to an altcoin. funny that!.
please take off your core fanboy hat and put on a unbiased bitcoin network hat and try to research what you preach

for months now the solution has been clear.
dynamic base blocksize along with dynamic weight to allow the features some love with the capacity growth we ALL want.
which would require both a node consensus followd by a pool consensus. and dont worry. nothing happens unless consensus is reached.
and if not reached nothing happens.
again if reached there is no intentional split/altcoin rhetoric. there is just a period of orphaning by the minority that have not updated where they cannot sync. again not chain splitting. just a loss of sync-ability by a low minority. and they upgrade if they want to remain full nodes.

after that drama has surpassed.
where the default at a high consensus starts at 2mb base 4mb weight, and can grow naturally without as much orphan risk and without the sync ability drama, by using the consensus of independent nodes settling their differences to an acceptable rate, . rather than dev teams setting the rules(no longer need developers to release versions just for limit changes, meaning no upgrading of nodes just for limit changes).

EG
imagine a future where
50% of nodes have 3mb base 6mb weight
30% of nodes have 2.7mb base 5.4mb weight
10% of nodes have 2.5mb base 5mb weight
6% of nodes have 2.2mb base 4.4mb weight
4% of nodes have 2mb base 4mb weight

pools can see that 100% agree to 2mb base 4mb weight. and see 96% agree with 2.2mb base 4.4mb weight.
yes those numbers are correct. because a 3mb base agreement means anything below 3mb is acceptable. its not the opposite.
so a 0.99mb block IS.. emphasis IS happily accepted by nodes with higher setting. just like (random number 0.2mb) is acceptable to 1mb limit nodes for the last 7 years

meaning pools can while making blocks anywhere between 250bytes to 2mb(when consensus shows 100% agreement to upto 2mb),.. pools can go through their own mining flagging consensus to see if 2.2mb base should go forward which will prompt the 4% laggers to dynamically change if pools reach an agreement.

all done dynamically without developer spoonfeeding.
obviously it stays at 2mb unless pools consensus reaches agreement

basically everyone gets their cake and gets to eat it.

the ones i made red are because of cost of set up, legal frictions with regulators and low chance of income/returns unless alot is invested in time and funds to set them up right

to add, for a low upfront cost but getting the ball rolling faster and more chance of healthy headache free returns
bitcoin meetup, conferences, conventions
bitcoin consulting services EG setting businesses up to accept bitcoin
bitcoin learning centres, colleges, hackathons

the issues with the fee war are.
the obvious ofcourse:
its not a first in first confirmed.
its no longer based on age of coin metrics (of how long ago the funds were recently used) meaning a rich guy can keep spending every~10minutes uninhibited)

but here are some other failures people are not noticing
1. at say 10sat/byte.. knowing average tx is 400byte. thats 4000sat/tx MINIMUM, on a no demand day (just under 3cents)

2. sites that suggest fees are operating in 10sat/byte intervals. meaning it psychologically makes people outbid each other in amounts of 4000sats (3cents rather than 'micropennies/individual sats). meaning if the average was 0.00012. people then pay 0.00016 instead of 0.00012001. pushing the price up by near 3cents per outbid rather than 0.001cent

3. fee's are now estimated over an average. rather then being instantly reacting to demand. meaning it hold the suggested price up for longer even with empty mempools

4. with the "average" metric instead of instantly dropping to suggest that free transactions are allowed in when mempool is empty. it is still biased towards pushing for fee's

basically
economics/price wars should never be used to sort out priority/spam.. CODE and filtering out bloated transactions or repeat spends too quickly, should be used

EG same as blockreward, not mature for X blocks to spend
EG no arbitrary data/messages, just lean tx code

it seems core devs are spending coin to bloat up mempool. to try to later suggest that only core have the solution and people should download core and get pools to use core to solve the problem.

the issue however is that its not that straight forward and requires people to sway pools to flag for cores feature. and then wait a month. and then download a new core implementation AGAIN. followed by moving funds from legacy (old) keypairs, to new HD segwit compatible seeded keypairs.

thus actually causing more bottlenecking later with everyone moving funds just to utilise a core feature that only has potential boost of 1.8x capacity.

its making everyone sit down to let core run around to demonstrate there is no room for everyone to walk. purely to then get everyone to run around with half promises they can freely walk around (basically child games to make a point)

short answer nope
no financial incentive to run a node.

the fees end up with the mining pools who add the fee's onto the blockreward as a bonus for themselves(in many decades the reward deminishes and the fee's become the main income for mining pools)

nodes receive no financial incentive

however if you care about security and trust that your private keys are safe and that by being part of the network you are helping to distribute(decentralize) the network to ensure there are less chances of attack, then that is your incentive(securing bitcoin).

however if everyone was to "just run core" then core developers then control the rules(become kings). so look for alternative full nodes to add more network security by being diverse, as well as decentralized, that way no one controls the network, and thus bitcoin is more secured

and here is another reason core are happy with the fee war.. its not about spam. its about money..
finding new ways to give people headaches and then cost them more money to get around a headache.

if only devs used code to sort out spam. like limiting sigops and having a cooldown period (like the blockreward has) before spending.. instead of using "fees" as the mechanism to avoid spending or making it costly to spend.

i feel ashamed that the dev's are using economic rules instead of code rules to sway who should and shouldnt use bitcoin.
2013+ has definetly been the period bitcoin jumped into the bankers pockets

kiklo
your crapcoin zeit can do small times for a simple reason. it has no utility.

as soon as you start having to propagate/relay zeit blocks to more than a couple hops away (which adds time to when the entire network gets informed of a new block), things will slowdown and you end up with a network fighting orphans due to some nodes not getting one block solution before a competitor has another.

changing the blockreward mechanism alone as a work around to enable changing the timing also has ramifications.

but hey, go play with your altcoin and see it crash out and get high orphan counts when blocks start to fill and cant get passed around the network quick enough.
you dont see the problem because your altcoin is not decentralized and distributed enough. it also uses PoS which shows your lack of understanding PoW
 

the theory of messing with difficulty to allow blocks to average, lets say 5 minutes "may" increase transaction count. but you have to take into account the other ramifications.

1. it messes with the coin production(blockreward) timing and changes the 2140 when mining should end. to being much sooner
2. pools need time to validate solved blocks and propagate them. if difficulty changes to average 5 minutes. we will see more "empty blocks" where pools circumvent the validation/propagation in an attempt to get blocks solved faster. thus less transactions get added to a block.
3. the 10 minute average has many reasons behind it.
4. changing the 2016blocks over 2 weeks has many negative ripple effects

research 2 and 3 and 4.
learn the why's and hows and whats.

reason 1 alone is reason enough not to do it. for economic, and for reasons revolving around rules that just should not be messed with.

i know you hate the mining pools so lets word it in a way you will understand, purely based on your hate of pools..

changing the timings to 2016blocks a week(5min average). means that in 10 minutes, the pools get a 200% pay rise because the change would mean they get paid twice every 10 minutes instead of once.
plus not guaranteeing that blocks will be full in those 5minute blocks (look at reasons why "empty blocks" are happening. (hint: its not due to low mempool(demand), but pools trying to be efficient solving blocks by starting empty blocks))

also changing the speed cant be "scaled" because there is a limit to how man times you can actually mess with all the mechanisms before it causes security weaknesses, bugs and issues.

so drop the change "blockspeed" idea. the side effects have more negatives than positives.

---

as for increasing the base blocksize. yes that has more noticeable effects and can be changed again and again, thus is about "scaling"..

unlike segwit which is a one time fix. that cannot then be repeated so its not "scaling". its just a side effect one time boost.

so yes changing the base blocksize is about "scaling", unlike segwit or your buzzword "blockspeed"

no

on AVERAGE??
you can check the last 100+ blocks here and count how many are empty
blocksize on the right.. most 999kb
https://blockchain.info/blocks

atleast learn the CONTEXT of the stats you try to use.

especially if your ignoring avoiding other stats simply because out of the mountain of stats available you have chosen one. but not gone as far as explain the limitations of the one stat you chose.

by the way the stat you prefer is something YOU chose, so the onus is on you to explain it. i have just tried to be helpful to show how to atleast back up your one stat by saying you can use other stats, and if a pattern emerges then good for you. but if other stats dont measure up then its best to find MANY stats that can combine to show some correlation..

or just face up that while there are still transactions in the mempool even with the occassional empty block. you need to explain the empty block concept.

atleast try.

and dont assume something because you formed an opinion. back it up with data, stats, information, rational logic, etc