How to Scale Bitcoin?

I was at the Scalingbitcoin developer conference this weekend, and I have to admit that I was quite impressed by the quality of the presentations and the spirit of collaboration that I experienced there.

Okay, I’m going to have to confess.  As being likely the one who first coined the term “schism fork”, having hearing people refer to that term at the conference made me sort of feeling guilty of helping to foment exactly the kind of divisive behaviour among the community that we should be trying to avoid.  It was then with a sense of relief that I came away from the conference with a new sense of confidence in Bitcoin and the ability of the developers, users, and mining community to come together and share their ideas and work on how to help Bitcoin grow.  As one of the miners put it, “money is worth nothing if you cannot use it”

There were 4 major scaling themes at the conference, and I think the organizers did a great job of making sure that they covered all the bases in order to answer a lot of what the public wanted to know about the current state of the Bitcoin ecosystem and what we are all doing about it.  There were other talks which dealt with outlining the current problems in scaling Bitcoin, such as propagation delays, block censorship, and the Great Firewall of China which certainly add colour to the discussion, but I will focus only on topics which proposed solutions.

  1. Short term scaling solutions
    1. Blocksize, BIP248, 102
    2. Segregated Witness
  2. Medium term scaling solutions
    1. Lightning
    2. IBLTs
    3. Blocksize, BIP100, 101, 103, 105
  3. Mining and Security scaling solutions
    1. Blockchain braids
    2. No more orphans
  4. Privacy and Fungibility scaling solutions
    1. Confidential Transactions
    2. Zero Knowledge proofs and provably anonymous coins


Short term scaling solutions:

There was general consensus (as measured by show of hands and applause) between Pieter Wuille’s work on segregated witness and Jeff Garzik’s bump to 2mb now while continuing to evaluate the other long term BIP block size proposals.  As Pieter’s proposal seemed a win-win with an acceptable risk profile, it looks to be the one that will be implement in the shortest time.  It will be deployed via soft fork.

Jeff spoke of the rest of the other block size BIPs and the major choice between those that allow the free market to determine block size (BIP100, 103, 105, 106) or those that opt for a predictable schedule so that people can plan accordingly around it. (BIP101, 248).  He also mentioned that the fallback plan to just do a one time bump to 2mb (BIP 102) is the least contentious of them all, and that the do nothing of BIP000 is the worst outcome. Besides the fact that BIP102 is the least contentious, the execution of a hard fork on the mainnet would allow collection of extremely useful and much needed data on how the network would react and behave, possibly setting the stage for hard forks in the future, and possibly proving that hard forks are not as much of a ‘schism fork’ danger as the conservatives skeptics among us (myself included) have warned about.

Considering the general agreement of the audience to both these speakers, the logical conclusion is to implement segregated witness ASAP, and also start planning a hard fork to 2mb within the next month, with a flag day of 6months later.  This would theoretically give us a block size of 2mb/8mb (txns/witnesses) which would be a large effective increase in txn throughput for Bitcoin.  This should carry us through the next year at least.

Medium term scaling solutions:

(move txns off-chain)

Of the slightly longer term solutions, Lightning stole the show.  Thaddeus Dryja and Joseph Poon talked about the stages of Lightning release, and the effective number of users that it would be able to support.  To measure Lightning’s effect on Bitcoin txn/s is difficult, as it is effectively moving most of the transactions between parties offchain to the Lightning layer, leaving only the opening and closing of Lightning channels on the Bitcoin network.  Thus at its most effective, Lightning can likely make Bitcoin match the transaction volume of VISA. (at least for +250million users).  In the worse case scenario its performance is no better than the current Bitcoin network.  It is however a new revolutionary technology, and it will be quite some time before wallets are created for it.  It effectively decentralizes the store of value from the UXTO set being kept by the nodes, to the wallets of individual users. Due to its radical nature, it will have some issues, (Backups will be complicated)  but I believe a lot of new applications may be able to take advantage of it.  Lightning represents no risk to the existing network, and thus although it is a big change to user wallets, it is safe to go ahead and implement without permission/consensus.

IBLTs, Weak Blocks
(reduce what needs to be sent in a block)

Basically sending only a small compressed representation of a block header and the transactions that the block contains instead of actually sending the transactions.  This can radically reduce the size of the data that needs to be propagated over the network.  This will likely be more feasible in reducing bandwidth requirements in the near term than Lightning, given that it doesn’t require any changes on the users end.

Weak Blocks are another take on reducing the amount of information that needs to be sent after a new block is found by pre-emptively sending out the block that you are currently mining. That way when you find it, others will just need to request the differences in the txn that your block from the one that they were mining.

BIP100,103,105,106 vs BIP100,248
(make block size limits bigger)

Essentially it is the choice between dynamic block size which is controlled by the market to meet demand, or a static predictable scheduled increase in block size to which the network and market must adjust to.  The consensus is that we must eventually pick one of these methods and that we need to further collect data and analyze which strategy to take.  All of them will require a hard fork, which is also something that we have little hard data on.

Long term scaling solutions:

Of much interest were some presentations about some possible evolutions of Bitcoin from a block chain to a different form of data structure.  Of note were the Block Braids of Bob McElrath and the No Orphans proposals of Yonatan Sompolinsky.  Although they were all at the theoretical stage, they seemed far enough along to perhaps create prototypes for (and maybe test on a sidechain).  They have the effect of eliminating wasted work in mining and eliminating the effect of propagation delays which affect the double spend safety threshold, respectively.

Because they affect the fundamental structure of the block chain, and thus have a high risk profile, I see them as requiring a lot more study in terms of how they change the incentive structures and attack vectors of Bitcoin therefore they are more longer term projects (we would certainly not entertain implementing them without being much more comfortable about hard forks, for instance, because one would be needed in order to recover from a botched rollout)



Privacy and Fungibility scaling solutions:

Last but not least, these are the solutions which stand to directly increase user interest in Bitcoin by delivering actual features that people want, as opposed to just focusing on increasing the processing bandwidth of the network.

Confidential Transactions:

Adam Back spoke on the work on CT and its promise to be able to make amounts transmitted between addresses completely private.  This currently works but has an increasing effect on the size of a transaction, so I don’t see this being implemented until the issue of block size is somewhat alleviated first.

Zero Knowledge Proofs (Zerocash):

This is the application of to be able to publish proof of ownership of coins without actually having to reveal their amounts.  This has a great impact on transparency and the ability for proof of reserves to be done in a way which does not leak any privacy.  This also has a side effect of being able to create a totally anonymous version of a Bitcoin, which has the effect of being a perfect (provably anonymous) coin mixer.

All in all, I see that the future is bright for Bitcoin and I am very honoured to be part of this community.  Seeing how everyone is working to improve and help Bitcoin grow into the next phase of its development is an inspiration.

Tip me with ChangeTip!

Please donate!Or send me some mBits using Bitcoin

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.