a ASIC does not have a hard drive.. it does not matter to an asic if a block is 250bytes or a gigabyte. the "hashing" is the same
an asic is just given a hash and rehashes it.

data or bloat does not hinder ASICS one bit.. it only hinders the pool/server that validates/relays full block data.

---

its taken years of debate and still no guarantee on moving the block size once.. do you honestly think moving to 1.2mb is going to benefit the network, and then have another few years of debating to gt 1.4mb..

if your talking about progressive blocksize movements that are automated by the protocol and not dev decisions per change.. then you are now waking up to the whole point of dynamics.. finally your looking passed blockstream control and starting to think about the network moving forward without dev spoon feeding . finally only took you 2 years (even if you think that hard limiting it at silly low amounts is good)

give it 2 more years and you will wake up to hard limit of 4mb and soft limit that moves up in increments.
EG
like the last 8 years (rplace hard with consensus and soft with policy, and you will start to understand)
1mb consensus 0.25mb policy 2009-2011
1mb consensus 0.5mb policy 2011-2013
1mb consensus 0.75mb policy 2013-2015
1mb consensus 0.99mb policy 2015-2017
to become
4mb consensus 2mb policy 2017-2018
where policy grows

oh and guess what.. pools never have just jumped from 0 to 0.25.. or 0.25 to 0.5..
even when policy allowed it, pools took things cautiously to avoid orphan risks

so say
4mb consensus 2mb policy 2017-2018 was implemented
pools wont make a 2mb block the very first block of activation. they would test the water with 1.000250mb to see the risks, timings issues of bugs orphans etc.
and increment from there.

you may argue "but whats to stop a pool jumping to 4mb".. well the same reason pools didnt jump to 1mb.. and instead themselves went up in safe increments to protect their own risks of orphans and other issues (as my last paragraph explained)
also thats where nodes would have an extra safeguard.. but ill leave you to take a few years to realise the extra safeguard. which is what dynamics is all about.

so go spend 2 years shouting nonsense/irrelevant until it finally dawns on you
have a nice 2 years

well for anyone thats wrote an implementation thats clean and knows the purpose of header files
they would be able to change to blocks over 1mb with 1 line of code in a header file.

yet the cludge of core ends up needing to change multiple functions in atleast 4 files. which can then cause a snowball affect of other issues if those functions were needed for other things..

in short by being cludgy they dug themselves a hole and cant get out of it with 1 spade. so rather than dig themselves out or starting again with clean code. they are trying to get people to follow them into the hole

you can. think of the sigops as another "limit" of spam that once filled nothing else can get in


we all know a tx bytes are made by (148*in)+(34*out) roughly(+-10bytes)

so lets make a tx that has 4k sigops
a) 3999input:1output= 591886bytes~(4ksigops)
b) 1input:3999output=136114bytes~(4ksigops)

5tx of (b)=680570bytes~(20ksigops)

screw it. i know there are many knitpickers
c) 1input:2856output=97252bytes~(2.857k sigops)
7tx of (c)=680764bytes(20k sigops)

so i can fill a blocks sigops limit easily with 7tx of (c)
and although its only 7tx, and only 0.68mb of data.. no other transactions can get into the base block.. not even segwit tx's

its not fixed.
the problem with quadratics /malleability is that malicious people will use it to do mallicious things.
unless mallicious people CANNOT do it. then its not fixed.

EG its illegal to use drugs in countries..
does not mean the war on drugs is fixed by some rule. because people still use and sell drugs.

unless there was a way to permenantly guarantee that no one can sell/use drugs, the war on drugs is not fixed.

