Scaling-wise, the Bitcoin Core developers are mainly focused on:
- SegWit, which increases the "effective" max block size to 1.8-4 MB (the exact size depends on the distribution of transaction types).
- Lightning, which "caches" transactions off-chain to allow for much higher volumes and zero confirmation times.
Both are very good ideas which will probably be essential to Bitcoin's long-term scaling. However, some people seem to be extremely concerned that fees could increase too quickly, and that the above solutions may be too slow in becoming widely useful. As I have previously mentioned, there are several options for quick scaling beyond SegWit or Lightning. I will outline a fairly simple one here, which will work on the Bitcoin network as it exists now. For those concerned about this issue, I recommend working on creating something like this.The idea is to make a federated sidechain with an unlimited block size, and rely on a certain amount of centralization within that sidechain to increase efficiency. This is the same way that Blockstream's Liquid sidechain works, which is intended for high-volume settlement between banks.With federated peg, a fixed set of centralized entities are designated as "signers" (aka "functionaries"). These are theonly entities which need to run full nodes, so scaling is way easier: just buy super-beefy servers for all of them. Everyone else just needs to download the sidechain block headers, their own transactions, and the needed Merkle branches. Also, confirmations are near-instant because there is no PoW mining, and fees can be very low because there is no block-space scarcity and the cost to signers for processing a transaction is minimal. If the signers are all independent (ie. they won't collude) and in different countries, then this arrangement can be quite secure, and arguably even more decentralized than when lightweight nodes trust the highly-centralized Bitcoin miners. The Tor network works similarly: the entire Tor network is administered by about 6 directory authorities run by independent organizations in separate countries. Obviously, this centralized arrangement would be totally unacceptable for Bitcoin as a whole, but I think that it's reasonable in this context.Blockstream has a framework for building your own federated 2-way-peg sidechain that will work with today's Bitcoin network: https://www.elementsproject.org/sidechains/creating-your-own.html Take that code, make a few adjustments for high volume (see the end of this post), and run with it. The code/instructions above creates a sidechain with only 1 signer -- for security, you'd want to have multiple signers (maybe 10-20) in a production network. You could copy code from Elements Alpha for this.From an end-user perspective: Wallets supporting the sidechain would have two separate balances, which can be thought of as "checking" and "savings". The savings part would be BTC balances exactly as now. The checking part would be BTC in the sidechain. BitPay etc. would show just one address, but would listen for transactions on both the Bitcoin network and the sidechain. Users would periodically move BTC from their savings to checking. Because the checking side is centralized and therefore less secure, I envision people generally never having a balance of more than $1000 or so in their checking balance -- if a transaction is more than a few hundred dollars, it's better to do it on the Bitcoin network directly.It's like having a high-security Swiss bank account which only allows wire transfers (Bitcoin network) plus a less-secure checking account which has a debit card (sidechain).Adjustments for higher volume:
- The overlay network would need to be different. It doesn't scale for everyone to broadcast their transactions to everyone else. Senders should just send transactions directly to one or more of the functionaries.
- To fetch your incoming transactions, you'd need to query the functionaries. It'd be nice to do this in some way that doesn't give functionaries a list of all of your addresses. Bloom filters are better than nothing, but it's possible to do even better.
- The functionaries all need beefy servers and low-latency, high-bandwidth connections between each other.
Additionally, it would be possible to add anonymity features to the sidechain (eg. confidential transactions). But I'm thinking here about something that could be done pretty quickly, so that's not essential.Elements Alpha (already running, though not intended for production use) and Rootstock (apparently soon to be released) are federated sidechains and therefore offer many of these same advantages, but they're not really focused on high volume or close integration with Bitcoin transactions, so I think it'd be better to create a dedicated sidechain for this.Since much of the code is already written, I think that a dedicated team could probably have this up and running in a month or two.