libtxsize -- a library for automated Bitcoin transaction-size estimates
llibtxsize —a library for automatedBitcoin transaction-size estimates
Johannes Hofmann
Dept. of Computer ScienceUniversity Erlangen-Nuremberg
Erlangen, [email protected]
Abstract —This paper presents libtxsize , a library to estimatethe size requirements of arbitrary Bitcoin transactions. Toaccount for different use cases, the library provides estimates inbytes, virtual bytes, and weight units. In addition to all currentlyexisting input, output, and witness types, the library also supportsestimates for the anticipated Pay-to-Taproot transaction type, sothat estimates can be used as input for models attempting toquantify the impact of Taproot on Bitcoin’s scalability. libtxsize is based on analytic models, whose credibility isestablished through first-principle analysis of transaction typesas well as exhaustive empirical validation. Consequently, thepaper can also serve as reference for different Bitcoin data andtransaction types, their semantics, and their size requirements(both from an analytic and empirical point of view).
I. I
NTRODUCTION
In most instances today, transaction-size estimates are usedto construct favorable transactions that minimize transactionfees. These estimates rely on heuristics and simple tools [1]–[3]. The solutions available so far are, however, limited inscope: all are limited to giving estimates for transactionsusing only inputs of identical type; some are even limited totransactions that use the same input and output type. Theseshortcomings are addressed in this paper, which presents libtx-size , a library to give size, weight, and virtual size estimatesfor transactions with arbitrary inputs, outputs, and witnesses.Although libtxsize can be used in the context of fee opti-mization, the library was developed to provide estimates thatcan serve as inputs for quantitative models whose projectionsprovide objective data to assess the impact of future improve-ments on Bitcoin’s scalability. To this end, libtxsize includessupport for the anticipated Pay-to-Taproot transaction type.This paper is structured as follows. Digital signatures, whichare used by Bitcoin to establish ownership of coins, arediscussed and investigated as to their size requirements in Sec-tion II. The formats of Bitcoin transactions and their compo-nents, such as inputs, outputs, and witnesses, are presented inSection III and studied as to their size requirements. Section IVinvestigates the dynamic components of inputs, outputs, andwitnesses, derives analytic estimates, and validates them usingempirical data. Section V discusses how libtxsize integrates thefindings of the previous sections in a bottom-up way. Finally,Section VI provides a summary and concludes the paper. II. E
NCODING OF PUBLIC KEYS AND SIGNATURES
Bitcoin uses public keys and signatures to establish own-ership of funds. So far, Bitcoin relies on the elliptic curvedigital signature algorithm (
ECDSA ) for signature verifica-tion. This, however, might change with BIP 340, whichintroduces Schnorr signatures. Both methods rely on ellipticcurve cryptography (
ECC ), and use the same elliptic curve, secp256k1 , defined in the Standards for Efficiency Cryptog-raphy (
SEC ) [4]. Despite these similarities, there are somedifferences between
ECDSA and Schnorr signatures concerningthe encoding of public keys and signatures in Bitcoin. Thesedifferences are discussed in the following.
A. Encoding of public keys1) Encoding of
ECDSA public keys: In ECC , public keyscorrespond to the x - and y -coordinates of points on an ellipticcurve. The secp256k1 curve used by Bitcoin uses 32-bytenumbers to represent the these coordinates.In case of ECDSA , these coordinates are encoded usinga standard defined in the
SEC [4]. Originally, Bitcoin onlysupported the uncompressed
SEC format. This format includesa one-byte
SEC prefix, which specifies the type of encoding(in this case, the uncompressed format), followed by the key’stwo 32-byte x - and y -coordinates. Encoding a public key inthe uncompressed SEC format thus requires 65 bytes.After some time, Bitcoin added support for the compressed
SEC format, which reduces the size of the encoding signif-icantly by taking advantage of the fact that a public key’s y -coordinate can be derived from its x -coordinate (with theexception of its sign). The compressed
SEC format thus onlyincludes a public key’s x -coordinate. The ambiguity concern-ing the y -coordinate’s sign is resolved using the SEC prefix:there are two magic numbers for the compressed
SEC format;one indicates a positive y -coordinate, the other a negative one.By getting rid of 32-byte y -coordinate, the compressed SEC format allows public keys to be encoded using only 33 bytes.Fig. 1a shows the share of uncompressed and compressedpublic keys in transactions over time. The empirical datareveals a steady decline in the use of uncompressed keys in For a given x -coordinate, the corresponding y -coordinates are obtainedby solving the secp256k1 curve’s equation y = x + 7 for y . Note that y implies two valid solutions, y and − y , which differ only with respect to sign. a r X i v : . [ c s . D C ] F e b ig. 1. (a) Public key encoding type and (b) histogram of signature sizes. Bitcoin over the years, a development presumably driven bythe reduction in fees for transactions using smaller publickeys. In fact, in the recent past the share of transactionsusing uncompressed keys has been so low that, for practicalpurposes, they can be neglected. In light of this, for thefollowing investigation, public keys are assumed to have asize of 33 bytes.
2) Encoding of public keys in Schnorr signatures:
Publickeys in Schnorr signatures also correspond to curve points. ForSchnorr signatures, however, the encoding of public keys doesnot follow the
SEC [4] standard. Instead, a custom encoding isused, which includes only a point’s x -coordinate. Ambiguityconcerning the y -coordinate is resolved using the coordinate’sparity by defaulting to the even y value. The encoding ofSchnorr public keys thus have a size of 32 bytes.
B. Encoding of signatures1) Encoding of
ECDSA signatures:
ECDSA signatures forthe secp256k1 curve consist of two 32-byte numbers, r and s , and Bitcoin’s encoding of such signatures follows theDistinguished Encoding Rules ( DER ) [5].Per
DER , each of the numbers, r and s , is prefixed by twobytes: one to encode the data type, which in case of Bitcoin issigned integer; the other to indicate the size of the followingdata—typically 32 bytes for the values r or s . So far, thismakes for a total overhead of four bytes.On top of that, there are two bytes at the beginning of each DER signature: one to indicate that the signature consists oftwo objects ( r and s ), and another to indicate the total sizeof the encoding. Finally, an additional byte at the end of thesignature indicates the signature hash type, which is used byBitcoin to determine which parts of a transaction to use whencreating a signature. Overall, this results in seven extra bytesto encode the two 32-byte values r and s .In theory, this should result in a total signature size of71 bytes. In practise, however, several points must be consid-ered. First of all, the fact that Bitcoin uses signed integers asdata type has implications on the signature size: for, whenever r or s have their most significant bit ( MSB ) set, their encodingsrequire an additional one-byte zero padding so they are notinterpreted as negative numbers. Note that values that havetheir
MSB set are also referred to as “high values,” whereasthose that have the bit not set are referred to as “low values.” The modulo of curve secp256k1 is odd, so the modulo operation mapseven numbers to odd ones and vice versa. Since the two solutions for y varyonly in sign (cf. footnote 1), one y will be even and the other odd. Originally, no restrictions applied to r and s . Assuminguniform distribution of values, each number should have its MSB set half of the time, implying a 25% chance of nopadding, a 50% chance of padding for exactly one of thevalues, and a 25% chance of padding for both values. In thiscase, signatures are expected to have an average size 72 bytes.Today, however, several restrictions apply: Bitcoin Core0.11.1 introduced the “low s ” rule, which enforces that onlytransactions with low s values are relayed. Thus, s is guaran-teed to require no padding; r , however, still requires paddinghalf of the time, leading to an average signature size of71.5 bytes. Newer implementations voluntarily implement the“low r ” optimization, and create signatures that have a low r value as well. In this case, none of the values require padding,resulting in an average signature size of 71 bytes.Finally, whenever an r or s value has eight or more of itsleading bits set to zero, the respective value can be encodedusing less than 32 bytes. The overall signature size can thusbe smaller than the previously established averages.To quantify the overall impact of the different factorsinfluencing the signature size, an analysis of empirical datais in order. The histogram in Fig. 1b shows the incidenceof different signature sizes over the course of the last twoyears. As expected, the bulk of signatures have a size of 71or 72 bytes. The slight bias toward 71 bytes can be creditedto the previously discussed “low r ” optimization of state-of-the-art implementations. Moreover, a small amount of 70-bytesignatures can be observed. These can be attributed to thepreviously discussed occurrence of leading zero bits in thebinary representation of r and s values. In fact, there are evensignatures with sizes of only 69 or 68 bytes; these, however,occur too infrequently to be visible in the histogram. The av-erage signature size according to empirical data is 71.46 bytes,which is in line with the analytically estimate of 71.5 bytesestablished previously. Thus, for the following investigation,signatures are assumed to have a size of 71.5 bytes.
2) Encoding of Schnorr signatures:
Schnorr signaturesconsist of a curve point, P , and a 32-byte value s . To savespace, the signature only contains P ’s 32-byte x -coordinatefrom which the corresponding y -coordinate can be derived(ambiguity concerning y is again addressed by implicitly usingthe y that is even). Unlike ECDSA , Schnorr signature encodingdoes not follow
DER [5]; instead, the two 32-byte values, r and s , are encoded back to back without additional metadata.The size requirement for Schnorr signatures is thus 64 bytes.III. T RANSACTION FORMAT
In the following, the general formats of transactions as wellas transaction inputs, outputs, and witnesses are discussed, andthe formats’ implications on transaction size are investigated. Creating a signature with one or more low values is done by changing therandom input used during signature creation for as long as is necessary untila signature with the desired number of low values is found.ABLE IL
OCKING SCRIPT FORMATS BY TRANSACTION TYPE . Type Locking script P PK σ p p OP _ CHECKSIGP PKH OP _ DUP OP _ HASH
160 20 h OP _ EQUALVERIFYOP _ CHECKSIG
Bare
MS OP _ m σ p p . . . σ p n p n OP _ n OP _ CHECKMULTISIG
Null Data OP _ RETURN σ d d P SH OP _ HASH
160 20 h r OP _ EQUALP WPKH OP _0 20 h p P WSH OP _0 32 h r P TR OP _1 20 h A. Transaction format
All transactions includes the following fields: a four-byteversion, two variable-length integers (varints) to indicatethe number of inputs and outputs, and a four-byte lock-time. Segregated Witness (SegWit) transaction include twoadditional bytes: a one-byte SegWit marker to indicate thatthe transaction includes witness data, and a one-byte SegWitversion. Note that no additional varint is required to indicatethe number of witnesses in the transaction, since the numberof witnesses implicitly corresponds to the number of inputs.Transaction-size estimates thus include a fixed eight-byte(or ten-byte, in case of SegWit) contribution; the size of theencodings of two varints; and the sizes of the inputs andoutputs (and, in case of SegWit, the witnesses). B. Transaction input format
From a high-level viewpoint, each transaction input com-prises two key pieces of information: a reference to an unspenttransaction output (
UTXO ) and an unlocking script that satisfiesthe locking script of the referenced
UTXO .The
UTXO reference consists of a 32-byte transaction iden-tifier (
TXID ) to reference a previous transaction, and a 4-byte position number to indicate a particular output of thereferenced transaction.Unlocking scripts have a variable size, and their contentsdepend on the type of
UTXO they are trying to spend. Scriptformats for different transaction types will be covered in thenext section; for now, it is sufficient to note that the script’ssize is encoded using a varint.Finally, each input contains a 4-byte sequence number,which is currently used for the replace-by-fee mechanism thatallows updating a transaction’s fee.To summarize, the input size is made up a fixed componentof 40 bytes, comprising the 32-byte
TXID , the 4-byte position,and the 4-byte sequence number; and a variable one, compris-ing the unlocking script and the encoding of its size.
C. Transaction output format
Transaction outputs include two key pieces of information:an amount and a locking script. A variable-length integer is a data type devised to minimize the size whenencoding non-negative integers up to a size of eight bytes. Its requires onebyte to encode values from 0 to 252; three bytes for up to 16-bit integers;five bytes for up to 32-bit integers; and nine bytes for up to 64-bit integers. TABLE IIU
NLOCKING SCRIPT FORMATS BY TRANSACTION TYPE . Type Unlocking script P PK σ s s P PKH σ s s σ p p Bare
MS OP _0 σ s s . . . σ s m s m P SH - MS d σ r r P SH - P WSH - MS σ r OP _0 32 h w P SH - P WPKH σ r OP _0 20 h p The amount of Bitcoin associated with the output is encodedusing an 8-byte integer. Like unlocking scripts, locking scriptshave a variable size, which is encoded using a varint. Thecontents of locking scripts depend on the type of output thatis created, and will be covered in the next section.The output size is thus made up of a fixed component ofeight bytes to specify the amount, and a dynamic componentcomprising the unlocking script and the encoding of its size.
D. Transaction witness format
Witnesses can serve as alternative stores for data to unlockoutputs. Each witness contains a varint to indicate the numberof items it contains. The items are of arbitrary size, so eachitem’s length is encoded using a varint as well.IV. T
RANSACTION INPUTS , OUTPUTS , AND WITNESSES
In the following, the inputs, outputs, and (where applica-ble) witnesses formats of the different transaction types areinvestigated. In each instance, the discussion begins with afirst-principles-based analysis of size requirements; based onthis, an estimate for the size requirements is derived, which isthen verified using empirical data (including historical data inBitcoin’s blockchain up until November 2020).
A. Pay-to-Public-Key1) Outputs:
The locking-script format used by Pay-to-Public-Key ( P PK ) outputs is shown in Table I, with σ p , thesize of the following public key; p , an SEC -encoded public key;and OP _ CHECKSIG , the Bitcoin Script instruction for signatureverification. The encoding of the key’s size requires one byte,the encoded key uses 33 bytes, and the Script instruction usesanother byte, leading to a total script size of 35 bytes.Together with the eight-byte amount and the one-byte varintto encode the locking script’s size, this leads to a total size of44 bytes for P PK outputs.This analytic estimate is validated by the empirical datashown in Fig. 2a, which contains a histogram of the sizesof P PK outputs. Discounting 76-byte outputs, which are anartifact from Bitcoin’s early days when public keys wereencoded using the uncompressed SEC format, all outputsmatch the analytic estimate of 44 bytes.
2) Inputs:
The unlocking-script format used by P PK inputsis shown in Table II, with σ s , the size of the followingsignature, and s , a DER -encoded signature. The encoding ofthe size of the signature requires one byte and the signatureitself requires, on average, 71.5 bytes, leading to an averagetotal script size of 72.5 bytes.
Size [bytes] I n c i d e n ce [ % ] (a) P PK outputs
100 110 120 130
Size [bytes] (b) P PK inputs Fig. 2. Histograms of P PK (a) output and (b) input sizes. Also taking into account the 40 bytes for
TXID , position,and sequence number as well as one-byte varint to encode thescript’s size, this leads to an average input size of 113.5 bytes.As before, the analytic estimate is validated by empiricaldata. Fig. 2b contains a histogram of the sizes of all P PK inputs up to Nov. 2020. As expected, more than 90% of allinputs have a size of 113 or 114 bytes and thus match theestimate. Inputs with a size of 115 bytes are artifacts from atime when the “low s ” rule was not enforced; inputs smallerthan 113 bytes can be attributed to the occurrence of encodingsof r and s with eight or more leading zero bits (cf. Sect. II-B). B. Pay-to-Public-Key-Hash1) Outputs:
Pay-to-Public-Key-Hash ( P PKH ) outputs thelocking-script format shown in Table I, with OP _ DUP , theBitcoin Script instruction to duplicate the top stack item; OP _ HASH
HASH
160 function to the top stack item; 20, the size ofthe following hash; h , a 20-byte HASH
160 of a public key; OP _ EQUALVERIFY , the Bitcoin Script instruction to makethe transaction invalid if the two top stack items differ;and OP _ CHECKSIG , the Bitcoin Script instruction to verifya signature.The four Bitcoin Script instructions and the encoding ofthe size of the hash require one byte each. Together with the20-byte hash, this leads to locking-script size of 25 bytes.Taking into account the eight-byte amount and the one-bytevarint to encode the size of the locking script, the total size of P PKH outputs is 34 bytes. As before, this analytic estimateis corroborated by empirical data, shown in Fig. 3a. The dataindicates that all P PKH outputs have a size of 34 bytes.
2) Inputs: P PKH inputs use the unlocking-script formatshown in Table II, with σ s , the size of the following signature; s , a DER -encoded signature; σ p , the size of the followingpublic key; and p , a SEC -encoded public key.The encodings of the sizes of the signature and the publickey require one byte each, whereas signature and public keyrequire 71.5 and 33 bytes, respectively, leading to an averageunlocking-script size of 106.5 bytes.Considering the 40 bytes for
TXID , position, and sequencenumber as well as a one-byte varint to encode the unlockingscript’s size, this results in an average input size of 147.5 bytes.The estimate is supported by empirical data shown inFig. 3b. As expected, the majority of inputs have a size of 147 Bitcoin defines
HASH
160 as subsequently applying the
SHA
256 and
RIPEMD
160 hashing functions to input data.
10 20 30 40
Size [bytes] I n c i d e n ce [ % ] (a) P PKH outputs
150 160 170 180
Size [bytes] (b) P PKH inputs
Fig. 3. Histograms of P PKH (a) output and (b) input sizes. or 148 bytes. As before, small deviations from the estimate canbe attributed to the
DER encoding. The second cluster around180 bytes is an artifact from Bitcoin’s early days where publickeys where encoded using the uncompressed
SEC format.
C. Bare Multi-Signature1) Outputs:
The (bare) multi-signature ( MS ) locking-scriptformat is shown in Table I, with OP _ m , indicating the numberof signatures required to satisfy the locking script; σ p i and p i ,the sizes and encodings of n public keys; OP _ n , indicatingthe number of public keys; and OP _ CHECKMULTISIG , the MS -validation Script instruction.The Script instructions contribute three bytes, the encodingof the size of each of the n public keys contributes one byte,and each public key 33 bytes. This results in a locking-scriptsize of n + 3 bytes. Together with the eight-byte amountand the one-byte varint to encode the script’s size, this resultsin a size of n + 12 bytes for m -of- n MS outputs.This analytic estimate is verified for 1-of-2 and 1-of-3 MS outputs, which together amount for more than 98% of all MS outputs. The estimates are 80 and 114 bytes, respectively. Theempirical data shown in Fig. 4a supports these estimates: thebulk of 1-of-2 and 1-of-3 MS outputs have a size of 80 and 114bytes, respectively. In each case, there is a smaller number ofoutputs that are 32 bytes larger than the estimate—artifactsfrom old transaction using the uncompressed format in whichpublic key’s include the 32-byte y -coordinate.
2) Inputs:
The MS unlocking-script format is shown inTable II, with OP _0, a dummy Bitcoin Script instruction toaddress a bug in the implementation of OP _ CHECKMULTISIG ;and σ s i and s i , the sizes and encodings of m signatures.The Script instruction contributes one byte, the encodings ofthe size of the m signatures one byte each, and each signature,on average, requires 71.5 bytes. This results in an averageunlocking-script size of . m + 1 bytes. Also consideringthe 40 bytes for TXID , position, and sequence number and
80 100 120 140
Size [bytes] I n c i d e n ce [ % ] (a) bare multisig outputs1-of-21-of-3
110 130 150 170 190
Size [bytes] (b) bare multisig inputs
Fig. 4. Histograms of bare MS (a) output and (b) input sizes. Size [bytes] I n c i d e n ce [ % ] Null Data outputs
Fig. 5. Histogram of Null Data (
OP_RETURN ) output sizes. the one-byte varint to encode the script’s size, the resultingaverage size for m -of- n MS inputs is . m + 42 bytes.The analytic estimate is verified for 1-of-2 and 1-of-3 MS variants, which together amount for more than 98% of all MS inputs. Since m =1 for both variants, they share the estimate of114.5 bytes, which is supported by the empirical data shownin Fig. 4b: as expected, the bulk of all 1-of-2 and 1-of-3 MS outputs have a size of either 114 or 115 bytes. D. Null Data1) Outputs:
The Null-Data locking-script format is shownin Table I, with OP _ RETURN , the Bitcoin Script instruction toindicate an unspendable output; σ d , the size of the followingdata; and d , the data included in the output. Note that as ofBitcoin Core 0.12.0, only 80 bytes of data are allowed.The Bitcoin Script instruction contributes one byte. Theencoding of the data’s size requires one or two bytes; and theactual data requires σ d bytes. The locking-script size is thus σ d + 2 for data smaller than 75 bytes and σ d + 3 for largerdata. Combined with the eight-byte amount and the one-bytevarint to encode the script’s size, this results in an output sizeof σ d + 11 for outputs that include up to 75 bytes of data, and σ d + 12 for outputs with more data.This analytic estimate is verified for 20- and 80-byte Null-Data outputs, which together amount for more than 90% ofall Null-Data outputs. The estimate for the former is 31 bytes;for the latter it is 92 bytes. These estimates are corroboratedby the empirical data in Fig. 5. E. Pay-to-Script-Hash1) Outputs:
The Pay-to-Script-Hash ( P SH ) locking-scriptformat is shown in Table I, with OP _ HASH
HASH
160 function; 20, the sizeof the following hash; h r , a 20-byte HASH
160 of a redeemscript; and OP _ EQUAL , the Script instruction to determinewhether the two top stack items are identical.The Script instructions and the encoding of the size of thehash contribute one byte each; together with the 20-byte hash,this results in a total locking script size of 23 bytes. Togetherwith the eight-byte amount and the one-byte varint encodingthe script’s size, this leads to an output size of 32 bytes. Thisestimate is confirmed by the empirical data shown in Fig. 6a.In contrast to fixed-size P SH outputs, the size of P SH inputs varies significantly depending on the type of redeem In Bitcoin Script, sizes between 1–75 bytes are implicitly encoded usinga single byte; larger values require a one-byte magic number to indicate anexplicitly encoded length in one, two, or four additional bytes [6].
10 20 30 40
Size [bytes] I n c i d e n ce [ % ] (a) P SH outputs
260 270 280 290 300
Size [bytes] (b) P SH -multisig inputs2-of-22-of-3 Fig. 6. Histograms of P SH (a) output and (b) P SH - MS input sizes. script included in the input. The most relevant use cases arediscussed in the following. P SH - MS inputs: The P SH - MS unlocking-scripts formatis shown in Table II, with d , data corresponding to thesignatures required to satisfy the redeem script; σ r , the sizeof the following redeem script; and r , the redeem script. Incase of P SH - MS , the data, d , follows the conventions for MS unlocking scripts documented in Table II, whereas the redeemscript, r , follows those of MS locking scripts documentedin Table I. In Sect. IV-C, the sizes for these scripts wereestablished to be . m +1 and n +3 bytes, respectively. Incase the redeem script is smaller than 76 bytes, the encodingof its size, σ r , requires one byte; in case it is larger, twobytes. The unlocking scripts used in m -of- n - P SH - MS inputsthus have a size of . m + 34 n + 5 bytes for redeem scriptssmaller than 76 bytes, and an extra byte in case of largerredeem scripts.Together with the 41-byte contribution of TXID , position,sequence number, and the encoding of the script’s size, thisleads to an estimate of . m + 34 n + 46 for redeem scriptssmaller than 76 bytes; larger redeem scripts are subject toadditional overhead (discussed in more detail in the following).These analytic estimates are verified for 2-of-2 and 2-of-3 P SH - MS inputs, which together amount for more than 90%of such inputs. For the former, n = 2 , so the estimate for theredeem script’s size is n + 3 = 71 bytes. The encoding ofthe script’s size therefore requires only one byte. For m = n = 2 , the estimate of the input’s size is thus . m + 34 n +46 = 259 bytes. For 2-of-3 P SH - MS inputs, n = 3 , and theaverage redeem-script size is n + 3 = 105 bytes, whichmeans the encodings of the redeem script’s size requires twobytes. Together with the data to satisfy the redeem script,which requires . m + 1 = 146 bytes, this leads to a totalunlocking-script size of
105 + 2 + 146 = 253 . Because varintscan only encode numbers up to 252 with a single byte, theencoding of the unlocking script’s size requires three bytes.Taking into account the contributions of the 32-byte
TXID , the4-byte position, the 4-byte sequence number, the 3-byte varintto encode the script’s size, and the 253-byte unlocking script,yields a total input size of 296 bytes.The two estimates are corroborated by empirical data inFig. 6b. Almost half of all 2-of-2 P SH - MS inputs match theestimate of 259 bytes; signatures one byte smaller or largerthan the estimate are explained by DER -encoded signaturesbeing, on average, 71.5 bytes: absent the “low r ” optimization,there is a 50% probability of generating either a 71-byte or 72- Size [bytes] I n c i d e n ce [ % ] (a) P SH - P WSH inputs
210 220 230 240 250 260
Size [bytes] (b) P SH - P WSH witnesses2-of-22-of-3
Fig. 7. Histograms of P SH - P WSH (a) input and (b) witness sizes. byte signature; for two signatures, this implies a 25% chanceof two 71-byte signatures (corresponding to inputs with a sizeof 258 bytes), a 50% chance of one 71-byte and a 72-bytesignature (resulting in 259-byte inputs), and a 25% chance oftwo 72-byte signatures (leading to 260-byte inputs).For 2-of-3 P SH - MS , too, almost half of all inputs matchthe estimate of 296 bytes. Again, around 25% of inputsare one byte larger than the estimate, which, as before, canbe explained by a 25% chance of generating two 72-bytesignatures. Another 25% of inputs have a size of 293 bytes,three bytes smaller than the estimate, which can be explainedby a 25% chance of generating two 71-byte signatures. In thisinstance, the unlocking script’s size is only 252, which meansthe script’s size can be encoded using a one-byte varint insteadof a three-byte one. The three byte deviation from the estimatethus originates from: a one-byte reduction caused by the useof two 71-byte signatures instead of the estimate of two times71.5 bytes; and two more bytes because only one byte (insteadof three) is required to encode the unlocking script’s size. P SH -Pay-to-Witness-Script-Hash- MS Inputs:
Theunlocking-script format of P SH -Pay-to-Witness-Script-Hash- MS ( P SH - P WSH - MS ) inputs is documented in Table II, with σ r , the size of the following redeem script; and the redeemscript, comprising OP _0, the Script instruction to indicate aversion zero witness program; 32, the size of the followinghash; and h w , a 32-byte SHA
256 hash of the witness script.The encoding of the redeem script’s size, the Script instruc-tion, and the encoding of the hash’s size contribute one byteeach. Together with 32-byte witness script hash, this results inan unlocking-script size of 35 bytes. Taking into account thecontribution of the 32-byte
TXID , the 4-byte position, the 4-byte sequence number, and one byte for the varint to encodethe unlocking script’s size, this results in a total input sizeof 76 bytes. This estimate is validated by the empirical datashown in Fig. 7a, which confirms all P SH - P WSH inputs havea size of 76 bytes. P SH - P WSH - MS Witnesses:
The P SH - P WSH witnessformat is documented in Table III, with n i , a varint encodingthe number of items in the witness; d , data, consisting of m signatures (following the format of MS unlocking scriptsshown in Table II) to satisfy the witness script; σ w , the sizeof the witness script; and w , a witness script, containing theparameters m and n , as well as n public keys (following theformat of MS locking scripts documented in Table I), that willbe interpreted as locking script.Note that the number of witness items and the size of the
60 70 80 90
Size [bytes] I n c i d e n ce [ % ] (a) P SH - P WPKH inputs
90 100 110 120
Size [bytes] (b) P SH - P WPKH witnesses
Fig. 8. Histograms of P SH - P WPKH (a) input and (b) witness sizes. witness script are encoded using varints, not Bitcoin scriptinstructions. In most cases, there are less than 252 items inthe witness, and the witness script is smaller than 252 bytes,so the varints encoding these typically contribute one byteeach. The contribution of the data to satisfy the unlockingscript corresponds to the estimate for MS locking scripts of n + 3 bytes established in Sect. IV-C. The witness script’scontribution corresponds to the estimate for MS unlockingscripts of . m + 1 bytes (cf. Sect. IV-C). So, in case thereare fewer than 252 items in the witness and the witness scriptis at most 252 bytes, the overall estimate for the witness is . m + 34 n + 6 bytes.The analytic estimate is verified for 2-of-2 and 2-of-3 P SH - P WSH - MS inputs, which together amount for more than 90%of such inputs. For the former, m = n = 2 , so the estimateis . m + 34 n + 6 = 219 bytes; for the latter, m = 3 and n = 2 , and the estimate is 253 bytes.The estimates are corroborated by the empirical data shownin Fig. 7b, which contains a histogram of all 2-of-2 and 2-of-3 P SH - P WSH - MS witnesses up to Nov. 2020. For both MS variants, the peak of its distribution matches the estimate. Asbefore, inputs that are one byte smaller or larger than the esti-mate can be explained by the 25% chances of creating eithertwo 71-byte signatures or two 72-byte signatures instead ofthe estimate, which uses the average of two times 71.5 bytes. P SH -Pay-to-Witness-Public-Key-Hash Inputs: Theunlocking-script format of P SH -Pay-to-Witness-Public-Key-Hash ( P SH - P WPKH ) inputs is documented in Table II, with σ r , the size of the following redeem script; and the redeemscript, comprising OP _0, the Script instruction to indicate aversion zero witness program; 20, the size of the followinghash; and h w , a 20-byte HASH
160 hash of a public key.The encoding of the sizes of the redeem script and the hashof the public key contribute one byte each. Together with theone-byte Script instruction and the 20-byte hash, this results in The fact that the public keys’ sizes are encoded with a one-byte varintinstead of a one-byte Bitcoin Script instruction does not affect the estimate.TABLE IIIW
ITNESS FORMATS BY TRANSACTION TYPE . Type Witness P SH - P WSH - MS n i d σ w w P SH - P WPKH σ s s σ p p P WPKH σ s s σ p p P WSH - MS n i d σ w w P TR (key path) 1 σ s s P TR (script path) n i d σ w w c Size [bytes] I n c i d e n ce [ % ] (a) P WPKH in- & outputsinputoutput
85 95 105 115
Size [bytes] (b) P WPKH witnesses
Fig. 9. Histograms of P WPKH (a) input and output, and (b) witness sizes. a total unlocking script size of 23 bytes. Together with the 32-byte
TXID , the 4-byte position, the 4-byte sequence number,and one byte for the varint to encode the unlocking script’ssize, this results in a total input size of 64 bytes. This estimateis validated by the empirical data in Fig. 8a, which confirmsthat all P SH - P WPKH inputs have a size of 64 bytes. P SH - P WPKH
Witnesses:
The P SH - P WPKH witnessformat is documented in Table III, with 2, to indicate twowitness items; σ s , a varint encoding the size of the followingsignature; s , a valid signature for the following public key; σ p ,a varint encoding the size of the following public key; and p ,the public key corresponding to the HASH
160 hash used in thelocking script. The three varints contribute one byte each, andthe signature and key 71.5 and 33 bytes, respectively, makingfor a total witness size of 107.5 bytes.This estimate is corroborated by empirical data shown inFig. 8b, which indicates that more than 99% of all P SH - P WPKH witnesses have a size of either 107 or 108 bytes.The bias toward 107 bytes can be explained by the fact thatthe “low r ” optimization, which results in 71-byte signaturesin comparison to the 71.5-byte average used by the estimate,was already widely used by the time P SH - P WPKH wasintroduced.
F. Pay-to-Witness-Public-Key-Hash1) Outputs:
The locking-script format of Pay-to-Witness-Public-Key-Hash ( P WPKH ) outputs is shown in Table I,with OP _0, the Script instruction to indicate a version zerowitness program; 20, the size of the following hash; and h p , a HASH
160 hash of a public key. The Bitcoin script instructionand the encoding of the hash’s size contribute one byte each,the last 20 bytes, resulting in a locking-script size of 22 bytes.Together with the 8-byte amount and 1-byte varint to encodethe script’s size, this results in an output size of 31 bytes. Thisestimate is validated by the empirical data in Fig. 9a, whichconfirms that all P WPKH outputs have a size of 31 bytes.
2) Inputs:
For P WPKH , the data to satisfy the lockingscript resides in the witness, so the unlocking script is empty. P WPKH inputs thus consist only of a 32-byte
TXID , a 4-byte position, a 4-byte sequence number, and a 1-byte varintto indicate a zero-length unlocking script. Inputs thus have afixed size of 41 bytes, a fact which is corroborated by empiricaldata shown in Fig. 9a.
3) Witnesses: P WPKH witnesses contain the same data as P SH - P WPKH witnesses (cf. Table III): 2, to indicate twowitness items; σ s and s , the size of and the corresponding
10 20 30 40
Size [bytes] I n c i d e n ce [ % ] (a) P WSH in- & outputsinputoutput
105 135 165 195 225 255
Size [bytes] (b) P WSH witnesses1-of-12-of-22-of-3
Fig. 10. Histograms of P WSH (a) input and output, and (b) witness sizes. signature; and σ p and p , the size of and the correspondingpublic key. Again, the varints contribute one byte each, thesignature and public key 71.5 and 33 bytes, respectively,resulting in a witness-size estimate of 107.5 bytes.The estimate is validated by empirical data shown in Fig. 9b,which shows that 99% of all P WPKH witnesses have a sizeof either 107 or 108 bytes. As was the case for P SH - P WPKH witnesses, the fact that SegWit was introduced after the “low r ” optimization explains the bias toward 107-byte witnesses(cf. Sect. IV-E6). G. Pay-to-Witness-Script-Hash1) Outputs:
The Pay-to-Witness-Script-Hash ( P WSH )locking-script format is shown in Table I, with OP _0, the Scriptinstruction to indicate a version zero witness program; 32, thesize of the following hash; and h w , the SHA
256 hash of awitness script. The first two items contribute one byte each,the last 32 bytes, resulting in a locking-script size of 34 bytes.Also considering the account the amount (eight bytes) andthe varint encoding the script’s size (one byte), this resultsin an output size of 43 bytes. This estimate is validated bythe empirical data in Fig. 10a, which confirms that all P WSH outputs have a size of 43 bytes.
2) Inputs:
For P WSH , the data to satisfy the locking scriptresides in the witness, so the unlocking script is empty, as wasthe case for P WPKH . Inputs thus have a fixed size of 41 bytes(cf. Sect. IV-F2). This estimate is corroborated by empiricaldata shown in Fig. 10a.
3) Witnesses:
More than 98% of all P WSH transactionsare used for MS , so the following discussion focuses on P WSH - MS . P WSH - MS witnesses contain the same data as P SH - P WSH - MS witnesses (cf. Table III). The estimate forthe witness size is thus identical as well and corresponds to . m + 34 n + 6 bytes (cf. Sect. IV-E4).In the following, this analytic estimate is verified for 1-of-1, 2-of-2, and 2-of-3 P WSH - MS witnesses, which togetheramount for more than 98% of all P WSH - MS transactions.For m = n = 1 , the estimate is 112.5 bytes; for m = n =2 , it is 219 bytes; and for m = 2 and n = 3 , 253 bytes.All estimates are supported by the empirical data shown inFig. 10b. In all instances, the observed sizes match the analyticestimates. For the latter two variants, the bias toward smallersizes can again be explained by the “low r ” optimization (cf.Sections IV-E6 and IV-F3). . Pay-to-Taproot Since Pay-to-Taproot ( P TR ) is not yet available, estimatesin this section cannot be validated using empirical data.
1) Outputs:
The P TR locking-script format is shown inTable I, with OP _1, the Script instruction to indicate a version-one witness program; 32, the size of the following hash; and p ,a 32-byte tweaked Schnorr public key. The first two items eachcontribute one, the last 32 bytes, resulting in a locking-scriptsize of 34 bytes. Adding the 8-byte amount and one-byte varintto encode the script’s size, yields an output size of 43 bytes.
2) Inputs:
The data to satisfy the locking script resides inthe witness, leaving the unlocking script empty. As in case of P WPKH (cf. Sect. IV-F2), inputs thus have a size of 41 bytes.
3) Witnesses: P TR locking scripts can be satisfied eitherby key path (i.e., by providing a valid signature for thetweaked public key in the locking script) or script path (i.e.,by providing a valid input, a corresponding witness script, anuntweaked public key, and hashes of the leaves and branchesof the Merkle tree required to determine the tree’s root).In case of the key path, P TR witnesses comprise: 2, thenumber of witness items; σ s , the size of the following Schnorrsignature; and s , a Schnorr signature. The two first items arevarints that contribute one byte each, and a Schnorr signatureuses 64 bytes in case of the default signature hash type and65 bytes in case of a custom signature hash type. Absentempirical data, the witness-size estimate will be based on theassumption that the default signature hash type is used in mostcases. The P TR key-path witness-size estimate based on thishypothesis is, therefore, 66 bytes.In case of the script path, P TR witnesses comprise: n i , thenumber of witness items; d , data to satisfy the script presentednext; σ w , the size of the following witness script; w a witnessscript to be interpreted as locking script; and c , a control block(the first byte of the control block encodes the leaf version,which in case of the script path is always 0xc0; the next 32bytes encode an untweaked Schnorr public key; finally, thecontrol block holds one or more 32-byte blocks that encodethe hashes of the leaves and branches of the Merkle tree thatare necessary to reconstruct the Merkle root used to tweak thepublic key).V. A UTOMATING TRANSACTION - SIZE ESTIMATES libtxsize integrates the previously established and empiri-cally validated analytic models to estimate the size, virtual sizeand weight of arbitrary transactions. In addition to overall esti-mates, libtxsize can provide information about a transaction’scomponents, such as the sizes of individual inputs, outputs,and witnesses, as well as transaction overhead.The library is available on GitHub and uses a bottom-up approach to create estimates: first, if necessary, the sizesof redeem and witness scripts are estimated to determinethe size requirements of the Bitcoin Script instructions andvarints that encode the lengths of such scripts; next, thescript and witness sizes are calculated, taking the results of https://github.com/virtu/libtxsize TABLE IVE
STIMATES OF COMPONENTS ( IN BYTES ) BY TRANSACTION TYPE . Type Output [B] Input [B] Witness [B] P PK
44 113.5 — P PKH
34 147.5 — P WPKH
31 41 107.5 P TR (key path) 43 41 66 P WSH - m -of- n - MS
43 41 72.5 m +34 n +6 § P SH - m -of- n - MS
32 72.5 m +34 n +46 * — P SH - P WSH - m -of- n - MS
32 76 72.5 m +34 n +6 § P SH - P WPKH
32 64 107.5
NULL DATA σ d +11 † — —Bare m -of- n - MS n +12 72.5 m +42 — § Estimate two bytes larger if witness contains more than 252 items;two more bytes required if witness script larger than 252 bytes. * Estimate one byte larger if redeem script larger than 75 bytes;two more bytes required if unlocking script larger than 252 bytes. † If σ d > bytes, the estimate is one byte larger. the previous step into account. Once the script and witnesssizes are known, the size of the Bitcoin Script instructionsand varints to encode their length are determined, and otherconstant contributions of inputs ( TXID , position, and sequencenumber) and outputs (amount) are considered. Finally, thesizes of all inputs, outputs, and witnesses are assembled,and the transaction overhead (transaction version, two varintsindicating the number of inputs and outputs, lock time, and,if applicable, SegWit marker and version) is added.The library is written in Python and exposes a Python in-terfaces to get estimates for input, output, and witnesses sizes,as well as estimates for transactions. libtxsize also includes acommand-line interface to facilitate quick experimentation.VI. R
ESULTS AND C ONCLUSION
The formats of Bitcoin transactions, inputs, outputs, andwitnesses were presented. Moreover, the sizes of differentinput, output, and witness types were investigated using first-principles analysis, from which analytic estimates were de-rived. A summary of these estimates is presented in Table IV.Furthermore, all estimates (with the exception of Pay-to-Taproot, for which no empirical data is available so far) werevalidated using empirical data.Finally, libtxsize , a library that makes the findings easily ac-cessible by automating estimates for the size, virtual size, andweight of transactions and their components, was presented.R, a library that makes the findings easily ac-cessible by automating estimates for the size, virtual size, andweight of transactions and their components, was presented.R