2023.03 Vol.1

The Last Mile

The Lightning Network protocol allows for cheap, instant bitcoin transactions between two parties. But it has a steep barrier to entry. First, a user needs to be using bitcoin, which is a big leap coming from the fiat-world. Assuming buy in there, they then need to open a lightning “payment channel” (a.k.a. broadcast a multi-signature bitcoin transaction). Now they just have to manage a private key in order to make lightning payments…and keep the channel in good shape with liquidity and fees and…it’s a lot.

The Lightning Network’s cheap, instant transactions are suited for the “buy a coffee” use case more than the “buy a car” one. So shouldn’t the bitcoin equivalent of buying a coffee be easier to use than buying a car? (This analogy kinda breaks down when you consider how in the fiat-world you have to first open a bank account, but the fiat-world isn’t dealing with a user on-ramping challenge at the moment.)

If we constrain the lightning on-ramping challenge to the digital version of “buy a coffee”, quick micro-transactions on the interweb, is there a way to minimize the upfront barrier to entry? A user just needs a light wallet with less than ~$100 USD in it at any point, similar to carrying cash in real life, they don’t need the security to hold the $20K+ USD required to buy a car. That should be held in a cold storage wallet taking full advantage of the bitcoin’s security.

There is some up-and-coming tech which might help in this “on-ramp to bitcoin in order to buy a digital coffee” scenario.

Zero Confirmation Channels

As mentioned above, a lighting payment channel requires a bitcoin transaction to be confirmed on the blockchain in order for lightning payments to take full advantage of the layer one consensus. A rule of thumb, which many lightning wallets follow, is to wait for the transaction to be confirmed six times before considering the channel active. This takes on average sixty minutes. It’s clear why this is painful for the “buy a digital coffee scenario”, no one wants to wait around for this.

But what if a users are ok with not taking full advantage of layer one in some scenarios? A user might be willing to trade a much better user experience (e.g. do not have to wait an hour) for a little less security, especially if the security is only for the ~$15 bucks they have in their wallet (with the rest of their funds are heavily locked down in cold storage).

This is the trade for zero confirmation channels. Instead of waiting for the six confirmations on the blockchain, the two parties consider the channel to immediately be active. All other aspects of the lighting protocol are followed (well, almost, there has to be some tweaks to the initial channel open handshake). So what security is being degraded?

The channel opening protocol usually follows the steps:

1. Alice wants to open a channel with X capacity with Bob
2. Alice and Bob create a 2-of-2 multisig transaction which Alice contributes 100% (X) of the funding
3. Before the transaction is broadcasted, the first commitment transactions (which are not intended to be broadcasted) are created which send 100% of the funds to Alice (since nothing has happened on the channel yet)

This risk of a zero-conf channel is on Bob. Say Alice opens a zero-conf channel, sends Bob sats for something, but then double spends the funds of the original zero-conf funding transaction. Bob is just outta luck.

Could this be useful in the “on-ramp to buy a digital coffee” scenario? A service could sell zero-conf channels to users in exchange for out-of-band fiat payments.

1. User sends service $15 USD for a channel of similar value in order to on-ramp to the lighting network
2. The service opens a zero-conf channel with the user and pushes all the funds to the user’s side of the channel

There is a lot of trust in this scenario:

1. The user is trusting that the service will in fact open the channel after sending them some fiat.
2. The user is trusting that the service will not double spend the funding transaction before its confirmed.
3. The service is taking on some risk exposing itself to fiat charge-back issues.

With all that said, for a small amount of value this might be a perfectly acceptable trade.

There is some handwavy-ness to the above proposal surrounding how the user manages the channel and actually makes payments (like how do they calculate routes across the Lightning Network?), which I am going to keep murky by just saying that I believe tech like LDK is making it much easier for lightweight wallets to not have to be full lightning nodes.

Another issue might be the cost of the zero-conf funding transaction. The goal is still for this to someday get in the blockchain, so it will probably have to pay a fee. How much does that push up the minimal-viable-channel capacity though?

Zero-conf channels are just one possible strategy though, next up is hosted channels.