0

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

Improve this question
5
  • This is something between Ethereum's sharding proposal and Bitmessage's streams idea.
    – MCCCS
    Feb 11, 2021 at 18:26
  • 1
    Ahh..Sharding was the term I was looking for...Thanks!
    – Ryan Jones
    Feb 11, 2021 at 18:29
  • To only verify one shard just means you are trusting others to verify the other shards. Don't trust, verify.
    – chytrik
    Feb 12, 2021 at 7:03
  • Well..you are Trusting the protocol to verify the other shard..same way you are trusting the protocol to deliver your block reward..but I see what you mean. The transaction isn't really finished until it is confirmed on both shards.
    – Ryan Jones
    Feb 12, 2021 at 20:58
  • You are not 'trusting the protocol', you are trusting users that are running software that is validating the shards that you are not (ie, how would the protocol stop users on another shard from creating a fake proof? It cannot). This is only marginally different than running a light-wallet, wherein you validate the block headers, but trust others that run nodes to validate the full blocks. afaik it is widely accepted that the most information-efficient way to verify information is to have the information itself, you cannot compress the information and gain the same verification assurances.
    – chytrik
    Feb 12, 2021 at 23:27

1 Answer 1

Reset to default
3

No, I don't think that sharding is as simple or beneficial as portrayed here. Here are a few thoughts:

  • Splitting by addresses doesn't seem plausible. Most transactions have either multiple inputs or multiple recipients. It's not clear how transactions would be handled that attempt to spend funds from both chains or pay to both chains. If they need to be present on each chain, I don't think we'd get a significant traffic reduction on either chain. If they do get included on both sides, how do we ensure that they don't get confirmed on only one side? If they can only be included on one side, how do we coordinate that?
  • ETH has been working on Sharding since 2016(?), and as far as I can tell, it requires layers of mitigations and complexity, and comes with all sorts of trade-offs. ETH requires global state for each transaction's execution. By introducing sharding, ETH gets multithreaded validation. Bitcoin's transactions are inherently stateless, and its scalability concerns are related to total resource usage. Two shards of 0.5 MB blocks are no better than one chain with 1 MB blocks for that. Two shards with 0.5 MB blocks that have a storage footprint of 0.75 MB and coordination overhead sound like a step back.
  • It sounds like a complete consensus overhaul. It's unlikely that people would be comfortable to support such a proposal.

That said, we already have some sidechains and second layer solutions that we can offload transaction traffic to with far less overhead or critical changes.

Improve this answer
1
  • 1
    Thanks for the comments...I'll accept as answer. However the two shards would still have 1MB blocks but half the transactions would have larger transactions sizes due to the added data. Probably not 50% larger... The multiple inputs and outputs though kinda kills it.
    – Ryan Jones
    Feb 11, 2021 at 20:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.