Why didn't you calculate this for 10 MB blocks? After all, we are talking about this increase now.
For increase to 10 MB, I'll right as well vote in favor, and maybe a little higher than that. I have clarified before that I'm not strictly against anything beyond 4 MB, I'm just not of the opinion that it's going to solve the problem; it's only delaying it.
math: doing nothing= delaying * (avoiding problem * causing more problems)
Can somebody show me some data or a paper to support this?
It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions. When they broadcast their block, the rest of the miners must firstly verify it before mining on top. The bigger the block size, the more time it takes to verify the block, and hence, the more the time the lucky miner gains to continuing mining alone.
a. miners(asics) dont verify transactions/blocks... you mean POOLS
b. POOLS verify transactions pre-confirm. and you as a LN nutcase know nodes can validate "millions of payments a second"
c. POOLS verify a hash matches header.. header has transaction merkle root. root matches leafs.. and leafs are known/checked TXID
at point C competing pools and nodes are not again validating all transactions..
d. at most if a merkle leaf does not correspond to a TXID in a nodes mempool of unconfirms, they ask their peer for that TX.
e. the amount of tx they need to call and validate due to not already having in mempool is a small % of a block
the whole "verification time" is not as big of an assault on nodes as you think it is
And it's not just verification, it's propagation as well. If you we had 1 GB of blocks, as in BSV, you could perhaps imagine this better. During the time that gigabyte is traveling across the network and is in the process of verification, the lucky miner gains invaluable time advantage.
mempools are already validating 300mb-500mb of transactions all the time right now.. stop pretending that nodes cant handle 100mb-500mb+ when all evidence shows the opposite
funny part is you are part of the crew that doesnt want to stop !ONE! transaction being 4mb yet you then say nodes cant handle a few dozen mb of transactions.. even when mempool and subnetwork "state" validtion prove nodes can handle ALOT more then your imaginary barriers
You persist in presenting this as the ultimate argument, despite my repeated assertions that the storage requirement is not our foremost concern.
but your crew is happy that fee's are(time of posting)
341.23 sat/vB ≤ 20 min. (LEAN 226sat tx = 77,066sat = $28.23)
but you want to say a 2012 $150 hard drive for the historic and next 5 years (17 years = $10 a year) is a problem
if paying $10 a year is a concern.. then the tx fee means you want people to only use bitcoin once every 3 years??
sorry but the reality is its the tx fee thats the concern. not the hardware cost..
tx fee is making people not want to transact/run nodes daily..