segwit is not a war on quadratics fix
its not even a prohibition (think about the 1920's alcohol prohibition)
its just a gesture rule where people can voluntarily move to a gated community that voluntarily wants never touch quadratics. and it wil turn out that the only people wanting to move are the people that never intended to spam in the first place

Malleability Fixes - not fixed. just offering a 'opt-in' keypair type thats disarmed from doing malleability (only the innocent will happily disarm)
Linear scaling of sighash operations - not fixed. just offering a 'opt-in' keypair type thats disarmed from doing quadratics (only the innocent will happily disarm)
same for the rest.

but im glad you admit that adding code to force users to only pay using a certain transaction method is " equal to censorship.".. now think about it
in regards to people saying
"Maybe they can be prohibited and all people owning bitcoins on non-Segwit keys have to transfer them to Segwit addresses."
"prioritise native->SW... SW->SW"
"Q: users move funds to segwit keys A: Which is guaranteed to happen"

also glad your now seeing the truth that its just a optimum HOPE not a reasonable expectation much like the 8 year hope of 7tx/s
"In regards to forcing people into Segwit addresses: While everyone using SW keys would be an optimal future, forcing them into doing this may set a dangerous precedent."

most pools connect via things like fibre or supernodes as it used to be called and let the fibre/supernodes propogate the data out to all the other nodes thus taking pressure off the pools from getting huge demand for direct connections from random users.

as for the random users and merchants that build up the symbiotic relationship of the diverse decentralise per network that keep pools in line and ach other inline. thats more of a question of the 8 dgree's of separation.

for instance if instead of 52 connections there was only 8.
if everyone had only 8 connections
8*8*8*8=4096
the data would not propogate to everyone in 4 hops/relays(based on bitnode count ~7000)
8*8*8*8*8=~32k
the data would propogate to everyone in 5 hops/relays
10*10*10*10=10k
the data would propogate to everyone in 4 hops/relays
20*20*20=8k
the data would propogate to everyone in 3 hops/relays
84*84=7056
the data would propogate to everyone in 2 hops/relays

so ill leave you to rationalise if you should step up and be more of a super node by going upto 84 as a nice healthy 2 relay number.
P.S if your going to want to help the network sync. doont use prunned/no witness features. otherwise people cant grab full data from you.

if you want to use prunned/no witness. then just let 8 connections and be at the bottom end cesspit of nodes that cant reliably sync with each other

1. pools dont NEED fee's today, yea its a bonus that can fluctuate but its not their main income. the reward is their main income.
the switch of income:bonus (from reward:fee to fee:reward) wont happen foe DECADES

2. pools would prefer to do things nodes accept to ensure they get atleast the reward. so pools are not gonna push any new rule or rock the boat with any new feature unless they know its not gonna get orphaned or going to cause spendability issues with certain merchants, which they prefer to spend the rewards on.

3. you may scream that coinbase might be segwit positive but what if the merchants/exchange/private investor they trade with prefers something else... think about that!! (do you even know what method a pool uses to get its fiat)

4. to highlight point one. pools have and will find the best ways to be efficient and within acceptable rules to get their blocks accepted. even if it means abstaining from a new rule change, even if it means starting a new 'empty block' while verifying a competitors solved block from a previous round.

5. i told you to get todays 'bonus' from users paying 2014 fee's would require an 8mb block. but as i have said for months pools dont see the fee's as a NEEDED income. its just a bonus. what is more important is getting their block accepted by the nodes first. because 12.5btc is more important than 1.5btc..

6. emphasising point 5 screwing around trying to get more than x fee's by increasing the risk of losing the 12.5+fee.. is like a walmart employee trying to screw $10 out of a cash register each month, risking losing $1k a month job... its just not logical to try being greedy



core guessed and gave fake reasons for 2mb years ago
better experts now found 32mb can work, 8mb is the general world wide no issue acceptability..
core accepted 8mb was a good safe number
core/blockstream prefer 4mb to be extra cautious because they know their compact blocks might need to ask twice for data now and again
core/blockstream prefer 1mb base with fake reasons of 'but pools NEED their fee's'.

strangely core removed lots of CODE that allows for reasonable controlled fee's thus allowing the fee's to get so out of control.
yep even in low demand, gmaxwlls 'average fee' concept keeps fee up. its not as reactive to low demand to make the price drop when demand is low
core stopped acting like devs and more like economist/bankers screaming "just pay more". yet core/blockstream have shown lack of communication with pools to actually ask the questions. 'what should core/blockstream do to make pools and nodes mutually happy' (the community)

all blockstream have done is 'would buying you a plane ticket and a seat an an exclusive bildrburg close door meting buy you blockstreams vote into following blockstream'.. yet 65% of pools even when bribed with all inclusive weekends still abstain/say nay.. because pools can see the cludgy code of segwit

just like it took the titanic before boat makers decided to double layer their hull.

though many people were trying to make money alternatives for generations. it take people who have the drive/ambition/knowledge/ inspiration to really make it happen.

EG aids has been around for thousands of years. but it only became worthy of looking at ways to prevent/cure/treat once it really started affecting wealthy straight couples

EG smoking and cancer risks for the rich were not a big deal for the rich. until the rich guys started dying of cancer.

but if everyone was following the exact same code.. EVERYONE gets affected if there was a bug
EG the 2013 event happened because everyone was virtually core managed..


however imagine if there were some 0.8 (leveldb) nodes and btcd(wrote in GO and leveldb storage) the network would continue and make blocks and only the 0.7(which would have been less majority, if more diversity existed)) would have been left unsynced. and it would have been far far easier to just say "hey 0.7 time to upgrade"

