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

not a currency??
anything can be a currency.

cigarettes in prisons
sexual favours between 2 people
art, antiques

currency is an umbrella term where below it there are sub categories. maybe you mean bitcoin is not
fiat money: because its not created circulated and endorsed fully by a government

money is a sub category of currency

bitcoin is not fiat money. and thats a good thing. but it is currency.
you are half right because bitcoin is a speculative asset currency

its deflationary

dont think of it from the point of 'every 10 minute it increases by 50btc' which a sort sighted view point

instead think of it from example
after block210,000 10.5mill coins were made and 10 minutes later 25 coins are added
growth is
0.00023809524% (10,500,025)
10 minutes later growth is
0.00023809467% (10,500,050)
10 minutes later growth is
0.00023809410% (10,500,075)

as you can see growth drops
EG
block 1
50 total 50
block 2
50 total 100 growth=100%
block 3
50 total 150 growth=50%
block 4
50 total 200 growth=33%
block 5
50 total 250 growth=25%

lots of addresses

ok. here goes go to
https://blockchain.info/block-height/1
click the hash
and you will see
No Inputs (Newly Generated Coins) ->
if the address after -> has an (unspent).. then its still on that address..

then
go to
https://blockchain.info/block-height/2
click the hash
and you will see
No Inputs (Newly Generated Coins) ->
if the address after -> has an (unspent).. then its still on that address..

repeat that by changing the block-height
there will be upto 52000 blocks you can manually go through that could be his

like i and others said. the coins are spread out over THOUSANDS of addresses

a few studies on the patterns of the extranonce have seen maybe under 1mill coins are his as oppose to over 1mill coins

https://bitcointalk.org/index.php?topic=507458.0

eg

black dots(blocks) that form a patterened line (probably satoshi)
red dots that form lines of different clants/lengths are lots of different people

also worth noting in the first 4 years (10.5mcoins produced) more than 10 people were mining.. way way more than 10 people.
plus ssatoshi disapeared within this firs 2 years. so mathematically over 1mill coins being just satoshis is a stretch

its spread out amungst many thousands of addresses
pretty much the first 144 blocks on day one of bitcoin  95% sure that majority of them coins (7200coins spread over 144 addresses) are satoshis.
yes each block  different address of about 50 btc each 144 blocks each day adds upto to thousands of addresses

in the first couple weeks id say 90% are satoshi's. the first month 40% are satoshis first couple months 20% are satoshis
by the end of the first year under 5% are satoshi's but all of those addresses thousands of addresses have ~50 btc on them each.

dont be so binary EG dont think about it as: buy all or sell all..
buy/sell in percentages of confidence you have in it going higher or lower

if your half unsure what to do.. as long as your in profit. sell half.. for instance.

that way if it continues going up you still have half your skin in the game.
if it goes down you got some profits to buy in cheaper and average out the other half to be more profitable later on another rise.

it all depends on your actual need of the funds for the next year. or if the funds you have invested are more for retirement in 5 to 10 years+ which can help you decide if you should care/get emotional about the temporary daily /month changes

interestingly.

a native(legacy) tx of 4k txsigops is treated as 16k txsigops in core v0.14 due to the WITNESS_SCALE_FACTOR (which is 4x)

so to correct myself about worry of propagation delay, native(legacy) tx does not/cannot perform 16k actual CPU intensive sigops. its still only 4000 real CPU intensive operations(just treated as 16k after the fact purely for cludgy mathematics of filling the limit)
yes lauda, cludgy code can lead to semantics games which core devotee's love.

but segwit still doesnt make the native keys disarmed from the 4k CPU intensive time that existed in 0.12 either
so segwit for CPU intensive purposes is no better or worse

---

however there is still the 5tx's to fill the 80k issue
where it doesnt need to be 16k/tx of actual sigops.. only 4k/tx..
that means 5tx's can hold up and prevent even segwit transactions utilising the 3mb weight area because those 5tx's have used up all of the block sigops due to all the cludgy maths of 80/5/4

---

tl:dr;
ok so segwit doesnt make native tx's able to be more quadratically CPU intensive. to cause more propagation delay
but it doesnt make native tx's any less quadratically CPU intensive than v0.12 (still 4k)

it doesnt stop native tx's making just 5tx's to fill a block (cludgy maths sigop count limit)

so to amend it - 3 attack vectors
1. just fill a block of native data to 1mb (data/byte bloat fill attack)
2. use up the block sigops limit with say 1000tx of just 20sigops each for example (cludgy maths sigopcount fill attack)
3. use up the block sigops limit with say 5tx of just 4,000sigops each for example (cludgy maths sigopcount fill attack)

yep. 4mb single block would be better for everyone..
but the other thing is that the hype about a compromise of 2mb+segwit.. was released on the 1st of april...
so although 4mb block where native and segwit can co-mingle in one merkle block(no block within block) would be better
im taking a pinch of salt as to if 'core' would actually really agree to code such a version of even 2mb+segwit for people to download.

segwit as a hardfork requires everyone to upgrade node.
but here is the thing.. native key users dont have to move funds to segwit keys.

what happens in reality is that instead of 2 merkle (block inside a block)..
its just 1 base block where the witness and txdata sit together.

and simple ALL share the same room.

its not
base 1mb           || witness <3mb  ||
[IN] [SIG] [OUT] ||                      ||  - native
[IN] [OUT]         ||[SIG]               ||  - segwit

it is
base 2mb
[IN] [SIG] [OUT]                          || - native
[IN] [OUT][SIG]                           || - segwit

thus both tx types benefit and coexist in the same area with no stripping (filtering/bridging) data.. blocks are the same for all nodes of the network because they all upgraded to just the 2mb hardfork