Bitcoin’s Silver Bullet: How to Get 10x Scaling and 0-Conf Today
Network Congestion
The bitcoin community has been engaged in a long-running debate about how to scale the blockchain. The mempool is developing a large backlog:
Some people want a hard fork to allow bigger blocks, while others want to a soft fork that implements a new technology called SegWit. Both sides claim their solution is simpler: hard forking because it involves fewer changes, and SegWit because it involves a soft fork. Neither side has been able to attract a clear majority.
The Fix
The good news is that the bitcoin network already has a way to get 10x scaling and trustless 0-conf transactions. This works without a hard or soft fork, and uses existing technology. We don’t even need to fix transaction malleability. I’m talking, of course, about one-way payment channels!
Payment Channels
Payment channels have been around for a long time; the original proposal was from Satoshi Nakamoto. The most recent iteration uses BIP65, and is straightforward. You can read more about it here. The basic idea is that a sender “posts” some funds on the blockchain to send to a specific recipient. Then, when the sender wishes to release some of those funds to the recipient, the sender sends the recipient a validly signed transaction spending only some of those posted funds. The recipient can countersign and broadcast the transaction to the blockchain. However, the recipient can intentionally choose not to settle the transaction if they want, so that the sender can double-spend it in the future with a new transaction that transfers more of the balance to the recipient. At any point, the recipient can broadcast the last transaction received and settle their funds on the blockchain, without broadcasting every intermediate transaction. Two blockchain transactions (one to open the channel and another to close it) could be the net result of thousands of individual transactions!
When we talk about payment channels, we usually talk about a user repeatedly making a micropayment to a service provider in a relatively short period of time. For example, this could make sense for a user to pay a WIFI hotspot provider for an internet connection. While this is possible, it’s a rare use-case and may explain why payment channels have never gotten much adoption. What is very common, however, is for large bitcoin services (exchanges, payment processors, wallets, etc) to pay one another on behalf of their users. This could be accomplished easily with payment channels. For end users of participating bitcoin services, the UI would be an improvement; there would be a simple pop-up asking the user to confirm their transaction (perhaps with their logo and an SSL lock icon), instead of having to deal with confusing bitcoin addresses and long confirmation times.
Here are the major differences of One Way Payment Channels vs the Lightning Network:
Protocol Changes
One Way Payment Channels: This works now, no politics or protocol changes needed! 21.co has free open source code that does exactly this and so does bitcore.
Lightning Network: Requires a malleability fix, SegWit would be best.
End-User Upgrades
One Way Payment Channels: End-users of participating bitcoin services install no new software, as all the functionality is server-side. Few services need to upgrade to provide tremendous utility.
Lightning Network: End-users who want this feature must opt-in and install new software.
User Experience
One Way Payment Channels: Better UI for end users: no more confusing bitcoin addresses since participating services will handle that behind the scenes. Instead of copy-pasting or scanning QR codes, participating bitcoin services could build a UI where it shows you a picture or logo of the person/company whose account the bitcoin service will credit for your funds.
Lightning Network: Having funds locked in hot channels (0-conf) and available in warm addresses (private key on internet connected machine), will be difficult to convey to end-users. Hopefully, good software can abstract most of this away.
Trust
One Way Payment Channels: Only works sending from one trusted BTC service to another. If Alice wants to do a one-off transaction where she sends 0.1 BTC from her wallet (where she controls the private keys) to Bob’s wallet (where he controls the private keys), this scheme provides no benefit.
Lightning Network: Trustless! You can chain payments from one channel to another (as long as transaction malleability is fixed).
Security
One Way Payment Channels: Slightly more funds in “hot” wallets. These could be tied up for the duration of the channel if your channel partner is uncooperative.
Lightning Network: Way more funds in “hot” wallets. These could be tied up for the duration of the channel if your channel partner is uncooperative.
Despite those differences, there are many ways that One Way Payment Channels and the Lightning Network are very similar:
Fees
Dramatically lower fees, especially for smaller transactions!
Payment channels require paying 2 fees, one to open the channel and another to close it. If the channel settles 1,000 transactions, this doesn’t really matter.
Instant Confirmation
Yes!
Payment channels must already be open in order to be used for a 0-conf transaction. If a customer wants to send more BTC than is in the channel, this scheme provides little benefit. In other words, this is better for smaller transactions that you can leave channels open for.
Accounting
More complicated vs vanilla bitcoin transactions, as 1 blockchain transaction could now represent a collection of many end-user transactions. This also may be tricky at first for existing users who got accustomed to looking things up on the block explorer of their choice.
Blockchain Availability
Requires blockchain availability on-demand. You need to be sure that if you have a valid redeem script from the sender, you can include it in the blockchain before the original refund transaction becomes eligible to be broadcast. This can be mitigated through smart software that handles fee calculation and time buffering appropriately.
While lightning is a better technology, one-way payment channels are available now. Why isn’t anyone using them? Imagine how great it would be for bitcoin users that already use trusted services to be able to transact nearly instantly, for a very low fee, and without complex bitcoin addresses. This obviously won’t solve all of bitcoin’s scaling problems, but it could relieve an enormous amount of pressure, improve user experience (especially for new users), and perhaps opens the door for bitcoin-backed micropayments!
For those that are technically minded, here is a more detailed description of how it might work in a hypothetical example between Poloniex and Bitpay. Note that I haven’t talked to either about this, but any two trusted bitcoin services would do.
Imagine that a Poloniex user wants to pay a BitPay customer. Poloniex and BitPay could partner to offer free 0-conf transactions with no counterparty risk and massively lower fees. This is how it would work:
Poloniex establishes a one-way payment channel with BitPay using OP_CHECKLOCKTIMEVERIFY (BIP 65). Poloniex encumbers 10 BTC that will be automatically refundable to Poloniex in 72 hours if BitPay is uncooperative. Let’s call this Transaction A. Once the transaction has settled on the blockchain, the channel is open and ready to use.
- When a Poloniex user wants to pay a BitPay customer, Poloniex signs a redeem script spending the UTXO from Transaction A (with some proceeds going to BitPay and some going back to Poloniex) and presents this signed transaction to BitPay. BitPay can countersign and broadcast this transaction (let’s call it Transaction B) at any time. BitPay chooses not to countersign/broadcast this valid transaction B, for now at least.
- When another Poloniex users wants to pay another BitPay customer, Poloniex again signs a redeem script spending the same UTXO from Transaction A (with correspondingly more proceeds going to BitPay and correspondingly less going back to Poloniex) and presents this signed transaction to BitPay. BitPay can countersign and broadcast this transaction (let’s call it Transaction C) at any time. Transaction C is technically a double-spend of Transaction B, but BitPay has no risk of a double-spend attack because both transactions require BitPay’s countersignature, and BitPay does not give that out for intermediate transactions. BitPay again chooses not to countersign/broadcast this valid transaction C, for now at least.
- The process in step 3 can repeat until all 10 BTC have been spent, or 72 hours have passed since Transaction A settled. However, only two transactions will ever hit the blockchain: Transaction A to open the channel and the final transaction that BitPay chooses to countersign/broadcast to close the channel. Even if the channel processed 1,000 transactions, only 2 fees will be paid!
Once the final channel closing transaction has been broadcast, it’s time to open a new channel, perhaps with a different number of BTC and hours until the channel opening transaction becomes refundable. You can read more about this process here.
Note that these payments do not go directly to/from end-users. Rather, BitPay and Poloniex must have internal accounting of which user’s balance gets increased/decreased by each channel payment.
While the process sounds very complicated, developers can build very nice UIs on top of this that are better for end-users vs the current way of having to deal with messy bitcoin addresses. So imagine you’re on the BitPay checkout page, you click “pay with Poloniex” and you get a pop-up from Poloniex asking you to confirm the transaction (perhaps with some sort of 2FA as well). You confirm, and your transaction is settled instantly. You never see a bitcoin address, or wonder what the “waiting for confirmation” text box on a block explorer means. It would be as easy to use as Venmo!
Update: BitGo CTO Ben Davenport pointed out to me that Moonbeam is another protocol that implements both the BTC payment channel logic, as well as a formal protocol for off-chain communication.
Thanks to Jimmy Song, Aaron Caswell, Matt Corallo, Bob McElrath, Bennett Hoffman, Christian Maher, Ryan Shea, Richard Kiss, and others for reviewing earlier versions of this post. To be clear: reviewing a blog post does not constitute endorsement of the contents!