by having diversity, only the non rule following nodes get kicked off the network or cant sync.
EG assert bug was not a network wide bug because of diversity

thus bitcoin continues due to diversity and only the problem code implementation would stop.

diverse decentralised peer network has its reasons to be diverse and decentralised.

---

the only advantage of everyone centralizing the exact same code line for line. is to make changes easily without veto because everyone would be forced to change without choice.. which also has its own risks and exploitability by doing this.

nope

satoshi was working on sourceforge right up to when he left december 2010

gavin however had his own repo on github thats started something like june 2010.

when satoshi left, gavin was deemed the main go to guy so people started using his github repo, which he opened up to other people to use aswell. he actually said in 2012-13ish that in a couple years he may move onto other projects
which he eventually did by giving the main maintainer keys to laanwj

gavin continued as just a contributor until core guys decided to cut gavin off due to the craig wright drama with a pretence that gavin "must have got hacked"

put simply
sha is a very binary heavy puzzle
ECDSA if very vector heavy puzzle

quantum computers can play with vectors easily compared to binary.
trying to solve a binary puzzle with a non binary method and then have the result back in binary is not as efficient use of quantum.

some have estimated that solving a binary logic problem with quantum results in only a 2x efficiency. where as a vector logic problem can be something like 256x efficient

LOL guaranteed. LOL

do pools prioritise LEAN transactions to allow more transactions in.. nope
do pools prioritise mature transactions to evade spammers.. nope (spam: those that intentionally respend every block)
do pools prioritise transactions with fee.. nope (empty blocks/btcc zero fee confirm)

you HOPE and have FAITH that pools will.. but 65% of pools are abstaining or saying no to wanting to prioritise segwit as a protocol. so they are not going to prioritise segwit transactions.

in short. no guarantee, no fix. just gesture, half expectations and faith
much like the expectation of
"if pools prioritise lean tx's we can get 7tx/s 2009-2017".. yet in last 8 years never had a block of 7tx/s

yes on testnet it can be seen but thats test net where 1 person is creating the tx's in a certain agenda display of expectation.. when dealing with real world people using it for real world needs. reality does not reach expectation or hope

P.S your "2.1mb" expectation is the exact same 7tx/s expectation that has been promoted since 2009.. but never reached
its all if's maybe's half gestures hopes faith trust.. not actual real rules that enforce it

segwit only = bigger block ONLY IF:
1. users move funds to segwit keys
2. segwit keys get accepted into blocks
3. native spammers dont fill the base block with native spam

