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.
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.
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.
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.