Re: Addressing Block size and occasional mempool congestion
but for how long are we going to continue like this ?.
I spent several hours, roaming around the internet and trying to figure out every suggested plans in addressing the problem of scalability. I even read across few BIPs such as BIP101 and others that have all been rejected so far by the Bitcoin community, as they weren't satisfactory enough to address the issue of block sizes.
Even with this implementation, we haven't been able to say "Goodbye" to congestion.
With the inability for SegWit to address the issue of small block size, SegWit2x was introduced basically to increase the size of blocks to 2mb for more accommodation of transactions, but this idea wasn't enough to get approval from the community due to the absence of replay protection. Meaning, the absence of this protection could cause a replay attack. Lightning network on the other hand requires creating a payment channel between two individuals. This was suppose to address the issue, but it doesn't have a say in the size of blocks either. And also, the technicalities behind it has not carried everyone along in understanding it.
The issue of congestion is still very much on ground, though it has failed off as there are no current events or any rush to trigger such. Certain periods like halving, Bull run and Bear run are ideal times to witness such. Unarguably, congestion will come, which some of us must have prepared the LN as a backup plan, while others can save themselves with the extra tx fees, but what's now left for others like myself rather than to sit and wait on the queue along other transactions that are available on the mempool ?.
Just a simple but decision making question for both developers and none developers today:
1. What do you think is a possible solution to this problem?.
I spent several hours, roaming around the internet and trying to figure out every suggested plans in addressing the problem of scalability. I even read across few BIPs such as BIP101 and others that have all been rejected so far by the Bitcoin community, as they weren't satisfactory enough to address the issue of block sizes.
Even with this implementation, we haven't been able to say "Goodbye" to congestion.
With the inability for SegWit to address the issue of small block size, SegWit2x was introduced basically to increase the size of blocks to 2mb for more accommodation of transactions, but this idea wasn't enough to get approval from the community due to the absence of replay protection. Meaning, the absence of this protection could cause a replay attack. Lightning network on the other hand requires creating a payment channel between two individuals. This was suppose to address the issue, but it doesn't have a say in the size of blocks either. And also, the technicalities behind it has not carried everyone along in understanding it.
The issue of congestion is still very much on ground, though it has failed off as there are no current events or any rush to trigger such. Certain periods like halving, Bull run and Bear run are ideal times to witness such. Unarguably, congestion will come, which some of us must have prepared the LN as a backup plan, while others can save themselves with the extra tx fees, but what's now left for others like myself rather than to sit and wait on the queue along other transactions that are available on the mempool ?.
Just a simple but decision making question for both developers and none developers today:
1. What do you think is a possible solution to this problem?.
IMO
Congestion is a way to force users into offchain solutions such as Lightning and Liquid.
So Congestion is a Feature, not something that will be fixed with something as simple as a Blocksize increase or even faster block speeds (like LTC 4X faster).
So don't expect any onchain solutions.
This leaves you with the following options to save money.
1. Become a Super Nerd and learn LN, which really only makes sense if you can process thousands of transactions per day. (Not Realistic)
2. Use Coinbase and use their Offchain transactions to send between accounts, at Zero Transaction Fees , limits are the receiver also must have a coinbase account to receive.
3. Use any of the other Cryptos beside BTC, that has excess onchain capacity for lower transaction fees, and they are numerous.
4. Transact in your local fiat , and only buy and sell BTC on an exchange as a investment and convert to fiat when needed, never needing to send actual BTC in a transaction to avoid BTC blockchain capacity limitations.