so charlie Lee working at coinbase has nothing to do with it.

he is well funded  now as a blockstream employee.

i guess bobbly lee wasnt paying him enough or the DCG cartel thought he would be more useful under the blockstream subsiduary rather than the btcc subsiduary

http://dcg.co/portfolio/#b

http://www.coindesk.com/blockstream-55-million-series-a/

within a couple weeks of genesis there were atleast 5 people mining.

within 6 months a couple dozen atleast.
figures get more murkier after that.

yep even theymos was around early on (using sirius-m username)

if you want proof others were working on bitcoin in january 2009
Nicholas Bohm- http://satoshinakamoto.me/2009/01/25/re-bitcoin-list-problems/
hal finney - http://satoshinakamoto.me/2009/01/25/re-bitcoin-v0-1-released-2/

theres other names too. should anyone want to research it.
google is your friend

the only implementation that has bypassed users support.. is blockstream(core)
asic boost has nothing to do with it. just like opencl had nothing to do with any decisions of core back in the day of the GPU mining.

imagine it. imagine core in 2012 wanted to change something but couldnt because it would cause issues with ATI's openCL. people would laugh at core if they started blaming ATI.
same goes for now.. if segwit hits a wall before being active, then REWRITE SEGWIT!!

its all just finger pointing drama, to get everyon looking in every direction apart from blockstream.
so just look at blockstream
EG blockstream made cludgy code instead of a clean node upgrade event.
EG blockstream made it so only pools get the vote('going soft').
EG blockstream going soft is an admitted backdoor exploit and they admit they want to add more backdoors to be able to go soft more often. (in th wrong hands its called a trojan)
EG blockstream now crying because all them all-inclusive exotic weekends didnt buy the pools into flag waving by last christmas (due to 65% abstaining/ objecting to the cludgy code)
EG blockstream now found out their 2merkle cludge is not as compatible as first thought (so now asking abstainers/objectors to reprogram themselves, to use filter/bridging nodes, to fork off, to add code to avoid attack vectors segwit causes, even offering to PoW bomb just to get the cludgy code in)

yep. instead of just backing down and going for a plan B of a 1 merkle segwit with proper block size increase for the entire network benefit, blockstream still want to bypass the idea of a network consensus upgrade and go straight to a controversial bilateral split..

much simpler blockstream just redo segwit as a proper 1 merkle version, remove the cludge and add the other features the community want too instead of pointing the fingers to blame pools, other implementations (which have done nothing for 2 years) and wasting upto 3 years just to push the cludgy version (UASF 'late2018' mandatory activation) and then make yet again half baked promises that they will remove the cludge and make it 1merkle full proper upgrade after that.. (no one believes them anymore)

a 1 merkle rewrite with the extra features the community want to unite the community. is safer AND FASTER to implement than the 2merkle cludge and all the threats half promises and features that wont 100% fix the network issues.. that blockstream are 'demanding get implemented or else'

the empty block is not about causing a backlog intentionally. its about instead of waiting 10 seconds/minute to validate a block before making a new block its about starting a new block WHILE validating the previous block. thus unable to add new tx to the new block attempt because they are unsure if the first one is all valid..

what you find is that pools do this alot. and after validating a previous block they start adding tx's (each round of using up all the nonces) and the only time you really ever see an empty block is when they are lucky enough to get a solution within seconds(first round) to not have been able to start adding tx's to a block

replace 2015 with 2014 and you have your answer.
mempool bloat changes.. but based on the last year where mempools average 3-4mb average.. then it would need 4mb blocks to bring conjection down. which to get to or exceed the 2014 fee of upto 10cent would far exceed the totals of 2014 tx fee income.. obviously

1. blockstream(CORE) removed all the fee controlling code. = core caused a fee rise. not pools.. core become bankers by not relying on code to control things and just instead shouted "just pay more"

