On May 14th, 2019, Bitcoin Optech hosted an Executive Briefing session at the Chaincode Labs office in New York. The seminars were targeted at executives and founders of Bitcoin companies, and covered what we think are the most important technical topics that executives needed to be aware of in 2019:
- A Return to Fees - why fees spike in Bitcoin, why high fees may return, and how businesses can thrive in a high-fee environment.
- Operating on Lightning - mainnet Lightning Network capacity has exploded in the last 12 months. A survey of how Lightning is being used now and discussion of opportunities for Bitcoin businesses adopting Lightning.
- The Next Softfork - features of upcoming Bitcoin softfork proposals: Schnorr signatures, Taproot and SIGHASH_NOINPUT. What those changes could mean for businesses.
A Return to Fees
The first presentation was given by Bitcoin Optech contributor Mike Schmidt, and focused on transaction fees and ways to mitigate costs and user confusion.
Schmidt begins his talk by reviewing some statistics from recent Bitcoin fee events, both short events from the past couple of months and the longer event from January 2017 to January 2018 where the next-block fee for an average-sized transaction was consistently over $1 (and often over $2). He reminds listeners that high fees are likely to return—which may have already happened—and that organizations that implement techniques to reduce their fees by even small percentages could save significant amounts of money for themselves or their customers if fees climb as high (or higher) than they did before.
He then describes several techniques services can implement in order to reduce their fees, and he roughly quantifies how much improvement can be expected from each technique. This includes: better fee estimation, better coin selection, payment batching, using segwit, UTXO consolidation, patient spending, Replace-by-Fee (RBF) fee bumping, Child-Pays-For-Parent (CPFP) fee bumping, and Lightning (as a future technique). He also notes that education plays an important role in getting users to accept and adopt several of these techniques, and points out that it can also help reduce user interaction costs such as providing customer support for stuck transactions during fee events.
The 30-minute presentation covers each point concisely, making it an excellent high-level overview for anyone interested in learning about the Bitcoin fee market and how to mitigate expected fee increases.
Operating on Lightning
Bitrefill CEO Sergej Kotliar then gave a talk about his experience running a commercial service on the Lightning Network.
Kotliar begins by explaining that high transaction fees during previous years had a significant effect on Bitrefill’s business, so they made a special effort to get really good at minimizing fee-related expenses. The ability to receive LN payments supported that goal, and he believes they were the first service on mainnet to sell real items for LN payments. Today, LN payments represent about 5% of their sales, similar to the amount of business they do using Ethereum.
He believes it’s important for businesses to start working on LN now. “In Bitcoin we’ve gotten used to waiting for things […] but making customers wait an unknown amount of time creates a risk that the customer will go away.” For example, by the time a deposit clears at an exchange, the customer may no longer be interested in making the trade that would’ve earned the exchange a commission. Additionally, Bitrefill’s experience with LN is that LN’s improved invoicing eliminates a number of different payment errors seen with onchain bitcoin payments, including overpayments, underpayments, stuck transactions, copy/paste errors, and other problems. Receiving payments over LN also eliminates the need to consolidate UTXOs and reduces the need to rotate money between hot and cold wallets. Eliminating all of these problems has the potential to significantly reduce customer support and backend expenses.
In a particularly interesting section of his talk, Kotliar shows how perhaps as much as 70% of current onchain payments are users moving money from one exchange to another exchange (or even between different users of the same exchange). If all that activity could be moved offchain using LN payments, exchanges and their users could save a considerable amount of money and everyone in Bitcoin would benefit from the increase in available block space.
Kotliar concluded his talk with a few short segments. He described what software and services Bitrefill sees LN users using today and what he expects them to be using in the near future. He then explained two of Bitrefill’s services for LN users (including businesses), Thor and Thor Turbo. Finally, he briefly described several planned improvements to LN: reusable addresses (see Newsletter #30), splicing in and out (see #22), and larger channels (also #22).
Overall, Kotliar made a compelling case that LN’s faster speed, lower fees, and improved invoicing means businesses that expect to remain competitive serving Bitcoin customers in the near future should start working on implementing LN support today.
The Next Softfork
The final seminar was given by Bitcoin Optech contributor Steve Lee about potential future softforks in the Bitcoin Protocol.
In his presentation, Lee describes the various phases of a soft fork from idea to proposal to implementation to activation. Using this framework, he identifies the current state of the Schnorr/Taproot soft fork (see Newsletter #46), the consensus cleanup soft fork (#36), and the noinput soft fork proposals (BIP118 and bip-anyprevout, see #47). Although later in the presentation he provides an overview of the consensus cleanup soft fork (fixing several non-urgent problems in the protocol) and the noinput proposals (enabling new features for contract protocols such as the Eltoo layer for LN), his talk—and this summary of it—focuses on the combined bip-schnorr, bip-taproot, and bip-tapscript proposal.
After providing a high-level overview of Schnorr signatures and signature aggregation—information probably already familiar to readers of this newsletter—Lee builds a significant portion of his presentation around 2-of-3 multisig security for business spenders, a feature used by many businesses today. He first describes the savings available to users of threshold keys, aggregated public keys that only require a subset of the original parties in order to create a valid signature, such as an aggregated key created from three individual keys that can be signed for by any two of the participants for 2-of-3 multisig security. The upside of this approach is maximal efficiency and privacy onchain, but the downside is required interactivity creating the pubkey, interactivity creating the signature, and an inability of the keyholders to use block chain data for auditing to determine which subset of them actually participated in signing.
Addressing both the public key interactivity and the signature auditing concerns, Lee uses an easy-to-understand sequence of illustrated slides to demonstrate an alternative construction possible using a combination of Taproot’s key-path and script-path spending. Three MuSig-style 2-of-2 aggregated pubkeys are created—one for each of the three possible pairs of signers in 2-of-3 multisig. Because this is MuSig n-of-n key aggregation, it doesn’t require interaction. The most likely of these combinations (e.g. a hot wallet key and a third-party security key) is made available for Taproot key-path spending, allowing an output to be spent using a single aggregate signature that looks like any single-sig spend. The two alternative options (e.g. each involving a cold backup key) are placed in a MAST tree for a script-path spend. This isn’t as private or as cheap but it provides redundancy. For any of these options, any third-party looking at the block chain data sees only a single signature and no direct information about how many parties are involved, but each of the three key holders knows which two of the participants’ public keys were used to create the particular aggregated key that the spending signature matched, giving them private auditability. Lee concludes this portion of the talk by summarizing the tradeoffs and showing the clear overall benefits of Schnorr and Taproot for current multisig spenders.
In addition to enhancing current uses of Bitcoin, also described are new features that aren’t currently practical but which would become so if Schnorr-style signatures and MAST-style script trees become available. Lee finishes his talk by providing a rough, and heavily caveated, timeline for when we might see the changes described in his talk.
About Bitcoin Optech
Bitcoin Optech exists to help Bitcoin businesses adopt scaling technologies. We publish a weekly technical newsletter and run workshops on scaling tech. The 2019 Executive Briefing was our first event targetted at executives and management, and presented important technical topics at a high-level for decision makers at Bitcoin businesses.