This week’s newsletter briefly describes two discussions on the Bitcoin-Dev mailing list, one about Bitcoin vaults and one about reducing the size of public keys used in taproot. Also included are our regular sections about bech32 sending support and notable changes in popular Bitcoin infrastructure projects.

Action items

• Optech schnorr/taproot workshops: Optech is hosting workshops in San Francisco (September 24) and New York (September 27) on schnorr signatures and taproot. Engineers will learn about these technologies and how they apply to their own products and services, build schnorr and taproot wallet implementations, and have an opportunity to take part in the feedback process for these proposed changes to the Bitcoin protocol.

  Member companies should send us an email to reserve spots for your engineers.

News

• Bitcoin vaults without covenants: In a post to the Bitcoin-Dev mailing list, Bryan Bishop describes how pre-signed transactions paid to scripts using OP_CHECKSEQUENCEVERIFY (CSV) could allow users to detect and block attempts to steal their money by a thief who had gained access to the user’s private keys, a capability previously referred to as providing Bitcoin vaults. After describing at length both the basic protocol and several possible variations, Bishop made a second post describing one case where it would still be possible to steal from the vaults, although he also suggests a partial mitigation that would limit losses to a percentage of the protected funds and he requests proposals for the smallest necessary change to Bitcoin’s consensus rules to fully mitigate the risk.

• Proposed change to schnorr pubkeys: Pieter Wuille started a thread on the Bitcoin-Dev mailing list requesting feedback on a proposal to switch bip-schnorr and bip-taproot to using 32-byte public keys instead of the 33-byte compressed pubkeys previously proposed. Compressed pubkeys include a bit to indicate to verifiers whether their Y coordinate is an even or odd number. This can be combined with an algorithm that allows verifiers to determine two possible Y coordinates for the full pubkey from the 32-byte X coordinate contained in the compressed pubkey. One of these coordinates is odd and one is even, so the oddness bit allows verifiers to pick the correct coordinate, preventing them from having to try both combinations during verification (which would slow down verification in general and eliminate any benefits from batch signature verification). Several mathematical schemes have been proposed that would produce signatures for keys whose Y coordinates could be inferred without the additional bit (which is currently the only data contained within a prefix byte). This would save one vbyte for each payment to a taproot output (potentially thousands of vbytes per block if most users migrate to taproot) and 0.25 vbytes for each public key included in a script-path spend. For previous discussion about 32-byte pubkeys, please see Newsletter #48.

Bech32 sending support

Week 22 of 24 in a series about allowing the people you pay to access all of segwit’s benefits.

We’ve frequently mentioned the fee savings available to people spending segwit inputs, but we’ve never before mentioned that you don’t need to take advantage of the savings. If you want, you can pay the same fee you would’ve paid without segwit in order to possibly have your transaction confirm more quickly (all other things being equal). For some users, such as traders attempting arbitrage across exchanges, saving money may not be as important as faster confirmation for the same amount of money.

To examine this idea, let’s first generate a chart using Bitcoin Core’s fee estimates that illustrates the potential fee savings available to creators of typical single-sig, one-input, two-output transactions:

We see that, in general, it takes longer for a transaction to confirm the less you pay—but users of segwit can often pay less per transaction for the same amount of waiting. Now let’s simply re-arrange the axes for the same data:

For a given fee, it’s expected that users of segwit will sometimes wait less time for confirmation than legacy users, with native segwit users gaining the greatest advantage. In these estimates, the variation in confirmation speed for different transaction types all paying the same total fee can be more than 6 blocks (about an hour on average).

For users and organizations who have a fixed maximum price they’re willing to pay in fees per transaction, using segwit could significantly reduce confirmation time for their transactions during periods of high activity. Although this advantage only benefits people spending from bech32 and other segwit addresses, it’s another reason to expect people and organizations will increasingly request your software and services pay bech32 addresses in the near future.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, LND, C-Lightning, Eclair, libsecp256k1, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

• C-Lightning #2858 limits the maximum number of pending HTLCs in each direction to 30 (down from the maximum 483 allowed by the LN specification) and makes the value configurable with a --max-concurrent-htlcs option. The fewer the number of pending HTLCs, the smaller the byte size and fee cost of a unilateral close transaction because settling each HTLC produces a separate output that can only be spent by a fairly large input.