2. blockstream(CORE) bypassed node consensus by going soft = core gave the only veto power to pools for segwit... pools didnt have control before core gave it to them. pools dont have control over other implementation proposals

3. other implementations are sticking with the standard NODE and POOL symbiotic consensus. thats has existed since day one and made no threats of splits/ PoW changing / banning nodes

4. re-implementing a new 'priority' formulae can actually reward lean average users with cheap fee's while penalising bloated repeat spenders (moving funds very block spammers).

5. there is no need to push fee's to $1+ a tx EVER. far better to naturally grow the blocksize in levels nodes can handle (even core admit 8mb is 'safe') thus allowing a 2015 10c fee ($220 total) to be upto $1760 total just by allowing more 10cent tx's in. not forcing $1 fees by holding tx count limits down to cause a upto $2k total (which pools dont need right now anyway)

6. lastly to debunk your mindset that pools want fee's .. i will hand you your own words "miners are still producing empty blocks.". if they cared about fee's they wouldnt empty block.. logically

core are the only ones wanting to create a bilateral or contentious split. core have been the ones screaming for anything not core to split away..
so if cores code causes a bilateral/contentious split (BIP9 and UASF has that ability) then core should be the one that adds "replay protection" if core was to decide to pull the split pin. in short core should take the heat. (and yes it is possible)

all other implementations want to stay together as a diverse per network. so why the hell should they be told to add in code and then be the ones that move away to allow core to have a dominant tier network.

ok lets word it this way..
anyone abstaining from segwit by just sticking with 0.12 rules being told to program a new version with replay protection..
yet core who have changed the code refuse to add in code to avoid risks of replay protection. (facepalm)

---

lastly if you dont think core code is cludgy.
ask yourself why the cludgy maths of native sigops is in line 4xx of a .cpp file and not in a header files(.h) such as policy/consensus.
and why the cludgy maths requires reading four different files instead of just having it all in a single header file as a set variable (easy to do)

and when it comes to changing from a 2merkle block to a 1 merkle block (which core pretends to promise later)... its not a simple edit of one file to change the metrics. but requires yet another big rewrite to undo the cludge of creating their 2merkle block

if you done a cs college course it wont teach you how to read the cludge any better. it would teach you how to read c++ and then recognise cludge when you see it.. because devs are not doing the basics of arranging variables in a logical way.

in short if the current devs of core/blockstream jumped over to litecoin or hyper ledger and retired their desire to work on bitcoin (devs are not immortal, their interests do change) the cludge they leave behind makes it doubly as hard to sort out for anyone new coming in.

---

your devotion to devs without knowing c++ reveals more about your lack of understanding bitcoin, but your adoration of a temporary team and trust that their word twisting should be good enough.

P.S im laughing at how you took the glory of 'explaining it'.. yet you were not 'questioner2' in IRC. and if you read the entire conversation then you would see that segwit does not 'fix' things. it just twists things

you try admitting it but prefer to word twist it

"Segwit wouldn't change that." = "segwit doesnt fix that"

so much cludge while keeping spam attack vectors open.

oh and i did admit i was wrong about the quadratic risk not being worse while at a 2merkle implementation(using math cludge). its no better either.
its just a maths game. of faking how many sigops it really does. by multiplying the rule.
i laugh at a 'sigopcount' variable that gets told not to count real sigops but hold a number thats not related to real sigops count, but a math cludge

and when segwit becomes a 1 merkle block. (removing the witness factor would be part of that) it will become a problem. which you have shown a bit of worry over.. but would not outright admit

---

why waste 2 years on the cludge of a 2 merkle with a promise of a 1 merkle within the year after..(3 year wasted)
when they could have done a 1 merkle initially with all the other features users want and have the 1 year grace period.(1 year and united community)

why even threaten the bilateral/controversial split for a 2 merkle and then promise a 1 merkle a year after doing a split. theres just no logic to it relating to keeping a diverse peer network.. but alot of logic when seeing the desire of a dominant blockstream owned tier network