One of the most dangerous things when wanting to solve an issue is to interpret the cause of that issue wrongly! In this case:
But we later go back to same problem when TX fees increases, and so many pending transactions are all seated at the mempool waiting to be confirmed, at this point in time, those who are able to pay higher fees get their transactions ahead of others, but for how long are we going to continue like this ?.
What we've been experiencing for a long time is not a scaling issue. It is a
spam attack issue that I've been talking about for just as long. The spam attack under the name Ordinals is injecting the mempool with a lot of junk transactions because there is a scam market creating the incentive for regular users to participate in that spam and basically fund the attack.
Now that the cause of the problem is clarified, we can focus on working solutions which is to prevent this exploit to make the attack either impossible or at the very least too expensive to be done.
Otherwise if this situation is interpretant wrong and as a scaling issue, the solutions such as increasing capacity would only make the problem worse because the spammers would have more space and cheaper transactions to continue their attack. This is why misinterpreting the issue is dangerous.
The introduction of Segregated Witness (SegWit) which was proposed in BIP-148,
SegWit BIPS are 141 and 143. The BIP148 has very little to do with SegWit.
thereby removing signature from Bitcoin transaction data.
Wrong.
SegWit does NOT remove anything from transaction data! It introduces a new "field" in each transaction known as witness that will hold signature (and other stack items needed for unlocking output scripts being spent).
This also means that there are more space to accommodate more transactions, only when certain parts of the transaction is removed.
Once again you made a conclusion based on wrong information. SegWit introduces Witness field and that way increases the capacity so that blocks can be as big as 4 MB instead of being capped at 1. By that increase it allows blocks to accommodate more transactions.
but it main purpose is to offer lower tx fees by taking up less block space. Even with this implementation, we haven't been able to say "Goodbye" to congestion.
The biggest goal of SegWit was to address transaction malleability.
The reason why it offers lower tx fee is not the smaller tx size (SegWit txs are in some cases bigger than legacy, byte-wise). The reason is because they use this new field called Witness that takes up that extra (3MB) space not the legacy 1 MB and they receive a discount for that reason.
SegWit2x was introduced basically to increase the size of blocks to 2mb
It is called 2x not 2MB which means it was doubling the capacity introduced by SegWit which would be 8 MvB weight.
wasn't enough to get approval from the community due to the absence of replay protection.
Wrong.
Replay protection is not even a Bitcoin related thing. It is only defined for altcoins that create an exact copy of Bitcoin protocol and its blockchain. Copycatcoins such as Bcash.
The reason for its lack of support was because we should have either chosen a hard fork from the start or a soft fork all they through. Mixing the two makes no sense.
IMO any future hard fork should address a lot of things not just a simple block size cap bump.
1. What do you think is a possible solution to this problem?.
I explained it at the beginning.
I want to add that I believe at some point we also need to address the scaling issue through a hard fork to fix a lot of things in the protocol (eg. merging Legacy and SegWit, fix bugs like sigopcount) and also increase the cap itself.