output-types on Murch ado about nothing

A breakdown of different output types and their address formats

Thu, 23 Dec 2021 00:00:00 +0000

I was inspired by a recent reddit post to write my own description of the various single-sig output formats in Bitcoin. I’ll be covering only output types that make use of a single signature.

“Legacy Outputs” aka P2PKH

Pay to Public Key Hash was the first output type that got an address standard. Addresses for P2PKH outputs start with “1” and use the Base58Check encoding. The address encoding provides a checksum and represents a shorthand to communicate recipient information—which improved the UX over the prior situation which required the sender to handle the recipient’s full public key or non-standard output script to send a transaction.

Example: 1MDPuAy9WCbNQin71j9S3MKAAe9mGBRNVx

Issues:

High transaction weight
Case-sensitive addresses
Bigger data footprint than Pay to Public Key

“Wrapped Segwit Outputs” aka P2SH-P2WPKH

Segwit aimed to introduce a new family of output types which we refer to as native segwit, but the authors realized that adoption of a new address format would take time. The segwit softfork additionally introduced wrapped segwit outputs as a transitional solution, to be forward-compatible to wallets that could send to P2SH addresses. Since P2SH was rolled out in March 2012 and already widely used for multisig, most wallet software supported sending to P2SH when segwit was activated in 2017.

P2SH-wrapped Pay to Witness Public Key outputs are indistinguishable from other P2SH-uses until spent. All P2SH addresses start with the prefix “3” and use the Base58Check encoding like P2PKH addresses.

Wrapped segwit outputs lock funds to a P2SH Program, but their input script contains a Witness Program that redirects the script validation to the Witness Stack. While this achieved forward-compatibility, the redirection requires additional data that needs to be relayed on the network and stored in the blockchain. Since witness data is discounted by 75% when assessing transaction weight, wrapped segwit inputs are cheaper to create, even while their data footprint is larger than P2PKH.

All P2SH addresses start with “3”.

Example: 3Mwz6cg8Fz81B7ukexK8u8EVAW2yymgWNd

Issues:

Case-sensitive addresses
Redirection to the witness stack for evaluation adds extra data
Even bigger data footprint than P2PKH

Native Segwit Outputs

Instead of locking funds to a P2SH Program, the output script for native segwit outputs directly contains the Witness Program. This way, native segwit inputs only need a witness stack, and make do without the redirection data needed in the wrapped segwit construction, leaving only a zero-length stub for the input script. Native segwit outputs are represented with bech32 addresses for version 0, and bech32m for version 1–16. The bech32 encoding is single-case, making it easier to note down and dictate as well as more efficient to encode in QR codes. The bech32 encoding is engineered to provide error-detection guarantees. Bech32 and bech32m addresses start with “bc1”.

0) P2WPKH aka Native Segwit v0

Often simply referred to as “native segwit”, Pay to Witness Public Key Hash outputs lock funds to a public key hash similar to how P2PKH works. However, P2WPKH inputs provide the public key and signature in the Witness Stack instead of the input script, thus benefiting from the witness discount. Bech32 addresses encoding version 0 native segwit outputs start with “bc1q”, because “q” encodes 0 in bech32.

Example: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

Issues:

Bech32 addresses are still not supported by some wallets and services

1) P2TR aka Taproot aka Native Segwit v1

With the recent activation of Taproot, we add native segwit v1 outputs to our portfolio. Pay to Taproot outputs lock funds directly to a public key in the output’s witness program, which means (for single-sig uses) that the input only needs a single script argument, a signature, instead of needing to provide both a public key and signature like P2WPKH. P2TR uses Schnorr signatures, which are more compactly encoded than ECDSA signatures, reducing the signature size from 71-72 B to 64 B. This means that P2TR has the smallest data footprint even while the overall weight of input and output is slightly bigger than for P2WPKH. In addition, more complex spending conditions can be encoded in the leaves of the taptree that’s tweaked into the public key contained in the witness program. Bech32m addresses encoding P2TR outputs are longer than the bech32 addresses encoding P2WPKH outputs, since public keys are longer than the 20-byte hash used in P2WPKH. Addresses for P2TR outputs start with “bc1p”, because “p” encodes 1.

Example: bc1pay2tapr00tajnawrkf897ccgsmk4e0x8ng5g3rv3qzd7jzfy2zxspy50gj

