Wow franky!
So your job is not paying you $10 a hour is paying you $80 a day!
And the previous job was not paying you $1000 a month it was paying you $12 000 a year!
Do you have any other such insightful facts ? 


Just so you don't have to go and do the math every time, most manufacturers have listed the price per th/s for years, not that you would know of it since you obviously don't mine but still, the s21hydro is on sale for 12$/th and microbt is dumping the 30s for $10/th which would bring your 10 billion to 6 and 5!
Why would an attacker buy the most expensive gear for an attack when he's obviously not looking at ROI numbers?
Also you're forgetting they could simply buy the whole farms which would make the attacker even cheaper as you don't have to overpower 500exa anymore, you have bought 50exahhash so you only need 400 more. 


Again you're missing the point!
If Bitcoin will reach 400k then it means a ton of money is there, and a lot of interest around it, far larger than it was at just $40k, and you don't need to steal money to break that apart, just a successful re-write of 10-20 blocks and that's it! Who in his sane mind is going to pour millions into this knowing that every time he makes a transaction there is a risk of being reverted?

my opinion has never been to jump to 40mb at all.. nor any jump of blocksize under the current cludge model of base vs witness
i dont think there ever has been a proper proposal to jump so high in one go..

the natural common sense method is to decludge what we have now to make things more lean and then only need scaling by smaller adjustments over time. with no dev politics involved, that way we can scale up to more transactions using less space then the topics mention of 10x

EG
block size increases dont need dev politics. it can be based on blockdata deciding. EG if lets say 105000 blocks are 95% full then adjust blocksize. this can all be hard coded
it can also be hard coded by evaluating fee's per block. there are many hard data statistic stuff that code can use to automatically adjust parameters without dev politics involvement. (see: difficulty adjustments, see: reward halving)

fee's also do not need to drop to base levels. fee's can also have tiers too. where by spammers spending 1confirm utxo pay 144x more then someone that spends a utxo of 144confirm age
also the fee's can be tiered whereby certain opcodes cost more than other opcodes

end result is less spam unless it pays mining pools. but without punishing everyones fee


you do know by now that cores promises of the 4x blocksize did not result in 4x tx count
you do know by now that cores promises of segwit=leaner tx did not flourish either
you do know that segwit is the cause of allowing 1tx to utilise 3.99mb of space
heck even cores latest promise of taproot being less than one legacy signature length is not less than one signature length

heck even as far back as 2016 i was calling out how segwit would cause people to publish books and malicious data into the blockchain.. so i do hope you understand how 7 years later, when seeing ordinals and other junk crap.. that its not a empty fetish but instead highlighting the problems that were foreseen yet people want to ignore and just obediently adore cores roadmap unscrutinised

not useless.. just not yet utilised
as you know things like mid transaction opcodes allow things to change after the opcode to new formatting based on rules of expectation after the opcode

and like this, the first few bytes of a tx can be used to introduce new things for the entire transaction format, from the beginning

EG
the spending UTXO
imagine transactions are no longer identified by a TXID in SHA256 (32bytes)
but instead hash160(20 bytes)
by using a new versionbit at the start the network can make new nodes validate transactions via a new TXID that is shorter. thus savign 12 bytes per input

---

heck what if due to blocks immutability instead of UTXO being TXID, they instead just ID'd a tx by blockheight+tx position in block+output position in tx
EG
3byte block height (16777215 blockmax (319years))
2byte tx position in block (65535tx per block)
1byte output in tx (256 outputs per tx)

thus a UTXO id can be as small as 6bytes

---

also knowing not everyone will spend 8bytes of output "value" meaning max
18446744073709551615
184,467,440,737btc   09551615sats
it doesnt need to represent 187Billion btc(21m limit after all)

heck no one is going to move 3million in one output so this could go to 6bytes
2,814,749     76710655

thus saving 2 bytes per output

the first bit of a tx can actually be utilised in the future. so saying its useless is not correct.. it simply has not been used yet.

..
also this version bit can be used in different ways such as users own tx can use it as a flag bit for voting

..
but yes them 4 bytes, allowing for 4,294,967,295 different transaction versions. is too many future options
this could also be reduced to 1 byte of 256 versions of future options, seeing as how the tx version is after 15 years only at version 2

but its not a yes/no

when bitcoin moved from 1mb allotment to 4mb allotment it did not result in 4x transaction count nor a direct economic impact on fee's
instead the code changes had other edits to it that manipulated fees (legacy * 4) yep they made legacy more expensive as part of additional code, rather then letting the "freemarket" decide

there are other things that can be done to undo some of the changes, make tx leaner, and allow more transactions thus reducing the per tx fee per user even without further scaling blocks

which if done right, then scaling blocks would allow more tx thus not require so much congestion/bidding wars, further reducing fees

however thats not the direct devs want to take bitcoin

you are not understanding the question nor answers

because the answer is notstraight forward

EG
10x more blocksize does NOT mean 10x more transactions at current fee rate
so it may not mean 10x more fee

instead 10x more blocksize may end up that the limited transactions +junkweight pay less sats per byte per tx because te junkweight gets more discount

again without understanding al the details you cant give a yes/no.
the question does not say if there will be 10x more transactions or if the extra blocksize is actual tx utility or just witness space just for junk

if doesnt say if blocksize increase also includes fixing the cludgy bloat spam to make things leaner

EG current 4mb is about 4200tx which 10x would be 42k tx in 40mb
which if fee rates per byte stayed same would be 1x(same) fee per user but 10x fee total for the pool
hoever with less congestion could see 10x LESS fee per user but 1x(same) fe total for the pool

however
making leaner tx allowing for 16k tx in 4mb.. meaning 160k tx in 40mb
fes per user can go 40x LESS while still being 1x total fees for pool

SW does not discount.. the actual code is they premium'd legacy
there is a difference

by making legacy 4x more yes it made segwit cheaper than legacy, but not due to discounting segwit. but due to multiplying legacy
learn the difference

.. "if miners revenue could rise  if blocks are larger" is still not a yes/no. unless you are emphasising the "could".
because the fee's per user and the congestion also could decrease meaning the miners could get less total fees
so the answer to "could" is a yes. but to "would" is both yes and no

and there is always many variables to think about. its never straight forward

for instance. even now. blocksize has been same for years. yet individual miners get less sats per hashrate due to halvings and hashrate competition with other miners.
yep someone owning an s19 since 2020 is getting less sats now then they did in 2020

with that said. comparing the MARKET price, those sats are worth more
so its all adjustable to variables

which in short if asking WOULD 10x blocks =10x fee.. the answer is more then likely a no if you really wanted to fixate on a short answer without understanding the reasons, details, context

Thank god the fees are finally coming back to Earth.

I do think 10mb blocks would be tits (good).