I'm not really a technical guy, but if I were to calculate based on a common man's understanding,
If the average block confirmation is being reduced, let's say, for instance, from 4000transaction per block every 10 minutes to 4000 per block every 5 minutes. This will speed up the clearing of more transactions in less time and, as such, pave the way for other transactions to be executed if the transaction completion time is faster and more blocks are being covered than usual. Then there will be a less unconfirmed transaction, which will equally reduce the work load on miners and, as such, won't require others to pay more in order for their transaction to be upfront. Yes, it will actually reduce the fee charged per transaction.

Lowering the average Bitcoin block confirmation time could have several potential effects, both positive and negative:

Faster Transactions: The most obvious benefit of a lower confirmation time is that transactions would be confirmed more quickly. This would allow users to send and receive Bitcoin more efficiently, which could improve overall transaction throughput and user experience.

Higher Transaction Fees: A lower confirmation time could lead to an increase in transaction fees, as users may be willing to pay more to have their transactions confirmed more quickly. This could make Bitcoin transactions more expensive, especially during times of high network activity.

Increased Risk of Double Spending: A shorter confirmation time could increase the risk of double spending, where a user spends the same Bitcoin twice. This is because a shorter confirmation time gives attackers less time to launch a double spending attack before the transaction is confirmed.

Increased Network Congestion: A shorter confirmation time could also lead to increased network congestion, as more transactions would need to be processed in a shorter period of time. This could lead to longer wait times for users, higher transaction fees, and a higher risk of transaction failures.

Overall, lowering the average Bitcoin block confirmation time could improve the speed and efficiency of Bitcoin transactions, but it could also lead to higher transaction fees, increased network congestion, and a higher risk of double spending. Any changes to the Bitcoin protocol should be carefully considered and thoroughly tested to ensure that they do not have any unintended consequences.

I believe that in order to change the average block time, the way difficulty and bitcoin rewards work would also need to be adjusted...and probably would cascade into effects throughout all features of Bitcoin which would then either require adjustment or would raise the question as to if Bitcoin is still economically viable or not. Whether or not this is possible is one thing, though I would be almost certain that it would not pass consensus, as this kind of change would not just effect the speed of transaction times, though would extend all the way from the codebase to the economics of Bitcoin and its viability to operate in the future.

While some solutions seem simple in writing, generally they turn out not to be in practice.

Yes it is, in fact we do have blocks that getting confirmed with in few minutes of each other. It's random but it happens

For example, this happened about 1 hour back


it's the answer I am seeking. Why they opted for Blocksize instead of the average confirmation time.

---

This is obvious

---

Sounds reasonable

I was actually looking at it from the adoption point of view rather than the memes. The memes are useless, and we will have to find away of getting read of them. Let's say the memes are out of the picture and Bitcoin adoption has really grown huge with so many transactions streaming in from all corners per minute.

This is just a temporary solution or rather a solution for just two weeks. This process is done when the miners increase the hash rate (which is expensive and somewhat not profitable to the miners) and the interval between mining blocks are reduced, but once the 2016 blocks are all mined then the difficulty will adjust. The difficulty adjust in such a way that when the time to confirm a block is less than 10minutes, it will increase just to set the block average time to 10 minute again. For the miner to get transactions confirmed faster again then it has to increase the hash rate yet again

The current set time frame of ten-minute delay is a built-in function of the bitcoin blockchain validation process.
 It is the standard for an exchange performing a transaction or trade, so as to avoid congestion that might lead to failed, unverified transactions. Hackers might take control too.
Developers set the system in a way that, if transactions are being created too quickly, the system would add a zero to the number of zeros that must start the computed hash for a new block in the Blockchain. Imagine the collaboration.
Before an investor invests into the market, he/she wants to be sure that their funds don't get lost in the process, hence, why a critical look at the effects of lowering the average Bitcoin block confirmation time is necessary.
Anyways, with miners having to enjoy new pay increase and super computers and AI standing aside, it is quite possible to lower the confirmation time and still have a smooth flow, because more hands would be on deck to earn more from mining and new innovations developed to fill the lapse.

