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.
doing nothing is this math: 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 veryify transactions pre-confirm. and you as a LN nutcase know nodes can validate "millions of payments a second"
c. POOLS verify hash matches header.. header has transaction merkle root. root matches leafs.. and leafs are 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.
the whole "verification" time is not as big assult 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??