Is Strike the Lightning killer app? Bitcoin Tech Talk Issue #173

For the past few few years, something about lightning has bothered me. It’s a great tech and I like it a lot, but getting a lot of people to spend Bitcoin en masse seemed implausible to me, especially as Bitcoin is mainly used as a savings technology. Why would anyone spend a long-term appreciating asset? Why would making spending convenient add value to the network? The opposite, or making buying convenient is what adds value to a savings technology. Hence, I concluded that Lighting would really only come into play once Bitcoin becomes more of a method of payment.

My evaluation has changed due to a new product: Zap wallet’s Strike. Strike is a way to pay bitcoin to a merchant using a debit card. You can use a debit card to pay using lightning, as you can see in this demo. This is probably the most seamless experience for using Lightning as a payment rail that I’ve seen. The seemlessness is not the biggest feature, however. The biggest feature of Strike is the new flow of money. Lightning is no longer just useful for spending Bitcoin, but also for accumulating Bitcoin.

Currently, the only way to accumulate Bitcoin is to buy Bitcoin yourself or to get someone to pay you Bitcoin for some good or service you produce. Up until now, Lightning was more or less the same. You needed someone to spend Bitcoin for you to get some. Strike changes the equation. You can sell a good or service for fiat money and accumulate Bitcoin instantaneously! Not only that, but there’s no need for a bank account on the back end!

The privacy and regulatory implications of what Zap has built should not be overlooked. As Jack Mallers details in his post, they are already using Strike in his family’s cannabis business in Colorado. Strike was built as a way to replace credit card payments which are difficult due to the lack of banking relationships in that industry. Strike is literally banking the unbanked, just not in the way we think of the unbanked. This should become popular for merchants that use Bitcoin as a way to not deal with banks. For example, this helminthic therapy provider only takes Bitcoin. Because of FDA restrictions, they don’t have a bank account. I suspect that their customers would much rather use a debit card for purchase than Bitcoin to buy products. With Strike, they can.

Strike looks like the killer app for Lightning to me. Right now, lightning use is limited to bleeding-edge Bitcoin-owning techies. Strike solves a real problem (lack of bank accounts) for real people (gray or black market merchants that have trouble getting bank accounts) in a convenient way (not requiring people to go through a 17-step process to get Bitcoin on their phone first). That’s what I call product-market fit. Congrats to the Zap team and I will be following this particular product very closely.

Bitcoin

Taproot is still big news, with more useful tools coming out daily! I read through BIP341 on my Youtube channel this week talking about how Taproot combines the single-key p2pkh and more complex script hashing like p2sh. Core developer Karl-Johan Alm has added Taproot support to btcdeb (Bitcoin Script Debugger) with a well written guide here. If you want to play with Taproot, this is the place to start.

BIP119, or OP_CHECKTEMPLATEVERIFY which I covered last week, is under some scrutiny on bitcointalk.org with Greg Maxwell arguing that a more general covenant is desirable. Jeremy Rubin held the OP_CTV seminar on Saturday and the recording is available here.

Another way to smooth out fees is proposed by anonymous developer ZmnSCPxj, who wrote on the bitcoin-dev mailing list about how fees can be smoothed through insurance. Essentially miners sell fee insurance and users buy fee insurance to smooth out fees. A user that submits a transaction to a miner with insurance would be guaranteed either that the transaction will go through in X blocks or get an insurance payout from the miner in a trustless way. A business that doesn’t want to risk delaying payments can hedge with insurance based on market prices instead of relying on a blind guess. A proposal like this, if implemented, creates a more liquid and accurate fee market and would be welcome for that reason.

Connor Brown has a very readable post on Bitcoin’s development philosophy. As he points out, Bitcoin seeks first to do no harm. That means having to go slowly and carefully when introducing anything new.

If you’re using Trezor, please take care of the physical safety of your device. As this post from Kraken shows, a hacker can extract the seed from the device in as little as 15 minutes. If you use the BIP39 passphrase, that should make it more secure as the passphrase is not stored on the device.

Lightning

Besides Zap’s big announcement, Phoenix Wallet has a new release, 1.1.0. The most interesting part of this release is its support for LNURLs. Lightning users can scan a single URL (universal resource locator) and let their nodes do the multiple rounds of communication required for complex LN channel transactions. This can range from getting paid out of a channel to using some of the capacity available to open an inbound channel. More adoption of this standard should make Lightning experiences smoother going forward.

Christian Decker has put together a curated list of plugins for c-lightning. These mostly consist of utilities to maintain your lightning node.

Economics

Zain Allarkhia makes a compelling argument for why Bitcoin is interesting as money. The argument boils down to having strict decentralized controls that give it credibility. Definitely worth a read.

The fallout of the BCH dev tax continues. Peter Rizun has come out in opposition, including changing Bitcoin Unlimited to avoid the tax to essentially force a chain split. In addition, some anonymous miners have come out in opposition to the tax as well. Even bitcoin.com is backtracking. Jiang Zhouer replied by suggesting a miner vote on the tax plan. He proposes a threshold of 2/3 to implement the dev tax. Since the original plan includes orphaning blocks not paying the dev tax, getting 2/3 of miners to agree to the dev tax is very likely. Orphaning, after all, is more aggressive than voting.

This points out why centralizing something previously decentralized causes so much strife. It’s hard to force people that aren’t used to having an authority over them to follow your centralized dictum when they disagree. More chain splits in BCH and even BSV seem inevitable for this reason.

Bitcoin Gold had two more 51% attacks that apparently only cost $1200 each to enrich the attackers $36000 each time. As altcoins get less and less hashrate, the temptation to do this will grow and will have the unfortunate side effect of adding more Know-Your-Customer ID checks to more exchanges. Of course, delisting such coins would be the preferable method, but I suspect that the liquidity and the profits for such coins is still high enough for most exchanges to continue listing them.

London

I’m in London this week for the Advancing Bitcoin Conference, a conference aimed at developers. Please come by and say hello and if you have any of my books, I’ll sign them for you not just with my physical signature, but with my PGP signature.

Lastly, I have scholarships available for the next three Programming Blockchain seminars in Las Vegas, Hong Kong and Antwerp. I would appreciate your help in getting talented programmers to apply.

Fiat delenda est.