Quote from: squatter on February 08, 2019, 04:30:55 AM

Larger blocks cause propagation delays. This increases orphaning rates, which disproportionately hurts smaller miners

propagation is currently SECONDS.. so SCALING block sizes to atleast get passed the implied 600k transactions a day limit is not going to cause issues.

secondly nodes dont even need to receive the full block data in one lump. they can get blockheaders. and thn attach the transactions in their own nodes mempools to fill in the blanks and only request the few missing transactions that didnt get relayed to them. so again if nodes are only receiving block headers. the propagation is still low as the transactions element of a full block is not being sent with it.
a blockheader(~80bytes) of 2000tx includes TXIDs of 6bytes(compact/shortIDs) per tx =12kb
so instead of sending 1mb of a full block data blockheaders can be a little over 12kb
meaning a block of 4000tx =24kb (compared to 2mb)
meaning a block of 8000tx =48kb (compared to 4mb)

thirdly. "miners" dont care about blocksizes. get a screw driver and look inside an ASIC.. you will find no hard drive. asics do not store blockdata. they are just given a small piece of data and their job is to send back a hash. that is all

fourthly
bitcoin core has already dropped compatibility for xp/vista and so should drop minimum hardware specs of such outdated levels. we are not in the 1990's and should not be trying to keep bitcoin relevant to PC specs of a decade+ ago
average joe upgrades their PC's every 2-6 years.
imagine online gaming industry.. how innovative would they be if they had to keep specs down below millenium/decade old tech/spec..
the whole need to keep bitcoin functional for a raspi spec is just empty excuses.. because even on a raspi bitcoin is capable of more than 600k transactions a day processing

fifthly
scaling is not just about pure blocksize increases.. it is most definetly not about jumping to "gigabytes by midnight"
scaling can be done by
actually avoiding adding features that cause a byte per tx bloat.(sgwit actually uses more bytes per tx, but then hides the real bytes with its pseudo math of vbytes and witness scale factor and other wishy washy code)
core also STUPIDLY allow a block to be treated as filled by having just 5 transactions, with lots of sigops.. so reduce the sigops means more transactions, and less concern over any legacy linear sigop processing delays(yep core instigated the linear sigop delay drama by even allowing a transaction to have thousands of sigops.. all so they can sway people into accepting the LN gateway tx format called segwit)

in a peer-to-peer cash system. a peer does not need transactions of 16k sigops. in most cases they only need 2-5
thus going to that kind of transaction format of low sigops would actually speed up transaction validation where by more than 2000tx under low sigop counts can validate FASTER than 200tx under the current ratio

sixthly
fee's do not need to be pressured by a fe war over a limited space. it can be done be RE-introducing a fee priority mechanism.
a mechanism such as if a users funds are only 1confirm aged. they have to pay 144 times more than someone that only spends once a day(144confirm age). that way it actually means the whole community do not get pressured to pay the same high amount due to just a couple of spammers filling blocks.. but instead the spammers pay the price of spamming and its the spammers who want to spend every 10 minutes that would then see the incentive of using commercialised service networks like LN. while more modest ethical users get to remain happily using the bitcoin network still paying a more acceptable fee amount where because they dont spend often they wouldnt have benefitted from LN anyways.
simply trying to push EVERYONE, including the modest spenders into LN with the whole fe war pressure helps no one