1) Removing TX Data (@ 8:00)
the funny part is. that the 1mb limit was used to help restrict data being transmitted.
if pools are sending out say 4mb of data(cores 4mb weight concept) or 40mb(video's 50k tx concept). then there is no need for the 1mb base rule.
because now the 1mb is not used to limit data/bandwidth. its just limiting old transactions utility/ability to be accepted
also keeping the 1mb base rule but then having 99.99% of tx data outside of the block makes the real data being moved (for 50k tx) something like 40mb of real data..
the only reason to keep the 1mb base would be to prevent people who just want to do old(legacy) transactions.
thus forcing people to move funds to new funky keypairs/transaction types because their old legacy transactions wont get accepted into the base block any more (unless paying a HUGE fee because their 400byte legacy tx is the equivalent to 40 transactions of the new funky style)
keeping the 1mb base rule is more of a controlling the community while directing them down a certain road. rather than any bandwidth limitation security.
2) SHA256 (@ 12:00)
the guy doesnt understand the realistic workings of quantum.
binary logic problems would be solved by quantum computer of matching hertz at a 2x rate.
bitcoins PoW has so many hertz that are specifically dedicated to only doing one task (hashrate) that it outpaces a quantum computers at a CPU hert comparison by about 100,000 per asic unit and the network has atleast 130,000 asic units to produce one result every ~10minutes.
so quantum computers need to have 130,000,000,000 more hertz than a common binary PC. which isnt gonna happen any time soon.
more than likely. MANY people will individually make/use quantum asics to distribute and protect the network before one person can accumulate enough to hurt the network.
EG. did nvideo kill off bitcoin back in the GPU days?? nope they sold cards individually to users rather than accumilate their own farm to destroy bitcoin.
did antpool kill off bitcoin back in the first asic days?? nope they sold individual asics to users and kept their farm at reasonable levels
secondly... back to the hack-ability via quantum..
its non binary problems. such as vectors (ECDSA) that quantum computers of matching hertz can solve at a metric of 65,000x rate.
3) Koblitz Curve (@ 13:10)
i envision when the keypair curve changes we should not be restricted to one curve, thus mitigating the brute force chances by having more variaty as a defence
eg. instead of everyone picking random coordinates within y
2 = x
3 + 7 one person may have an address that starts
1
xxxxxx... which equals y
2 = x
3 + 7 is used
2
xxxxxx... which equals y
2 = x
3 + 8 is used
then for instance
4
xxxxxx... which equals lets say y
2 = x
3 + 9 is used
6
xxxxxx... which equals lets say y
2 = x
3 + 10 is used
or where
1
xxxxxx...7(appended to end of address) which equals y
2 = x
3 + 7 is used
1
xxxxxx...8(appended to end of address) which equals y
2 = x
3 + 8 is used
or where it may not even need to be y
2 = x
3 + x at all. we can have a huge array of different variables.
thus making it harder for a brute forcer to find all possible combinations, because the elliptic(map) and then resulting fibbonacco(private key) curves would differ
4) Bitcoin is single threaded (@ 18:20)
many users have multithreading versions of bitcoin so the whole linear/quadratic processing time has been a laughing stock due to lack of actual regular transactions that needed alot of processing. but should someone malliciously continue making endless blocks of large sigop tx's then multithreading has its advantages, the whole linear/quatratics issue can also be mitigated by just limiting sigops per tx.. or mitigated if segwit is activated (but then thats just a call to war for malicious users to try large sigop tx's to delay old legacy clients)
5) Bitcoin's time system is bad (@ 19:15)
i personally would not be using unixtime. i would be using blockheight instead.
so should others
6) Miners don't include TX in their block (@ 21:20)
miners do include tx's..
but.
here is the explanation of 'empty blocks'
when a block solution occurs the old method is:
to receive all that block data, verify it then verify the solution is also correct. then look at what tx's are confirmed in that block to know what transactions not to include in your next attempt at the next block. this can take upto a couple minutes.
when a block solution occurs the old method is:
instantly start a new empty block hashing while you waste a bit of time verifying someones solution. when confirmed, add unconfirmed transactions to your active attempt.
the thing is some blocks have luck of being solved in just a couple minutes and so thy have not had time to fill the blocks.
the logic is.. while your verifying a solution. why bother powering down your asics and twiddle your thumbs doing nothing for upto 2 minutes