Issues:

Bech32m addresses are brand-new and not yet supported by many wallets and services

Cost Considerations

All four described output types satisfy single-sig usage, although P2TR can do a lot more under the hood. Generally, the transaction cost is cheaper for newer output types: Legacy > Wrapped Segwit > Native Segwit. While the overall cost of P2TR input and output is slightly higher than that of P2WPKH, P2TR shifts a portion of the cost from the input to the output. When you don’t know at what feerate you’ll need to pay to spend your funds later, you should keep them in P2TR outputs, since they’ll have the smallest input cost. Likewise, you should prefer P2TR when others are paying you: the sender pays the output cost while the recipient pays the input cost. Although, you may still bump into some counter-parties that cannot send to bech32, and many that cannot send to bech32m, yet, the economic incentives are clear. If your preferred wallet or service doesn’t support bech32(m) yet, please do ask them to do so.

If you’re considering your transactions’ data footprint on the blockchain, you should also strictly prefer P2TR as it get you the most bang for the byte (see column “raw [B]” in table above). The data footprint for the output types is P2SH-P2WPKH > P2PKH > P2WPKH > P2TR.

2-of-3 inputs using Pay-to-Taproot

Tue, 18 Aug 2020 00:00:00 +0000

This article was originally published on my medium page on 2020-08-18.
This article was amended on 2020–12–20 to improve the description of the P2TR output scripts. Thanks to Matthew Zipkin, for pointing out the prior imprecision.

The Bitcoin community has been abuzz for a few years about bringing Schnorr signatures to Bitcoin. Since then, the idea has evolved into three formal Bitcoin Improvement Proposals: ‘BIP340 — Schnorr Signatures for secp256k1’, ‘BIP341 — Taproot: SegWit version 1 spending rules’, and ‘BIP342 — Validation of Taproot Scripts’. Respectively, they define a standard for Schnorr signatures in Bitcoin, introduce the Taproot construction, and formalize the new Script v1 instruction set. Taproot also iterates on the previous proposal of Merklized Alternative Script Trees (MAST).

There are two ways of spending a pay-to-taproot (P2TR) output. The first way is called keypath spending. P2TR funds are locked to a single public key similarly to pay-to-public-key (P2PK) outputs. The output script appears in the transaction as OP_1 <pubkey>. This script can be satisfied by providing an empty input script and a Schnorr signature of the corresponding private key in the witness program. The keypath is the default spending path. It is used in single-sig and collaborative multi-party spending.

Under the hood, the public key is a composition of an inner key and the Merkle root of a Taproot tree (the inner key is tweaked with the Merkle root). The inner key can optionally be a composite itself, for example multiple public keys aggregated via the MuSig scheme. These compositions are possible due to Schnorr signatures being linear.

The second way of spending a P2TR output uses one of the Taproot leaves. We call this scriptpath spending. First, the existence of the leaf needs to be proven which is done by revealing the inner key, the Merkle path to the Taproot leaf, and the script encoded in the leaf. Then, the spending conditions of the leaf’s script are fulfilled.

The remainder of this article explores the input costs of 2-of-3 multisig Taproot constructions. Some familiarity with the details of the proposals is helpful. Check out the Taproot overview and the excellent summary of the three BIPs by the Bitcoin Optech Group if you are looking to refresh the details.

The multisig user story

We are looking at a wallet construction using three keys held by two or three parties. The first key is held by the user, the second key is held by the service provider, and the third key is a backup key either held by the user or a key recovery service. We are assuming that the first two keys are hot and can be used in an interactive signing scheme as employed by MuSig. The backup key may be held cold e.g. on an air-gapped system in which case interactive signing should be avoided.

2-of-3 multisig with two hot keys and one (optionally) cold key

Classically, a 2-of-3 multisig address is constructed in the form of a pay-to-scripthash (P2SH) output of the form 2 <pubkey1> <pubkey2> <pubkey3> 3 OP_CHECKMULTISIG. This construction can logically be expressed as ‘(A ∧ B) ∨(A ∧ C) ∨(B ∧ C)’ which could also be thought of as “one of three 2-of-2 multisig scripts”. The latter translates nicely to Taproot: we can encode the preferred condition of spending with the user and the service key (the two hot keys) in an aggregated pubkey for the keypath, and put the two spending conditions using the backup key in leaves of the Taproot tree. Two variants are explored: one where the backup key is capable of participating in the interactive MuSig signing scheme, another that falls back to a simpler multisig scheme where signing is non-interactive e.g. because the backup key is air-gapped and the multiple roundtrips required for MuSig are inconvenient.

