This question falls under the heading of "shower thoughts" that are Generally discouraged in the bitcoin-dev list.
I hope this is the right forum.
I have been running my full node for a few weeks now and have been watching the number of transactions in the memory pool hover around 90K. I'm thinking this is only going to grow and yet we seem to have peaked at an average of 2.5k transactions per block.
I have read of various proposals (BIPs) to fix this but have not seen anyone suggest breaking up the chain into multiple chains.
Currently we have ONE BIG CHAIN that everyone mines...and all transactions go into it...all wallets addresses are contained...
But what if we take half of all addresses (say last digit odd or even) and create TWO Bitcoin chains... Each chain would start out with:
- Half the difficulty setting.
- Half the mining reward.
- And a special wallet address on each chain that contains all the bitcoins in the other chain. This wallet would not be able to have spends as normal. It would only be able to spend based on the workings on special rules.
Miners would split their mining across both chains. Difficulty would adjust independently as normal. Rewards would continue to halve as expected...however more transactions processed would mean more fee income per block. (Should take 2.5k peak transactions per block to 3.75k per pair of blocks to both chains)
Transactions will go to the chain for the source wallet address (odd or even) Any transaction that is odd to odd will stay on that chain...This is the savings in mempool and number of transactions as it won't effect the other chain.
Any transactions from odd to even will generate a transaction to the Special Wallet on Odd chain and add a new transaction to Even chain from special wallet to final wallet. And vice versa on the other chain.
The trick here would be having rules for the special wallet so only transactions can be spent from it using the other chains confirmed transaction as Proof. Embedded in that transaction is the spend to address that generates the final transaction on the other chain. Cross Chain transactions would be a bit slower as they would require a confirmation from 1st chain before adding a transaction to the mempool on second chain... And then the issue of if the first transaction on first chain got orphaned...how would you cancel transaction on second chain...but this is a far as I've gone...
If this works...you could split this up to 3 chains, four chains...etc...with rapidly diminishing returns.
Has anyone heard of this before? Thoughts? Comments? Thank you for reading! Ryan