Wouldn't the only way to change the block confirmation time be to reduce the difficulty? Ultimately this is the determining factor over block times, hence it increases with hash rate growth in order to maintain a 10 minute average. But by doing so this would create a fork in the protocol with one side respecting the original difficulty protocol, and others adopting a new one, so this doesn't sound like a solution at all.

Someone correct me if I'm wrong here, but there is no soft fork option imo, it'd be the same as increasing block size - there would be a conflict in the rules of the protocol.

for those using clearnet (normal internet) sending upto 4mb around the entire network in 2minutes wont cause issues
however for those syncing blocks via TOR, their internet is slower so can cause orphan issues for blocks under 2 minutes

but here is the other thing
if blocks were changed, where difficulty adjusts from doing 2016 blocks per fortnight (the actual expectation) to being 8064 blocks per fortnight (2.5min average) then that makes the bitcoin halving happen yearly instead of every 4th year average.
it also makes the total coin supply not complete in 2140 but in the year 2060~
 - these means an even quicker rush to pressure fee's to overtake rewards even sooner. thus defeating your idea of countering this years spam fee mania, and instead causing the fee mania to want to persist due to the new fee:reward paradigm happening in years instead of decades

also more rewards per hours also means pools get a 4x increase in hourly rate. meaning they can sell their coins for 4x less because their cost/reward is 4x better. meaning bitcoins underlying "bottom" support drops by 4x.

need i go on?

Why will doubling the block size bring problems? HDD/SSDs aren't expensive nowadays, this is not an issue and I have no idea how are we gonna to handle it otherwise. So, do you think that it's better to wait hours and days to get transaction instead of increased block size? Isn't that going to halt bitcoin adoption and increase altcoin adoption? If the purpose of bitcoin is to get rid of 3rd parties and make peer to peer transactions, then we need fast confirmations. Increasing of block confirmation time is not a deal, it will only do worse because it will change the date when last bitcoin will be mined, it will change the date of halving, so, no, but what can block size increase change negatively? Storage can't be an issue today.

on the BITCOIN network you can lock value.. and with enough confirmations. its immutable thus very strong..  where locktime is still workable.. and that lock does follow rules. (not sure how long that lasts before core devs soften that rule too.)

however on LN.. which you must treat as a separate network.. when creating channels where a SUPPOSED uxto is used to then create a child transaction that is then called a commitment. the rules on the LN side are WEAK AS F**K and not really rules at all. and yes the LN devs blame user error for accepting a channel open session with zero confirm txid as the funding. and close session with bad unlocks as user error, even though its devs fault for making such a crappy project with such lack of rules, lack of auditing, lack of controls. lack of checks

the reason i bring it up is becasue you seem to care less that bitcoin devs already did mess with bitcoin transactions. but dont want them to mess with things that can affect a broke OTHER network.. which i found amusing and strange, ..and after soo many months/years of chances you have yet to learn how broke LN is to realise its not worth caring about as something that does not securely secure/hold value. but just presumes to

just skip a few months/years and come to the realisation that LN is broke and a completely new subnetwork bridge needs to be created from scratch to service bitcoiners. rather then waste months trying to hope bitcoin does things to entertain and recruit lightning lemmings

LN has many many issues which is why more people have decided to avoid LN and use other subnetwork bridges to lock their bitcoin value to.

anyway. back to the topic.

what bitcoin devs need to do is stop with the radicalisation of sponsorship deals to just make bitcoin messy to promote corporate patented subnetworks as the saviour. and actually get back to making bitcoin efficient. where every byte of a tx counts and has purpose where actual checks are done. as was the case years ago

idea's such has messing just with difficulty lasts 2 weeks.
idea's like messing with block per adjustment and thus reward amounts per block to compensate to try to force it to last..  overall messes with too many other things including the scarcity and value proposition. thus not the fix

the real fix is to get code to actually check tx data like it suppose to do. as that was the integrity promise of blockchains. to have data which all fullnodes fully verify and meet standards