The most likely spending option with the two hot keys is encoded as an aggregated key in the keypath. The two backup spending options are put into leaves of the script tree.

Keypath spending costs

In the general case, all parties agree on a course of action and collaborate to use the keypath. This is the most cost-effective way to spend a P2TR output and allows multiparty spenders (and other complex spending conditions) to be indistinguishable from single-sig spenders.

Costs of keypath input

An input commits to a specific unspent transaction output (UTXO) which is defined by the transaction that created it and the position in that transaction’s output list. The UTXO entry provides the spending conditions to be satisfied by the spender. An nSequence field allows encoding replaceability, and the witness provides the spender’s authentication. In the case of the keypath this is a single Schnorr signature which in some cases may actually consist of multiple aggregated signatures.

outpoint (txid:vout): 32 vB+4 vB
scriptSig size: 1 vB
nSequence: 4 vB
count witness items: 1 WU
witness item size: 1 WU
signature: 64 WU

32+4+1+4+(1+1+64)/4 = 57.5 vB

Control Blocks

When a fallback to the backup key is necessary, the existence of the Taproot tree must be revealed. If there is only a single leaf, the spender provides only the inner key. Tweaking the inner key with the hashed leaf results in the public key. In sum, the data necessary to prove the existence of a scriptpath is called the control block.

Depth 0 control block

Length of control block: 1 WU
Header byte (script version, sign of output key): 1 WU
Inner key: 32 WU

1+1+32 = 34 WU

In case of two leaves, additionally the first hashing partner for the Merkle path must be revealed:

Depth 1 control block

Length of control block: 1 WU
Header byte: 1 WU
Inner key of root key: 32 WU
Hashing partner in tree: 32 WU

1+ 1+ 32 + 32 = 66 WU

Scriptpath spending cost

The below costs are in addition to the above costs of spending via the keypath.

Scriptpath spend assuming 2-of-2 MuSig leaf (hot backup key)

When the backup key is on a networked system, e.g. an HSM, and can participate in a multi-roundtrip signing process, we can make use of MuSig to aggregate the two public keys.

script size: 1 WU
script <pk> OP_CHECKSIG: 33 WU+1 WU
Depth 1 Control block: 66 WU

57.5+(1+34+66)/4 = 82.75 vB

Construction with 2-of-2 OP_CHECKSIG (cold backup key, no MuSig)

In the case that the backup key is offline and a human would have to make multiple trips employing USB sticks or QR codes, saving roundtrips may take precedence over saving a few bytes. Instead of an aggregated public key, we use a non-interactive multisig construction.

second signature: 1 WU+64 WU
script size: 1 WU
script <pk1> OP_CHECKSIGVERIFY <pk2> OP_CHECKSIG: 33+1+33+1=68 WU
Depth 1 Control block: 66 WU

57.5+(1+64+1+68+66)/4 = 107.5 vB

Discarded approach: single leaf with 2-of-3 script

It turns out that a single 2-of-3 leaf in lieu of the two 2-of-2 leaves is both more costly and less private.

+2nd sig: 1+64 WU
+1 empty witness item: 2 WU
Length of script: 1 WU
Script <pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD <pk3> OP_CHECKSIGADD 2 OP_EQUAL: 33+1+33+1+33+1+2=104 WU
Depth 0 Control block: 34 WU

57.5+(1+64+2+1+104+34)/4 = 109 vB

Conclusion

Upper bound of input and output sizes for single-sig and 2-of-3 multisig

The described 2-of-3 multisig scheme achieves input sizes of 57.5 vbytes for a keypath spend, 82.75 vbytes for the leaves using a hot backup key, and 107.5 vbytes for non-interactive backup spends. This results in a fee reduction by 45% for 2-of-3 inputs when switching from P2WSH to P2TR spending. In the uncommon case of a recovery transaction, the cost is negligibly increased for cold keys. Single-sig users are also incentivized to switch to P2TR as they save 11 vbytes on each input — the output cost is externalized on the sender.